Red Hat Bugzilla – Bug 453686
udev doesn't run volume id on whole block devices, causing mdadm --incremental to not run
Last modified: 2009-07-15 04:15:41 EDT
+++ This bug was initially created as a clone of Bug #447818 +++
-- Additional comment from email@example.com 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 firstname.lastname@example.org 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:
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 email@example.com 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 firstname.lastname@example.org 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
# rpm -q udev
# 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:
Thanks Harald, will give it a go...
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:
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.