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): rawhide-20080314 livecd
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
Bill, 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 with: 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 searching. And let me know if it would be useful to get any characterizations from another actual hardware machine that hits the bug. -Carl
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.