Red Hat Bugzilla – Full Text Bug Listing
|Summary:||udev doesn't run volume id on whole block devices, causing mdadm --incremental to not run|
|Product:||[Fedora] Fedora||Reporter:||Doug Ledford <dledford>|
|Component:||udev||Assignee:||Harald Hoyer <harald>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-07-15 04:15:41 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Doug Ledford 2008-07-01 18:29:23 EDT
+++ This bug was initially created as a clone of Bug #447818 +++ -- Additional comment from firstname.lastname@example.org on 2008-06-29 00:39 EST -- Sorry but mdadm-2.6.7-1.fc9 does not fix the problem. 1. The udev rule will only fire if the array is composed of partitions with a type of 'fd'. I.E. The block devices sdb and sdc each have a partition table with a partition set to 'fd', then the array is composed of sdb1 and sdc1. The udev rule does NOT fire if the array is composed of the sdb and sdc devices directly because the rule looks for a fs type of "linux_raid*". -- Additional comment from email@example.com on 2008-07-01 17:09 EST -- (In reply to comment #14) > Sorry but mdadm-2.6.7-1.fc9 does not fix the problem. > > 1. The udev rule will only fire if the array is composed of partitions with a > type of 'fd'. I.E. The block devices sdb and sdc each have a partition table > with a partition set to 'fd', then the array is composed of sdb1 and sdc1. The > udev rule does NOT fire if the array is composed of the sdb and sdc devices > directly because the rule looks for a fs type of "linux_raid*". I don't have a spare disk to remove the partition table on and test this, but I did test this by trying to see how udev responded to loopback devices that had no disk partition on them. In that case, udev was smart enough to know it was a linux raid device *without* a partition table, and without a partition table type of 0xfd. Instead, it was reading from the disk and looking for a raid superblock (I specifically test version 0.90 and 1.1 superblocks and it found both types, and it even changed ID_FS_VERSION to match the raid superblock type). You can duplicate my tests yourself by running: /lib/udev/vol_id /dev/<devicename> and checking the output. If you could please run the above command on a whole disk device under your setup and verify whether or not it correctly identifies the whole disk device, I would appreciate it. -- Additional comment from firstname.lastname@example.org on 2008-07-01 18:15 EST -- Still 2 strikes but I've got some additional info... The udev rule does not fire for raw block devices I think because nothing ever triggers vol_id to run. When I do a udevadm --test /block/sdb/sdb1, I can see in the output that vol_id is run and ID_FS_TYPE is set correctly to linux_raid_member. I can also see the mdadm rule run. When I do the same test on /block/sdb, vol_id is never run so ID_FS_TYPE is not set and mdadm is not run. It looks like 60-persistent-storage.rules only runs vol_id for partitions. -- Additional comment from email@example.com on 2008-07-01 18:24 EST -- Thanks for checking on that. So, for the first issue, I don't think that's an mdadm or md raid bug if udev is configured not to run vol_id on whole block devices. I know the upstream maintainer of mdadm/md kernel driver actually prefers running his raid arrays on the bare block devices, so I think that's something that needs to be supported. However, I could also imagine that udev might have problems with whole disk devices and hitting false positive matches, which might be why they only do partitions. I think it's something that needs a new bug under the udev component, so I'll go ahead and clone this bug for that purpose.
Comment 1 Harald Hoyer 2008-07-02 04:03:40 EDT
# rpm -q udev udev-124-1.fc10.i386 # udevtest /block/sda ... run_program: 'vol_id --export /dev/.tmp-8-0' run_program: '/lib/udev/vol_id' (stderr) '/dev/.tmp-8-0: unknown volume type' run_program: '/lib/udev/vol_id' returned with status 4 ... You may try: https://admin.fedoraproject.org/updates/F9/FEDORA-2008-5442
Comment 2 Doug Ledford 2008-07-02 10:36:17 EDT
Thanks Harald, will give it a go...
Comment 3 Bug Zapper 2009-06-09 21:52:26 EDT
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 4 Bug Zapper 2009-07-15 04:15:41 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.