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

Re: nslu2-utils, update-initramfs and triggers

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. 

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

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?

And, what about all the other bootloaders?

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

see shy jo

Attachment: signature.asc
Description: Digital signature

Reply to: