On Sat, 26 Jul 2008, Joey Hess wrote: > Martin Michlmayr wrote: > > * Paul Collins <[EMAIL PROTECTED]> [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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
