Any of the recently nightly live media don't appear to boot correctly.
They get a:
No root device found
Boot has failed, sleeping forever.
I tried to poke around with rdshell and initdebug, but I wasn't sure what to look for. ;(
I did see running the /cmdline/* scripts was giving a 'getarg' unknown error, but not sure if that was just the way I was calling it or not.
Happy to gather more info, or you can try yourself with any of the nightly composes at:
Same here for quite a while now (since before dracut-006-1.fc14).
I guess, this is with a qemu VM.
See bug 609049
works, if you replace root=live:CDLABEL=..." with "root=live:/dev/sr0"
As another data point I was able to sucessfully boot both a live DVD and a live USB version of the games spin using games-i386-20100625.15.iso from the nightly compose page.
(In reply to comment #2)
> works, if you replace root=live:CDLABEL=..." with "root=live:/dev/sr0"
So it could be fixed in livecd-tools?
(In reply to comment #4)
> (In reply to comment #2)
> > works, if you replace root=live:CDLABEL=..." with "root=live:/dev/sr0"
> So it could be fixed in livecd-tools?
no... fixing qemu would be the correct way
Ok, thanks for investigating carefully.
Do we leave this open or make it a duplicate of bug 609049 then?
Will it also require changes to dracut?
(In reply to comment #6)
> Ok, thanks for investigating carefully.
> Do we leave this open or make it a duplicate of bug 609049 then?
yes, maybe "duplicate" is better than "depends"
> Will it also require changes to dracut?
No, once qemu can handle the scsi command this bug is fixed.
*** This bug has been marked as a duplicate of bug 609049 ***
Nice fix for qemu! https://bugzilla.redhat.com/show_bug.cgi?id=609049#c1
I am not sure that this is the same bug but last nightly-composes live media doesn't boot also in vmware. Parameter "root=live:/dev/sr0" doesn't help.
Here error messages what I saw:
I also tried to write iso on USB with livecd-iso-to-disk and boot on real hardware from USB. The same result was with the same error messages.
In reply to Comment 9
That is bug 619020 which we believe has been corrected, as of August 2nd/3rd.