On Thu, Apr 13, 2006 at 08:18:59PM +0200, maximilian attems wrote: > i don't agree with the severity of this bug. > i'll present my arguments below. > > On Thu, Apr 13, 2006 at 10:29:06AM +0200, maximilian attems wrote: > > We've had this conversation before on IRC, and I don't believe there is any > > evidence that this is the case. Until you can show some, I regard this bug > > as release-critical. > we had a short exchange about it, i don't remember any conclusion. > regarding the severity i may cite yourself #353809 > -- snipp > "Nothing in this report has described actual breakage. If using > initramfs-tools to generate initramfs images prevents the system from > booting, that is indeed a critical bug, but that's not the bug that Jonas > filed." > -- Yes; that bug was filed at severity: critical, which was definitely the incorrect severity for the bug that was being reported. The submitter of that bug didn't argue at the time that the bug should be severity: serious; since then I've been convinced myself that this should be treated as a serious bug, at least pending the resolution of some outstanding questions. > by design initramfs-tools needs that: > a) allows each hook to add it's boot device detection scripts > if you want evms root you simply install evms. > thanks to it's initramfs hook you get evms root support. You can never "simply install evms" and get evms root support. There are other configuration changes that must be made to the installation to set up a system for evms root that isn't currently using it, including: - setting up an evms volume (probably) - changing the references in /etc/fstab to point to the new device (definitely) Having evms call update-initramfs at install time is completely gratuitous, because the system *won't* be set up for evms at the time of the evms postinst: either the update-initramfs will be a complete no-op and have to be repeated later once evms is set up, or it won't be a no-op -- meaning it will likely have done something undesirable, unrelated to evms. > b) prevents races in install order: > mkinitramfs-kpkg run by newer linux-image when not _all_ hooks are > yet unpacked, so latest updated initramfs has all content. > thus _only_ latest initramfs gets updated. And this is bad, because all you're doing is covering up bugs. The bug is either: - some package in the chain has broken dependencies, so packages it should depend on are not guaranteed to be in 'installed' state at the time its postinst runs, or - a package provides functionality which is called opportunistically by packages that do not (and should not) depend on it, but the package is not guaranteed to do the right thing when the interface is called while in state: unpacked. Based on the bug you pointed me to in the previous IRC discussion, it appears that there is (or was) an instance of the second of these in initramfs-tools -- where update-initramfs was called, overwrote the initrd with something broken, and exited 0. Repeatedly calling update-initramfs until it does the right thing isn't a good answer. My system shouldn't be left unbootable by an interrupted apt upgrade, nor should it be left unbootable if I try to build an initramfs by hand while the package is unconfigured (perhaps without being aware of this). Now, let's look closer at the race condition issue, which I admit is a real concern. Suppose that you have a system with root on lvm2 already, and initramfs-tools (or linux-image) is configured while lvm2 is unpacked but not yet configured -- and because it's not configured, it can't do the right thing. What should happen is: - update-initramfs calls the lvm2 hook script - the lvm2 hook script, because lvm2 is not currently usable, throws an error - update-initramfs catches the error, and the postinst of whichever package is involved aborts -- allowing the admin to retry after the lvm2 package has been configured. With the current behavior, where you rebuild the initramfs repeatedly and hope it comes out right at the end, you are throwing away very valuable information when it is possible to *know* that an initramfs is not bootable. And once you stop doing that (which isn't acceptable in the first place), you stop needing to update the initramfs separately for every hook because you'll get it right the first time the initramfs is written out! > c) allows moving around root > currently due to lvm2+mdadm not having yet the initramfs-tools hooks > the user does have to regenerate the initramfs when moving to lvm2 > root. as the initramfs was generated before lvm2 installed. So? See above wrt evms; the same comments apply here, only moreso because it's almost completely impossible that there will have been an lvm volume to be configured as the rootfs before the lvm2 package was installed (whereas evms may be pointing at some volume set up with an already-installed lvm2). So I don't see any real benefit to having all of these tools rebuilding the initramfs repeatedly during an upgrade cycle. Theoretically it would be nice to know as soon as a package is installed that it will break the initramfs, but using update-initramfs doesn't do this: the only way to be sure whether a new initramfs is broken is to try to boot from it. Since we can't force reboots during an upgrade (especially not once for each hook!), there is no significant increase in predictability by using this method, and users are better off if the upgrade doesn't touch the existing, working initramfs images at all. Now, Marco has a persuasive argument that udev version skew between rootfs and initramfs may cause problems; but that's not the problem that you claim this design addresses, and if that *is* the problem we need to address there are way we could do it with much less collateral damage. I would be more than happy to discuss with you guys possible designs for this; at the moment, though, I'm afraid I think the problem space is too ill-defined and needs to be clarified before I can comment intelligently on how to solve the problem. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature