Removing duplication in /boot - affects kernel development

[Paul Fox]

daniel wrote:
 > Hi,
 > 
 > At the moment, /boot in our images looks like this:
 > 
 > Development builds - kernel is found at /boot/vmlinuz, initramfs at
 > /boot/initrd.img and /boot/actrd.img. Unsecure boot is always used,
 > meaning that olpc.fth is executed, which loads the kernel and
 > initrd.img from those locations.
 > 
 > Release builds - kernel is found unsigned at /boot/vmlinuz, unsigned
 > initramfs are found at /boot/initrd.img and /boot/actrd.img. Those
 > files are also signed and duplicated in actos.zip (and runos.zip which
 > is a symlink), actrd.zip and runrd.zip. For unsecure boot, olpc.fth is
 > used, loading the unsigned kernels. For secure boot, the signed zips
 > are loaded by the firmware and olpc.fth is unused.
 > 
 > 
 > The problem I'd like to solve here is that in our release builds, we
 > are duplicating the kernel and initramfs (both unsigned and signed
 > versions are both shipped).
 > As a side effect of the solution outlined below, another small problem
 > will be fixed: we currently duplicate the OFW code used to upgrade the
 > firmware in olpc.fth, so that firmware updates take effect even in
 > unsecure mode. We can remove this duplication too.
 > 
 > 
 > The solution I'm proposing, with help from Mitch, is the following:
 > 
 > Our builds will always ship the kernel and initramfs *only* in their
 > actos/runos/actrd/runrd zip forms. However, in development builds,
 > these zip files will not have a signature. This will be done by the
 > build system - the build system will take the
 > vmlinuz/initrd.img/actrd.img files installed by the kernel RPM, and
 > put them in zip files (optionally with signatures), deleting the
 > originals.
 > 
 > olpc.fth (attached), used only in unsecure mode, by default will
 > instruct the firmware to execute the system from the runos/runrd zip
 > files, as if it were booting in secure mode, but without verifying any
 > signatures. This also means that the standard secure boot code will
 > upgrade the firmware if a newer version is found in bootfw.zip, so we
 > can remove the duplicated firmware upgrade code from olpc.fth.
 > 
 > This solves the duplication and is quite straight forward.
 > 
 > 
 > The questions raised here relate to development. There are 2 common
 > development routines that will be affected by this:
 > 
 > 1. Installing a new kernel RPM to test a new kernel/initramfs before
 > it gets shipped in a build (with rpm -Uvh kernel-foo.rpm).
 > This will continue to install the new kernel as /boot/vmlinuz and the
 > initramfs as /boot/{actrd,initrd}.img.
 > The olpc.fth shipped as part of this change will look for the presence
 > of /boot/vmlinuz, and, if found, will boot directly from that rather
 > than looking in the zip files and executing the secure boot code as
 > outlined above. So, this development routine is largely unchanged:
 > install a new kernel RPM, copy the files to the right place (e.g.
 > /bootpart, will probably try and improve on this step in future),
 > reboot.
 > The one side-effect that will happen here is that when you install a
 > kernel RPM in this fashion, the automatic firmware upgrade from
 > bootfw.zip will no longer happen. So, if you install a new kernel via
 > a RPM, and then a new firmware via a RPM, the firmware won't be
 > automatically flashed. I think we can live with this (and documented
 > on the wiki), what do others think?
 > 
 > 2. Copying a new kernel into place by hand (e.g. compile on another
 > system, copy to /boot/vmlinuz on XO, reboot). This will no longer work
 > as-is, since the system will now try to boot from /boot/vmlinuz (OK)
 > and /boot/initrd.img (not found). The initramfs will have to be put in
 > place at the same time as installing a custom kernel.

and if i don't, the machine will be unbootable, i guess?

is there a way to fall back on the signed zip version of the initrd
if there's no "plain" version?

 > I will add a "olpc-dev-kernel" script to olpc-utils which can simplify
 > this (it will put /boot/vmlinuz and /boot/initrd.img in place by
 > extracting them from the zip files). Run olpc-dev-kernel, *then* copy
 > your test kernel over, and then things will work as before.

it would be nice if the script didn't clobber existing plain kernel
and/or initrd files by default -- then one could install one's new
kernel and run the script in either order.

 > (Similar considerations apply for initramfs development: if you drop a
 > new initramfs in place, it won't be used until you put a /boot/vmlinuz
 > kernel in place too. But, run olpc-dev-kernel first, and things will
 > work as before).
 > 
 > 
 > Are developers prepared to put up with these 2 minor changes in the
 > interest in solving this duplication problem?

is the duplication problem greater than simply the waste of disk space?

paul
=---------------------
 paul fox, pgf at laptop.org