Bug#771379: linux-image-3.16-0.bpo.3-amd64: backport kernels not booting when root file system is on an LVM volume
Ben Hutchings <ben@decadent.org.uk> writes:
> Control: retitle -1 Dependencies in backport cause aptitude to favour dracut
>
> On Sat, 2014-11-29 at 19:20 +0100, Julien Cristau wrote:
>> On Fri, Nov 28, 2014 at 23:45:34 +0100, lee wrote:
>>
>> > Package: src:linux
>> > Version: 3.16.5-1~bpo70+1
>> > Severity: important
>> >
>> > + do an installation that has the root file system on an LVM volume
>> >
>> > + once finished, install the backports kernel
>> > this removes initramfs-tools because the backports kernel uses
>> > dracut
>> >
>> It shouldn't. You need to install initramfs-tools from backports
>> though.
>
> The wheezy-backports kernel packages have a dependency on
> initramfs-tools (>= 0.110~) | linux-initramfs-tool. They also have a
> Breaks: line for older initramfs-tools versions.
>
> apt-get fails to resolve this unless you add
> 'initramfs-tools/wheezy-backports' or '-t wheezy-backports' to the
> install command
>
> aptitude, however, proposes to replace initramfs-tools with dracut
> (which provides linux-initramfs-tool). If you keep answering 'n', it
> eventually proposes upgrading initramfs-tools to the version in
> wheezy-backports.
I wasn't too happy with what aptitude suggested and resolved the
dependency problems by manually purging initramfs-tools and installing
dracut (since it didn't occur to me that I might install initramfs-tools
from backports --- I thought the newer kernel does need dracut).
And somehow, you can easily end up with all kernels removed if you're
not particularly careful: Aptitude may remove the default kernel and
then simply not install the backports kernel for some reason (probably
because because it resolves dependencies like that).
It might ask you if you really want to remove the currently running
kernel, and you're likely to answer "yes" because you're switching to
the backports kernel anyway (and are under the impression that the
default kernel cannot remain installed because it requires
initramfs-tools which you had to remove) ... Then you try to reboot
because you're unaware that the backports kernel hasn't been installed
and find yourself having to boot a rescue system to install a kernel
(after wondering whether the hardware you're installing on is somehow
broken).
Perhaps a warning could be added to aptitude which comes up when you
quit aptitude without having a kernel installed.
> I think that I can deal with this in the backport by either
> (a) removing linux-initramfs-tool as a dependency, or
> (b) adding a versioned alternate dependency on dracut, that is not
> satisfied by stable,
> though neither of those is very satisfactory.
(c) remove from dracut that it provides initramfs-tools and have the
backports kernel require the backports initramfs-tools package
Apparently dracut doesn't exactly provide initramfs-tools for otherwise
the backports kernel wouldn't get stuck during boot when initramfs-tools
is not installed but dracut is while the root fs is on an LVM logical
volume. And when the backports-kernel requires initramfs-tools from
backports, users will be inclined to install it.
If I had to choose between only (a) and (b), I would go for (a). In any
case, why isn't dracut a sufficient replacement for initramfs-tools
despite providing linux-initramfs-tool?
I don't know about other software from backports, though. Dependencies
could be a more general problem, affecting many packages. How are users
supposed to deal with this?
And BTW, dracut has the huge advantage that you can explicitly exclude
modules from being included into the initrd image. With
initramfs-tools, I still haven't found a way to exclude the bnx2 and
e1000e modules (other than moving them away from /lib/modules/ before
updating the initrd image and putting them back after). They must not
be loaded so early because I'm passing network cards through to domUs,
which is impossible when their modules are loaded from the initrd image.
--
Again we must be afraid of speaking of daemons for fear that daemons
might swallow us. Finally, this fear has become reasonable.
Reply to: