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

[Andres Salomon <dilinger@debian.org>]

Hi,

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

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.

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

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.