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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
