On Fri, Apr 14, 2006 at 09:24:22PM +0200, maximilian attems wrote: > > 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.
> update-initramfs isn't a noop, > it happily include all the needed evms root support, > as evms added its hooks and calls update-initramfs. Aha, I was thinking that these update-initramfs hooks worked the same way as things did in the mkinitrd days -- where things were only added to the image if it was determined that they were useful. So if those hooks are adding their bits to the initramfs unconditionally, you're right; there's no worry about needing to call update-initramfs again by hand. What happens if a package like evms is *removed*? That would certainly break evms-on-root systems. But it would already have broken systems that used evms for filesystems other than the rootfs, so perhaps it's not significant. > > 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 > linux-image doesn't directly depend on an initramfs-tools hook like udev > so i don't understand that point. Well, linux-image does depend on linux-initramfs-tool, which must be satisfied before linux-image is configured. But since multiple packages provide linux-initramfs-tool, it's important that none of these packages allow their scripts to return success when they're not in a configured state. The same goes for the update-initramfs scripts: they shouldn't return success when we know we can't guarantee correct operation. > > 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! > ok this indicates 2 bugs: > - initramfs-tools no longer allowed to call update-initramfs > - exit 1 if hook script doesn't get it right > as linux-image will never depend on the hook itself, there is an high > probability that the hook is in state unpacked. Yes, there is a high probability that the hooking package is in state unpacked. I'm not sure this means the hook script must return non-zero, though -- many hook scripts may be usable even before their packages are configured. > > 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. > third bug: disallowing any hook to rebuild it's initramfs After thinking about all of this, I'm leaning toward the opinion that it makes sense for hooks to automatically rebuild the initramfs on initial install *only*. That gives you the benefits of being able to quickly add support for things like evms and lvm to the existing kernels, without as much risk of destabilizing already-working images. > ok, the following hooks install conf files, which may not be unpacked > on linux-image upgrade: evms and udev > searching the ubuntu bugs for the rationale of the update-initramfs > postinst, i get lots of broken upgrades, which were fixed by > dpkg-reconfigure linux-image, so agreeing that current state is not > optimal and that mkinitramfs needs to get stricter. > as example: > https://launchpad.net/distros/ubuntu/+source/initramfs-tools/+bug/32123 > for getting aboves right initramfs-tools needs a solution for > simultaneous linux-image and hook upgrades: > a) you ensure hook is upacked before linux-image > that's the easy one and the hook wouldn't need to do anything. > b) hook is unpacked after: > according to above leads to broken initramfs generation, > thus linux-image is not fully installed > "breaks" potentialy many upgrades Hmm, this can still be handled by having the hooking packages only call update-initramfs on initial install, and making sure that a hook script that's not ready fails explicitly instead of silently. - if linux-image is configured while all hooking packages are in working order, then update-initramfs works fine - if linux-image is configured while a hooking package is still unconfigured, the hook script errors out and configuration of linux-image is deferred - if linux-image is configured, and a hook script is installed afterwards, update-initramfs is called once by each package -- and even if the initramfs generated by the first call isn't bootable, there should still be initramfs'es from previous images that are bootable. And if udev should really call update-initramfs in certain upgrade scenarios as well, then that's also easy for it to do. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature
