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

Re: nslu2-utils, update-initramfs and triggers



On Sun, 27 Jul 2008, Joey Hess wrote:

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

the linux image in postinst does *not* call yet update-initramfs,
but mkinitramfs-kpkg, which is not triggered.
so that loophole does not yet exist.
 
> 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.

right i'd have to rethink to scrap mkinitramfs-kpkg postlenny.
for now there is just the flash_kernel missing after the generated
initramfs in update-initramfs.

-- 
maks


Reply to: