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 gap. 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