Bug#783297: [pkg-cryptsetup-devel] 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




signature.asc
Description: OpenPGP digital signature

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

[Michael Biebl]

Am 25.12.2015 um 14:46 schrieb Jonas Meurer:
> Am 26.04.2015 um 01:35 schrieb Michael Biebl:
>> On Sat, 25 Apr 2015 16:22:13 +0200 Michael Biebl  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.

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.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

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

[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.

> *) /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.

> 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.

[...]
> > 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.

Ben.

-- 
Ben Hutchings
Power corrupts.  Absolute power is kind of neat.
   - John Lehman, Secretary of the US Navy 1981-1987

signature.asc
Description: This is a digitally signed message part

Bug#783297: [pkg-cryptsetup-devel] 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  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




signature.asc
Description: OpenPGP digital signature

Bug#783297: breaks initramfs if BUSYBOX=n

[Michael Biebl]

On Sat, 25 Apr 2015 16:22:13 +0200 Michael Biebl bi...@debian.org wrote:
 Package: cryptsetup
 Version: 2:1.6.6-5
 Severity: grave
 
 Hi,
 
 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'm getting
 Begin: Running /scripts/init-bottom ... done
 /init: exec: line 338: switch_root: not found
 ...Kernel panic -n not syncing: Attempted to kill init
 
 
 To reproduce the bug, make sure you have the busybox package installed
 (which it is, by default), set BUSYBOX=n in
 /etc/initramfs-tools/initramfs.conf and run update-initramfs -u and
 reboot.
 


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.

/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.

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.


I've CCed the initramfs-tools and busybox maintainers for their input.


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

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.

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.






-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?




signature.asc
Description: OpenPGP digital signature

Bug#783297: breaks initramfs if BUSYBOX=n

[Michael Biebl]

Package: cryptsetup
Version: 2:1.6.6-5
Severity: grave

Hi,

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'm getting
Begin: Running /scripts/init-bottom ... done
/init: exec: line 338: switch_root: not found
...Kernel panic -n not syncing: Attempted to kill init


To reproduce the bug, make sure you have the busybox package installed
(which it is, by default), set BUSYBOX=n in
/etc/initramfs-tools/initramfs.conf and run update-initramfs -u and
reboot.

Be careful to either test this in a VM or keep a rescue media at hand.




-- Package-specific info:
-- /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.16.0-4-amd64 
root=UUID=5c503ec2-6528-44bb-9ff5-aa2687aa9706 ro quiet splash 
systemd.show_status=true

-- /etc/crypttab
# target name source device key file  options

-- /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# file system mount point   type  options   dump  pass
proc/proc   procdefaults0   0
# / was on /dev/sda7 during installation
UUID=5c503ec2-6528-44bb-9ff5-aa2687aa9706 /   ext4
errors=remount-ro 0   1
# /home was on /dev/sda6 during installation
UUID=7652cf98-e671-47ea-80d6-02be15580bb5 /home   ext4defaults  
  0   2
# swap was on /dev/sda5 during installation
UUID=c0d2bc19-898f-4306-a734-85e547e249f0 noneswapsw
  0   0

LABEL=Data  /mnt/data   ntfs-3g user,noauto,comment=systemd.automount   
0   0

LABEL=Fedora/mnt/fedora ext4noauto  0   0
LABEL=Ubuntu/mnt/ubuntu ext4noauto  0   0
LABEL=Asteria   /mnt/ssd ntfs-3g noauto,nofail,user,x-gvfs-show 0 0
#LABEL=BACKUP/mnt/usb   ext3auto0   2
#192.168.178.86:/srv/nfs /mnt/backup nfs _netdev 0 0

-- lsmod
Module  Size  Used by
vhost_net  17307  1 
vhost  22500  1 vhost_net
macvtap17526  1 vhost_net
macvlan18315  1 macvtap
tun26385  3 vhost_net
cpuid  12663  0 
ctr12927  3 
ccm17577  3 
xt_CHECKSUM12471  1 
iptable_mangle 12536  1 
ipt_MASQUERADE 12594  3 
iptable_nat12646  1 
nf_nat_ipv412912  1 iptable_nat
nf_nat 18241  3 ipt_MASQUERADE,nf_nat_ipv4,iptable_nat
nf_conntrack_ipv4  18448  2 
nf_defrag_ipv4 12483  1 nf_conntrack_ipv4
xt_conntrack   12681  1 
nf_conntrack   87424  6 
ipt_MASQUERADE,nf_nat,nf_nat_ipv4,xt_conntrack,iptable_nat,nf_conntrack_ipv4
ipt_REJECT 12465  2 
xt_tcpudp  12527  6 
iptable_filter 12536  1 
ip_tables  26011  3 iptable_filter,iptable_mangle,iptable_nat
x_tables   27111  8 
xt_CHECKSUM,ip_tables,xt_tcpudp,ipt_MASQUERADE,xt_conntrack,iptable_filter,ipt_REJECT,iptable_mangle
bridge106102  0 
stp12437  1 bridge
llc12745  2 stp,bridge
vmnet  50245  13 
ppdev  16782  0 
parport_pc 26300  0 
parport35749  2 ppdev,parport_pc
fuse   83350  7 
vmw_vsock_vmci_transport25862  0 
vsock  30772  1 vmw_vsock_vmci_transport
vmw_vmci   55383  1 vmw_vsock_vmci_transport
pci_stub   12429  1 
vboxpci23077  0 
vboxnetadp 25443  0 
vboxnetflt 23324  0 
vmmon  81251  0 
vboxdrv   340067  3 vboxnetadp,vboxnetflt,vboxpci
binfmt_misc16949  1 
joydev 17063  0 
hid_generic12393  0 
hid_microsoft  12578  0 
usbhid 44460  0 
cdc_mbim   12825  0 
ecb12737  0 
hid   102264  3 hid_generic,hid_microsoft,usbhid
iTCO_wdt   12831  0 
iTCO_vendor_support12649  1 iTCO_wdt
x86_pkg_temp_thermal12951  0 
intel_powerclamp   17159  0 
intel_rapl 17356  0 
coretemp   12820  0 
uvcvideo   79005  0 
videobuf2_vmalloc  12816  1 uvcvideo
videobuf2_memops   12519  1 videobuf2_vmalloc
cdc_ncm26618  1 cdc_mbim
videobuf2_core 47787  1 uvcvideo
usbnet 30844  2 cdc_mbim,cdc_ncm
v4l2_common12995  1 videobuf2_core
videodev  126451  3 uvcvideo,v4l2_common,videobuf2_core
mii12675  1 usbnet
kvm_intel 139116  3 
cdc_wdm17427  1 cdc_mbim
media