Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #61565

Bug#765750: initramfs-tools: should probably recreate initrd after installing

Cross-posted to 2 groups.

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

On Fri, 17 Oct 2014 21:10:39 +0200 (CEST) Santiago Vila
<sanvila@unex.es> wrote:
> Package: initramfs-tools
> Version: 0.116
> 
> When I install dracut, a new initrd is generated automatically using dracut.
> 
> If I install initramfs-tools again, dracut is removed but this time a
> new initrd (generated by initramfs-tools) is not generated.
> 
> I see a lot of danger here.
> 
> Either initrds are generated automatically or they are not.
>
> If they are, installing dracut and then reinstalling initramfs-tools
> should leave the system in the same state as before.
> 
> This is particularly important because initrds generated by dracut are
> not always suitable for everybody so the user might reasonably expect
> that reinstalling initramfs-tools should create a "safe" initrd again.
>
> Not sure avout the severity of this bug, but it seems that more and
> more people are using dracut, so this might eventually become a real
> serious problem and will bite us.

The current behaviour doesn't seem right, but at least you get a
warning about it:

    update-initramfs: /boot/initrd.img-4.18.0-rc5-amd64 has been altered
    update-initramfs: Cannot update. Override with -t option.

This check dates from version 0.26, in 2005.  It was the last release
prepared by Jeff Bailey, and all the changes are in a single commit
with little explanation.  Looking at the the state of Debian and the
linux-2.6 package at the time, I think the reasoning must have been
something like:

(1) Multiple initramfs/initrd generators were available and could be
coinstalled.  The configuration file /etc/kernel-img.conf specified
which one kernel packages should invoke ("ramdisk" variable).

(2) Packages that hooked into initramfs-tools would always run update-
initramfs if it existed, and it would immediately update the initramfs,
because triggers hadn't yet been invented.

(3) To keep the alternate initramfs generators working, update-
initramfs therefore had to either (a) check the configuration file to
find out whether initramfs-tools was meant to be used, or (b) keep
track of which initramfs images it created and therefore "owned".

At this point, (1) is no longer true; the "ramdisk" variable is not
honoured and the initramfs generator to be invoked is chosen by
installing one of several conflicting packages.  I think this means
that (3) no longer follows, and whichever of the automatic initramfs
generator packages is currently installed should be considered to "own"
/boot/initrd.img-*.

I will therefore change update-initramfs to behave as if the "-t"
option is always used.

Ben.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had
thought. I realized that a large part of my life from then on was going
to be spent in finding mistakes in my own programs.
                                                 - Maurice Wilkes, 1949

Back to linux.debian.kernel | Previous | Next | Find similar | Unroll thread

Thread

Bug#765750: initramfs-tools: should probably recreate initrd after installing Ben Hutchings <ben@decadent.org.uk> - 2018-07-25 14:10 +0200

csiph-web