2018-01-17 19:05 CET

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0001867openmediavaultBugpublic2017-12-15 21:16
Reportersubzero79 
Assigned Tovotdev 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
Platformx86OSdebianOS Version9.3
Product VersionArrakis (4.x) 
Target VersionFixed in VersionArrakis (4.x) 
Summary0001867: RaidMgnt service doesn't exclude device mapper volumes (OMV4)
DescriptionI just realised by using the zfs plugin (which uses RaidMgnt->getCandidates) that some devices that are used, have fs and referenced are displayed there to be used to create an vdev's. Same happens if i go to raid and try to create a md device. The problem is with device mapper, for example devices that are encrypted and mapped to /dev/mapper/, omv uses path /dev/dm-X (dm-0, dm-1, etc) to check them with blkid

From what i see in the function getCandidates it checks if device has a fs with hasFilesystem. This function calls blkid for all devices and greps per device. something like

blkid | grep -E '^/dev/sdb.*:.+\sTYPE=.+$'

Now in this testing VM the blkid outputs this

/dev/sdb1: UUID="752dee88-11a3-4524-848e-d50baf0211a2" TYPE="ext4" PARTUUID="90be8dfe-01"
/dev/sdb5: UUID="42085c24-f740-4d24-b64d-4f5ccd81ea98" TYPE="swap" PARTUUID="90be8dfe-05"
/dev/sdg1: LABEL="zdata" UUID="700788198549427404" UUID_SUB="15825917686293877084" TYPE="zfs_member" PARTLABEL="zfs-c4a35f9f269f780f" PARTUUID="d09b998d-35f0-9a4a-ac20-b2c0fd0e207d"
/dev/sdj1: UUID="ce89cfc9-a3f2-4529-b3c0-9422462458b8" TYPE="ext4" PARTUUID="9d0e85ea-f6f8-46c9-9ea7-33f738fb2116"
/dev/sdh: UUID="d60240ea-d93b-4a30-ad46-99eebd6921b6" TYPE="crypto_LUKS"
/dev/sdi: UUID="31e4637e-89b4-4a21-9d22-58c75f168036" TYPE="crypto_LUKS"
/dev/sdk1: UUID="1582f2be-7a16-4190-9cfa-d987a19e3c72" TYPE="ext4" PARTUUID="113b2676-01"
/dev/mapper/sdh-crypt: UUID="8ae74023-1720-4a36-bdb4-7c4e8b0940bf" TYPE="ext4"
/dev/mapper/sdi-crypt: UUID="caae118c-031e-4e9d-819a-4f1b9c35df80" TYPE="ext4"
/dev/sde1: PARTLABEL="zfs-e19d7c02a611799e" PARTUUID="d8b94c2b-3905-794e-a186-1b67ea372911"
/dev/sde9: PARTUUID="9addb50c-1dbb-314a-9a01-8fb3e2f2754e"
/dev/sdf1: PARTLABEL="zfs-50d050c05649d665" PARTUUID="51bbc6b9-79b1-1348-8a18-8f97514c0918"
/dev/sdf9: PARTUUID="ad72d050-5048-1740-b38a-4e4d61022cc8"
/dev/sdd1: PARTLABEL="zfs-5b4446bee05b38f7" PARTUUID="2fadec09-e1c6-d647-af9c-81e96fe45d59"
/dev/sdd9: PARTUUID="cc404bcc-b061-2f40-afc6-bd43eb3d40d1"
/dev/sdc1: PARTLABEL="zfs-5938add33ba6e58d" PARTUUID="021905da-9341-f043-baf4-cab36a806eea"
/dev/sdc9: PARTUUID="4a122f08-f9cf-3a43-a325-80870dfa998e"
/dev/sdg9: PARTUUID="258eaabc-1524-4a48-976e-eab8a1267d5b"

Problem is dm-X doesn't get displayed at general blkid, but the mapped name does. omv in this case greps using dm-X

ls -la /dev/mapper
total 0
drwxr-xr-x 2 root root 100 Dec 14 09:23 .
drwxr-xr-x 18 root root 3660 Dec 14 09:23 ..
crw------- 1 root root 10, 236 Dec 14 09:22 control
lrwxrwxrwx 1 root root 7 Dec 14 09:22 sdh-crypt -> ../dm-0
lrwxrwxrwx 1 root root 7 Dec 14 09:23 sdi-crypt -> ../dm-1

now if we check blkid per device it returns the fs signature

blkid /dev/dm-0

root@debian9:/dev# blkid /dev/dm-0
/dev/dm-0: UUID="8ae74023-1720-4a36-bdb4-7c4e8b0940bf" TYPE="ext4"

Additional InformationThis same situation happens if you use the LVM plugin. Create a LV, create fs on top, mount it.

I haven't tested this yet in omv3 (debian8)

i've attached some screenshots also
TagsNo tags attached.
Product build
Attached Files

-Relationships
+Relationships

-Notes

~0005071

subzero79 (reporter)

Just a quick test modifying filesystem.inc hasFilesystem to

$cmdArgs = [];
$cmdArgs[] = escapeshellarg(sprintf("%s",realpath($deviceFile)));
$cmd = new \OMV\System\Process("blkid", $cmdArgs);

Returns the devices with no fs signature

~0005073

votdev (administrator)

Fixed in openmediavault 4.0.15, see https://github.com/openmediavault/openmediavault/commit/e1aad037b9a5e02a7f739744b6c67748e973a07e.
+Notes

-Issue History
Date Modified Username Field Change
2017-12-14 02:01 subzero79 New Issue
2017-12-14 02:01 subzero79 Status new => assigned
2017-12-14 02:01 subzero79 Assigned To => votdev
2017-12-14 02:01 subzero79 File Added: Screenshot_2017-12-14_10-57-44.png
2017-12-14 02:01 subzero79 File Added: Screenshot_2017-12-14_10-57-27.png
2017-12-14 02:21 subzero79 Note Added: 0005071
2017-12-15 21:16 votdev Status assigned => resolved
2017-12-15 21:16 votdev Resolution open => fixed
2017-12-15 21:16 votdev Fixed in Version => Arrakis (4.x)
2017-12-15 21:16 votdev Note Added: 0005073
2017-12-15 21:16 votdev Product Version Erasmus (3.x) => Arrakis (4.x)
2017-12-15 21:16 votdev Product build 4.0.14-1 =>
+Issue History