Description of problem:
Doesn't find the root volume correctly. However, all I need to do is run:
echo "add" > /sys/block/sr0/uevent
and exit the shell, and it's OK.
Version-Release number of selected component (if applicable):
Happens on a i965 ahci box. Doesn't happen on a plain-IDE box using ata_piix.
Hmmm, doesn't happen in kvm for me either which is going to make this a little
trickier to debug :-/
I wonder if we're losing the uevent and if Harald's recent changes to add more
debugging would help track it down
I saw this problem on a kvm with a LVM partition as a virtual harddisk...
debugging only helps in start_udev
I rebuilt a livecd with some udev debugging, but it was really too much noise to
filter through. So far it fails on one box, but works on another (and in KVM.)
So, this appears to be a kernel bug. udev gets the uevent for /dev/sr0, and
attempts to run vol_id on the device:
/dev/.tmp-11-0: error opening volume: No mediun found
I suspect the initial uevent needs to be delayed until the inital medium scan is
done, at least until we can get reliable uevents for medium changes.
Reproduced on real hardware. Yeah, I don't know that we can really do anything
about this in the initrd (well, unless we make all calls to vol_id run sleep
first) or something crazy like that
Thanks for the workaround in this bug report.
I just tried booting the F9 Beta Live CD for the first time and the boot halted
WARNING: Cannot find root file system!
Create symlink /dev/root and then exit this shell to continue the boot sequence.
I looked around for an existing bug report, but failed to find any. Luckily
David Zeuthen pointed me to this bug report. At first I thought the workaround
didn't work, but then I found that if I waited for a while between the echo and
the exit that it all worked.
Hopefully my comment here might make the bug report easier for others to find in
And let me know if it would be useful to get any characterizations from another
actual hardware machine that hits the bug.
Awful terrible hack for the initrd pushed to git that should work around this
maybe fixed with udev-120, because a lot of rules now react on 'change' (dunno,
if the kernel sends an event here)
Between new udev and my hack, I was at least able to boot on the box that I
couldn't before. Bill -- how about on yours?
Works with 0411.