Bug 757361

Summary: dracut reports on boot: Waiting for /dev/md127 to become clean
Product: [Fedora] Fedora Reporter: Peter Bieringer <pb>
Component: dracutAssignee: dracut-maint
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 16CC: dracut-maint, jonathan, kas, mpreisle, ncjeffgus, universe6
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: dracut-013-20.fc16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-14 23:35:51 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Peter Bieringer 2011-11-26 17:28:27 UTC
Description of problem:
After booting after updates, dracut reports

dracut: Waiting for /dev/md127 to become clean

(which means wait for over 1 hour until system is usable)


Version-Release number of selected component (if applicable):
kernel-3.1.2-1.fc16
dracut-013-19.fc16.noarch


How reproducible:
After every reboot until finally the RAID is resynced


Expected results:
Booting with background resync


Additional info:
kernel-3.1.1-2.fc16 with older ramdisk still behaves fine


Is there any workaround known to disable 

/usr/share/dracut/modules.d/90mdraid/mdraid-waitclean.sh

in the ramdisk somehow or make this at least optional?

Comment 1 universe6 2011-11-27 18:35:24 UTC
Just installed fedora 16 (bios boot and boot partition non raid, swap and encrypted LVM PV on raid1, LVM group with four LVs tmp, root, home and var).

I got exactly the same situation/kernel. 750Gb is going to take a long time I guess.





PS (unrelated)

So far the fedora 16 installation experience has been pretty bad.

First I tried preupgrade (from f15). Didn't work because var on different partition ...

Then I tried a new installation, but anaconda couldn't handle dual monitors apparently (worked fine with f15)

Then I installed /boot on raid, but didn't work either (grub2 no such disk found).

Reinstalled and put on /boot non raid. grub2 works, but run into the dracut problem above ...

:-)

Comment 2 Peter Bieringer 2011-11-27 19:02:33 UTC
My current workaround: unpack initramfs, remove lib/dracut/hooks/pre-mount/10dmraid-waitclean.sh, and repack initramfs

Comment 3 Martin Preisler 2011-12-10 15:41:23 UTC
Just got bitten by this today after a power outage. I run RAID1 specifically to avoid outages as much as possible, waiting for the array to be synched means waiting for 2+ hours with no way to get anything done.

I had to run an older kernel to get the system going.

Peter's workaround works as expected, I didn't notice any harmful side effects.

My platform is x86_64, so this isn't i686-only.

Comment 4 Jan "Yenya" Kasprzak 2011-12-11 10:08:56 UTC
Changing arch to all. This is pretty bad - I have to drive to the server room today in order to discover the server has been waiting for its 4-way RAID-10 array to become synced.

Comment 5 Fedora Update System 2011-12-13 11:45:16 UTC
dracut-013-20.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/dracut-013-20.fc16

Comment 6 Fedora Update System 2011-12-13 21:51:07 UTC
Package dracut-013-20.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dracut-013-20.fc16'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-17051/dracut-013-20.fc16
then log in and leave karma (feedback).

Comment 7 Fedora Update System 2011-12-14 23:35:51 UTC
dracut-013-20.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.