Bug#550584: Initial triggers patch and tracking of highest kernel
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