Ubuntu 22.04 service fails to start after re-encrypting LUKS volume changed partition UUIDs

Environment

Physical server running Ubuntu 22.04 LTS, root on LUKS-encrypted /dev/sda2, re-encryption performed with cryptsetup-reencrypt, /etc/crypttab and /etc/fstab previously referenced by UUIDs, systemd used for boot target and service dependencies.

Symptoms

After completing LUKS re-encryption and rebooting, several systemd services (nginx, custom-app.service) fail to start during boot with 'dependency failed' errors and system enters multi-user.target with services inactive; services start manually after mounting the filesystem.

Observations

journalctl -b shows systemd-unit failures reporting mount point unavailable; fstab mount by UUID failed with 'no such device'; /dev/mapper/cryptroot is present after manual luksOpen but the UUIDs from lsblk -f differ from the entries in /etc/crypttab and /etc/fstab; initramfs still tries to mount old UUID at early boot.

Already attempted

Manually opened LUKS container with cryptsetup luksOpen and mounted root to /mnt; edited /etc/crypttab and /etc/fstab to match new UUIDs and regenerated initramfs with sudo update-initramfs -u; ran systemctl daemon-reload; rebooted once more — services still fail during cold boot but can be started after interactive rescue and mounting the filesystem.

Question

How do I ensure systemd services start automatically on boot after LUKS re-encryption changed UUIDs, and what reversible boot-time checks should I perform to avoid repeated manual intervention?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

Initramfs contains cached old identifiers and was not rebuilt, so early-boot unlock fails 90%

Outdated /etc/crypttab or /etc/fstab entries referencing old UUIDs after re-encryption 80%

Race between device node creation and systemd mount due to missing systemd-cryptsetup service enabled in initramfs 35%

Summary

Re-encryption changed block device identifiers (UUIDs) referenced by crypttab/fstab and the initramfs used at early boot still contains the old identifiers, causing mounts and dependent services to be skipped at the systemd init stage. Systemd treats failed mounts as failed dependencies and prevents services from activating. Updating /etc/crypttab and /etc/fstab alone is insufficient until the initramfs used by the bootloader is regenerated and the boot-time cryptsetup hooks are updated. Other possibilities include wrong crypttab formatting, mismatch between device-mapper names and crypttab entries, or missing dracut/initramfs hooks for unlocking encrypted volumes early.

Suggested Fixes

Diagnostic step 1

Boot into a rescue environment or single-user mode and verify current partition UUIDs with lsblk -f and blkid.

Diagnostic step 2

Update /etc/crypttab and /etc/fstab to use the new UUIDs or persistent /dev/mapper names; do not remove existing entries until verified.

Diagnostic step 3

Regenerate the initramfs used by your kernel(s) with sudo update-initramfs -u -k all, then inspect /boot for expected initramfs timestamp changes.