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. st...@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 -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110309154350.gg6...@einval.com
