Booster package template and libusb dependencies

[NickSlash]

I’ve noticed a couple of things while using Booster and wasn’t sure whether either is something that should be reported as a bug?

During installation, busybox: true is added to config.yaml. I assume this is intended to enable the emergency shell, but according to the Booster documentation, busybox should be added to extra_files rather than as its own key. This doesn’t break anything so didn't want to raise it as a bug?

My second issue was with using a Clevis/YubiKey challenge-response binding on a LUKS volume.

I added ykchalresp from ykpers to extra_files. During boot, Booster did attempt to use it to unlock the volume, but it failed because of a libusb issue. When Booster generates the initramfs it determines the dependencies of binaries added through extra_files and includes them in the image. One of the dependencies of ykchalresp is libusb-0.1.so.4, so Booster includes both libusb-0.1.so.4 and libusb-0.1.so.4.4.4.

libusb-0.1 is provided by libusb-compat and the files picked up by booster aren't enough as libusb-1.0 is required too. As a result, ykchalresp doesn't work during early boot. I worked around this by adding the newer libusb libraries to extra_files resulting in:

extra_files: ykchalresp,/lib/libusb-1.0.so.0,/lib/libusb-1.0.so.0.5.0)

I was wondering if there is a way the dependency could be picked up but cant think of a reasonable way for it to be fixed on the package side. Adding them as extra_files in the template would work but that doesn't address the actual problem and not everyone needs the libraries. Any other methods would likely need to be dealt with in Booster itself rather than from the package.

Looking at the ykpers template, it looks like configure_args could be updated to use libusb1 as backend instead of libusb. (yubico recommended this too).

So a bit of a question, but also just wanted to share as I couldn't find much info on the libusb issue.