Bug#362064: udev: udev tries to write to an installed, working initrd without asking
posting our irc conversation with mdz about current update-initramfs calls:
21:29 <maks> mdz: do you remember why you added to initramfs-tools the update-initramfs call?
21:30 <maks> more precisely to the postinst
21:30 * vorlon perks up
21:30 <maks> the changelog has no notice to an bug report.
21:32 <maks> vorlon: the notes tell to run latest initramfs
21:32 <vorlon> notes?
21:33 <maks> the changelog
21:33 <maks> but afair mdz had nitpicks on update-initramfs
21:33 <maks> i'd be happy to hear those
21:34 <mdz> maks: in order for bugfixes to take effect
21:35 <vorlon> but this comes at the expense of boot config stability
21:39 -!- Amaya_ is now known as amaya
21:45 <Manoj> I would rather have allthe initramfs stuff remain in experimental if it is so commom, and important, for bug fixes to ake effect immediately :)
21:45 <maks> Manoj: you already expressed that, good idea. :-P
21:45 <maks> beside joking with yaird 2.6.14 didn't migrate to testing ;)
21:45 * Manoj goes and stands in the corner now
21:46 <Manoj> maks: I find that acceptable -- if stuff needs working out, there is no burnig hurry to move it into testing
21:47 <maks> 2.6.15 with initramfs-tools allowed d-i release.
21:54 <Manoj> maks: there is no implied criticism for the underlying technology in initramfs-tools.
21:55 <Manoj> (well, would be nice if there was support for encrypted root and swap, but they)
21:56 <maks> Manoj: that's almost there.
21:56 * maks boots from cryptoroot
21:56 <maks> using luks to be more precise
21:58 <Manoj> well, I use dm-crypt, and currently there is no way to convert :(
22:04 <maks> hmm me uses dm-crypt to, baeh
22:05 <maks> ah old cryptsetup
22:06 <Manoj> well, when I started converting my laptop, luks wasn't in Debian
22:06 <dilinger> wait, luks and the old cryptsetup stuff isn't compatible?
22:06 <Manoj> on disk sigs are different
22:06 <dilinger> s/isn't/aren't/
22:07 <dilinger> and there's no conversion? isn't that something the package should take care of? :(
22:07 <dilinger> sarge->etch upgrades are going to suck for people w/ large encrypted disks
22:20 <mdz> vorlon: not really
22:21 <mdz> vorlon: in our experience, it's fixed a lot of problems, and caused few, and in the few cases, we were glad to find the bugs early rather than have them lurk
22:22 <mdz> vorlon: the initramfs contents are very stable from one run to the next (and even on different hardware), at least in ubuntu, unlike with mkinitrd
22:24 <Manoj> so far
22:25 <Manoj> all that means is that you have not, so far, encountered a bug
22:46 <vorlon> mdz: the current behavior also increases the cross-section for the bootloader config being inoperable in the event of a power failure (due to removed but not replaced initramfs images, for instance, or use of lilo requiring a bootloader step); it could also overwrite a hand-crafted initramfs unnecessarily and without warning the user, which is certainly not something users would expect based on our past initrd handling
22:48 <vorlon> maks and jbailey squashed an error in my understanding, though; I was under the impression that initramfs-tools hooks worked like they did for initrd-tools, where stuff is only added to the image if it's known to be needed
23:00 <maks> vorlon: the handcrafted initramfs is _not_ overwritten
23:01 <maks> we have an sha1sum of the initramfs we generate and thus allow to overwrite
23:01 <vorlon> maks: storing checksums somewhere?
23:01 <vorlon> ok
23:02 <vorlon> then my only worry is having the boot config being out of order repeatedly during an upgrade
23:04 <maks> what's "the boot config"?
23:04 <vorlon> boot block+bootloader+initramfs image
23:05 <vorlon> if you have lilo, each change means a not-insignificant window where your system isn't bootable
23:05 <maks> in grub case the window is short
23:05 <vorlon> yes
23:05 <vorlon> not all bootloaders are grub-like, though
23:13 <mdz> vorlon: I don't think it represents a significant increase to those risks (which already exist)
23:14 <mdz> maks: it is overwritten in our case
23:15 <mdz> the same things (and worse) happen when the kernel is upgraded, e.g.
23:15 <mdz> I considered this thoroughly and I feel that it is the right way to go, but do what you feel is best
23:16 <vorlon> mdz: previously, there was no overwriting of the initrd for an installed kernel unless the user ok'ed it explicitly; I think going from that to possibly multiple re-writes of the initramfs per upgrade cycle is a significant increase, particularly for anyone cursed with slow disks
23:17 <maks> vorlon: https://wiki.ubuntu.com/InitramfsUpdates
23:17 <vorlon> I'm not sold either way on this issue right now, though, just trying to weigh the factors
23:17 <mdz> vorlon: since when has the user been prompted about overwriting the initrd?
23:17 <mdz> that certainly wasn't the case at the time we moved to initramfs-tools
23:18 <mdz> but I don't use mkinitrd anymore
23:18 <vorlon> mdz: doesn't k-p always prompt for it, when the overwriting is done by an upgrade of the kernel image?
23:18 <vorlon> mkinitrd never overwrote anything of its own initiative, so had no reason to prompt; but I'm pretty sure k-p does prompt
23:19 <mdz> I don't recall ever seeing such a prompt, and I see no such code in k-p
23:21 <mdz> the change we made was from "initrd is updated when the kernel is upgraded" to s/kernel/& or certain other packages including initramfs-tools/
23:21 <vorlon> hmm, k-p does throw all kinds of warnings when you're installing a kernel version that already exists; maybe I'm just thinking of those
23:23 <micah> Clint: i blame you
23:24 <vorlon> Clintachu, I blame you
23:25 <mdz> maks: that's a different, but related, issue
23:26 <dilinger> vorlon: it doesn't prompt about overwriting the initrd specifically
23:26 <mdz> maks: that's "package foo installs an initramfs-tools hook, but it won't take effect until some unpredictable future time when the kernel is upgraded"
23:26 <mdz> (or rather, the solution to that problem)
23:28 <maks> mdz: indeed that point is important, and what worries me the most atm are the races between linux-image upgrade and not yet unpacked hook. last update-initramfs should get it right.
23:29 <maks> but i see lots of bug reports on the ubuntu side for dapper upgrade that only needed one last dpkg-reconfigure linux-image
23:32 <mdz> maks: indeed, we certainly seem to have a bug remaining there, where it isn't brought fully up to date during the upgrade
23:33 <mdz> maks: I don't think it's a kernel vs. initramfs-tools problem, though, since the kernel depends on initramfs-tools
23:33 <mdz> the initramfs will be generated twice, but it should be correct both times and end up OK
23:33 <mdz> I'm not sure what the cause of that problem is yet
--
maks
Reply to: