Bug#550584: Initial triggers patch and tracking of highest kernel
On Wed, Mar 09, 2011 at 04:10:03AM +0100, Loïc Minier wrote:
> Hey
>
> I've read through the bug, but still didn't setup a test environment,
> but "triggered" by Hector and Clint's activity on the bug I thought I'd
> rather share patches and proposals early.
>
> First, quick problem statement:
> a) flash-kernel isn't called when installing a new kernel ABI
> b) flash-kernel might be called more times than strictly needed
> c) flash-kernel doesn't have a clear contract on what to do when
> multiple kernels are installed on the system or when kernels are
> removed
Yup.
>== triggers ==
>
> In the middle of this bug's thread, there is a proposal to add
> triggers; it wasn't entirely obvious to me what part of the problem
> triggers would solve. I think triggers are good to avoid running
> things multiple time, so they would mostly help with the problem b).
>
> This would be helpful if for instance linux-2.6's postinst would call
> flash-kernel, and initramfs-tools' postinst would also call
> flash-kernel. However in practice that's not what happens; instead,
> pretty much all packages arrange to call update-initramfs -u which is
> implemented as a trigger -- and hence only runs once -- which calls
> flash-kernel. Some packages like linux-2.6 will also call the
> update-initramfs -c or -d, but that doesn't call flash-kernel.
>
> One area where triggers would be helpful is to avoid multiple calls
> when doing installation or upgrades of multiple kernels.
>
> Unfortunately, you can't pass arguments to triggers, so only one
> flash-kernel call type can be implemented as a trigger, for instance
> the "flash-kernel --supported" and "flash-kernel 2.6.38-2" calls
> wouldn't be implemented as triggers, but "flash-kernel" would be. I'm
> attaching a sample patch doing this (untested, but it's just to support
> the discussion). The current implementation of "flash-kernel" without
> a kernel ABI is to use /vmlinuz and /initrd.img or /boot/vmlinuz and
> /boot/initrd.img, but I don't think we can rely on these symlinks being
> up-to-date on all Debian installs; does anybody think so?
Potentially dangerous, depending on the history of each system, yes.
>== getting flash-kernel called on new kernels ABIs ==
>
> I think this one is relatively simple, flash-kernel always requires an
> initrd (and it depends on initramfs-tools), and if a kernel is updated,
> its initrd will be updated as well; once update-initramfs is done, it
> will call /etc/initramfs/post-update.d/* per:
>http://kernel-handbook.alioth.debian.org/ch-update-hooks.html#s-initramfs-hooks
>
> We should probably change update-initramfs-tools to not hardcode the
> call to flash-kernel anymore and rely on /etc/initramfs/post-update.d
> for this as well.
Yes, makes sense.
>== multiple kernels and removals ==
>
> The hard part is dealing with multiple kernels being installed, or
> kernels being removed. The good news is that for most boards, when a
> kernel is removed the system should remain mostly bootable (at least up
> to mounting the root) since flash-kernel copies the kernel and initrd
> data in NAND or generates an uImage, except the GTA02 initrd.
>
> The best thing I could think of is having all
> /etc/initramfs/post-update.d and /etc/kernel/postinst.d calls keep a
> note of which kernel initrd are being touched, and update
> /var/lib/flash-kernel/known-kernels with the data. flash-kernel would
> install the highest version according to dpkg --compare-versions and we
> could implement a config file to force a specific kernel later (e.g.
> /etc/flash-kernel.conf) or perhaps even support for chosing between
> kernels in future versions (debconf? boot menu?). The reason the
> state file is needed is that if you have upgrades for linux-2.6.37 and
> linux-2.6.38, and the linux-2.6.37 one is installed after linux-2.6.38,
> you still want the linux-2.6.38 update to be the flashed one. The
> reason we need to track all versions in the state file is for removals
> where we want to select the next highest available version of the
> kernel. The main problem is that flash-kernel wont know about all
> versions at the time where we introduce this.
Can we work it out by looking at any kernels that are currently
installed, or checking in u-boot setup (or similar) which kernel it's
currently going to use? It bothers me a little that we need to keep
state somewhere, but I don't see a better way offhand. Would it be
better stored in /boot somewhere (yes, bikeshedding...) ?
How well will things cope with the New World Order where the kernel
team upload new kernels with an ABI of "trunk" during development
phases? I guess we can add extra logic to cope with that if necessary.
> I'm attaching a naive implementation which doesn't deal with removals
> and only keeps track of the latest initrd ABI (not of the kernel one).
> (again, untested, sorry!)
> NB: debian/initramfs/post-update.d/flash-kernel needs to be +x in the
> native package.
>
> So to sum up, on top of the trigger support, I would propose that we
> add an initramfs hook to track available versions in a
> /var/lib/flash-kernel/ file and use that in the trigger to select the
> highest still installed version we should flash.
>
> Does this make sense? Any issue with this proposal?
I think I'm in agreement, modulo comments above.
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"Since phone messaging became popular, the young generation has lost the
ability to read or write anything that is longer than one hundred and sixty
characters." -- Ignatios Souvatzis
Reply to: