Bug#362064: udev: udev tries to write to an installed, working initrd without asking

[maximilian attems <maks@sternwelten.at>]

On Sun, Aug 20, 2006 at 04:25:53PM -0400, Andres Salomon wrote:
> 
> Here's a use case where having initramfs-tools unconditionally update
> initramfs images is a bad thing (at the very least, violating the
> principal of least surprise).

you use an plural, which is wrong.
initramfs-tools updates the newest one only.
it has been doing so since day 1 in the archive.
 
> I had a machine that was had a poorly supported sata_mv chipset; dapper
> nor sarge w/ 2.6.15/2.6.16 images would install onto it.  I had to make
> a custom cd w/ backported libata and sata_mv drivers.  Needless to say,
> it was a pain in the ass to get installed.

aren't tomorrow dailies based on 2.6.17, but that is offtopic..
 
> After installation, I backported etch versions of busybox and
> initramfs-tools (uploading the latter to backports.org) in order to do
> some testing to see if I could get some installation and boot bugs
> fixed.  I installed both backports, then I backed up the existing
> initramfs image and created a new image.  The intent was to pull new
> busybox binaries into the new initramfs, and keep the old initramfs
> around in order to recover the system.  I did not realize that during
> the package's postinst, existing images would be updated; so, the
> "backup" initramfs image that I had copied also had the new version of
> busybox in it.  As it turns out, the busybox backport was broken (not
> sure if it was the build, or some interaction w/ the rest of the
> system).  Booting using either image would not work, and I had no way to
> recover the system (due to bugs in my custom installer cd, recovery
> didn't seem to work).

the package postinstall explicitly tells what it does:
# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-2.6.17-2-686

so it can only have been overlooked.
 
> I ended up having to reinstall the system using the custom installer cd.
> I was not pleased.  I expect that if I have a working initramfs image
> in /boot, it should remain untouched until I explicitly give permission
> for it to be touched.  

oldstyle initrd-tools and yaird do this,
but they don't have any possiblity to have hooks for other packages.


-- 
maks