Description of problem: I'm running livecd-creator on fully updated Fedora 14 (as of 3rd of March 2011). livecd-creator fails to generate working f14 livecd. Booting from livecd ISO image fails with "Boot has failed, sleeping forever". Screenshot URL of the livecd boot console kernel messages here: http://pasik.reaktio.net/fedora/f14/livecd-creator/f14-livecd-boot-has-failed.jpg So basicly the kernel detects the CD drive, but it fails to mount (livecd) root. Version-Release number of selected component (if applicable): livecd-tools-14.2-1.fc14.x86_64 squashfs-tools-4.1-2.fc14.x86_64 How reproducible: Always. Steps to Reproduce: 1. (on a fully updated fedora 14 host) yum install livecd-tools 2. livecd-creator --config=f14.ks --cache=/var/cache/livecd-f14 3. boot physical machine from the ISO image. Actual results: Boot fails with "Boot has failed, sleeping forever". Expected results: Boot works and livecd-root gets mounted. Additional info: I've with and without f14 updates-repo for the livecd. kickstart-script to generate the minimal f14 livecd: # cat f14.ks lang en_US.UTF-8 keyboard fi timezone Europe/Helsinki auth --useshadow --enablemd5 selinux --disabled firewall --disabled part / --size 1024 repo --name=f14 --mirrorlist="http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-14&arch=i386" %packages @core anaconda-runtime bash kernel passwd policycoreutils chkconfig authconfig rootfiles # SELinux disabled requires this /usr/sbin/lokkit %end %post --nochroot # remove "quiet" and "rhgb" options to enable verbose startup cat $LIVE_ROOT/isolinux/isolinux.cfg | sed -e 's/ quiet //g' | sed -e 's/rhgb //g' > /tmp/test.cfg cp /tmp/test.cfg $LIVE_ROOT/isolinux/isolinux.cfg echo "echo testing testing.. " >> $INSTALL_ROOT/etc/rc.local echo "sleep 20" >> $INSTALL_ROOT/etc/rc.local %end
I think there is something missing in your ks file First check this page http://fedoraproject.org/wiki/FedoraLiveCD/LiveCDHowTo Use a kickstart from /usr/share/spin-kickstart/*.ks Then build your LiveCD based on one of those ks.
I used the example kickstart script from /usr/share/doc/livecd-tools-14.2/livecd-fedora-minimal.ks with some small additions . I'll try with /usr/share/spin-kickstarts/fedora-live-mini.ks and see how that goes.
I generated f14 livecd using non-modified /usr/share/spin-kickstarts/fedora-live-mini.ks and it fails to boot with the following errors: No root device found No root device found Boot has failed, sleeping forever. So it's the same problem as with my custom kickstart script .. Any ideas?
I did some more testing: - The generated f14 livecd images do work OK on qemu. - The generated f14 livecd images do NOT work on physical hardware. On physical hardware livecd kernel does detect the CD drive OK (as can be seen in the screenshot in the original report above) but for some reason it is not able to mount the livecd root fs. Is there any way to debug this further?
Oh, and I forgot to mention that the official (GA) Fedora 14 installer ISO image does work fine on the same physical hardware where my self-generated f14 livecd fails to mount the root fs from the cd.
OK, so you built a LiveCD based on a known kickstart file. The LiveCD creator downloads databases (sqlite files) from Fedora repositories (and mirrors). It could be that one or some database files were downloaded at the time when a mirror was synced which could have "confused" the livecd-creator. However, you could delete the local cache directory and then re-build a standard LiveCD.
(In reply to comment #6) > OK, so you built a LiveCD based on a known kickstart file. > > The LiveCD creator downloads databases (sqlite files) from Fedora repositories > (and mirrors). It could be that one or some database files were downloaded at > the time when a mirror was synced which could have "confused" the > livecd-creator. However, you could delete the local cache directory and then > re-build a standard LiveCD. Please do not speculate, have you tried to reproduce the bug?
Created attachment 482229 [details] Screenshot of a successful fedora 14 minimal build
> Please do not speculate, have you tried to reproduce the bug? I just uploaded a screen shot which shows a successful boot of a Fedora 14 minimal LiveCD. I also built a Desktop variant based on GNOME. Both LiveCDs boot in my VMware and on physical HW. I have to admit that what I wrote sounds a bit far fetched - if you just read my last post. In fact, other people had reported a similar, if not the same bug, in another bug report. https://bugzilla.redhat.com/show_bug.cgi?id=624028 Please also read comment 37 - Jeff Cook's reply https://bugzilla.redhat.com/show_bug.cgi?id=624028#c37 I am building Fedora LiveCDs almost every day. I ran into a similar issue where I could not find the root cause why my LiveCDs would not boot properly. I tried numerous scenarios but all of them failed, except one. I deleted the /var/cache/live directory, the livecd-creator's cache directory - et voilà! This solved my problem. I have to say that I had difficulties, at that time, in downloading packages from the fedora repository and mirror servers. This may have caused this issue I ran into.
I've started from scratch multiple times, ie. I've deleted the cache directory. And I've tried with and without fedora updates repo (for the livecd). And it just doesn't seem to work.. Any other ideas how to debug that? Does anaconda/plymouth/something have kernel parameters I could use to get more debug output at boot time? Thanks for the reply.
Hi, i've donwloaded a fedora 14 live iso, used liveusb creator to write on usb pen, and then the same error already reported in this thread appeared. It wasn't my first time with liveusb creator, but since F14 it's not working anymore. I've repeated the procedure several time, with no success even trying to modify the parameter root=live:UUID=xxxx in root=live:LABEL=FEDORA trick. The bug is serious, many people avoids joining Fedora cause of this bug. Thanks.
Removing the the quiet and rhgb kernel parameters should let you see more of what is happening during boot.
I already removed "quiet" and "rhgb" options.. the screenshot above shows the "full" boot messages. Does dracut/plymouth/anaconda have some options I could use to get more verbose output during livecd boot/startup?
I just tested a freshly built F14 spin (Desktop with updates-testing and the latest F14 kernel from koji) and it booted up just fine on both optical media and a USB built using livecd-iso-to-disk. So likely there is either a hardware/bios factor or liveusb-creator issue. If you are using liveusb-creator, it needs to be using a recent syslinux. If it is using something before version 4, it isn't going to work.
(In reply to comment #11) > Hi, i've donwloaded a fedora 14 live iso, used liveusb creator to write on usb > pen, and then the same error already reported in this thread appeared. > It wasn't my first time with liveusb creator, but since F14 it's not working > anymore. I've repeated the procedure several time, with no success even trying > to modify the parameter root=live:UUID=xxxx in root=live:LABEL=FEDORA trick. > The bug is serious, many people avoids joining Fedora cause of this bug. > Thanks. liveusb-creator is a separate program, used to write existing iso's to USB. livecd-creator, which this bug is about, is used to create new iso's with different or updated content. If you have a problem with liveusb-creator please file a bug against that component.
Pasi, can you upload the faulty ISO disc image file somewhere it can be downloaded and examined for errors? This at least will give us something to work with in determining your issue if it is in fact not an issue with the livecd-tools package. Upload the ISO file so it can be downloaded and tested for any error.
Pasi, I used your f14.ks file and built a minimal LiveCD. This LiveCD did not boot in my VMware as shown in the screen-shot (f14-no-boot.jpg). The boot loader configuration file isolinux.cfg is empty. Then I also rebuilt fedora-live-mini.ks from the Fedora 14 spin-kickstart package. Which resulted in a bootable LiveCD but got stuck in the boot process. I found out that the prefdm (located in /etc/X11/) tried to launch one of the supported display managers. It is a bit odd since the minimal LiveCD is not suppose to boot into a Desktop Environment so I checked the /etc/inittab for the default runlevel; it was set to runlevel 5 which is X11 (GUI). I spent some time in narrowing down the root cause until I realized the it was right in front of me... At line 11 of fedora-live-mini.ks xconfig --startxonboot This was the trouble maker (on my side). I do not know if this will solve the issue on your side. Just delete this line or comment it with a # and everything should work. The new created LiveCD runs in my VMware and on real HW.
Created attachment 482868 [details] LiveCD built based on f14.ks does not boot
Oops! Copy-Paste issue! Pasi, I was able to build a bootable LiveCD based on your f14.ks. When I copy-pasted the kickstart it accidentally wrapped a line to the next line. Screen-shot attached. It shows the firstboot. Please verify your image(s) with another VM.
Created attachment 482871 [details] LiveCD built based on f14.ks boots successfully
I've uploaded f14 custom livecd iso-image here: http://pasik.reaktio.net/fedora/f14/livecd-creator/livecd-f14-test-201103081655.iso . It doesn't have any F14 updates included. ks.cfg used to generate the iso is here: http://pasik.reaktio.net/fedora/f14/livecd-creator/f14-test.ks . that ISO boots in Qemu but it doesn't boot on physical hardware (baremetal server). Official F14 installer CD does boot OK on the same physical server. Here's the command I used to build the livecd (on a fully updated f14): livecd-creator --config=f14-test.ks --cache=/var/cache/livecd-f14-test
I also tried booting the livecd on physical server and adding "rdshell" parameter.. and thus dracut gives me a shell. From the shell I'm able to mount /dev/sr0 just fine.. so I'm just wondering why the livecd is not able to mount root..
(In reply to comment #21) > that ISO boots in Qemu but it doesn't boot on physical hardware (baremetal > server). Official F14 installer CD does boot OK on the same physical server. I downloaded your ISO image and tested it with my VMware as well as with a Core i7/QM57 (Calpella) board. Works fine in both cases. Can you share the HW spec of your server with us?
Ok, thanks for testing. My physical machine is a server with Intel Xeon 5600 series CPUs and Intel 5520 chipset. It has remote management BMC with ISO/media emulation and I'm using that to remotely boot the ISO image. But like said, on the same physical server: - Official F14 GA installer CD/DVD boots and works just fine. - Official F14 GA liveCD does NOT boot, same problem, "No root device found" ! - My custom f14 livecd boot detects the CD drive (usb remote media) but doesn't mount it.. "No root device found" ! - If I add "rdshell" kernel boot option to my custom f14 livecd I get a shell, and I can mount the CD (/dev/sr0) just fine from there. So it's just the *live* boot that fails, for both the official livecd and my custom f14 livecd.. same problem with both. It seems like it's not even trying to mount the CD in that case.. at least it doesn't give any errors about the mount attempts.. Any further ideas?
It looks like this more likely to be a dracut problem.
Seems to a CDROM drive problem.. Does USB stick booting work?
I don't think it's a CDROM problem.. like said I can mount the CD just fine when going to a shell on my custom livecd. And other CD's work (including Fedora installer CD) fine. Should I file a new bug against dracut? Any ideas how to further troubleshoot this?
(In reply to comment #27) > I don't think it's a CDROM problem.. like said I can mount the CD just fine > when going to a shell on my custom livecd. > > And other CD's work (including Fedora installer CD) fine. > > Should I file a new bug against dracut? Any ideas how to further troubleshoot > this? What do you mean by 'other CD's work'? Are you referring to - Fedora 14 Installation DVD - Fedora 14 LiveCD Both original version are working fine? If so, all versions (DVD & LiveCD including your custom LiveCD) are using dracut-006-3. If your custom LiveCD does not work properly but the Installation DVD and the original LiveCD do work then it must be something different. I would still try using a LiveUSB to make sure that it is really not related to the CDROM.
(In reply to comment #27) > I don't think it's a CDROM problem.. like said I can mount the CD just fine > when going to a shell on my custom livecd. > > And other CD's work (including Fedora installer CD) fine. > > Should I file a new bug against dracut? Any ideas how to further troubleshoot > this? Which version of dracut and udev is installed? What's the output of (in dracut rdshell): # udevadm info --query=property --name=/dev/sr0 # /lib/udev/cdrom_id --debug /dev/sr0
> > What do you mean by 'other CD's work'? Are you referring to > > - Fedora 14 Installation DVD > - Fedora 14 LiveCD > > Both original version are working fine? > - Fedora 14 Installation DVD works fine. - CentOS5 LiveCD works fine. - My custom-built f14 livecd does not work, "No root device found". - Fedora 14 (official) LiveCD does not work, same problem, "No root device found".
> > Which version of dracut and udev is installed? > in the livecd: dracut-006-3.fc14. udev version 161. > What's the output of (in dracut rdshell): > > # udevadm info --query=property --name=/dev/sr0 > # /lib/udev/cdrom_id --debug /dev/sr0 # udevadm info --query=property --name=/dev/sr0 UDEV_LOG=3 DEVPATH=/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5.3/1-5.3:1.0/host7/target7:0:0/7:0:0:0/block/sr0 MAJOR=11 MINOR=0 DEVNAME=/dev/sr0 DEVTYPE=disk SUBSYSTEM=block ID_CDROM=1 ID_CDROM_MEDIA=1 ID_CDROM_MEDIA_CD=1 ID_VENDOR=AMI ID_VENDOR_ENC=AMI\x20\x20\x20\x20\x20 ID_VENDOR_ID=046b ID_MODEL=Virtual_CDROM ID_MODEL_ENC=Virtual\x20CDROM\x20\x20\x20 ID_MODEL_ID=ff20 ID_REVISION=1.00 ID_SERIAL=AMI_Virtual_CDROM_serial-0:0 ID_SERIAL_SHORT=serial ID_TYPE=cd ID_INSTANCE=0:0 ID_BUS=usb ID_USB_INTERFACES=:080650: ID_USB_INTERFACE_NUM=00 ID_USB_DRIVER=usb-storage ID_PATH=pci-0000:00:1d.7-usb-0:5.3:1.0-scsi-0:0:0:0 DEVLINKS=/dev/block/11:0 /dev/scd0 /dev/disk/by-id/usb-AMI_Virtual_CDROM_serial-0:0 /dev/disk/by-path/pci-0000:00:1d.7-usb-0:5.3:1.0-scsi-0:0:0:0 # /lib/udev/cdrom_id --debug /dev/sr0 main: probing: '/dev/sr0' cd_inquiry: INQUIRY: [AMI ][Virtual CDROM ][1.00] info_scsi_cmd_err: GET CONFIGURATION failed with SK=5h/ASC=20h/ACQ=00h cd_profiles: drive is pre-MMC2 and does not support 46h get configuration command cd_profiles: trying to work around the problem info_scsi_cmd_err: READ DISC INFORMATION failed with SK=5h/ASC=20h/ACQ=00h cd_profiles_old_mmc: no current profile, but disc is present; assuming CD-ROM cd_media_toc: READ TOC: len: 12, start track: 1, end track: 1 cd_media_toc: last track 1 starts at block 0 info_scsi_cmd_err: READ DISC INFORMATION failed with SK=5h/ASC=20h/ACQ=00h ID_CDROM=1 ID_CDROM_MEDIA=1 ID_CDROM_MEDIA_CD=1 Note that "mkdir /mnt && mount /dev/sr0 /mnt" works OK in rdshell !
Any ideas what to try?
(In reply to comment #31) > cd_inquiry: INQUIRY: [AMI ][Virtual CDROM ][1.00] > info_scsi_cmd_err: GET CONFIGURATION failed with SK=5h/ASC=20h/ACQ=00h > cd_profiles: drive is pre-MMC2 and does not support 46h get configuration > command > cd_profiles: trying to work around the problem > info_scsi_cmd_err: READ DISC INFORMATION failed with SK=5h/ASC=20h/ACQ=00h > cd_profiles_old_mmc: no current profile, but disc is present; assuming CD-ROM > cd_media_toc: READ TOC: len: 12, start track: 1, end track: 1 > cd_media_toc: last track 1 starts at block 0 > info_scsi_cmd_err: READ DISC INFORMATION failed with SK=5h/ASC=20h/ACQ=00h > ID_CDROM=1 > ID_CDROM_MEDIA=1 > ID_CDROM_MEDIA_CD=1 > Here is the problem... The virtual CDROM implements the "READ TOC" SCSI command in a broken way. It does not return details about the tracks on the CDROM. So, you would need a cdrom_id workaround. Could you try these udev packages? http://people.redhat.com/harald/downloads/udev/udev-147-2.35.el6/
Thanks! I'll try that. Just to make it sure: I install that udev version to the livecd filesystem, I assume udev for the boot image is fetched from there?
Harald: That el6 version of udev 147 works OK ! No problems mounting the livecd with that udev version. I rebuilt that udev 147 el6 src.rpm for f14 and then I did some ks install script %post hackery to "update" udev to 147 el6 version when generating livecd and to re-generate initramfs image and copy it over to isolinux/initrd0.img and now the generated f14 livecd works fine! So udev in fedora requires a workaround for this "READ TOC" issue! Here's the hackery I used to "update" to 147 udev in f14 livecd: # copy udev update for testing.. %post --nochroot cp -a /root/udev/rpm/libudev-147-2.35.fc14.i686.rpm $INSTALL_ROOT/tmp/ cp -a /root/udev/rpm/libgudev1-147-2.35.fc14.i686.rpm $INSTALL_ROOT/tmp/ cp -a /root/udev/rpm/udev-147-2.35.fc14.i686.rpm $INSTALL_ROOT/tmp/ %end # install udev update %post echo "Installing updated udev rpms.." rpm -Uvh --nodeps --force /tmp/libudev-147-2.35.fc14.i686.rpm /tmp/udev-147-2.35.fc14.i686.rpm /tmp/libgudev1-147-2.35.fc14.i686.rpm echo "done installing udev update." echo "Re-generating kernel initramfs image.." /sbin/dracut -f /boot/initramfs-2.6.35.6-45.fc14.i686.img 2.6.35.6-45.fc14.i686 echo "Done re-generating initramfs." %end # update isolinux/initrd0.img %post --nochroot echo "Copying new initramfs image to isolinux directory.." cp -af $INSTALL_ROOT/boot/initramfs-2.6.35.6-45.fc14.i686.img $LIVE_ROOT/isolinux/initrd0.img echo "Done copying initramfs." %end Thanks a lot!
udev "READ TOC" bug is tracked here: https://bugzilla.redhat.com/show_bug.cgi?id=690181 .
(In reply to comment #36) > udev "READ TOC" bug is tracked here: > https://bugzilla.redhat.com/show_bug.cgi?id=690181 . are you sure this is the same bug? are you using a iscsi cdrom?
Not totally sure.. I'm using virtual CDROM drive provided by the management processor in the server. Linux does see it as USB CDROM drive. Anyway udev-147-2.35.el6 works OK, while the 161 version in Fedora 14 fails to identify the livecd disc/iso.
(In reply to comment #38) > Not totally sure.. I'm using virtual CDROM drive provided by the management > processor in the server. Linux does see it as USB CDROM drive. exactly.. bug#690181 is about cdrom over iscsi, I think. So your bug is the incomplete READ TOC implementation of the virtal CDROM provided by the management processor in the server. So the server software is to be blamed.
Yes, the root cause is the buggy virtual cdrom drive in the server. But when it works just fine with another versions of udev, workaround should be added to udev. I'm pretty sure this affects many users. Note that for example CentOS5 livecd works just fine ! Also Fedora 14 official installer CD is happy with that virtual cdrom drive.
*** Bug 698444 has been marked as a duplicate of this bug. ***
Should I open a new bug against udev so that workaround for this problem can be included in udev?
I just reassigned it.
Great, thanks. Comment #31 has all the info about the virtual cdrom drive (provided by the server ipmi/bmc management processor). Summary: udev-147-2.35.el6 works OK, ie. "READ TOC" works OK, and f14 version of udev fails to identify the CD.
Is it expected that udev in F15 beta behaves differently? Should I try to generate a livecd based on F15 beta and try it on that server and see if F15 udev is able to identify the CD ?
(In reply to comment #45) > Is it expected that udev in F15 beta behaves differently? Should I try to > generate a livecd based on F15 beta and try it on that server and see if F15 > udev is able to identify the CD ? no, the bug is still there (upstream). I discussed it already with the udev author.
Any workarounds found for the udev "READ TOC" issue? Thanks.
Any updates? should I try with F15 ? (was there any related changes in udev in f15 ?)
Ping ?
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping