# Kicksecure 18: emerg-shutdown causes immediate power-off during boot after LUKS unlock
Environment
- OS: Kicksecure 18, bare metal, LXQt
- Kernel: `6.12.113+deb13-amd64`
- Package: `security-misc-shared 3:54.2-1`
- Storage: Internal NVMe SSD
- Root filesystem: ext4 on LUKS encryption
- Initramfs: dracut
- Hardware: Lenovo laptop, AMD platform
Problem
After entering the LUKS passphrase during a normal boot, the computer abruptly powers off before reaching the login screen.
The issue is reproducible whenever `emerg-shutdown.service` is enabled.
Booting with the following temporary kernel parameters allows the system to start normally:
```text
systemd.mask=emerg-shutdown.service rd.systemd.mask=emerg-shutdown.service
```
No shutdown reason or kernel panic is visible in the journal.
Steps to reproduce
- Enable `emerg-shutdown.service`.
- Reboot normally.
- Enter the LUKS passphrase.
- The system proceeds into normal systemd initialization.
- `emerg-shutdown.service` starts.
- The computer abruptly powers off.
Troubleshooting performed
**1. Recovery mode**
Booting into single-user recovery mode and then running `exit` allowed the system to continue booting successfully.
Booting directly into `multi-user.target` did not resolve the problem.
**2. Disabling emerg-shutdown**
Masking `emerg-shutdown.service` during boot prevents the unexpected power-off.
**4. Testing without boot-device monitoring**
Created a temporary systemd override replacing `ExecStart` with:
```ini
[Service]
Type=simple
ExecStart=
ExecStart=/usr/bin/emerg-shutdown --keys=KEY_LEFTCTRL|KEY_RIGHTCTRL,KEY_LEFTALT|KEY_RIGHTALT,KEY_END
```
the system again powered off during boot.
This suggests that monitoring the NVMe device is not required to reproduce the issue. However, the binary still initializes and processes Netlink events even when `–devices` is omitted.
**5. NVMe and USBGuard**
The root-device detection helper correctly resolves the encrypted root filesystem to its underlying NVMe partition.
Available kernel logs show normal NVMe detection and filesystem mounting, without obvious device disconnection or I/O errors.
USBGuard logs show permitted devices and no obvious blocking event associated with the issue.
Relevant logs
From an unsuccessful boot:
```text
systemd[1]: Starting emerg-shutdown.service - Emergency shutdown when boot media is removed…
emerg-shutdown: path: /
emerg-shutdown: is block device: no
emerg-shutdown: path: /dev/mapper/[REDACTED_LUKS_DEVICE]
emerg-shutdown: is block device: yes
emerg-shutdown: real_dev_path: /dev/dm-0
emerg-shutdown: path: /dev/dm-0
emerg-shutdown: is block device: yes
emerg-shutdown: dm slaves_dir: /sys/class/block/dm-0/slaves
emerg-shutdown: path: /dev/nvme0n1p5
emerg-shutdown: is block device: yes
systemd[1]: Started emerg-shutdown.service - Emergency shutdown when boot media is removed.
```
In a separate failed boot with the keyboard-only override:
```text
systemd[1]: Started emerg-shutdown.service - Emergency shutdown when boot media is removed.
```
The system then powered off unexpectedly. No clear reason was recorded.
The journal excerpts are selected from different failed boots. Identifying values and timestamps have been removed.
Expected behavior
`emerg-shutdown` should remain enabled and permit normal system boot unless the configured emergency key combination is pressed or a monitored boot device is actually removed.
Questions
- Is this a known issue with `security-misc-shared 3:54.2-1`?
- Is there a recommended fix that preserves the emergency keyboard shortcut rather than disabling the service entirely?
I would prefer to keep the emergency shutdown functionality enabled.
Thank you.