On Sat, 07 Nov 2015 02:47:27 +0100 Christoph Anton Mitterer <cales...@scientia.net> wrote: > Package: initramfs-tools > Version: 0.120 > Severity: normal > > > Hi. > > I've just noted the following: > Processing triggers for initramfs-tools (0.120) ... > update-initramfs: /boot/initrd.img-4.2.0-1-amd64 has been altered. > update-initramfs: Cannot update. Override with -t option.
So it does actually warn, contrary to the bug title. > Not sure what caused it to think that I've modified it, mkinitramfs saves md5sums under /var/lib/initramfs-tools. Perhaps you replaced the initramfs image with a different version, or perhaps it was corrupted at some point. > ... nevertheless. > such a status message will likely just drown in the flood of log messages > during any update. I don't think you can blame the package maintainer if you ignore such warnings. > And in such case the initramfs may stay stale, which could cause quite > some troubles,... from non booting systems up to even security issues. Kernel updates always run update-initramfs synchronously using the -t option (via /etc/kernel/postinst.d/initramfs-tools) so I don't see much of a security issue here. > I'm not sure whether it would be better to simply let the trigger use -t, > cause this may be undesired either. I'm not sure how important the -t option is, now that we have initramfs-tools-core for users that don't want automatic rebuilds. Maybe we can get rid of it. > Would there be a way to give a more interactive warning (e.g. debconf)? > Or does it seem reasonable in such a case to fail the trigger? I don't like either of those options. I think the answer will usually be that we should go ahead and update the initramfs anyway. Ben. -- Ben Hutchings Quantity is no substitute for quality, but it's the only one we've got.
signature.asc
Description: This is a digitally signed message part
