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

Re: nslu2-utils, update-initramfs and triggers

maximilian attems wrote:
> update-initramfs has code to work it out with lilo.
> see run_bootloader().
> current heuristic is to check if grub *and* lilo are around,
> then it gets complicated. if only lilo is there it will be
> called, same goes with elilo and zipl.
> if both bootloader are there do_bootloader setting in /etc/kernel-img.conf 
> is first checked and obeyed. if not set last but least mbr is checked.

I see. That works for lilo as long as there is no do_bootloader or
postinst-hook running lilo before update-initramfs. But, d-i sets
do_bootloader for lilo. So, the kernel package runs update-initramfs,
which does nothing (triggerized), then the kernel package runs lilo. If
the system loses power at this point, before the trigger is run, it will
probably not be bootable. The trigger fixes this, but that is an ugly

I think that the same gap exists for elilo, and zipl, and vmelilo.
Perhaps some of these bootloaders allow recovering from the
inconsistency better than others.

Also, the glantank is another arm box with the same problem as
flash-kernel. (glantank-update-kernel is run by kernel-img.conf
postinst-hook, does a very similar search like flash-kernel for a kernel
and initramfs, symlinks the initrd into /boot/initrd, and devio's the
kernel image to /boot/zImage (where the box's bootloader will find
them). If update-initramfs is delayed, this hook runs before it, and
seems that it must install an old or inconsistent initrd/kernel pair.)

> so i'd guess update-initramfs should get a small flash kernel section
> in run_bootloader() 

We could do this for flash-kernel and glantank-update-kernel to solve the
problem for those, I think. The section would just check for the
appropriate machines, and run the programs.

But, that would leave open the window where loss of power == no boot.
For some of these systems, particularly the nslu2, no boot =~ reinstall.
I don't think that's acceptable, really.

see shy jo

Attachment: signature.asc
Description: Digital signature

Reply to: