After upgrade of f44 server boot is failing - crypttab processing changed by systemd

Ask Fedora
, , ,
1

Today I updated my f44 server and it failed to reboot successfully.
The reasons as far as I can tell is that it’s not unlocking all the luks encrypted volumes.

I have 3 luks volumes

  • /
  • /var
  • /shares - my SMB shares stuff.

I can edit the config of the system to investigate and fix what’s wrong.

First I stripped down /etc/fstab to only /, /var and /boot.
Then I reorder the 3 entries in the /etc/crypttab to list /, /var then /shares.
I have turned off all services that depend on the /shared being mounted.
booting an old kernel does not fix the issue so it’s something else that updated.

I’m dropped in the emergency shell. But all to often as I attempt to investigate and fix the system the emergency shell stops, I lose the shell, and I end up with a hung system that I cannot start a console on to proceed with debugging.

  1. How do I stop emergency shell from stopping?
  2. Any idea what changed in the last week around /etc/crypttab processing?
  3. I have a rescue SSD that I can use to mount the systems file systems then chroot into the system. Will dnf undo work from the chroot?
2

By commenting out /var in /etc/fstab I have the system booting.

I reviewed all the packages updated.

There is a new systemd. I have downgraded systemd and I have a working system again.

Bad version is: 259.6-1
Working is: 259.5-1

I’ll have to raise a BZ about this tomorrow…

4

It’s of little use, but to have explicit confirmation of what can be already guessed:

I have no issues with 259.6-1 , f44 kde (7.0.11-200). I have encrypted file systems. However, my /var is a btrfs subvolume and part of the root file system, although it is a separated mount point (subvolume). So from the perspective of unlocking (dmcrypt/cryptsetup), /var is not separated in my case. Just to add complementary information that could become relevant in a bug report at some point.

It would be interesting to have confirmation of someone else who has a separated /var already on the device level.

5

Raised as 2487442 – fail to boot when / and /var are encrypted

6

See this comment on the BZ 2487442 – fail to boot when / and /var are encrypted
tl;dr it’s a systemd bug