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

[Jonas Meurer]

clone 783297 -1 -2
reassign -1 busybox
retitle -1 don't source initramfs.conf in busybox initramfs hook
reassign -2 initramfs-tools
retitle -2 remove busybox hook, leave responsibility to busybox package
severity -2 important
retitle 783297 split initramfs integration into a separate package
severity 783297 wishlist
thanks

This mail clones the original bugreport two times and reassigns the
clones to the busybox and initramfs-tools packages with appropriate
titles. See below for details.

Am 27.12.2015 um 07:35 schrieb Ben Hutchings:
> On Fri, 2015-12-25 at 14:46 +0100, Jonas Meurer wrote:
> [...]
>>
>>> /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.
> 
> This is part of initramfs-tools.

So this busybox initramfs hook should be dropped from initramfs-tools
and responsibility for installing busybox into initramfs be handed over
to the busybox package.

>> *) /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.
> 
> This is actually called zz-busybox, and is part of busybox.  Somehow I
> failed to notice this exists. :-/
> 
>> 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?
> 
> Yes, this is stupid.  We should arrange to properly hand over
> responsibility for installing busybox, and adjust package dependencies
> accordingly.

Ack.

> 
>> 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.
> 
> It should certainly stop doing that.

This is about the bug in busybox: stop sourcing initramfs.conf from the
zz-busybox initramfs hook.

> [...]
>>> 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?
> 
> No, they should only recommend them.   The busybox hook script is
> changed in initramfs-tools 0.121~rc2 to hard fail if busybox is wanted
> but not installed.  If it's dropped in favour of the zz-busybox hook
> script, then I can move that check into mkinitramfs.

So indeed the check needs to be moved to mkinitramfs as soon as
responsibility for installing busybox is handed over to the busybox
package itself.

Am 27.12.2015 um 14:21 schrieb Michael Biebl:
> Am 25.12.2015 um 14:46 schrieb Jonas Meurer:
>> 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.
>
> If you want to cleanly support those two different use cases, it looks
> like the cleanest solution would be, to ship the initramfs integration
> in a separate binary package, say cryptsetup-initramfs-tools.
>
> This subpackage would have a strict dependency on initramfs-tools and
> busybox. The main cryptsetup package could have a recommends on that
> subpackage.

This part is about the cryptsetup package itself: it is suggested to
split the initramfs stuff out into a seperate binary package (I prefer
the name 'cryptsetup-initramfs'). This is a wishlist bug.

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/20160107/132da9ac/attachment.sig>