This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 624028 - livecd-creator creates iso that doesn't boot
livecd-creator creates iso that doesn't boot
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: livecd-tools (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Brian Lane
Fedora Extras Quality Assurance
: Reopened
: 635768 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-13 09:08 EDT by Rex Dieter
Modified: 2011-06-28 10:37 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-28 10:37:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
f13 kde-4.5.0 kickstart file (6.79 KB, text/plain)
2010-08-13 09:08 EDT, Rex Dieter
no flags Details
Add support for NetworkManager 0.8 DBus spec (3.30 KB, application/octet-stream)
2010-09-09 18:37 EDT, Richard Vidal-Dorsch
no flags Details
Update package dependencies and also add device-mapper-multipath (1.71 KB, patch)
2010-09-09 18:41 EDT, Richard Vidal-Dorsch
no flags Details | Diff

  None (edit)
Description Rex Dieter 2010-08-13 09:08:41 EDT
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?
Comment 1 Bruno Wolff III 2010-08-13 11:27:06 EDT
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.
Comment 2 Rex Dieter 2010-08-13 11:35:21 EDT
thanks!  I'll try that.
Comment 3 Rex Dieter 2010-08-13 12:18:41 EDT
built squashfs-tools-4.1-0.3.20100803 for f13, and it seems to work like a champ.
Comment 4 Bruno Wolff III 2010-08-13 12:49:45 EDT
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.
Comment 5 Rex Dieter 2010-08-13 13:20:55 EDT
ugh, the plot thickens.

I tried generating a live image enabling updates-testing repo, and booting fails again.  :(
Comment 6 Bruno Wolff III 2010-08-13 13:41:21 EDT
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.
Comment 7 Bruno Wolff III 2010-08-13 13:43:44 EDT
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.)
Comment 8 Bruno Wolff III 2010-08-13 13:45:51 EDT
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.
Comment 9 Jasper O'neal Hartline 2010-08-13 14:07:05 EDT
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.
Comment 10 Jasper O'neal Hartline 2010-08-13 14:13:56 EDT
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.
Comment 11 Jasper O'neal Hartline 2010-08-14 19:43:03 EDT
Can the original bug reporter provide some more information?
Comment 12 Rex Dieter 2010-08-14 20:15:27 EDT
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).
Comment 13 Rex Dieter 2010-08-14 20:17:41 EDT
autopsy on irc suggested I try reproducing the failure removing kernel boot options: rhgb quiet 

I'll try to do that (soon).
Comment 14 Bruno Wolff III 2010-08-14 20:57:39 EDT
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.
Comment 15 Rex Dieter 2010-08-15 12:48:24 EDT
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)?
Comment 16 Jasper O'neal Hartline 2010-08-15 13:03:54 EDT
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)
Comment 17 Arun S A G 2010-08-30 00:18:38 EDT
I installed squasfs-tools 4.1, still i am not able to boot the created iso.
Comment 18 Jasper O'neal Hartline 2010-08-30 00:30:57 EDT
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.
Comment 19 Arun S A G 2010-08-30 00:45:05 EDT
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.
Comment 20 Jasper O'neal Hartline 2010-08-30 09:06:56 EDT
Ok this is not a livecd-creator or ISO bug. This is probably a virt-manager or Anaconda bug, in what you are describing.
Comment 21 Rex Dieter 2010-08-30 09:17:01 EDT
See item 1 in comment #10 (probably needs a newer udev)
Comment 22 Scott Dowdle 2010-09-01 18:14:54 EDT
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.
Comment 23 Scott Dowdle 2010-09-02 13:36:21 EDT
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.
Comment 24 Arun S A G 2010-09-03 00:18:07 EDT
(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?
Comment 25 Scott Dowdle 2010-09-03 11:26:48 EDT
(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.
Comment 26 Jeff Cook 2010-09-04 23:11:43 EDT
(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
Comment 27 Edilson Osorio Junior 2010-09-08 11:32:45 EDT
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
Comment 28 Richard Vidal-Dorsch 2010-09-09 18:37:13 EDT
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)
Comment 29 Richard Vidal-Dorsch 2010-09-09 18:41:04 EDT
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
Comment 30 Richard Vidal-Dorsch 2010-09-09 19:29:05 EDT
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.
Comment 31 Jeff Cook 2010-09-10 14:59:08 EDT
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
Comment 32 Scott Dowdle 2010-09-11 11:10:55 EDT
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.
Comment 33 Jeff Cook 2010-09-13 03:53:21 EDT
(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
Comment 34 Scott Dowdle 2010-09-13 10:54:12 EDT
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/
Comment 35 Richard Vidal-Dorsch 2010-09-13 16:23:08 EDT
(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.
Comment 36 Jeff Cook 2010-09-13 23:25:46 EDT
(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
Comment 37 Jeff Cook 2010-09-15 19:06:27 EDT
(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
Comment 38 Bruno Wolff III 2010-09-15 21:27:08 EDT
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.
Comment 39 Danishka Navin 2010-09-23 12:30:05 EDT
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.
Comment 40 Danishka Navin 2010-09-23 12:33:39 EDT
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?
Comment 41 Jeff Cook 2010-09-23 17:52:29 EDT
(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
Comment 42 Danishka Navin 2010-09-26 11:46:40 EDT
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.
Comment 43 Fedora Admin XMLRPC Client 2010-10-21 13:58:06 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 44 Brian Lane 2010-10-28 20:48:48 EDT
*** Bug 635768 has been marked as a duplicate of this bug. ***
Comment 45 MarcH 2010-11-09 04:26:43 EST
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>
Comment 46 Pasi Karkkainen 2011-03-03 14:47:23 EST
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..
Comment 47 Rex Dieter 2011-03-03 15:00:21 EST
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.
Comment 48 Brian Lane 2011-03-03 15:07:06 EST
Does it work without updates? If so, then it is due to other packages changing things.
Comment 49 Pasi Karkkainen 2011-03-03 15:25:15 EST
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..
Comment 50 Pasi Karkkainen 2011-03-03 15:37:04 EST
New bug opened here: https://bugzilla.redhat.com/show_bug.cgi?id=681999
Comment 51 Pasi Karkkainen 2011-04-11 16:08:22 EDT
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).
Comment 52 Bug Zapper 2011-06-01 07:30:12 EDT
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
Comment 53 Bug Zapper 2011-06-28 10:37:04 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.