Boot takes 2 minutes before LUKS decrypt screen shows

Hello,

When I boot my computer it takes roughly 2 minutes (give or take another 1, I didn’t time it) before the drive decrypt screen shows.

There are tools that can provide insight into the boot timing.

What do these commands report?

systemd-analyze
systemd-analyze critical-chain

You might need to see kernel messages for clues.

sudo journalctl -b 0 -k
1 Like
systemd-analyze
Startup finished in 12.256s (firmware) + 1min 4.271s (loader) + 2.394s (kernel) + 40.545s (initrd) + 10.123s (userspace) = 2min 9.590s 
graphical.target reached after 10.123s in userspace.

loader is slow at 1min 4s.
initrd is slow at 40s. Does this include the LUKS work?


systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.


graphical.target @10.123s
└─multi-user.target @10.123s
  └─rsyslog.service @10.087s +35ms
    └─network-online.target @10.085s
      └─NetworkManager-wait-online.service @3.150s +6.934s
        └─NetworkManager.service @2.294s +853ms
          └─network-pre.target @2.293s
            └─firewalld.service @1.941s +352ms
              └─polkit.service @1.903s +35ms
                └─basic.target @1.897s
                  └─dbus-broker.service @1.873s +15ms
                    └─dbus.socket @1.869s +321us
                      └─sysinit.target @1.867s
                        └─systemd-resolved.service @1.828s +38ms
                          └─systemd-tmpfiles-setup.service @1.764s +61ms
                            └─local-fs.target @1.762s
                              └─boot-efi.mount @1.739s +22ms
                                └─boot.mount @1.703s +35ms
                                  └─systemd-fsck@dev-disk-by\x2duuid-4dfb131c\x2d0c1d\x2d44a7\x2dbe4c\x2d1f289ff67092.service @909ms +29ms
                                    └─dev-disk-by\x2duuid-4dfb131c\x2d0c1d\x2d44a7\x2dbe4c\x2d1f289ff67092.device

A total of 10s spent here. This probably isn’t the issue.


Here is the output from sudo journalctl -b 0 -k. I kept only the lines where there was a significant delay from the previous.

Dec 27 09:27:40 fedora kernel: [drm] pre_validate_dsc:1634 MST_DSC dsc precompute is not needed
Dec 27 09:28:18 fedora kernel: BTRFS: device label fedora devid 1 transid 7931 /dev/mapper/luks-6c7d528a-840c-44c0-b5a6-8fb5b40640e0 (252:0) scanned by mount (1770)

Not sure what is happening here but it mentions LUKS so it seems to be related to the issue. 38s To do something.

Dec 27 09:28:24 fedora kernel: r8169 0000:bf:00.0 enp191s0: Link is Up - 1Gbps/Full - flow control rx/tx
Dec 27 09:28:55 fedora kernel: HDR SB:01 1a 02 00 84 85 82 3b af 2f 79 8a 0a 1c df 0a

I have an HDR monitor. Still weird that whatever this is takes 31s.


I also ran systemd-analyze blame

This stood out. Again LUKS takes some time.

39.507s systemd-cryptsetup@luks\x2d6c7d528a\x2d840c\x2d44c0\x2db5a6\x2d8fb5b40640e0.service
 6.934s NetworkManager-wait-online.service
 2.709s dnf-makecache.service
 1.458s plocate-updatedb.service
  853ms NetworkManager.service

I have a 4TB SN850x (gen4 nvme) SSD so maybe it just takes a while before it is even ready to decrypt?

The LUKS headers are a few KiB, the driver size does not matter.
I have a 8TiB HDD that is fast to become ready.

I think that means the time it takes grub to load the kernel.
Do you have a very long timeout on grub?

I see my loader time is 9.304s (loader) and I have a 5s timeout.

If you remove rhgb and quiet from the kernel command line you can see when the kernel starts to run. You can use grubby to remove these options like this:

sudo grubby --remove-arg=rhgb --update-kernel=ALL
sudo grubby --remove-arg=quiet --update-kernel=ALL

Now reboot and see how long it is before the first message from the kernel.
Which is usually something like this:

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x610f0000]

I have two monitors both using DP. Until I switched which monitor was plugged into which DP port on the PC I never saw these screens. Now I see these screens. Probably something to do with the HDR monitor if I had to guess.

This one appear for a few seconds. Probably 5, like yours.

This next one is the slow on. When this is done the LUKS decrypt screen appears. About minute or so. Didn’t actually time it.

This is without you recommended steps. I will do those next.

I ran both of those commands and shutdown and the booted it back up again. It made no real difference. Things look a bit different but time wise it is the same.

It gets “stuck” on this screen.

But once I press a button on the keyboard this shows up prompting me for my password to decrypt the drive.


I don’t know what the first message from the kernel is because once they start they just fire off so fast and I am at my login screen in no time.

I think the loader time will include time it takes you tp type in the passphrase.
Does that acount for the slow boot time you see?

It does not. I type my password in a few seconds. There is something else going on.