[pkg-cryptsetup-devel] Bug#783297: Bug#783297: breaks initramfs if BUSYBOX=n

[Jonas Meurer]

Hi Michael, hi Ben,

Am 26.04.2015 um 01:35 schrieb Michael Biebl:
> On Sat, 25 Apr 2015 16:22:13 +0200 Michael Biebl <biebl at debian.org> wrote:
>> if the cryptsetup package is installed, it also installed a
>> initramfs-tools hook.
>>
>> I use BUSYBOX=no in initramfs.conf, but the  cryptroot hook copies
>> /bin/busybox to the initramfs nonetheless.
>>
>> As a result, the initramfs is unable to boot the system
> 
> I looked into this in more detail, and the culprit seems to be
> /usr/share/initramfs-tools/conf-hooks.d/cryptsetup
> which forcefully set's
> BUSYBOX=y.

Yes, cryptsetup initramfs scripts do depend on busybox. At least this
was the case some years ago.

As cryptsetup can be used without initramfs (e.g. only home partition or
removable storage encrypted), the cryptsetup package doesn't depend on
"initramfs-tools, busybox" but merely recommends them.

> /usr/share/initramfs-tools/hooks/busybox will see the BUSYBOX=y setting
> and copy the busybox binary.
> 
> /usr/share/initramfs-tools/hooks/zz-busybox sources
> /etc/initramfs-tools/initramfs.conf, therefor BUSYBOX=n will be set
> again, and the symlinks are not created.

Honestly, this looks like a bug in busybox to me. What's the reason for
the two busybox initramfs hook scripts at all?

*) /usr/share/initramfs-tools/hooks/busybox copies bin/busybox to the
   initramfs and links /bin/sh to it without sourcing initramfs.conf.
*) /usr/share/initramfs-tools/hooks/zz-busybox-initramfs sources
   initramfs.conf, removes busybox binary from initramfs if existent,
   and copies bin/busybox to initramfs and links all aliases provided
   by busybox to it.

I don't understand the following:

What's the purpose of /usr/share/initramfs-tools/hooks/busybox at all,
if changes are reverted by
/usr/share/initramfs-tools/hooks/zz-busybox-initramfs later on anyway
and redone in a slightly different fashion?

Why does /usr/share/initramfs-tools/hooks/zz-busybox-initramfs source
initramfs.conf? The BUSYBOY variable is exported by mkinitramfs anyway.

The simplest fix to this bug would be to stop sourcing initramfs.conf in
hooks/zz-busybox-initramfs.

> The result is a broken initramfs.
> 
> I'm not sure, what is supposed to take precedence in such a case: The
> configuration in /etc/initramfs-tools/initramfs.conf or
> /usr/share/initramfs-tools/conf-hooks.d/cryptsetup and if it's a bug in
> cryptsetup which forcefully overrides BUSYBOX= or if it's a bug in
> busybox, which sources /etc/initramfs-tools/initramfs.conf in
> /usr/share/initramfs-tools/hooks/zz-busybox and therefor doesn't respect
> the settings which are set via conf-hooks.d.

To my understanding, the purpose of
/usr/share/initramfs-tools/hooks-conf.d is to provide a place where
packages that include an initramfs hook script can overwrite settings to
initramfs.conf without altering the config file itself. In other words,
this directory is like an include directory for initramfs.conf. This
implies, that every script which explicitly uses/sources initramfs.conf,
needs to honour this include directory as well.

In fact, we (Guilhem Moulin and me) discuss a related topic with the
initramfs-tools maintainers in bugreport #807527[1] at the moment. In
our eyes, initramfs-tools should provide a clear API or best practice
for custom initramfs hook configuration.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807527

> If cryptsetup really requires busybox and forcefully sets BUSYBOX=y, why
> does the cryptsetup package not depend on busybox?

See above.

> I see several possible fixes here
> 
> a/ /usr/share/initramfs-tools/hooks/zz-busybox doesn't source
> /etc/initramfs-tools/initramfs.conf directly and as a result respects
> settings from hooks directories.

If there's no reason for sourcing initramfs.conf in hooks/zz-busybox,
then this definitely is the way to go.

> b/ /usr/share/initramfs-tools/conf-hooks.d/cryptsetup drops the
> BUSYBOX=y line. And if this is not an option, because cryptsetup
> requires busybox, then this should be reflected in the package
> dependencies accordingly by making the Recommends a Depends.

Do you think that the cryptsetup packages should depend on
initramfs-tools and busybox despite the fact that they're usable without?

Cheers
 jonas


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-cryptsetup-devel/attachments/20151225/d2b625dc/attachment.sig>