Clevis package: dracut hooks incompatible with dash and non-systemd environment

[mmdbalkhi]

Is this a new report?

Yes

System Info

Void 6.19.3_1 x86_64 GenuineIntel uptodate hold rrrFFFFFF

Package(s) Affected

clevis-20_2

Does a report exist for this bug with the project's home (upstream) and/or another distro?

latchset/clevis#456

Expected behaviour

The system should automatically detect the TPM2-bound LUKS2 volume during the dracut initramfs stage, unseal the key using the TPM2 (without any user interaction), and unlock the device seamlessly so the boot process continues normally. Clevis-dracut hooks should execute correctly under Void's environment (/bin/sh -> dash, no systemd in initramfs).

Actual behaviour

The boot process fails in one of the following ways:

• Syntax errors or failures in Clevis hooks due to bashisms when scripts are executed with dash (e.g. [[ ]] , <<<, etc.).
• Errors related to undefined DRACUT_SYSTEMD variable in /init (/usr/lib/dracut/modules.d/99base/dracut-lib.sh)
• Even after manually editing files like /usr/bin/clevis-luks-common-functions to be dash, new errors appear (such as DRACUT_SYSTEMD is not set).

As a result, automatic TPM2-based unlocking does not work out of the box on Void Linux.

Steps to reproduce

1. Bind a LUKS2 partition

   sudo clevis luks bind -d /dev/nvme0n1p2 tpm2 '{}'
   

2. Add Clevis-related modules to dracut config:
   Create /etc/dracut.conf.d/99-clevis.conf with:

   add_dracutmodules+=" network clevis crypt "
    install_items+=" /usr/bin/clevis /usr/bin/clevis-decrypt-tang "
   

3. Regenerate the initramfs:

   sudo dracut -f
   

4. Reboot the system.

Additional troubleshooting:

• Manually converted /usr/bin/clevis-luks-common-functions (and some other hooks) from bash to POSIX /bin/sh to fix initial syntax errors.
• Switched the entire initramfs to use bash as /bin/sh
• Added a fallback for the DRACUT_SYSTEMD variable in the affected scripts (e.g. DRACUT_SYSTEMD=${DRACUT_SYSTEMD:""}).

Even after these changes, the boot process still failed :(

[ahesford]

We ship the upstream modules as is. Take up this issue with the upstream source.

The module claims to work without systemd, so if it doesn't, either the module is doing something wrong or your configuration is wrong; they will be able to help identify the cause.

The hook uses a /bin/sh shebang but sources a bash script. This is just plain wrong. They need to fix their shebangs.