Bug#362064: udev: udev tries to write to an installed, working initrd without asking
initramfs differs from initrd as it's no fs, but just an archive.
you can easily append stuff to it that wasn't inside yet.
On Thu, 13 Apr 2006, Steve Langasek wrote:
> On Thu, Apr 13, 2006 at 08:18:59PM +0200, maximilian attems wrote:
<snipp severity discussion, rm speaks>
> > 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)
sure and point the $bootloader to your new location.
but i bet many user will forget to regnerate your initramfs in those cases.
> 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.
> > 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
linux-image doesn't directly depend on an initramfs-tools hook like udev
so i don't understand that point.
> - 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!
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.
<snipp lvm case>
> 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
> 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.
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
thanks
--
maks
Reply to: