Long BOOT Firmware POST time

seth · 2026-02-09 15:32:34

Roughly, near zero + the amount of time it takes to type your password

Depends on whether the boot partition is encrypted - at least grub seems to be exceptionally slow with decryption.
But the OP is legit waiting for the UEFI to post (what takes about a split second here)

@Lone_Wolf, sure you're not running some rather pointless self-tests or RAM training?

tekstryder · 2026-02-09 15:54:52

seth wrote:

Depends on whether the boot partition is encrypted - at least grub seems to be exceptionally slow with decryption.

Yeah, not an issue with systemd-boot. Near instant with an 11yr old intel lappy.

seth wrote:

But the OP is legit waiting for the UEFI to post (what takes about a split second here)

Hence our various suggestions regarding pre-post troubleshooting.

Much like The Boston Museum of Science... it'll be "fun to find out".

seth · 2026-02-09 16:28:17

Are you sure systemd-boot can handle an encrypted boot partition at all?
https://wiki.archlinux.org/title/Dm-cry … _partition

tekstryder · 2026-02-09 16:34:23

Derp. Encrypted boot != encrypted root.

Regardless, neither the OP nor Lone_Wolf have encrypted /boot.

Lone_Wolf · 2026-02-10 10:24:45

Firmware settings :
Power Down Enable is enabled
Memory Context Restore is auto but setting it to enabled doesn't make a difference
fast boot is enabled

The memory used is shown as jedec 5600 , xmp/expo are not used as far as I can find.
Output of dmidecode is at http://0x0.st/PAmL.txt

Decrypting/unlocking is fast .

Systemd-analyze output :
Time spent in the bootloader(ReFind) increases loader time, slowly typing passphrase increases kernel time .

firmware time after multiple boots varied between 18 sec and 20.5 sec , rebooting shows similar numbers.

tekstryder · 2026-02-10 12:42:20

Lone_Wolf wrote:

firmware time after multiple boots varied between 18 sec and 20.5 sec , rebooting shows similar numbers.

Hmm 19 sec firmware time was my last cold boot so that doesn't seem terrible with lots of devices.

I just gave it a couple reboots for this thread.

"Fast" LUKS passphrase entry:

Startup finished in 7.905s (firmware) + 346ms (loader) + 1.647s (kernel) + 2.721s (initrd) + 10.856s (userspace) = 23.477s 
graphical.target reached after 10.856s in userspace.

Slow LUKS passphrase entry:

Startup finished in 7.932s (firmware) + 346ms (loader) + 1.648s (kernel) + 2.626s (initrd) + 24.678s (userspace) = 37.232s 
graphical.target reached after 24.676s in userspace.

So, looks like it hits userspace here.

Lone_Wolf · 2026-02-11 12:44:02

I'm using busybox init and encrypt hook, are you using systemd init + sd-encrypt hook ?

tekstryder · 2026-02-11 13:29:12

Lone_Wolf wrote:

are you using systemd init + sd-encrypt hook ?

On laptop, yes.

On system quoted above, no. Only raid10 array is encrypted, not root.

So, that's the kernel vs userspace allotment difference.

Your cold boot vs warm boot are similar and consistent @ 18-20s?

Still doesn't seem terrible like the OP's firmware time, but reboot should™ be quicker in that regard.

Kamitachi · 2026-02-15 09:26:57

After a rough week, I'm back to try what you have suggested, sorry for disappearing when you are taking your time to help me u.u

seth wrote:

You could just copy the grub efi into /EFI/Microsoft/Boot/bootmgfw.efi - no idea whether that's what freaking the BIOS out but we've exhausted all reasonable paths…

So, this didn't work out, in BIOS it didn't even show up. I don't know if I did something wrong when copying the file, or if it just doesn't work on the fly.

tekstryder wrote:

If Seth's suggestion to fool the UEFI into "finding" the MS boot manager is unsuccessful...
...my next step would be to remove grub entirely, wipe the ESP partition clean (hell, hit it with /dev/zero fill), and switch to a simpler bootloader (systemd-boot) with the ESP mounted properly on /boot or /efi.
You don't have any esoteric requirement for the over-engineered and antiquated grub.

If it's not an inconvenience, can you be more specific about what I have to do?

To be honest, I think I already said that on one of my first posts. I followed a guide on how to install Arch with LVM because I want those NVMe as one drive. The video was 5years old and was using grub, I don't know if this systemd-boot is newer, but I'll gladly try if it solves my issue

I have a USB with Arch installer ready just in case, but I'm afraid to break something doing what you are suggesting and lose everything...

Someone along these last days said something about encrypted LVM. In my case, I don't have mine encrypted, my PC is not a laptop, so I didn't think that was necessary in my case, so I didn't encrypt my LVM.

Kamitachi · 2026-02-15 09:34:58

One more thing,

Seth, if you remember, you told me to create a new grub-install because the one I created with --removable didn't make sense.

After a week of having the one without --removable booting first, I decided to remove the one I first created, the result was that Linux stopped booting, I had to boot the arch installer USB I had to create again the --removable grub

tekstryder · 2026-02-15 13:56:27

Kamitachi wrote:

install Arch with LVM because I want those NVMe as one drive

Booting such an LVM volume inherently should™ not be an issue with a proper grub or systemd-boot installation.

Your symptoms point to either memory training/diagnostics or the UEFI failing to find the initial bootloader entry it's seeking, then falling back after some timeout.

What occurs on-screen during this long wait? Is the MSI splash screen disabled? Is the display entirely blank?

Kamitachi wrote:

After a week of having the one without --removable booting first, I decided to remove the one I first created, the result was that Linux stopped booting, I had to boot the arch installer USB I had to create again the --removable grub

This doesn't make much sense. You're claiming to have created multiple grub installations concurrently?

Kamitachi wrote:

If it's not an inconvenience, can you be more specific about what I have to do?

More important than the grub/systemd-boot distinction is ensuring there isn't some "phantom" entry on the ESP partition that the UEFI is chasing.

My suggestion was to kill the ESP contents with fire (dd if=/dev/zero). E.g... bootable USB live environment -> mount the ESP somewhere -> delete everything from its filesystem -> follow the installation guide to install a bootloader, mount root, reinstall kernel + regenerate initramfs.

If a clean ESP + fresh bootloader install doesn't get this working as expected there's gotta be something wrong with the UEFI or mistaken settings therein.

When you updated the UEFI did it fully clear/reset? That happens with my MSI board, so it was a fresh start each update.

Kamitachi · 2026-02-15 14:15:30

tekstryder wrote:

What occurs on-screen during this long wait? Is the MSI splash screen disabled? Is the display entirely blank?

It's entirely blank, until those 45s has past it doesn't display the MSI splash screen

tekstryder wrote:

This doesn't make much sense. You're claiming to have created multiple grub installations concurrently?

Yeah, at some point, seth suggested to reinstll grub without --removable parameter. Maybe I screw up at that moment, and he wanted me to do another thing

tekstryder wrote:

When you updated the UEFI did it fully clear/reset? That happens with my MSI board, so it was a fresh start each update.

Yes, it did, every option in the BIOS was like default, I had to reactivate XMP and GameBoost

tekstryder wrote:

My suggestion was to kill the ESP contents with fire (dd if=/dev/zero). E.g... bootable USB live environment -> mount the ESP somewhere -> delete everything from its filesystem -> follow the installation guide to install a bootloader, mount root, reinstall kernel + regenerate initramfs.

Okay, I'll try later, thanks.

Do i have to go to /boot to do this (dd if=/dev/zero)?

Last edited by Kamitachi (2026-02-15 14:17:45)

seth · 2026-02-15 14:22:03

tekstryder wrote:

You're claiming to have created multiple grub installations concurrently?

I decided to remove the one I first created

How and where did you remove what exactly and instead left what else in place?

tekstryder · 2026-02-15 14:28:16

Kamitachi wrote:

tekstryder wrote:
What occurs on-screen during this long wait? Is the MSI splash screen disabled? Is the display entirely blank?
It's entirely blank, until those 45s has past it doesn't display the MSI splash screen

I'm referring to the setting itself (Full Screen Logo Display or Boot Logo Display). Ensure that it's disabled.

Otherwise any preboot memory enumeration, configuration, diagostics, and training information will not be displayed.

On my board there's no actual "logo" displayed, just a blank screen during training if the logo option is not disabled.

Kamitachi · 2026-02-15 14:45:45

tekstryder wrote:

I'm referring to the setting itself (Full Screen Logo Display or Boot Logo Display). Ensure that it's disabled.
Otherwise any preboot memory enumeration, configuration, diagostics, and training information will not be displayed.
On my board there's no actual "logo" displayed, just a blank screen during training if the logo option is not disabled.

I disabled that and I still have an empty screen before post, no info

Kamitachi · 2026-02-15 15:03:09

seth wrote:

tekstryder wrote:
You're claiming to have created multiple grub installations concurrently?
I decided to remove the one I first created
How and where did you remove what exactly and instead left what else in place?

This is what I have now:

/boot

EFI  grub  initramfs-linux.img  intel-ucode.img  vmlinuz-linux

/boot/EFI

.:
BOOT  GRUB

./BOOT:
BOOTX64.EFI

./GRUB:
grubx64.efi

I deleted /boot/EFI/BOOT
First with efibootmgr -b and then deleting the folder and file directly

I'll try to do as tekstryder suggested and delete everything from that partition with the dd command.
I didn't do it yet because I'm a bit afraid tbh.
I'll try to use systemd-boot instead of grub as he suggested too.
I don't really know the true differences between the two, but I'll follow his suggeston of using systemd-boot

seth · 2026-02-15 15:23:13

the result was that Linux stopped booting

But grub still showed up first?
(It's oc. possible that the UEFI completely ignores anything but BOOT/BOOTX64.EFI despite it being detected but I don't see how you could then have booted the other entry…)

After deleting the entry w/ "efibootmgr -B" (nb. the uppercase "B"), what did/does the efibootmgr list look like? Grub still detected (and as default)?

Kamitachi · 2026-02-22 14:55:31

Again, I didn't have much time to test things the rest of the week, so I was doing tests today.

First, seth and tekstryder, about the grub and all those things. I did what tekstryder said: dd if=/dev/zero to the boot partition and installed systemd-boot. The result was still the same, that the time was not improving. So, I concluded that my problem wasn't related to the LVM, or at least I was discarding that possibility for now.

Then, I found that my motherboard has some debug LEDs that indicate the motherboard's state.
I saw that before POST, a white LED was on, and, according to the manual, it indicates that the GPU is not detected or fail. I was afraid my graphics card was malfunctioning.On board LEDs

So, this morning I decided to clean my PC to remove dust, and I used that excuse to test what some of you have suggested: disconnect everything and connect things one by one and see if that improves boot time.

The conclusion is that I found that if I don't have my Valve Index VR Headset connected, POST time is around 15s instead of 45-48s.

I'm happy to know that my motherboard, graphics card and, especially, RAM were good. But I don't understand why having my HMD connected makes my POST time increase by ~30s

Last edited by Kamitachi (2026-02-22 14:57:51)

tekstryder · 2026-02-22 15:05:58

Kamitachi wrote:

disconnect everything and connect things one by one

I thought this had already been performed and ruled out way upthread haha.

Kamitachi wrote:

if I don't have my Valve Index VR Headset connected, POST time is around 15s instead of 45-48s.

Always feels good to root-cause an issue. Good luck with that headset.

At least you got some bootloader setup practice out of this

Kamitachi · 2026-02-22 15:23:47

tekstryder wrote:

I thought this had already been performed and ruled out way upthread haha.

Yeah, I'm sorry

tekstryder wrote:

Always feels good to root-cause an issue. Good luck with that headset.

I'll have to investigate why it does this, with 2DP cables (Monitor and HMD) and 3 phisical port on the Graphics Card I have tried all posible combination to connect the cables, but none worked. I saw somewhere on Reddit that someone had solved my issue by changing the cables to another port.
So yeah, I still have work to do, but I won't annoy any of you anymore

tekstryder wrote:

At least you got some bootloader setup practice out of this

Yeah, I had plenty hahaha

Thanks for all your support, guys

Arch Linux

#51 2026-02-09 15:32:34

Re: Long BOOT Firmware POST time

#52 2026-02-09 15:54:52

Re: Long BOOT Firmware POST time

#53 2026-02-09 16:28:17

Re: Long BOOT Firmware POST time

#54 2026-02-09 16:34:23

Re: Long BOOT Firmware POST time

#55 2026-02-10 10:24:45

Re: Long BOOT Firmware POST time

#56 2026-02-10 12:42:20

Re: Long BOOT Firmware POST time

#57 2026-02-11 12:44:02

Re: Long BOOT Firmware POST time

#58 2026-02-11 13:29:12

Re: Long BOOT Firmware POST time

#59 2026-02-15 09:26:57

Re: Long BOOT Firmware POST time

#60 2026-02-15 09:34:58

Re: Long BOOT Firmware POST time

#61 2026-02-15 13:56:27

Re: Long BOOT Firmware POST time

#62 2026-02-15 14:15:30

Re: Long BOOT Firmware POST time

#63 2026-02-15 14:22:03

Re: Long BOOT Firmware POST time

#64 2026-02-15 14:28:16

Re: Long BOOT Firmware POST time

#65 2026-02-15 14:45:45

Re: Long BOOT Firmware POST time

#66 2026-02-15 15:03:09

Re: Long BOOT Firmware POST time

#67 2026-02-15 15:23:13

Re: Long BOOT Firmware POST time

#68 2026-02-22 14:55:31

Re: Long BOOT Firmware POST time

#69 2026-02-22 15:05:58

Re: Long BOOT Firmware POST time

#70 2026-02-22 15:23:47

Re: Long BOOT Firmware POST time

Board footer