Removing duplication in /boot - affects kernel development

[Daniel Drake]

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.
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.
(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?

Thanks,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: olpc.fth
Type: application/octet-stream
Size: 1378 bytes
Desc: not available
URL: <http://lists.laptop.org/pipermail/devel/attachments/20120305/1457ba19/attachment.obj>