Bug 491356 - Failed to start array (RAID0) with root fs - udev related portion
Failed to start array (RAID0) with root fs - udev related portion
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
rawhide
x86_64 Linux
high Severity urgent
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
:
Depends On: 490972
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-20 11:28 EDT by Doug Ledford
Modified: 2009-03-20 13:04 EDT (History)
7 users (show)

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


Attachments (Terms of Use)

  None (edit)
Description Doug Ledford 2009-03-20 11:28:17 EDT
--- Additional comment from dledford@redhat.com on 2009-03-20 11:24:32 EDT ---

Made some progress on this.  If I change rc.sysinit to have a udevadm trigger call before the udevadm settle call, all works (the udevadm settle call in rc.sysinit is not in the official package yet, but it replaces the mdadm -As line in rc.sysinit right before lvm startup).  However, the call to start_udev a few lines above *also* has a udevadm trigger call in it, and that *should* be sufficient.  So there is a question as to why calling udevadm trigger *again* only a few lines later works.  I'm going to clone this bug against udev in rawhide to see if we can address that part of the issue.

The specific thing to note is that the mdadm supplied 65-md-incremental.rules file is *not* being run by the udevadm trigger call in start_udev, but when we make the call a few lines later in rc.sysinit, it does get run and arrays get started properly.
Comment 1 Doug Ledford 2009-03-20 13:04:03 EDT
OK, I've isolated the problem, and udev is *not* the culprit, sorry for the false bug report.  (The problem is that the / fs is ro at the time udev_start runs and this screws up mdadm which wants to write to /var/run/mdadm/mdadm.map)

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