This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 453686 - udev doesn't run volume id on whole block devices, causing mdadm --incremental to not run
udev doesn't run volume id on whole block devices, causing mdadm --incrementa...
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
9
All Linux
low Severity high
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 447818
  Show dependency treegraph
 
Reported: 2008-07-01 18:29 EDT by Doug Ledford
Modified: 2009-07-15 04:15 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-15 04:15:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Doug Ledford 2008-07-01 18:29:23 EDT
+++ This bug was initially created as a clone of Bug #447818 +++


-- Additional comment from george.joseph@fairview5.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 dledford@redhat.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 george.joseph@fairview5.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 dledford@redhat.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.

Note You need to log in before you can comment on or make changes to this bug.