[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


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