[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#362064: udev: udev tries to write to an installed, working initrd without asking

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

> > 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

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

> > 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.

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

Reply to: