# systemd-analyze
Startup finished in 3min 36.134s (firmware) + 7.077s (loader) + 7.043s (kernel) + 7.608s (userspace) = 3min 57.864s someone who is good at the economy please help me budget this. my family is dying
I get that modern DDR5 memory controllers need to solve at least 50 electrical engineering sudokus before they can actually use a DIMM, but when you have even a moderately loaded system it takes a whole era to reboot, I fear what DDR6 will look like
@benjojo about 20 years ago we got one of the old Sun “Thumper” storage chassis. They had 48 spinning SATA HDDs in them, the BIOS took an absolute age to POST!
Nov 2, 2026, 10:43 AM@benjojo
doesn't the BIOS have an option to remember the solutions from previous boot, then on a new boot quickly check if they still work, and only do the full memory training if they don't?
@wolf480pl I think this is more common on desktop class boards r than workstation/server ones, regardless I suspect a good % of the time is also spent doing a cursory RAM test or something similar
@benjojo "stop buying HPE"?
@zhenech Gigabyte! but also the supermicro DDR5 boxes are the same
Smells like failing power supply.
@SpaceLifeForm I don't think so? This is a universal thing over all DDR5 machines I operate. This one is actually quite short in the grand scheme of things as it's "only" 6x64G, rather than a fully loaded 12
The numbers do not make sense to me.
But consider the source. Funny how it attributes about 7 secs to firmware, loader, and kernel. Each.
I see no way that systemd could know in any way how much time the loader spent as systemd is a userland process that does not even exist until the kernel has started it.
I see no way that systemd could know in any way how much time the loader spent as systemd is a userland process that does not even exist until the kernel has started it.
Imagine being capable of reading source code and understanding things!
systemd is reading UEFI boot measurements.
https://github.com/systemd/systemd/blob/main/docs/BOOT_LOADER_INTERFACE.md
Loader takes 7 seconds because GRUB has a standard debian 5 second menu wait, and probe/fetch/decompress easily takes the other 2 seconds.
I don't know where you are drawing a link to power supply being bad and boot times taking long (but the rest of the machine is fine? and has been fine for ~1Y+), a bizarre conclusion to make.
Just tested on a Bookworm machine.
It takes 15 seconds to boot to the GUI login screen for me. And this is an older box. Though, it is SSD not spinning rust, so that could be a factor.
@SpaceLifeForm your machines are probably not using server motherboards and many 100's of GB of RAM
Correct. Is part of your startup time zero-ing out all of the Ram?
@SpaceLifeForm politely my friend, this was a throwaway joke not a diagnosis session
@benjojo does it at least show some screen output while computing the timing? My X99 board shows a black screen for about half a minute before the first d screen output.
@hennichodernich Gigabyte also leaves you in the dark (though the IPMI does say that it's in "Chipset initialization" state), the supermicro H13 board does give you this static image
@benjojo feels like ages to boot, but *this* seems a bit long to me. I suspect this "Machinist X99 PR9-H" board might have a buggy UEFI firmware providing wrong values.
@hennichodernich yeah that's uniquely bad