Re: second-stage bootloader for Thecus N2100?

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

On Fri, Jan 30, 2009, Paul Jakma wrote:
> What would be the best way to have some kind of support for retaining  
> old kernel/initrds and booting those? (And is anyone working on this?)

 We were looking into this in Ubuntu; actually the general problem was
 recovering from a breakage after a kernel/initrd upgrade, and allowing
 to boot older kernel/initrds.  There are many solutions to the first
 part, perhaps our preferred is when the bootloader is clever enough to
 e.g. boot from USB or SD card first, or even clever enough to offer you
 a list of kernels from a partition on your SATA disk!  Unfortunately
 RedBoot isn't really good at FS and USB or SATA would require new
 support in RedBoot.  Michael Casadevall explored this option:

> - A small, static Linux env in flash to act as bootloader via kexec ?

 ...and ran into problems with kexec on a target board we're using.  He
 explored building an env from kboot and petitboot.  Oliver Grawert
 explored adding an initramfs-tools boot script to present a menu, all
 in shell.  These solutions were quite promising, but required some
 hacks.  With kboot/petitboot, you're bloating the initramfs size,
 probably would still fit in the case of the Thecus N2100 though (in our
 case, even a standard initramfs wouldn't fit).

 Also, this is no silver bullet: you still want to be able to recover
 from breakage in the flash's kernel/initramfs, or upgrade them (even if
 less regularly), and it will require starting two kernels, hence making
 boot times longer.

 You also face a prompting problem on the Thecus N2100 which doesn't
 have a display/console by default (you can of course solder it in, but
 that's less user friendly  ;-) and going the telnet/ssh route might
 make it a) insecure b) slower to boot c) tricky to actually log in
 during the open window.

 https://lists.ubuntu.com/archives/ubuntu-devel/2009-January/027229.html
 https://wiki.ubuntu.com/Specs/ARMSoftbootLoader

 I'll forward your comments to Michael and Oliver; we are and remain
 very interested in your ideas and input!  Right now we're likely to go
 with the bootloader route as it supports SD boot, but a more generic
 solution would probably involve a Linux kernel and an initramfs if we
 want drivers to access hardware, filesystems, and perhaps things like
 LVM/crypto devices and offer some logic to select the image.

   Bye
-- 
Loïc Minier