Skip to content

90crypt/parse-crypt.sh: Escaping issue leading to corrupted service name (luksx2d... instead of luks\x2d...) when using dracut-systemd #2478

Description

@LeonardBA

Describe the bug
Hello,
I noticed a cosmetic but annoying issue in the initramfs boot logs on a Debian system using Dracut and systemd.

dracut-initqueue tries to start a mispelled service where the backslash of the hex code \x2d (for the dash -) is dropped, turning it into x2d.

Log output:
dracut-initqueue[509]: Failed to start systemd-cryptsetup@luksx2d77c02c01x2d7f4ax2d4eb5x2dbe96x2d808ee478a149.service: Unit systemd-cryptsetup@luksx2d77c02c0

Meanwhile, native systemd successfully finds and starts the correct unit a fraction of a second later:
Starting systemd-cryptsetup@luks\x2d77c02c01\x2d7f4a\x2d4eb5\x2dbe96\x2d808ee478a149.service - Cryptography Setup for luks-77c02c01...

Root cause analysis:
The issue seems to come from modules.d/90crypt/parse-crypt.sh.
While it tries to duplicate the backslash using str_replace to escape it for udev rules generation:
luksname="$(str_replace "$luksname" '' '\')"

The subsequent evaluation or parsing inside the dracut-initqueue loop drops the backslash entirely, causing udev to invoke a non-existent service name (luksx2d...).

Additionally, an explicit type is missing during the systemd-escape call inside dev_unit_name, triggering this warning early in the boot:
systemd-escape[321]: Input 'luks-77c02c01...' is not an absolute file system path, escaping is likely not going to be reversible...

Distribution used
Debian 13 stable

Dracut version
106-6

Init system
Systemd

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugOur bugs

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions