Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Support updating kernel on Live image|
|Product:||[Fedora] Fedora||Reporter:||Joe Buck <jbuck>|
|Component:||LiveCD||Assignee:||Jeremy Katz <katzj>|
|Status:||CLOSED DUPLICATE||QA Contact:|
|Fixed In Version:||Doc Type:||Enhancement|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-05-29 16:36:39 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Joe Buck 2008-04-21 22:53:57 EDT
Description of problem: yum or PackageKit will attempt to upgrade the kernel of a Live CD if run. However, the newly installed kernel will not be run when the Live CD is rebooted. Version-Release number of selected component (if applicable): Fedora 9 preview. How reproducible: Easy to reproduce. Steps to Reproduce: 1. Create a bootable USB stick with persistent store with livecd-iso-to-disk 2. Boot it. Do "yum update" or similar, a new kernel is "installed". 3. Reboot. Actual results: The original, buggy kernel is still used. Expected results: The new, bug-fixed kernel should boot. Additional info: The reason for the problem is that the USB stick uses syslinux, and wants to boot vmlinuz0 from the /syslinux directory, but yum update puts the updated kernel in /boot, expecting that grub is used. It also seems that the wrong kind of initrd is provided with the upgrade. Given that the persistent store lets me have a Linux system in my pocket, to use on any of several machines, it would be nice if there were a way to upgrade the kernel without having to redo the disk, lose my persistent data, etc. One possibility would be for the live CD to have an alternate package, say kernel-livecd, so that an upgrade would replace the kernel and initrd in the right place for syslinux to work.
Comment 1 Jeremy Katz 2008-04-22 14:50:15 EDT
Patches accepted (although doing a separate kernel is probably not going to fly). Or I'll take a look and see what we can do in the F10 timeframe
Comment 2 Joe Buck 2008-04-22 23:44:02 EDT
I don't think that a separate kernel is needed; the standard kernel from the regular kernel package should work. It just needs to be moved or copied. In fact, I tried copying the kernel and initrd from /boot into /syslinux and rebooting. The kernel boots OK, but the system dies in the boot because there's no /dev or /selinux (which are apparently supposed to be in the initrd). So the problem is that an updated initrd would be needed, which is a superset of the initrd that grub uses. An alternate possibility that might be simpler (and that wouldn't have to wait for F10) is to just provide a script that can update a USB stick outside the regular packaging system. I don't know how the livecd-tools work, but perhaps another possibility is to use them to build another initrd. Then, when the kernel is updated, the user would just need to run a script to build a new initrd and copy the kernel into the right place. If I understood this stuff better I'd take a shot at it.
Comment 3 Joe Buck 2008-04-23 14:31:07 EDT
One possible approach to fixing this issue would be the following: Whenever a new kernel is released, re-run the livecd-creator program, as if you were going to re-spin the entire live cd. But put only the initrd file for that respun cd in a special new package, livecd-initrd. The post-install script for the package would be responsible for copying the kernel and initrd into the /syslinux directory. It would be easiest for users if the packaging system could do all the magic, so that the regular PackageKit update would take care of it. That's perhaps a task for Fedora 10. But having a script to do the job would be acceptable too. If I have time over the weekend I'll see if I can come up with some hack.
Comment 4 Bug Zapper 2008-05-14 05:54:27 EDT
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 5 Jeremy Katz 2008-05-29 16:36:39 EDT
*** This bug has been marked as a duplicate of 446935 ***
Comment 6 Joe Buck 2009-05-06 14:31:55 EDT
Jeremy, marking this report as a duplicate of 446935 was improper for two reasons. First off, this one is older and provides more information about the problem from a user perspective. Second, while fixing 446935 would be a necessary step to fix this bug, it would not be sufficient: it would still be necessary, when a new kernel becomes available, to not only build a proper initrd but also to put the new kernel in the right place. Because fixing 446935 would not fix this bug, it's clearly not a duplicate. Please reopen.