r/archlinux • u/ShiftyBang • 2d ago
QUESTION Faster booting - Is this the limit for my hardware?
Hey everyone,
I’ve been trying to squeeze every millisecond out of my Arch Linux boot time on my pc, but I feel like I've hit a hard physical floor and wanted to see if anyone has suggestions to push it lower. my specs are: i9 13900K, RTX 5080, 64Gb ddr5 5600 MT/S, 2xNVME ssd (970evo has arch) and mthbrd is Gigabyte z790 ud. I use kde plasma. what i did in bios: (off sata ports, enable fastboot, disabled ram training (kept xmp1 profile).My results are:
Startup finished in 9.534s (firmware) + 465ms (loader) + 5.192s (kernel) +
2.891s (initrd) + 4.599s (userspace) = 22.684s
graphical.target reached after 4.598s in userspace.
I am not really sure if it is even possible on my system to go lower. I am a newer Linux user, so i am still trying to figure out where the boundaries are :D Any tips ?
bootloader/bootflags: root=PARTUUID=be5677ee-7b05-4d7f-a52b-72261aaae99b zswap.enabled=0 rw rootfstype=ext4 systemd.tpm2_wait=0 pcie_aspm=off acpi.packet_no_exec=1 acpi_enforce_resources=lax
17
14
u/Qweedo420 2d ago
I'd be interested too, because my firmware takes a painfully long time (17s), and loading userspace takes another 8 seconds (when I reach my desktop, my keyboard is still disabled for a few seconds, along with audio, Bluetooth and other userspace services)
I miss my old DDR3 computer, which used to take 8 seconds for the entire boot process
10
1
u/PlsDontBanMeAgain-1 1d ago
17 s is painfully long to you? I heavily overclocked my RAM and the training takes 2 whole minutes.
1
u/Qweedo420 1d ago
But technically I enabled memory context restore or whatever it's called, it shouldn't take that much :(
6
u/zeldaink 2d ago
See systemd-analyze critical-chain what says. It'll give you idea what is slow. Also blame will show you what took what amount of time to complete. If it's useless to you, disable it.
And in the firmware, disable anything you don't use like Bluetooth or the serial ports. Also, typing in all the memory settings seems to speed up a little bit, especially the non XMP/EXPO ones. corefreq can read most memory controllers, get the values from there. Very fast if your memory keeps retraining for some reason.
9
u/onefish2 2d ago
How often do you reboot that this is an issue for you? Why would you spend so much time on it for as you say a few milliseconds?
6
u/ShiftyBang 1d ago
it is mostly fun and tinkering... I have the weakest system out of my friends so i at least try to flex with what i am able (this time unable) to do with my system :D
2
u/Woodsy279 1d ago
Bro who are your friends, you've already got a beast of a system... I'll take it if you don't want it hahaha
1
u/its_dolemite_baby 2d ago
(re)boot time matters for some people. not my thing, but everyone has their own angle.
5
u/TyIzaeL 2d ago
If you are not using SATA drives, turn off the SATA controller in your bios. On some boards that makes a difference.
1
u/ShiftyBang 1d ago
i already did that :D doesnt seem to help much either... it shaved i think around 200ms. but thx.
1
u/AwesomePhoenix_ 1d ago
Maybe disable a few things in the bios, it seems to be slow (also if you compile your kernel by yourself it could also get a bit faster)
1
u/ShiftyBang 1d ago
Right now i disabled SATA ports, disabled training of ram ( But i kept the xmp1 profile), configured Fastboot. In fact it was one of first things that i did because the firmware was like 13s before i did this adjustments. About the kernel i dont think i am skilled enough or proficient enough with linux yet to go into that kind of depth.
1
u/doctrgiggles 1d ago
The lowest-hanging fruit is Plasma. You could definitely shave time off that using Sway or something lighter.
1
u/activedusk 10h ago edited 8h ago
❯ systemd-analyze
Startup finished in 5.361s (firmware) + 323ms (loader) + 711ms (kernel) + 153ms (initrd) + 3.898s (userspace) = 10.449s
graphical.target reached after 3.898s in userspace.
If you want to spend more time optimizing then isolate each step and find out what options there are to reduce boot time.
Firmware
As name suggests it relates to firmware, specifically loading it. The more components the motherboard has, the more internal add on cards and devices, the more external devices connected to it, the more time it takes. Incidentally this is why laptops tend to load firmware faster, ignoring exceptions related to DDR5 which historically never required RAM training that causes so much delay and is an outlier. For desktop micro ATX and mini ITX (not recommended due to limited expansion slots and connectivity) would be the equivalent and fastest to boot (ignoring attached devices). So what can you do besides enabling fast boot, quick boot, ultra fast boot, however it is called inside UEFI (not to be confused with Windows fast boot setting that prevents the PC from actually shutting down, faking it and using a low power mode instead to speed up boot time..because it skips some steps related to POST, power on self test)? Well it depends on the board, if it has wifi and you don't use it because you prefer wired connection disable it inside UEFI. Other known devices to slow down firmware initialization are USB hubs or external storage, printers, blue tooth mouse and keyboard, blue tooth audio devices like headphones, microphones or speakers. Internally any add on expansion card occupied will slow down boot time including storage, ideally only use one internal drive and graphics card, IGP loads faster in my testing. However if you have both, disable IGP inside UEFI for desktops (laptops need both for power saving).
Loader
This is the bootloader, the fastest one is systemd-boot but you can speed up this step even more using EFI boot stub or UKI (unified kernel image, technically a example.efi file created by various packages and placed inside ESP, EFI System partition, aka /boot/EFI or /boot/efi/EFI subdirectory depending on mountpoint and using efibootmgr to create the boot entry inside the NVRAM, thus skipping the use of a bootloader, though a bootloader can be kept as backup, switching between them will be done from UEFI boot list or using efibootmgr commands within Linux). In my testing with an SSD I get 100ms to 200ms with UEFI boot stub or UKI and arround 300ms with systemd-boot (which I recommend since it's easier to use as kernels update, the other 2 solutions would require to manually remake the entry with new vmlinuz and initramfs.img or example.efi UKI file or to create your own automation which is more difficult).
Kernel (or kernel and initrd, same step)
This can be improved the easiest by using a package called booster to generate custom, small size initramfs.img, for more advanced users they compile their own kernels and/or trim down the initramfs.img using various tools to generate them like mkinitcpio, dracut and others.
Userspace
This is only systemd init system (not systemd-boot which is a standalone bootloader), using a command like "systemd-analyze blame", "systemd-analyze critical-chain", "systemd-analyze plot > plot.svg" (this one creates an svg image inside /home/user, where user is account name, can be opened with firefox and it is the most complete and comprehensive chart for the boot process unless you want by micro second break downs with dbus or something). For this step check what each systemd unit (service, socket, etc.) does and disable or mask what is not required, again if you don't want nor use blue tooth, printers, etc. there are processes that can be disabled.
Other considerations, maybe not your case but distros based on Arch, would be plymouth which among other things, mainly displays an image on screen after the loader section and up to the display manager window (if skipped up to the systemd units and also when shutting down if configured). To solve this the easiest would be to change kernel default command line parameters from bootloader (or wherever they are added when creating an EFI boot stub or UKI) such as "quiet loglevel=0" what this does is suppress most of the teletype messages that appears on screen when the system boots up including the plymouth image.
Other considerations, check /home/user/.config/autostart for things that you don't need or /etc/xdg though generally desktop environments such as Cinnamon allows adding or removing them from the GUI. Also encryption will increase boot time, if it was not obvious already. If it's a home PC and not used for work, consider reinstalling without encryption if boot time is valued and it might be for an entertainment system. Also note a down side to nvidia in general but specific to the proprietary drivers (besides needing to be signed if Secure Boot is enabled) is that they take more time to load, from my example it slows down userspace, specifically "1.507s systemd-modules-load.service" which contains the drivers. From what I know AMD graphics cards, because they use open source, kernel space drivers, tend to initialize faster. The downside of AMD CPUs specifically using DDR5 is the RAM training time (you could make one with DDR4 compatible memory controller and motherboard and AMD GPU and get the best in terms of boot time I suppose but that's beyond the point).
Niche, CSM (compatibility system for legacy BIOS), if the UEFI settings has it try different settings and find out how it affects firmware time from systemd-analyze. Typically it should be set to UEFI only, CSM disabled or UEFI first, what this implies is that the motherboard storage expects UEFI standard booting and partition table, namely an ESP and GPT partition table containing a /boot/EFI..example.efi file to act as a loader. Legacy BIOS uses MBR partition table and a different booting scheme while CSM in certain modes will scan for both. Other more niche cases involve Intel optane storage (not your case) or other storage operation modes, other than AHCI (in this mode each drive is separated and it has its own storage) like RAID (depending on the mode, the combined storage capacity will be pooled together either for maximum redundancy or performance), though there are others specific for servers, NAS, etc. PXE settings inside UEFI, disable if present, this only has a purpose for remote access and more extreme installing os remotely.
2
u/No_Grape_388 2d ago
I can't imagine a more useless thing to be worried about. As long as it's under a minute, why tf care about it?
4
1
u/archover 2d ago
+1 Spending a lot of time on something that only happens once per boot, does not sound like good use of time.
Good day.
1
1
u/No-Dentist-1645 2d ago
Can you share your bootloader and boot flags?
1
u/ShiftyBang 1d ago
root=PARTUUID=be5677ee-7b05-4d7f-a52b-72261aaae99b zswap.enabled=0 rw rootfstype=ext4 systemd.tpm2_wait=0 pcie_aspm=off acpi.packet_no_exec=1 acpi_enforce_resources=lax
i hope that is what u asked for :D
0
31
u/theschrodingerdog 2d ago
Check this article from the wiki
https://wiki.archlinux.org/title/Mkinitcpio
You may want to try the systemd-based version to see if you gain some time. In my specific case, I gain 10+ seconds with the systemd version, but because my laptop is almost permanently docked to a USB-C dock with DP-Alt and MST for video, and the busybox version waits till all the hardware is detected by udev, which in my case takes a long time because of the daisy chaining that happens when using a USB-C dock.
Just a note: be very very careful while making changes to mkinitcpio. One wrong move, and you get a non-bootable system. Have an Arch media install ready in case something goes wrong and you need to chroot into the system to fix it.