Boot failing: Dracut-initqueue rm: cannot remove /lib/dracut/hooks/initqueue/finished/devexists-.....sh: Read-only file system

Question

I started using Dracut around a year ago to use Yubikey Pin unlock and everything was fine a few days ago. After a routine apt update on my LUKS encrypted Debian Trixie machine the linux kernel was updated to 6.7.12-amd64. Now every boot gets stuck with the following errors:

Dracut-initqueue rm: cannot remove '/lib/dracut/hooks/initqueue/finished/devexists-<some more stuff incl. the UUID of the boot partition>.sh': Read-only file system
Dracut-initqueue rm: cannot remove '/lib/dracut/hooks/initqueue/finished/devexists-<some more stuff incl. the UUID of the EFI partition>.sh': Read-only file system

Here is a picture of the boot process:

There's still a prompt for the LUKS password (or Yubikey pin) and the disk seems to be decrypted fine after entering. However, afterwards there's an endless systemd start job for the LVM volume containing the root partition.

Here are the partitions incl. UUIDs. The root partition resides in a LUKS container:

sdb                     8:16   0 476,9G  0 disk                                     
├─sdb1                  8:17   0   243M  0 part  /boot/efi         DB08-0D0C
├─sdb2                  8:18   0   954M  0 part  /boot             74559e4f-03f0-46db-98f3-fa2633484d4c
└─sdb3                  8:19   0 475,8G  0 part                    3bce844f-0111-4b31-b551-4b82dbfc88bf
  └─debianlvm         253:1    0 475,8G  0 crypt                   bSc1Y8-yMKj-dfUJ-RSmh-9FrQ-BzcE-yvmmcj
    ├─emzwolvm-debian 253:2    0 111,8G  0 lvm   /                 7c6c5be7-4ddf-4ba5-beef-b29bf92322a1
    └─emzwolvm-vms    253:3    0   364G  0 lvm                     d43f0f69-dbb5-4a04-9099-963dd37dab8a

This is the corresponding grub menu entry:

menuentry 'Debian GNU/Linux' --class debian --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-7c6c5be7-4ddf-4ba5-beef-b29bf92322a1' {
    load_video
    insmod gzio
    if [ x$grub_platform = xxen ]; then insmod xzio; insmod lzopio; fi
    insmod part_gpt
    insmod ext2
    set root='hd1,gpt2'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd1,gpt2 --hint-efi=hd1,gpt2 --hint-baremetal=ahci1,gpt2  74559e4f-03f0-46db-98f3-fa2633484d4c
    else
      search --no-floppy --fs-uuid --set=root 74559e4f-03f0-46db-98f3-fa2633484d4c
    fi
    echo    'Loading Linux 6.7.12-amd64 ...'
    linux   /vmlinuz-6.7.12-amd64 root=/dev/mapper/emzwolvm-debian ro rootflags=subvol=@rootfs  quiet
    echo    'Loading initial ramdisk ...'
    initrd  /initrd.img-6.7.12-amd64

Here's /etc/crypttab:

emzwo_crypt UUID=3bce844f-0111-4b31-b551-4b82dbfc88bf none fido2-device=auto,token-timeout=1,luks,discard
home_crypt UUID=75b97063-8c09-4089-9ea2-a82ffea5ee34 /root/luks_keys/luks_home_keyfile.key luks,discard

And /etc/fstab:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/emzwolvm-debian /               btrfs   defaults,subvol=@rootfs 0       0
/dev/mapper/emzwolvm-vms /vms               btrfs   defaults 0       2
UUID=74559e4f-03f0-46db-98f3-fa2633484d4c /boot           ext4    defaults        0       2
UUID=DB08-0D0C  /boot/efi       vfat    umask=0077      0       1
/dev/mapper/home_crypt /shared_home           ext4    defaults        0       2

What I tried so far, everything without a difference:

• booting from the older kernel
• booting from a live stick, chroot into system, regenerate grub and initramfs via dracut
• Checking if there are btrfs snapshots - nope (but created one now...)
• replacing the "ro" with "rw" in linux command line of the grub entry

Not tested:

• switching back to initramfs-tools

I have no clue what was happening. Any ideas how to fix this?

Thanks in advance.

Answer 1

I solved the problem installing initramfs-tools again. This is what I've done:

• boot into a live OS,
• create a chroot environment and
• install initramfs-tools

Make sure to use the exact names for unlocking your LUKS containers as stated in /etc/crypttab as the containers won't be recognized on boot otherwise and you have to fix that on the initramfs rescue shell (guess who didn't. Fixed that afterwards by changing /etc/crypttab to the new names and recreated initramfs).

My FIDO2 unlock doesn't work that way anymore but at least I have a working system.

The initial problem must have something to do with an automatic dracut update happening shortly before:

• new package installed: dracut-install:amd64 (060+5-8, automatic)
• dracut:amd64 upgraded from 060+5-1 to 060+5-8)
• dracut-core:amd64 upgraded from 060+5-1 to 060+5-8

Hope that helps anybody out there.