[okso]

The four steps that take time when booting a Linux system are:

* bios/UEFI

* bootloader (GRUB/...)

* Linux kernel

* service management

bios/UEFI often have settings to reduce the time waiting for user input. Same goes for the bootloader.

You can use `dmesg --boot` to analyze the boot of the Linux kernel.

You can use `systemd-analyze critical-chain` to find out about what slows down the start of the services.

[vladvasiliu]

> You can use `dmesg --boot` to analyze the boot of the Linux kernel.

What kind of information does this give?

On my machine it doesn't work.

    ~ » dmesg --boot
    dmesg: unrecognized option '--boot'
    
    ~ » dmesg -V
    dmesg from util-linux 2.38
    
    ~ » uname -r
    5.18.14-zen1-1-zen

[anyfoo]

I strongly suspect it would give you the content of the kernel log ring buffer (what "dmesg" alone gives you), but up until the time that userspace comes up, probably.

A lot of distributions have something very similar in /var/log/dmesg or /var/log/boot or similar. They do this by just doing something like "dmesg > /var/log/dmesg" early at boot so that the boot messages are (hopefully) still in the ring buffer.

[bool3max]

Correct me if I'm wrong but nowadays you can completely skip the "bootloader" step by using EFISTUB, i.e. having the UEFI firmware load the kernel as an UEFI executable.

[Arnavion]

Yes. you can.

But if you ever have an emergency where you need to modify the kernel cmdline, your firmware needs to provide an interface to do that, which many don't. Using a bootloader is safer in that regard.

[jefftk]

In an emergency you could boot from external media instead, no?

[oddlama]

Yes, and it's quite comfortable. If you don't want to use external media, many boards also come with a builtin UEFI shell which is quite powerful. From there you can simply execute the kernel with the desired cmdline. (like ./vmlinuz root=...)

[Arnavion]

Yes, or keep a copy of edk2-shell around.

[butz]

I've used `systemd-analyze` for whole boot process overview. Thanks to your suggestions I can dig deeper.

Startup finished in 12.132s (firmware) + 1.822s (loader) + 2.106s (kernel) + 1.352s (initrd) + 10.098s (userspace) = 27.513s

[tecoholic]

I did a `systemd-analyze citical-chain` and noticed that `snapd.service` took the most amount of time. So I edited the `/lib/systemd/system/snapd.service` based on the suggestion here [1] and set `After=network-online.start`. The critical-chain time has from ~12 sec to ~4sec. Here is full `systemd-analyze`

Startup finished in 2.348s (firmware) + 3.276s (loader) + 3.303s (kernel) + 4.309s (userspace) = 13.239s graphical.target reached after 3.892s in userspace

The interesting thing is, I haven't noticed any improvements in the time to interactivity from power button press. May a small 2-3 sec. That I could just attribute to disabling session saving and restoring in KDE

Edit: I reverted the change in snapd.service, now I get

Startup finished in 2.328s (firmware) + 3.599s (loader) + 3.284s (kernel) + 13.754s (userspace) = 22.966s graphical.target reached after 13.431s in userspace

Again, almost no difference in actual time to usability. Where is this ~10 secs saved or exhausted?

[1] - https://askubuntu.com/questions/1380790/is-it-possible-to-st...

[vinay_ys]

snapd doesn't block your interactivity. You can start typing in your password and login and start to launch your app, meanwhile the user space startup sequence is still running.

[tecoholic]

That explains why there is no change in time to interactivity. Thanks.

[butz]

Enabled "fast boot" in BIOS: Startup finished in 4.369s (firmware) + 1.935s (loader) + 2.516s (kernel) + 1.336s (initrd) + 9.797s (userspace) = 19.954s

One caveat - after enabling "fast boot" it is impossible to enter BIOS configuration usual way with hotkey, had to use `systemctl reboot --firmware-setup`.

And there's a `systemd-analyze plot` command, which draws a chart of boot process in SVG format.

[rahimnathwani]

I just ran systemd-analyze on a low-power machine running debian buster. The last two lines of output were:

boot-efi.mount @4.143s +614ms

dev-mmcblk0p1.device @4.039s

4 seconds seems like a long time to wait for access to the boot device. It's not like an MMC device needs to spin up.

[joezydeco]

If you're using extfs and didn't shut down properly, it's probably doing integrity checks.

[rahimnathwani]

I just rebooted and that first step still took 3.988s

I wonder whether it's something to do with the hardware. The box is a repurposed Dell Wyse thin client.

[jjoonathan]

re: bios settings, any keywords I should look for?

I've had MSI and Gigabyte motherboards, but the best I've been able to do has been to reduce from ~15 seconds to ~13 or so because the wait duration is just for the splash screen and chopping it to 0 just doesn't do all that much, the BIOS still dominates the startup time.

[Alupis]

Were you using UEFI mode, Fast Boot mode, and an NVMe drive? Boot times should only be a few seconds at most under similar configurations.

"Fast Boot" modes bypass hardware startup checks such as Memory, keyboard, etc. It also skips polling for keyboard input, which typically looks for the user pressing function keys to access boot menus, BIOS menus or other special startup procedures. Skipping polling alone can shave many seconds off boot times.

Just be aware, after enabling Fast Boot mode, you'll have to trigger a reboot into BIOS/UEFI from within your OS or by using a blessed utility provided by your MOBO manufacturer.

[rustqt6]

So I've mostly learnt from you but it's also possible I'm right here so I'd say- you can very well boot into firmware from bootloaders too. Systemd-boot has one default entry on my installation and I believer grub allows u too. Gonna actually go lookup grub because I need that entry

[sentientslug]

On my MSI board I think it’s called Fast Boot or Fast Startup. Also not sure of the wording but an option to skip splash screen.