Red Hat Bugzilla – Bug 443538
Support updating kernel on Live image
Last modified: 2013-01-09 23:40:37 EST
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
Version-Release number of selected component (if applicable):
Fedora 9 preview.
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".
The original, buggy kernel is still used.
The new, bug-fixed kernel should boot.
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.
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
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.
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
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.
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
*** This bug has been marked as a duplicate of 446935 ***
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.