Bug#550584: Initial triggers patch and tracking of highest kernel

[Loïc Minier <lool@dooz.org>]

On Thu, Mar 10, 2011, Hector Oron wrote:
> Last night I tested this patch, but maybe I was doing something wrong
> as it did not seem to work. Then I manually generated uImage and
> uInitrd and now kernel stalls at:

 Ah thanks; sorry that it's not working, do you have the log of running
 flash-kernel/kernel updates etc.?

>  1. Chainload boot, at first boot load the usual kernel then call the
> new one with kexec, if everything is fine then the user can replace
> old kernel with new kernel, else the kexec call fails and leaves you
> with old kernel.

 Sure, that's a nice approach; kexec doesn't work reliably on all
 platforms though, but that would be an option for platforms which
 support it.  There are various efforts to provide such an UI, petitboot
 or kboot for instance.

>  2. Bootloader scan /boot, implement in the bootloader a scanner for
> /boot, passing as parameter the higher version found. But if that
> fails, device is bricked.

 Perhaps a nicer option is to provide a boot.scr which does that so that
 the u-boot config is just "load boot.scr and run it", and we generate a
 complex or a simple boot.scr.

 But again, some boards use redboot or other bootloaders so I'm not sure
 whether it's something we can apply across all boards.  We would
 definitely want to offer boot.scr for SD boot though, but that's
 future.

-- 
Loïc Minier