Bug 624028
| Summary: | livecd-creator creates iso that doesn't boot | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Rex Dieter <rdieter> | ||||||||
| Component: | livecd-tools | Assignee: | Brian Lane <bcl> | ||||||||
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
| Severity: | medium | Docs Contact: | |||||||||
| Priority: | low | ||||||||||
| Version: | 13 | CC: | adam.stokes, bruno, danishka, david.brown, dhuff, dowdle, jan.kratochvil, Jasper.Hartline, jeff.the.cook, katzj, Marc.Herbert+rhzilla, orion, osoriojr, pasik, richard.dorsch, sagarun, satellitgo, wtogami | ||||||||
| Target Milestone: | --- | Keywords: | Reopened | ||||||||
| Target Release: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | Linux | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: | Story Points: | --- | |||||||||
| Clone Of: | Environment: | ||||||||||
| Last Closed: | 2011-06-28 14:37:04 UTC | Type: | --- | ||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Embargoed: | |||||||||||
| Attachments: |
|
||||||||||
This might be due to a long standing squashfs bug recently fixed for F14. The fix hasn't been backported to F13 yet (though it's on my list of things to do). You could try using squashfs 4.1 from F14 and see if that solves the problem for you. thanks! I'll try that. built squashfs-tools-4.1-0.3.20100803 for f13, and it seems to work like a champ. Thanks for the feedback. I am going to close this as it isn't really a livecd-tools bug. This does provide more evidence that I need to get a fix backported to F13 and F12. I'll probably end up cherry picking the patch though, as 4.1 hasn't actually been finalized yet and I don't want to bring it back to F13 or F12 before that happens, unless it can't be avoided. ugh, the plot thickens. I tried generating a live image enabling updates-testing repo, and booting fails again. :( The same way or differently? There were some recent udev related changes that caused some issues, though I don't know if they would affect live images. I think a fix was available, though I am not sure what its status is. Come to think of it, if you are using an F14 repo, it might be the splash image bug. The location of splash images changed in F14 and that breaks live images. A fix is in the F14 version of livecd-tools, but the fix hasn't been back ported yet. (I was on vacation recently, and these changes happened shortly before I left, so there were some loose ends that still needed to be taken care of.) So if you want you can try the F14 version of livecd-tools. A fix will be available for F13 and possibly F12 at some point, but we are leaning to doing a full upgrade rather than cherry picking a few patcghes, and I want to wait until the next patch rollup before doing an F13 build. As far as I know 033-3 could be pushed to F13. No need to cherry pick this early in livecd-tools stages with less than complicated patches. Also about a rollup, there are at least 6 which could be introduced which some are only relevant to F14 because of syslinux 4.02, but I don't see how that actually helps you to wait until the next patch rollup unless you make sure to only rollup a few patches that only F13 can handle. Also, there are 3 major bugs which will cause some behavior like this: 1) Qemu/KVM doesn't implement SCSI CDROM 0x51 command Requires: udev-160-9 2) SquashFS bug, memcpy() to memmove() Requires: SquashFS Tools built around August 3rd or 4th. 3) Syslinux splash missing Requires: livecd-tools-033-3 If the bug reporter could give more information to exactly what he is seeing, before the unable to mount root device error, or in more detail what it is he is seeing, this will help pinpoint what he is seeing if it isn't a new bug uncovered. Can the original bug reporter provide some more information? OK, full details as I know them now, after some more experimentation. My observation of the failure is: boot splash, then a plymouth progress bar, then very shortly into plymouth animation, get the error: No root device found Boot has failed, sleeping forever. I had previously upgraded to livecd-tools-033-3, but that alone didn't help. Then up'd to squashfs-tools-4.1-0.3.20100803 Interestingly, there be another variable here. my first attempts tried to enable updates-testing repo (to get the new kernel there). Even after these updates, to livecd-tools and squashfs-tools, still didn't work. fail Out of paranoia, I then tried disabling updates-testing. success. next try, was adding a custom repo with kernel-2.6.34.3-37.fc13 (the version currently in updates-testing). success. I'm tempted to try again, re-enabling updates-testing and/or try to biset what's in updates-testing causing problems here (unless there's other suggestions to try at this point). autopsy on irc suggested I try reproducing the failure removing kernel boot options: rhgb quiet I'll try to do that (soon). As a side note I have a 4.0 version of squashfs with a backported fix for the large inode issue built for F13. I have requested a push to testing and it should show up there soon. Wrt comment #10 and a newer udev, does that need to be on the image created or on the host creating the live image (or both)? If you are using Qemu virt the newer udev needs to be in the target LiveCD which you are trying to boot up. (The image created) I installed squasfs-tools 4.1, still i am not able to boot the created iso. In reply yo Comment 17 Can you upload your ISO somewhere so that we can take a look at it? Also describe which version of livecd-tools you are using and what repository tree you're using to build your livecd from, and the kickstart files which you're using. I can boot the ISO from Virtualbox, but not with virt-manage; Again when trying to install the ISO from virtualbox anaconda complains that i have to reinitialize the harddisk after clicking reinitialize button anaconda crashes! Here is the kick start file http://psgkriya.org/saga/misc/msec-fedora-remix.ks ISO file is 1.7G, given the network bandwidth i have , i can't upload it right now. Ok this is not a livecd-creator or ISO bug. This is probably a virt-manager or Anaconda bug, in what you are describing. See item 1 in comment #10 (probably needs a newer udev) I turned off graphical boot... and it didn't change much. The error is: No root device found Boot has failed, sleeping forever. What precedes the error is: dracut: Scanning devices vda2 for LVM volume groups dracut: Reading all physical volumes. This may take a while... dracut: Found volume group "vg_montanalinux32" now active I'll try to making a custom updates repo rather than using the stock one... and put back the previous release of udev to see reverting back helps. Ok, I reverted back to udev-151-10.fc13 for my livecd-creator built OS and it boots under KVM fine now.... so with regards to post #10... Switching to the newer livecd-tools didn't help... but switching to that AND reverting back one release of udev did. Perhaps just the udev part would have fixed it but I haven't tried that. (In reply to comment #23) > Ok, I reverted back to udev-151-10.fc13 for my livecd-creator built OS and it > boots under KVM fine now.... so with regards to post #10... > > Switching to the newer livecd-tools didn't help... but switching to that AND > reverting back one release of udev did. Perhaps just the udev part would have > fixed it but I haven't tried that. What about anaconda? It still crashes? (In reply to comment #24) > What about anaconda? It still crashes? To clarify, I'm not using the Fedora update repo because it contains newer versions of things that are broken on Fedora 13. I created my own private update repo... added in all of the updates accept for packages known to cause breakage... and put in the previous releases of those instead. The previous releases I used were: dbus-glib-0.86-3 NetworkManager-0.8.1-1 NetworkManager-glib-0.8.1-1 NetworkManager-gnome-0.8.1-1 udev-151-10 Now I have an iso that will build, boot, and install. Who'da thunk? But seriously we appear to know what the problems are... and many if not all of the fixes are available in the F14 packages... which we can't use on Fedora 12 and 13 because they want to drag in a zillion F14 dependencies which would end up producing a Frankenstein if they produced anything at all. Those who maintain the packages appear to be unwilling, for what whatever reasons, to back-port the fixes. Let's hope this situation changes. (In reply to comment #25) The problem discussed above, "No root device found Boot has failed, sleeping forever" for ISOs created using LiveCD-creator has brought my development process to a screeching halt. I'm working on some custom Kiosks for the Open Source Digital Voting project, and the scripts that built successful ISOs in July stopped building good ones in late August. I tried almost everything suggested above. Some fixes worked temporarily, then started failing. Here is what I tried. Downgrade squashfs to 4.0.2 - first ISO built worked, second not Upgrade squashfs to 4.0.4 (July state) - no love Downgrade udev to 151.9 - no love Upgrade udev to 151.10 (July state) - no love Build/install squashfs 4.1 - no love Build/install livecd-tools 033-3 - worked first couple of times, then stopped Yesterday I thought I had a process that worked. I would reboot, rebuild squashfs 4.1 and livecd-tools 033-3, then use livecd-tools to build the ISO, and IT WOULD BOOT! I don't really want to work this way, but I've got some deliverables due soon. But it failed on the 4th iteration, and then I tried to rebuild Walsh's Fedora Kiosk, my initial test case, and it failed too. I'm at a loss on how to proceed, give the totally intermittent nature of the problem. Can I revert back to Fedora 12, or are the same problems present there? Would someone who has a working system please give me pointers on how to achieve a stable work-around? Thanks in advance...Jeff I was trying to respin a Fedora 12 and was stucked at the same problem. Arun Sag pointed me to this discussion and it helped to solve that. I deleted NetworkManager-0.8.3* from /var/tmp/revisor-yumcache/updates/packages and changed to enabled=0 at the [update] sector on /etc/revisor/conf.d/[myrespin].conf Now, it installs NetworkManager-0.8.1* with no problem at Anaconda. It was sucessful to me. Regards Edilson Created attachment 446389 [details] Add support for NetworkManager 0.8 DBus spec This patch adds support for the new NetworkManager 0.8 D-Bus spec located here http://projects.gnome.org/NetworkManager/developers/spec-08.html Modifications were done on isys.py as well as on network.py I have tested this patch with latest kernel 2.6.34.6-54.fc13.x86_64 in both modes (console-only and GUI) Created attachment 446390 [details]
Update package dependencies and also add device-mapper-multipath
Anaconda's RPM spec file also needs to be modified
Update dependencies
Add device-mapper-multipath
I just released a patch (above) which solves a crash of anaconda. I first thought it was a NetworkManager bug but it turned out to be a change of the D-Bus Interface of the NetworkManager which caused anaconda to crash. Is there any estimate on when there will exist an installable mainline release of Fedora with a working version of LiveCD-Creator? Fedora 12 will not install on my machine, Fedora 13's version is broken, with and without updates, and Fedora 14's version is also broken, last time I checked a couple of days ago. Thanks...Jeff I just wanted to mention that rolling back to the previous version of the udev package fixed this issue for me... BUT a recent update (last night) has broken my build process. An update to device-mapper now gives the following error when I try to build: Error creating Live CD : Failed to build transaction : device-mapper-1.02.54-2.fc13.i686 requires udev >= 153-1 Looks like I'll be rolling back one or more additional packages in order to be able to build my remix. So far that's 3 NetworkManager-* packages, 1 udev package, one dbus-glib package... and now 1 or more device-mapper* packages. I definitely look forward to when this problem is fixed. (In reply to comment #32) Scott, please clarify, when you say "rolling back", I presume you are referring to the state of the update repo being accessed by your version of Live CD Creator, and not the state of your Fedora OS, correct? For clarity, can you tell us which versions of the following packages you are using in the OS and in your update repo (since I cannot for the life of me recreate a working environment that solves this problem): livecd-tools squashfs-tools udev dbus-glib NetworkManager NetworkManager-glib NetworkManager-gnome device-mapper Thanks...Jeff By rolling back I mean using an modified updates repo that doesn't include the problematic packages. For a list of previous release packages I'm using, see: http://img.cs.montana.edu/linux/montanalinux/packages/i686/ http://img.cs.montana.edu/linux/montanalinux/packages/x86_64/ (In reply to comment #34) > By rolling back I mean using an modified updates repo that doesn't include the > problematic packages. For a list of previous release packages I'm using, see: > > http://img.cs.montana.edu/linux/montanalinux/packages/i686/ > http://img.cs.montana.edu/linux/montanalinux/packages/x86_64/ I rebuilt last night my mini livecd (fedora-live-mini.ks) with a modified anaconda-13.42 package and everything works just as expected. When I build, however, a mini livecd with the latest fedora-live-mini.ks the ISO image boots fine but gets stuck infinitely after having started abrtd daemon. I have to switch to tty2 to log-in. I believe this issue may be related to the additional packages which were pulled-in... Here is the list of packages I am using (official Fedora updates repo) [root@localhost livecd]# rpm -qa | grep -E 'NetworkManager|device-mapper|^udev|^dbus|livecd-tools' | sort dbus-1.2.24-1.fc13.i686 dbus-glib-0.86-4.fc13.i686 dbus-libs-1.2.24-1.fc13.i686 dbus-python-0.83.0-6.fc12.i686 dbus-x11-1.2.24-1.fc13.i686 device-mapper-1.02.54-2.fc13.i686 device-mapper-event-1.02.54-2.fc13.i686 device-mapper-event-libs-1.02.54-2.fc13.i686 device-mapper-libs-1.02.54-2.fc13.i686 device-mapper-multipath-0.4.9-14.fc13.i686 device-mapper-multipath-libs-0.4.9-14.fc13.i686 livecd-tools-033-3.fc13.i686 NetworkManager-0.8.1-6.git20100831.fc13.i686 NetworkManager-glib-0.8.1-6.git20100831.fc13.i686 udev-153-3.fc13.i686 The issue you are experiencing might be related to several things. Try flushing your local yum cache (livecd cache folder). In my case it is /var/cache/live/. Then, avoid building live CDs with updates-testing repo - this can cause very strange side effects especially when packages appear in the updates-testing repo and then disappear for some reasons (bugs, incompatibilities, etc.) Sometimes it happens that fedora mirror servers are not perfectly synced so that yum got confused which then the livecd build script terminated with an error. This happened a few times to me last week (Murphy's law). I temporarily switched from mirror servers to the closest one to workaround this issue. Additionally, you will not get around of modifying anaconda to work properly with the latest NetworkManager release which is from my perspective the simplest solution instead of setting up a local repo with older package releases. All you will have to do is to use the patches and recompile the anaconda-13.42-2.fc13.src.rpm package. (In reply to comment #34) Scott, I tried your solution, on two different installations of Fedora 13, building fedora-live-base.ks, without success. Just like when I tried it with no updates, during the ISO boot the white and blue installation progress bar gets almost to the Fedora 13 label on the right, then the final segment of the bar turns orange and it hangs. I downloaded your specific RPMs, built a local updates repo, removed all newer instances of the conflicting RPMs from the local repo, populated the repo with your RPMs, then ran createrepo to update the control information. On both machines, the LiveCD-Creator process went smoothly, no significant errors or warnings. I checked to ensure that no updates beyond the scope of your RPMs were installed, and everything was OK there. Here are the packages of yours which were installed in the ISO: dbus-glib-0.86-3.fc13.i686 device-mapper-1.02.44-1.fc13.i686 device-mapper-event-1.02.44-1.fc13.i686 device-mapper-event-libs-1.02.44-1.fc13.i686 device-mapper-libs-1.02.44-1.fc13.i686 device-mapper-multipath-0.4.9-14.fc13.i686 device-mapper-multipath-libs-0.4.9-14.fc13.i686 NetworkManager-0.8.1-1.fc13.i686 NetworkManager-glib-0.8.1-1.fc13.i686 squashfs-tools-4.0-5.fc13.i686 udev-151-10.fc13.i686 Now, you do not mention what version of squashfs you are using. Perhaps this is the problem? Also, I'd like to know exactly what versions of certain packages you are running under Fedora 13, so I can see how my OS differs from yours. Here are the two sets of packages I have installed on my two Fedora 13 OSes: #1: OS has been updated, back and forth [jvc ~]$ alias greplcd alias greplcd='grep -E '\''NetworkManager|device-mapper|^udev|^udisk|^dbus-glib|livecd-tools|squashfs-tools'\''' [jvc ~]$ rpm -qa | greplcd | sort dbus-glib-0.86-4.fc13.i686 dbus-glib-devel-0.86-4.fc13.i686 device-mapper-1.02.44-1.fc13.i686 device-mapper-event-1.02.44-1.fc13.i686 device-mapper-event-libs-1.02.44-1.fc13.i686 device-mapper-libs-1.02.44-1.fc13.i686 device-mapper-multipath-0.4.9-14.fc13.i686 device-mapper-multipath-libs-0.4.9-14.fc13.i686 livecd-tools-031-1.fc12.1.i686 (upgraded to 033-3 via make install) NetworkManager-0.8.1-4.git20100817.fc13.i686 NetworkManager-glib-0.8.1-4.git20100817.fc13.i686 NetworkManager-gnome-0.8.1-4.git20100817.fc13.i686 NetworkManager-openconnect-0.8.1-1.fc13.i686 NetworkManager-openvpn-0.8.1-1.fc13.i686 NetworkManager-pptp-0.8.1-1.fc13.i686 NetworkManager-vpnc-0.8.1-1.fc13.i686 squashfs-tools-4.0-4.fc13.i686 (upgraded to 4.1 via make install) udev-151-10.fc13.i686 udisks-1.0.1-1.fc13.i686 #2: OS has had no updates performed dbus-glib-0.86-4.fc13.i686 dbus-glib-devel-0.86-4.fc13.i686 device-mapper-1.02.44-1.fc13.i686 device-mapper-event-1.02.44-1.fc13.i686 device-mapper-event-libs-1.02.44-1.fc13.i686 device-mapper-libs-1.02.44-1.fc13.i686 device-mapper-multipath-0.4.9-14.fc13.i686 device-mapper-multipath-libs-0.4.9-14.fc13.i686 livecd-tools-031-1.fc12.1.i686 NetworkManager-0.8.1-6.git20100831.fc13.i686 NetworkManager-glib-0.8.1-6.git20100831.fc13.i686 NetworkManager-openconnect-0.7.997-1.fc13.i686 NetworkManager-openvpn-0.7.997-1.fc13.i686 NetworkManager-pptp-0.7.997-3.git20100120.fc13.i686 NetworkManager-vpnc-0.8.0-1.git20100411.fc13.i686 squashfs-tools-4.0-2.i686 udev-151-10.fc13.i686 udisks-1.0.1-1.fc13.i686 Thanks for listening...Jeff (In reply to comment #35) > (In reply to comment #34) I now have a working system that generates LiveCDs that actually boot up. I have been corresponding privately with Richard Vidal-Dorsch, who claimed it was not the RPM package installation state of my machine nor was it the set of updates being added into the LiveCD-created OS. Richard recommended I clear out /var/cache/live (the cache location for my LiveCD-Creator scripts) and run a test using his private version of a fedora-mini kickstart file. This worked to generate a bootable LiveCD, but starting up the ISO in the VMM still produces the "No root device found" error. So I reran my original LiveCD-Creator scripts, which use the currently installed kickstart files, and sure enough, these ISOs now still produce the same error in the VMM but boot up fine as LiveCDs. I checked some old ISOs to make sure I wasn't crazy, and an ISO from September 2nd has both the VMM error and will not boot from LiveCD (produces the "... sleeping forever" error message). I have no idea what has happened here. The VMM still does not work to boot these ISOs, so I can't use it for testing, but the LiveCDs boot, and that is the final objective, so I'll slog on with what I've got. Thanks, Richard...Jeff There will eventually be a version of 034 pushed to F13 as some bugs were fixed that apply to older Fedoras. But I want to see it get some more testing. I think it has a dependency on python 2.7, but 2.6 will probably work if you install with --nodeps. That might help, but I don't know that it will for what you are seeing. I got the same issue on yesterday... 'No root device to... sleeping for ever' I have tested the iso on KVM using Fedora 12 64bit system and Fedora 13 64bit system. Could you please let me know how to fix this issue? I am using my Fedora 13(64bit) system to buil Fedora 13 X86 beased Remix. I got the same issue on yesterday... 'No root device to... sleeping for ever' I have tested the iso on KVM using Fedora 12 64bit system and Fedora 13 64bit system. Could you please let me know how to fix this issue? I am using my Fedora 13(64bit) system to build Fedora 13 X86 based Remix. above comments are bit complex to me. so, higly appreciate if you give me steps to fix. I am using fedora-live-base.ks file shall I attached my kickstart files? (In reply to comment #40) > I got the same issue on yesterday... > 'No root device to... sleeping for ever' Since starting to get this error message in the VM, around August 26th, I never succeeded in eliminating it. BUT, when I burn my ISOs to CD/DVD/USB, they now successfully reboot my PC. Essentially, all I did was eliminate the cache. I deleted the contents of /var/cache/live and removed the "cache=" part from my livecd-creator script. Not being able to test them in the VM is annoying, but not being able to boot them at all was way more annoying...Jeff i have created an image on last night but it also not booted on both VM as well as the base system. i have deleted the content of the cache/ but used cache=cache/ directory as I added customized generic-logos package (once I build the image rebuild it using the cache by adding rebuilded generic-logos package. This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component. *** Bug 635768 has been marked as a duplicate of this bug. *** See this discussion about anaconda/livecd general policy with respect to updates: <http://lists.fedoraproject.org/pipermail/livecd/2010-November/thread.html#6454> <http://thread.gmane.org/gmane.linux.redhat.fedora.livecd/4179> Was this problem resolved? I'm seeing this same problem with current (fully updated as of 3rd of March 2011) Fedora 14 running livecd-creator generating f14 livecd image.. If you're seeing this on f14 with updated components, it's highly likely to be due to something else, you should file a new bug. Does it work without updates? If so, then it is due to other packages changing things. It seems to happen with and without updates (for the live cd). In both cases the host (where I run livecd-creator) had all the updates installed. I guess I'll file a new bug report.. New bug opened here: https://bugzilla.redhat.com/show_bug.cgi?id=681999 Adding a note here aswell.. please see https://bugzilla.redhat.com/show_bug.cgi?id=681999 for more information. My problem seems to be caused by an issue in udev. If the CDROM drive doesn't implement "READ TOC" command properly some udev versions fail to identify the disc and thus mounting root fails. This issue is present at least in udev version that's included in Fedora 14. el6 udev version available from http://people.redhat.com/harald/downloads/udev/udev-147-2.35.el6/ seems to work OK for me (with f14 livecd). This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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 Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |
Created attachment 438679 [details] f13 kde-4.5.0 kickstart file $ rpm -q livecd-tools livecd-tools-031-1.fc12.1.x86_64 Trying to create a fedora-13-based live image to show-case the newly released kde-4.5.0 (similar to how what I've done in the past), but all I end up with is an iso that won't boot (using virt-manager/kvm anyway). The error is... No root device found Boot has failed, sleeping forever. kickstart used is attached. Any hints, advice?