Enormous boot time with fresh install

General system Newbie
1

Hi all,

ive just switched from manjaro to endeavour. I am already familliar with long boot time, as manjaro also took quite some time to boot, after decrypting the drive. But endeavour just took it to another level. I am on a fresh install an the boot time is about 8 minutes with decryption. How can I (in this case drasticaly) reduce the boot time?
My partitions are split up in boot root and home using swap with 32gb RAM and a 16core 11th gen Intel.
I was already not cool with manjaro taking 4 minutes and i want to switch for various reason, but I cant shrink the boot time, endeavour is out for me…

$ systemd-analyze 
Startup finished in 8.912s (firmware) + 58.770s (loader) + 1.174s (kernel) + 3min 786ms (initrd) + 1min 31.603s (userspace) = 5min 41.248s 
graphical.target reached after 1min 31.596s in userspace.

Any advice is very much appreciated! :slight_smile:

Edit: i have checked my BIOS options, there is a Secure boot option, which is set to off (as i remember this is neccessary, otherwise linux wouldt boot?). Besides that, the device offers a hardware security-chip. Does anyone know, how to utilize this opportunities at best? The device is a thinkpad P1 gen4, this is usually a pretty powerfull device with many security features…
I do want my stuff to be encrypted and securely stored, but with good usability and least compromises on security.
I allways split partitions in swap root home and boot, usually encrypting every partition except from boot as luks drives (chosing ext4 at setup, checking “encryption” and providing a password. What is best practice here?
In my oppinion, encrypting the root partition seems to make sense, as the data stored there can give assumptions to what i’m doing on the device, asside from logs i suppose…

Edit 2:
allright guy, i suppose i have to excuse myself for making a typo in the grub conf, after correcting to ibt=off, updating and installing the driver again, i am at arroud 30s for grub decryption and about 30-40s for booting, seems fine.
are there any ways to improve that?
I will install again now, trying to set up systemd instead of grub, i remember being asked that in the installer.

1 Like
2

That seems really high. So does 91 seconds in userspace.

Can we see the output of systemd-analyze critical-chain

2 Likes
3

I’m assuming you’re using grub or are you using systemd-boot?

Is this full disk encryption? LUKS? Did you use the default encryption settings or custom?

4

yess

graphical.target @1min 31.691s
└─multi-user.target @1min 31.689s
  └─cups.service @1min 31.608s +77ms
    └─network.target @1min 31.605s
      └─NetworkManager.service @1min 31.582s +20ms
        └─network-pre.target @1min 31.541s
          └─firewalld.service @1min 31.372s +165ms
            └─polkit.service @1min 31.389s +11ms
              └─basic.target @1min 31.223s
                └─sockets.target @1min 31.221s
                  └─dbus.socket @1min 31.219s
                    └─sysinit.target @1min 31.162s
                      └─systemd-sysctl.service @1min 31.119s +36ms
                        └─systemd-journald.socket
                          └─system.slice
                            └─-.slice
5

Better post your journal log (use eos log utility).

6

yes, grub and partitions encrypted as luks drives, the swap is encrypted aswell, though im only being asked one password.
Ive used the “custom” settings to set the partitions.
home and root in ext4 with the checkbox encryption afterwards typing in a password.
The option “luks” doesnt allow to enter a password and the installer crashes at ~1-2% setting up luks drives.

7

if your /boot is encrypted then you may be running into an issue like this

https://wiki.archlinux.org/title/GRUB/Tips_and_tricks#Speeding_up_LUKS_decryption_in_GRUB

System absolutely chugs when booting an encrypted /boot if you dont do this. This obviously reduces the security of said encrypted partition but unless you need to use grub or cant use secure boot/custom signing keys you can move to systemd-boot and use a unified kernel image with secure boot to keep your efi unencrypted and have the initial kernel,etc. that is in /boot signed/verified.

If youre not using an encrypted /boot then perhaps you arent using AES? AES should be hardware accelerated for both AMD and Intel to be nearly transparent for most people.

8

But he is seeing 5m in the initd and userspace. That should be after the grub encryption delay.

1 Like
9

true :sweat_smile:, so likely isnt that

10

IDK why you’d even encrypt /boot. There should be NOTHING important there. For all intents and purposes if your machine is stolen, it’s already done for.

Same for /.

The only thing that should be encrypted is /home. Anything else is pointless.

11

there are some arguments to be made to the contrary but lets not derail the OPs support thread into a discussion of the merits to what is/isnt encrypted

2 Likes
12

i thinki didnt encrypt boot, its fat32.
it do think i should encrypt root though

13

what harddrive is used for the install? ssd or HDD?
i use such setup on a dualcore intel with 3GB of RAM on SSD and it boots in less a minute…

14

Even on a hard drive that boot time is a bit much, even an HDD should be fast enough to boot and be decrypted fairly quickly these days.

The question remains though, is the drive encrypted with AES or something else?

15

i am pretty shure didnt enter a password for /boot…
secrureboot is an alternative to grub? do you mean files as custom signing keys, like usb sticks?

16

If he checked the encrypt checkboxes he has 2 separate luks partitions using the calamares defaults.

17

oh yes, the drive is an ssd, aes is part of the hardware drive ssds right? i am unsure…

18

and the swap partition encrypted aswell, 64gb. though not being asked for that password.

19

AES has to do with that but not in this case exactly

just need to know did you let the installer encrypt the drive or did you do it yourself outside the installer following a guide or something?

It seems like youre not having the encryption hardware accelerated for some reason. That would cause very long boot times

20

Can we see systemd-analyze blame to see if there is anything interesting there.