Long BOOT Firmware POST time

Kamitachi · 2026-02-07 17:23:18

seth wrote:

Honestly, I don't think it's anything like this.
Honestly, knowing is better than believing.
Also seth now a couple of times wrote:
Can you boot w/o delay when attaching a bootable USB key (and in doubt change the boot order)?

Unpluged evrything except the ethernet and monitors, same time.
Change boot order to boot a USB with arch installer, same time

Kamitachi · 2026-02-07 17:24:51

tekstryder wrote:

Oh, I missed upthread... you reinstalled the bootloader, but it's still trying the wrong entry (0001) first.
Set grub to load first:
sudo efibootmgr -o 0000,0001

Kamitachi wrote:

In the BIOS, I had to change UEFI Hard Disk Drive BBS Priorities to use GRUB instead of UEFI OS, but nothing changed; it still takes ~45s for Firmware POST

After doing this, the boot order is the expected now

BootCurrent: 0000
Timeout: 2 seconds
BootOrder: 0000,0001
Boot0000* GRUB HD(1,GPT,38358050-1949-4b4a-aa71-4c36be695465,0x800,0x100000)/\EFI\GRUB\grubx64.efi
Boot0001* UEFI OS HD(1,GPT,38358050-1949-4b4a-aa71-4c36be695465,0x800,0x100000)/\EFI\BOOT\BOOTX64.EFI0000424f

seth · 2026-02-07 17:38:27

except the ethernet

Ethernet isn't necessary to boot the system at all.

Otherwise

Change boot order to boot a USB with arch installer, same time

So this is not related to any EFI on the disk, or the bootloader (let alone the OS)
Something *will* have changed about the UEFI configuration or hardware and the arch installation is coincidental resp. might have caused you to make that change - revisit the changes we know you made to the secureboot setup.

Kamitachi · 2026-02-07 17:45:13

seth wrote:

except the ethernet
Ethernet isn't necessary to boot the system at all.
Otherwise
Change boot order to boot a USB with arch installer, same time
So this is not related to any EFI on the disk, or the bootloader (let alone the OS)
Something *will* have changed about the UEFI configuration or hardware and the arch installation is coincidental resp. might have caused you to make that change - revisit the changes we know you made to the secureboot setup.

The only change I made related to secureboot was disabling it on the bios because I couldn't boot Arch otherwise

tekstryder · 2026-02-07 18:09:21

Kamitachi wrote:

yesterday I updated the firmware, and it's still the same.

After the firmware update did you re-enable "fast boot" and any other available boot optimizations?

What mobo is this?

Kamitachi wrote:

Unpluged evrything except the ethernet and monitors, same time.
Change boot order to boot a USB with arch installer, same time

Still smells like the pre-boot diagnostics (memory training / verification) that a UEFI will do when not explicitly disabled.

seth · 2026-02-07 18:50:59

The only change I made related to secureboot was disabling it on the bios because I couldn't boot Arch otherwise

While not likely, re-enable it and see whether you can access the BIOS w/o delay again afterwards.

Kamitachi · 2026-02-07 21:12:36

tekstryder wrote:

Kamitachi wrote:
yesterday I updated the firmware, and it's still the same.
After the firmware update did you re-enable "fast boot" and any other available boot optimizations?
What mobo is this?
Kamitachi wrote:
Unpluged evrything except the ethernet and monitors, same time.
Change boot order to boot a USB with arch installer, same time
Still smells like the pre-boot diagnostics (memory training / verification) that a UEFI will do when not explicitly disabled.

After the update, fast bout was again enabled, so I tried again and still slow boot.
My motherboard is a MSI Z790 Tomahawks Wifi
I have tried all this option but none worked memory fast boot

Seth wrote:

While not likely, re-enable it and see whether you can access the BIOS w/o delay again afterwards.

Same slow boot u.u

seth · 2026-02-07 21:44:14

https://download-2.msi.com/archive/mnu_ … 00BIOS.pdf

Set that to "Enabled"

Do you happen to have XMP enabled? (disable it)

On a formal note, please avoid bloating the thread with pointless full quotes of previous posts..

Kamitachi · 2026-02-07 22:26:11

seth wrote:

Set that to "Enabled"

Set what? The link is for the BIOS documentation, but not to any section.

seth · 2026-02-07 22:28:07

I linked the BIOS manual as general reference, but the comment was referring to the setting in your screenshot (fast boot)

Kamitachi · 2026-02-08 07:38:10

Didn't work either, memory fast boot and disabling XMP and same time to POST.

I even tried to reset to default to see if I had made any change i didn't remember and no, the only options that I changed are my fans curves and disabling secureboot

Last edited by Kamitachi (2026-02-08 07:40:11)

seth · 2026-02-08 09:09:03

Do you get a long post when only entering the BIOS, rebooting from there here BIOS, rebooting from there into the BIOS… ie. never start any OS?
Disable all boot devices.
Disable anything that scans for hardware.

While it makes no sense at all you can try to re-install windows and see whether hat has any impact, but if the UEFI is unconditionally looking/waiting for some windows EFI (\EFI\Microsoft\Boot\bootmgfw.efi) that's something you'd have to take to MSI…

Kamitachi · 2026-02-08 09:23:06

I'm always changing whatever in the bios, reboot to SO, then reboot again to the SO. Here is when I see if there was any impact from the change or not.

seth wrote:

Disable all boot devices

They are disabled, only the GRUB one is in the boot order

seth wrote:

can try to re-install windows

I'm not going to reinstall Windows again. I already have almost 2TB of data on the PC, between games, videos and photos.
I already had problems saving important things to change to Arch, asking my friends for external drives to save most of my things...

seth wrote:

but if the UEFI is unconditionally looking/waiting for some windows EFI (\EFI\Microsoft\Boot\bootmgfw.efi) that's something you'd have to take to MSI…

Wouldn't it show in efibootmgr or in the BIOS bootorder if that were the case?

seth · 2026-02-08 09:38:13

Wouldn't it show in efibootmgr or in the BIOS bootorder if that were the case?

It would primarily be a bug in the firmware - and the point would be that there's no such EFI entry but the firmware figures "I'm just gonna wait and see whether maybe one shows up"
I don't even necessarily consider this likely, but we've looked into pretty much "everything that could go wrong" at this point.

The main reasons for POST delays are CPU, RAM and GPU, because the firmware *has* to make sure those are ok.
Are there indications for problems w/ any of those in the running system? PCI bus errors?

5hridhyan · 2026-02-08 09:45:01

building on what @seth said about the firmware checking the RAM on MSI Z790/DDR5 boards, that 45s+ delay is almost always the board performing a full training cycle.

look in your BIOS for 'Memory Context Restore' or "MCR" and 'Power Down Enable'. you want to make sure both are enabled rather than left on 'Auto'. when these are off, the firmware re-trains the memory timings from scratch every time you boot, which takes forever.

Also, to rule out a hardware 'hang' during the PCI/USB initialization seth mentioned, it might be worth testing with absolutely minimal hardware: just a single RAM stick and no internal USB headers (AIO, RGB hubs, etc.). If it's still 45s+ with one stick and zero peripherals, it's definitely a firmware-level handshake issue.

Kamitachi · 2026-02-08 09:46:17

seth wrote:

Are there indications for problems w/ any of those in the running system? PCI bus errors?

None, everything is okay when I'm using the PC, I can game without issues, I can watch videos, use discord and sharescreen, programming, etc. Everything is fine when the SO boots.
It's just the POST that annoys me, because with the PC that I have, it shouldn't take that long to POST, especially when it wasn't like this before...

seth · 2026-02-08 10:02:05

None, everything is okay when

I meant in the system journal - you can get non-stop correctable PCI errors w/o really noticing it.

with the PC that I have, it shouldn't take that long to POST

That has nothing to do with "the PC that you have", i386 boards would usually post in less than a second - there's a problem w/ the hardware or the firmware for sure.

Kamitachi · 2026-02-08 10:22:41

5hridhyan wrote:

'Memory Context Restore' or "MCR" and 'Power Down Enable'.

I don't have those options as my motherboard is the intel one. After a quick search I found that MCR is Memory FastBoot, which is enabled, and Power Down Enable is Power Down Mode, which has multiple options. I selected APD(Active Power Down)

I also tried MSI Fast Boot, which says that when enabled USB, PS2 and SATA devices will not be detected while booting.

5hridhyan · 2026-02-08 10:33:06

yeah I had a confusion w/ the names, have you tried "minimal" hardware boot? like single RAM stick, unplug internal USB headers (AIO coolers, RGB hubs etc), also unplug all external USB devices like Valve Index, dongles etc, If the POST time suddenly drops to 10-12s, you can plug things back in one by one to find the killer. If it's still 47s with one stick of RAM and no peripherals, then you've ruled out everything except the Motherboard, CPU, or the NVMe drives themselves....

Kamitachi · 2026-02-08 11:17:17

No, I have not tried yet, maybe I'll later or next weekend.

This is driving me crazy, to be honest, it has no sense hahaha

seth · 2026-02-08 20:33:18

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…

tekstryder · 2026-02-08 20:58:50

5hridhyan wrote:

that 45s+ delay is almost always the board performing a full training cycle.

I already mentioned that multiple times upthread and OP confirmed it's disabled.

IFF the memory training aspect is truly ruled out...

I'd return to the original problems:

1) Using discouraged EFI mount point (/boot/efi). See blue note: https://wiki.archlinux.org/title/EFI_sy … unt_points
1) efivars corruption initially and grub reinstall, but I'm leaning toward some weirdness with the now-MIA Window Boot Loader, as has already been guessed at.

Also, note that the rest of the bootable devices from #5 are not showing in efibootmgr output.

For comparison here's my MSI Z690, even though I don't allow/have any of those extra devices enabled:

BootCurrent: 0000
Timeout: 0 seconds
BootOrder: 0000,0001,0002,0003,0004
Boot0000* Linux Boot Manager HD(1,GPT,6070b85a-2c49-4806-8da9-c9c6c4cd4e39,0x800,0x1f4000)/\EFI\systemd\systemd-bootx64.efi
Boot0001  Windows Boot Manager HD(1,GPT,6070b85a-2c49-4806-8da9-c9c6c4cd4e39,0x800,0x1f4000)/\EFI\Microsoft\Boot\bootmgfw.efi
Boot0002* UEFI:CD/DVD Drive BBS(129,,0x0)
Boot0003* UEFI:Removable Device BBS(130,,0x0)
Boot0004* UEFI:Network Device BBS(131,,0x0)

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.

Last edited by tekstryder (2026-02-08 21:01:17)

Everything2067 · 2026-02-09 11:45:29

Some BIOSes (like mine (HP)) save their own logs and you can usually see them from the BIOS setup. Does your BIOS have an option to do so?

Lone_Wolf · 2026-02-09 13:04:26

I have a similar boot time with my asrock taichi lite 870E + ryzen 9 9950x .

cold boot time is around 45 seconds, soft reboot is 20ish .
However my / and /home are lvm on luks2 encrypted so I need to put in the passphrase (10+ chars) to unlock .
No idea how much time unlocking / decrypting/lvm preparing volumes takes.

(he esp is not encrypted and mounted on /boot)

Are (some of) your partitions encrypted ?

tekstryder · 2026-02-09 14:17:58

Lone_Wolf wrote:

No idea how much time unlocking / decrypting/lvm preparing volumes takes.

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

You can observe the diff yourself with systemd-analyze after slowly vs quickly entering your LUKS passphrase.

Arch Linux

#26 2026-02-07 17:23:18

Re: Long BOOT Firmware POST time

#27 2026-02-07 17:24:51

Re: Long BOOT Firmware POST time

#28 2026-02-07 17:38:27

Re: Long BOOT Firmware POST time

#29 2026-02-07 17:45:13

Re: Long BOOT Firmware POST time

#30 2026-02-07 18:09:21

Re: Long BOOT Firmware POST time

#31 2026-02-07 18:50:59

Re: Long BOOT Firmware POST time

#32 2026-02-07 21:12:36

Re: Long BOOT Firmware POST time

#33 2026-02-07 21:44:14

Re: Long BOOT Firmware POST time

#34 2026-02-07 22:26:11

Re: Long BOOT Firmware POST time

#35 2026-02-07 22:28:07

Re: Long BOOT Firmware POST time

#36 2026-02-08 07:38:10

Re: Long BOOT Firmware POST time

#37 2026-02-08 09:09:03

Re: Long BOOT Firmware POST time

#38 2026-02-08 09:23:06

Re: Long BOOT Firmware POST time

#39 2026-02-08 09:38:13

Re: Long BOOT Firmware POST time

#40 2026-02-08 09:45:01

Re: Long BOOT Firmware POST time

#41 2026-02-08 09:46:17

Re: Long BOOT Firmware POST time

#42 2026-02-08 10:02:05

Re: Long BOOT Firmware POST time

#43 2026-02-08 10:22:41

Re: Long BOOT Firmware POST time

#44 2026-02-08 10:33:06

Re: Long BOOT Firmware POST time

#45 2026-02-08 11:17:17

Re: Long BOOT Firmware POST time

#46 2026-02-08 20:33:18

Re: Long BOOT Firmware POST time

#47 2026-02-08 20:58:50

Re: Long BOOT Firmware POST time

#48 2026-02-09 11:45:29

Re: Long BOOT Firmware POST time

#49 2026-02-09 13:04:26

Re: Long BOOT Firmware POST time

#50 2026-02-09 14:17:58

Re: Long BOOT Firmware POST time

Board footer