maximilian attems wrote: > 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. Thanks for explaining that (and for your patience). > right i'd have to rethink to scrap mkinitramfs-kpkg postlenny. Yes, it will need some real care to avoid the power outage gap when dropping it. > for now there is just the flash_kernel missing after the generated > initramfs in update-initramfs. Well, my understanding now is: - kernel package installed - mkinitramfs-kpkg generates initramfs #1 - postinst_hook=flash-kernel is run, flashing new kernel+initramfs - <stuff> - update-initramfs triggered, generates initramfs #2 If so, there's no pressing need to reflash the kernel at the end. It's only confusing/ugly that as Paul Collins reported it can seem to flash before updating. But not dangerous. We can modify update-initramfs to call flash-kernel, but it will just flash the second build of the initramfs. Is there any reason to perhaps want to use that one? Or will we be just be doubling the write cycles to the flash? FWIW, I've committed a patch to flash-kernel svn so that you could do somehing like this: if flash-kernel --supported >/dev/null 2>&1; then flash-kernel fi -- see shy jo
Attachment:
signature.asc
Description: Digital signature