Fedora 35 randomly won't go past LUKS password at boot time

My Fedora 35 Workstsation has a LUKS-encrypted BTRFS drive with the OS and another ext4 LUKS-encrypted drive.

When I boot up, plymouth asks for the password to decrypt the drive that contain the OS.

After putting the password, it shows a progress bar.

After the progress bar, it shows the “enter your password” again, with a “Enter Auth Username” text beneath it.

Now, sometimes this dialog lasts a fraction of a second, then the interface to choose the user is shown.

But some other times plymouth gets stuck here.

How can I fix this?

I tried to check my drive for errors, but no errors were found:

$ sudo btrfs check --force --readonly --check-data-csum /dev/mapper/luks-XXX
Opening filesystem to check...
WARNING: filesystem mounted, continuing because of --force
Checking filesystem on /dev/mapper/luks-XXX
UUID: XXX
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking csums against data
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 52566847488 bytes used, no error found
total csum bytes: 43974356
total tree bytes: 1356103680
total fs tree bytes: 1201094656
total extent tree bytes: 88981504
btree space waste bytes: 235573251
file data blocks allocated: 316809916416
 referenced 78492864512
1 Like

Hello @johnnyjuki ,
So first I think what you are dealing with here is not a filesystem related issue at all. So please don’t force check your butter fs.
This is a laptop with Fedora Linux 35 Workstation installed correct? If you power up with AC connected, it works as expected, but when on battery only, it doesn’t continue after unlocking your luks partition for booting. Just paraphrasing what you stated for my own clarity. There are release notes that you should review since there has been power management changes recently in Fedora Linux which are very likely affecting your current install by way of configuration issues perhaps.

Hi,

I confirm it is still happening with the latest updates.

This is a laptop with Fedora Linux 35 Workstation installed correct?

Yes

If you power up with AC connected, it works as expected, but when on battery only, it doesn’t continue after unlocking your luks partition for booting

Yes

There are release notes that you should review since there has been power management changes recently in Fedora Linux which are very likely affecting your current install by way of configuration issues perhaps.

My power profile is set to “Performance”.

Other than that I don’t know how to debug.

Where can I find the logs for the previous boot?

Does your machine boot a Fedora Live USB ok when on battery only?

The logs for the previous boot are actually whatever logs for boot’s - n till current boot. The command is journalctl -b -n --priority=3 Where n is the number of boots back (to subtract) and --priority=3 means errors. You can also pipe it to grep or egrep if you have a keyword you know is relevant, by doing this journalctl -b -n | grep sleep and it will find any journal entry from the logs with sleep in it for instance.

The problem is unrelated to how the PC is powered, by plug or by battery. I just booted the PC from battery.

I edited the question accordingly.

1 Like

Thanks.

So journalctl -b -0 --priority=3 shows the current boot? I will try that command with -1 when it fails to boot and I am able to boot right afterwards.

Also please see my previous answer.

My first instinct will be:

  • disable fast boot in System Firmware Settings
  • disable suspend to disk

And, I encountered once before:

  • sometimes it give me a graphical UI to enter decryption password
  • sometimes there is just a text mode promot, but entering the correct pass phrase still can continue the boot.

May not be relevant to your situations at all. Just sharing.

1 Like

Hi,

Could you copy and paste the result from sudo grubby --info=ALL on here?

Here you are:

$ sudo grubby --info=ALL
[sudo] password for XXX: 
index=0
kernel="/boot/vmlinuz-5.15.5-200.fc35.x86_64"
args="ro rootflags=subvol=root rhgb quiet"
root="UUID=XXX"
initrd="/boot/initramfs-5.15.5-200.fc35.x86_64.img"
title="Fedora Linux (5.15.5-200.fc35.x86_64) 35 (Workstation Edition)"
id="XXX-5.15.5-200.fc35.x86_64"
index=1
kernel="/boot/vmlinuz-5.15.4-201.fc35.x86_64"
args="ro rootflags=subvol=root rhgb quiet"
root="UUID=XXX"
initrd="/boot/initramfs-5.15.4-201.fc35.x86_64.img"
title="Fedora Linux (5.15.4-201.fc35.x86_64) 35 (Workstation Edition)"
id="XXX-5.15.4-201.fc35.x86_64"
index=2
kernel="/boot/vmlinuz-5.14.18-300.fc35.x86_64"
args="ro rootflags=subvol=root rhgb quiet"
root="UUID=XXX"
initrd="/boot/initramfs-5.14.18-300.fc35.x86_64.img"
title="Fedora Linux (5.14.18-300.fc35.x86_64) 35 (Workstation Edition)"
id="XXX-5.14.18-300.fc35.x86_64"
index=3
kernel="/boot/vmlinuz-0-rescue-XXX"
args="ro rootflags=subvol=root rhgb quiet"
root="UUID=XXX"
initrd="/boot/initramfs-0-rescue-XXX.img"
title="Fedora (0-rescue-XXX) 34 (Workstation Edition)"
id="XXX-0-rescue"

Those arguments looks wrong for me.

I only have experience with / partition encrypted but not with /boot encrypted.

But maybe you could give another result of sudo cat /etc/crypttab, cat /etc/default/grub and cat /etc/fstab and maybe another user here could help you.

Btw if the / is the only partition encrypted, first we could check:

On crypttab it should be at least you could found following content:

luks-1111-your-uuid-disk-2222 UUID=1111-your-uuid-disk-2222 none discard

On /etc/default/grub on the GRUB_CMDLINE_LINUX= should contain:

...
GRUB_CMDLINE_LINUX="rd.luks.uuid=luks-1111-your-uuid-disk-2222 rhgb quiet"
...

The luks-1111-your-uuid-disk-2222 can be check with lsblk and you’ll get on the root partition.

After that run sudo grub2-mkconfig -o /boot/grub2/grub.cfg.

Update:

Just ignore what I said above. Turn out it’s ok with your current grub config. I just tested it.

journalctl -b will show the current boot.

It happened again in the boot before this one.

Here are the logs:

$ journalctl -b -1 --priority=3
-- Journal begins at Thu 2021-07-22 15:23:35 CEST, ends at Sun 2021-12-05 00:56>
Dec 05 00:53:13 fedora kernel: x86/cpu: SGX disabled by BIOS.
Dec 05 00:53:13 fedora kernel: sd 4:0:0:0: [sda] Asking for cache data failed
Dec 05 00:53:13 fedora kernel: sd 4:0:0:0: [sda] Assuming drive cache: write th>
Dec 05 00:53:13 fedora kernel: integrity: Problem loading X.509 certificate -65
Dec 05 00:53:13 fedora kernel: integrity: Problem loading X.509 certificate -65
Dec 05 00:53:28 fedora systemd-udevd[1086]: /etc/udev/rules.d/40-libsane.rules:>
Dec 05 00:53:28 fedora systemd-udevd[1086]: /etc/udev/rules.d/40-libsane.rules:>
Dec 05 00:53:28 fedora systemd-udevd[1086]: /etc/udev/rules.d/S99-2000S1.rules:>
Dec 05 00:53:28 fedora systemd-udevd[1086]: /etc/udev/rules.d/S99-2000S1.rules:>
Dec 05 00:53:31 fedora alsactl[1566]: alsa-lib parser.c:242:(error_node) UCM is>
Dec 05 00:53:31 fedora alsactl[1566]: alsa-lib main.c:1405:(snd_use_case_mgr_op>
Dec 05 00:53:31 fedora alsactl[1566]: alsa-lib parser.c:242:(error_node) UCM is>
Dec 05 00:53:31 fedora alsactl[1566]: alsa-lib main.c:1405:(snd_use_case_mgr_op>
Dec 05 00:53:32 fedora systemd-udevd[1113]: vboxdrv: /usr/lib/udev/rules.d/60-v>
Dec 05 00:53:32 fedora systemd-udevd[1116]: vboxdrvu: /usr/lib/udev/rules.d/60->
Dec 05 00:53:32 fedora systemd-udevd[1113]: vboxnetctl: /usr/lib/udev/rules.d/6>

It happened again in the boot just before this one and 2 boots before this one.

Here are the logs.

How can I deactivate plymouth to see what’s happening? Just uninstall it through dnf?

$ journalctl -b -1 --priority=3
-- Journal begins at Thu 2021-07-22 15:26:04 CEST, ends at Sun 2021-12-05 10:30:41 CET. --
Dec 05 10:25:18 fedora kernel: x86/cpu: SGX disabled by BIOS.
Dec 05 10:25:18 fedora kernel: sd 4:0:0:0: [sda] Asking for cache data failed
Dec 05 10:25:18 fedora kernel: sd 4:0:0:0: [sda] Assuming drive cache: write through
Dec 05 10:25:18 fedora kernel: integrity: Problem loading X.509 certificate -65
Dec 05 10:25:18 fedora kernel: integrity: Problem loading X.509 certificate -65
Dec 05 10:25:33 fedora systemd-udevd[1083]: /etc/udev/rules.d/40-libsane.rules:41 Unknown group 'scanner', ignoring
Dec 05 10:25:33 fedora systemd-udevd[1083]: /etc/udev/rules.d/40-libsane.rules:26: GOTO="libsane_rules_end" has no matching label, ignoring
Dec 05 10:25:33 fedora systemd-udevd[1083]: /etc/udev/rules.d/S99-2000S1.rules:41 Unknown group 'scanner', ignoring
Dec 05 10:25:33 fedora systemd-udevd[1083]: /etc/udev/rules.d/S99-2000S1.rules:26: GOTO="libsane_rules_end" has no matching label, ignoring
Dec 05 10:25:36 fedora alsactl[1563]: alsa-lib parser.c:242:(error_node) UCM is not supported for this HDA model (HDA Intel PCH at 0xa4414000 irq 148)
Dec 05 10:25:36 fedora alsactl[1563]: alsa-lib main.c:1405:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -6
Dec 05 10:25:36 fedora alsactl[1563]: alsa-lib parser.c:242:(error_node) UCM is not supported for this HDA model (HDA Intel PCH at 0xa4414000 irq 148)
Dec 05 10:25:36 fedora alsactl[1563]: alsa-lib main.c:1405:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -6
Dec 05 10:25:36 fedora alsactl[1563]: alsa-lib parser.c:242:(error_node) UCM is not supported for this HDA model (HDA NVidia at 0xa4000000 irq 17)
Dec 05 10:25:36 fedora alsactl[1563]: alsa-lib main.c:1405:(snd_use_case_mgr_open) error: failed to import hw:1 use case configuration -6
Dec 05 10:25:36 fedora alsactl[1563]: alsa-lib parser.c:242:(error_node) UCM is not supported for this HDA model (HDA NVidia at 0xa4000000 irq 17)
Dec 05 10:25:36 fedora alsactl[1563]: alsa-lib main.c:1405:(snd_use_case_mgr_open) error: failed to import hw:1 use case configuration -6
Dec 05 10:25:37 fedora systemd-udevd[1123]: vboxdrv: /usr/lib/udev/rules.d/60-vboxdrv.rules:1 Only network interfaces can be renamed, ignoring NAME="vboxdrv".
Dec 05 10:25:37 fedora systemd-udevd[1108]: vboxdrvu: /usr/lib/udev/rules.d/60-vboxdrv.rules:2 Only network interfaces can be renamed, ignoring NAME="vboxdrvu".
Dec 05 10:25:37 fedora systemd-udevd[1123]: vboxnetctl: /usr/lib/udev/rules.d/60-vboxdrv.rules:3 Only network interfaces can be renamed, ignoring NAME="vboxnetctl".
Dec 05 10:27:15 fedora systemd[1]: Failed to start Forward Password Requests to Wall.
Dec 05 10:27:30 fedora kernel: ACPI BIOS Error (bug): Could not resolve symbol [\_SB.PCI0.LPCB.EC0._Q37.POWS], AE_NOT_FOUND (20210730/psargs-330)
Dec 05 10:27:30 fedora kernel: ACPI Error: Aborting method \_SB.PCI0.LPCB.EC0._Q37 due to previous error (AE_NOT_FOUND) (20210730/psparse-529)
$ journalctl -b -2 --priority=3
-- Journal begins at Thu 2021-07-22 15:26:04 CEST, ends at Sun 2021-12-05 10:31:46 CET. --
Dec 05 10:23:58 fedora kernel: x86/cpu: SGX disabled by BIOS.
Dec 05 10:23:58 fedora kernel: sd 4:0:0:0: [sda] Asking for cache data failed
Dec 05 10:23:58 fedora kernel: sd 4:0:0:0: [sda] Assuming drive cache: write through
Dec 05 10:23:58 fedora kernel: integrity: Problem loading X.509 certificate -65
Dec 05 10:23:58 fedora kernel: integrity: Problem loading X.509 certificate -65
Dec 05 10:24:11 fedora systemd-udevd[1054]: /etc/udev/rules.d/40-libsane.rules:41 Unknown group 'scanner', ignoring
Dec 05 10:24:11 fedora systemd-udevd[1054]: /etc/udev/rules.d/40-libsane.rules:26: GOTO="libsane_rules_end" has no matching label, ignoring
Dec 05 10:24:11 fedora systemd-udevd[1054]: /etc/udev/rules.d/S99-2000S1.rules:41 Unknown group 'scanner', ignoring
Dec 05 10:24:11 fedora systemd-udevd[1054]: /etc/udev/rules.d/S99-2000S1.rules:26: GOTO="libsane_rules_end" has no matching label, ignoring
Dec 05 10:24:14 fedora alsactl[1522]: alsa-lib parser.c:242:(error_node) UCM is not supported for this HDA model (HDA Intel PCH at 0xa4414000 irq 148)
Dec 05 10:24:14 fedora alsactl[1522]: alsa-lib main.c:1405:(snd_use_case_mgr_open) error: failed to import hw:0 use case configuration -6
Dec 05 10:24:14 fedora alsactl[1522]: alsa-lib parser.c:242:(error_node) UCM is not supported for this HDA model (HDA NVidia at 0xa4000000 irq 17)
Dec 05 10:24:14 fedora alsactl[1522]: alsa-lib main.c:1405:(snd_use_case_mgr_open) error: failed to import hw:1 use case configuration -6
Dec 05 10:24:15 fedora systemd-udevd[1068]: vboxdrv: /usr/lib/udev/rules.d/60-vboxdrv.rules:1 Only network interfaces can be renamed, ignoring NAME="vboxdrv".
Dec 05 10:24:15 fedora systemd-udevd[1082]: vboxdrvu: /usr/lib/udev/rules.d/60-vboxdrv.rules:2 Only network interfaces can be renamed, ignoring NAME="vboxdrvu".
Dec 05 10:24:15 fedora systemd-udevd[1068]: vboxnetctl: /usr/lib/udev/rules.d/60-vboxdrv.rules:3 Only network interfaces can be renamed, ignoring NAME="vboxnetctl".

Remove “rhgb quiet” from boot args will allow you to see more during boot time.

1 Like

May be it’s your problem.

I found article about this problem. It give some different scenarios why it’s happen. Linux Mint: Integrity: problem loading X.509 certificate -65 before login.

1 Like

How can I remove those flags?

I always check the ISO before installing the OS.

I won’t disable Secure Boot.

cd /boot/loader/entries/

Within this folder, there are the files named for the entries you can choose when booting. Assuming that your Fedora is up to date, there is one containing “...5.15.6-200.fc35...”.

Open this file with your preferred editor (vi, nano, or whatever), and within the file, there is a line that begins with “options ...”. Within this line, you will find these flags.

After you made the changes, reboot.

Change only the one file! If there are some issues, you can still use the other entries to boot.

It was a service of mine that would wait for a password.

Disabling it solved the problem.

2 Likes