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