Bug 443538

Summary: Support updating kernel on Live image
Product: [Fedora] Fedora Reporter: Joe Buck <jbuck>
Component: LiveCDAssignee: Jeremy Katz <katzj>
Severity: low Docs Contact:
Priority: low    
Version: 9CC: dcantrell
Target Milestone: ---Keywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-29 16:36:39 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 438944    

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

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:
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.