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
Attachment:
signature.asc
Description: This is a digitally signed message part