Re: nslu2-utils, update-initramfs and triggers
On Sat, 26 Jul 2008, Joey Hess wrote:
> Martin Michlmayr wrote:
> > * Paul Collins <paul@burly.ondioline.org> [2008-07-27 01:47]:
> > > I seem to see this sort of thing a lot:
> > >
> > > update-initramfs: deferring update (trigger activated)
> > > Flashing kernel: done.
> > > Flashing initramfs: done.
> > > Processing triggers for initramfs-tools ...
> > > update-initramfs: Generating /boot/initrd.img-2.6.25-2-ixp4xx
> > >
> > > This strikes me as somewhat the wrong way around to do things.
> >
> > I don't think I've ever seen (or noticed this) myself, but this would
> > be a pretty serious issue.
> >
> > maks, joeyh, any comments?
>
> flash-kernel is configured to run as a kernel-img postinst_hook in
> /etc/kernel-img.conf. Same as update-grub or lilo. So yes, AFAICS, it
> will run before update-initramfs is triggered.
>
> Reviewing #447611, nowhere in the (extensive) discussion were
> flash-kernel or lilo mentioned, and I cannot see how deferring
> initramfs generation can be safe for either.
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.
> flash-kernel flashes whatever the /vmlinuz and /initrd.img symlinks (or
> the ones in /boot) point to. If the kernel has been updated and the
> initrd update postponed, and it flashes a mismatched set, I think that
> would be a RC bug. If this happens, why haven't any slug users noticed
> though?
so i'd guess update-initramfs should get a small flash kernel section
in run_bootloader()
> lilo records the position of the initramfs and kernel on disk. If that
> was the old initramfs, and a new one is generated, and it has the same
> location on disk, things would luckily work. If the new initramfs went
> to a different place, not so lucky. Maybe everyone has been lucky so far?
no see aboves.
> And, what about all the other bootloaders?
also handled.
> I'd lean toward disabling the triggerization code until we can prove
> it's safe, or maybe only turn it on if grub is being used.
>
> (That is, if we decide it's safe enough to use the triggerization with
> grub. If we want to keep systems bootable during upgrade even if power
> is cut, it's slightly less safe to delay update-initramfs, because if
> the power is cut between update-grub and update-initramfs, the first
> item on the grub menu won't boot. Requiring console access to fix.
> Without triggerization, a power cut would leave the grub menu in a
> bootable state at all times (unless the running kernel was removed
> earlier in the same upgrade).)
to quick shot, if someone points me to how update-initramfs can
detect flash-kernel the open case will work out.
--
maks
Reply to: