Booting Linux in five seconds (2008)
lwn.net
lwn.net
* 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.
Startup finished in 12.132s (firmware) + 1.822s (loader) + 2.106s (kernel) + 1.352s (initrd) + 10.098s (userspace) = 27.513s
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...
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.
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-zenA 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.
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.
"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.
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.
I wonder whether it's something to do with the hardware. The box is a repurposed Dell Wyse thin client.
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.
Probably, you're running in a mode which has no "hints" to avoid probe delay costs. Or, depend on subsystems (SCSI?) which depend on device spinup delay to avoid surges in current draw on the PSU, so e.g. raid disk arrays delay boot time to cohere and stabilise before they do cam control.
But usually, its because people run un-optimised, generic, factory-shipped because 30s is lost in noise. If you dive down the rabbit hole, you can get a LOT faster.
Huh. So is that why it takes server hardware two to four minutes to get past the BIOS screen? Gradual PSU-protecting spin-up of hardware RAID?
Server hardware also tends to do other hardware checks/validate before booting as well. Some of these checks are able to be disabled, and some others are not.
Then, there are systems like IBM iSeries running iOS/OS400 which then hands over to the OS to perform a great deal of system integrity checks before enabling services and I/O. Our Power7 series "400" system used to take upwards of 20 minutes to come online before we decommissioned it.
Generally speaking, for a server, boot time is not a factor. Nobody needs their physical server to boot and be ready in 5 seconds... so it's never been a priority. Stability and integrity are much more important in this arena.
As the GP noted, modern systems coordinate the array through an integral backplane and control spin-up of individual disks plus a lot more. The main difference between a "server" and a desktop is the reliability/integrity/redundancy built into the system, which comes at the cost of boot time. A worthy trade-off in most cases, and once the system is "alive", the expected performance is achieved.
Nobody has had the option of this. I very much have use cases for this, and while the firmware remains a persistent problem, I've been able to bring up the kernel and userspace on server hardware in a fraction of a second.
I'd love to have the firmware stop adding so much time here.
Physical servers tend to have extreme uptimes, compared to desktops and even VM's. It's a fairly rare occurrence to need to reboot a physical server (by rare, I mean only when doing updates that require a reboot, such as a kernel update, and these days there are mechanisms to avoid rebooting even under that scenario).
Needing to reboot often and be available in seconds just isn't a thing needed by most folks operating physical servers. Typically folks that require that operate VM's instead, which can freely be rebooted without powering down the hardware.
Physical servers just are not typically spun up and down in short succession - making the boot time completely irrelevant for all but the most extreme use cases. Many/most of the things a physical server is doing during POST and boot are necessary to guarantee reliability and integrity.
Perhaps desktop "off the shelf" hardware is more what should be prescribed under your scenario.
Spinning up in response to requests, without having to be constantly running (and being billed for).
It seems to me this particular use case is a lot like wanting a forklift capable of driving highway speeds. Can it be done? Sure. But then you sacrifice a lot of what made a forklift good at it's intended job.
There is nothing to be gained from running short-lived code directly on physical servers. Today's Hypervisors are very good at not getting in the way - ie. there is little to zero performance penalty from running a VM, particularly a VM with dedicated resources.
In any event - what you desire can already be achieved, just not with your typical IBM/Dell/HP/Whatever server platforms. The things that make these computers desirable (and earn the denotation of a "server") for long-running systems are unnecessary if the goal is to boot, execute some code, shutdown, repeat. Off the shelf commodity "desktop" hardware is fully capable of booting in seconds and executing code - you just lose all the redundancy/reliability - but that's not needed under this scenario anyway.
And that might be a bug, not a feature.
If you are running on physical servers you’re likely to be overprovisioning, at least a bit, to be able to absorb peak load.
But most of the time you’re not running at peak load.
If you can scale your workloads up and down, via containers or anything else, you have excess capacity being wasted. Basically you have servers turned on and doing nothing but waste electricity.
In that context you might want to just turn off servers and turn them back on when needed.
And in that context you want servers to boot quickly.
We have solutions for these scenarios already - VM's, Serverless, Containers, etc. I am having a really difficult time understanding the scenario where someone must use a "proper" server with all the long-runtime, redundant, resilient hardware configuration but needs it to turn on and off quickly.
Round hole, square peg. There are much better solutions available, starting with commodity hardware and ending with "the cloud".
Yes, but it also makes sense to be able to rent it for short periods of time, billing by the second. And sometimes you do need bare-metal, and a VM won't do.
Standard compute isn't the use case. Intel offers Slim Bootloader for systems that require very fast booting.. as close to "instant on" as you can get. An example would be a collision avoidance system in vehicles. Safety critical systems that require the ability to recover quickly.
My 'host rig' takes about 10 seconds to go from power-off to logged in to a full graphical desktop (LXDE) on a low-end quad core desktop with 8GiB total memory running Mint 20.3 and the Deb based VM assigned 1GiB of memory and 2x cores.
I am not sure why you have to wait 30 seconds. My current system runs PopOS, and it takes less than 10 seconds. My previous install (NixOS), used to boot in about the same time it took for my monitor to understand that the system was on. The BIOS screen takes about as much time as the OS to run(I have fast boot disabled).
By modern hardware, I assume you are using a SSD.
What hardware are you referring to?
Edit: Oh, and let me echo other comments: It depends on your hardware/firmware; the OS can't do anything about it if your machine takes 10 seconds to get to the bootloader.
But then I seldom reboot since linux hibernate got good, so maybe I'm a bad judge.
Hmm, I have not owned a computer that can hibernate in Linux since about the early 2000's. Every 3-4 years, I try to activate hibernate on one of my computers using the latest Ubuntu distribution, and have failed every time.
This on a 2013 Xeon 2667v2 (ivy bridge) with a PCIe 3 NVMe.
My network is handled by NetworkManager, so I think it only comes up after I log in. I'm not quite sure what udev is waiting for, but since I don't boot up my computer often enough, it never bothered me enough to go hunting. But it's just surprising to see Windows come up quicker, on exactly the same hardware (dual boot on the same NVMe).
I think among the three, MacOS takes the crown though - easily takes 5 minutes to boot, at least on an enterprise system.
Got a speedy NVME, and associated speedy hardware, and Windows would come up surprisingly quick, but man Linux was just like a light switch. The longest amount of time was spent waiting for the system to let me choose which OS I wanted.
I wish I could have 2 separate power buttons, which pointed to 2 separate nvme’s, so I wouldn’t haven’t to waste time choosing, and could just boot straight into the desired OS.
Hacky way: NVMe extender cable to drive bay. Split to dual connectors. Mechanical setup that acts as an interlock, where you push the desired drive into the connector, and that disconnects the other drive.
Total overkill and probably not practical to make. Fun to think about though.
Recent experience: I boot into Windows, but it screams for update. Ok, I update. It triggers my bios update - to my surprise, I had no idea an OS can do that. Ok, updating bios. Now Windows want me to update to win 11. Sure, let's give it ago, I waited this long. Message pops up - "Windows can't be updated to version 11 on this machine" or something along those lines.
OK, deep breaths, let's try to play some Dota. I start the game, play with friends aaaand here's the popup that asks me if I want to restart my machine now or schedule it for later - of course, this popup comes at the worst time possible, minimizing the game in the crucial moment and then I remembered - "ah yes, this is why I abandoned Windows, the updates and constant annoyance every week".
On topic - I run PopOS! and it boots below 10 seconds. After reading this article, I'll fiddle to see if it can be lowered.
Gentoo also boots incredibly quickly. I can't recommend it enough.
Or, if you're less sane but not insane enough for Gentoo, Arch. :p
Linux can do that too, it's an UEFI trick (it reboots into a capsule loader, which loads the new firmware into RAM and reboots into the current firmware's built-in updater). Try it: "fwupdmgr get-updates" to see if you have an update, then "fwupdmgr update" to reboot and install the update.
Thanks for the heads up, I did know but I appreciate the intent!
Microsoft should really fix that one of these days.
Haven't booted into non-enterprise Windows for years (only use it for work) so this comment absolutely sent me. Thanks – needed a laugh
My macbook takes ages to boot to login.
My MacBook Air M1 takes 12 seconds from cold boot (including firmware) to the password prompt. This is the prompt that unlocks FDE. After that, it shows my desktop in 10 seconds. So, 22 second in total.
I don't really care, because I reboot my Macs maybe once every few weeks.
(My Linux workstations usually take more than 12 seconds, perhaps even more than 22 seconds in EFI firmware.)
Loading from a flash drive.
Some distributions make some ... interesting choices w/r/t performance. I guess.
My boxen (Void or Alpine) consistently come up in count-on-one-hand seconds. If I wanted to start an X desktop at boot, that'd be maybe another second or two.
I have switches that boot Debian (on the control plane) that cost about £10,000 each. I've got similarly priced HPE servers that take around five minutes to tickle their fans, find their storage etc and generally piss around, not to mention Dell, IBM and Fujitsu.
Your PC/laptop is a thing and it takes a certain amount of time to startup. When the BIOS/UEFI hands over to Linux it will boot rather quickly unless you stop it or something is wrong. Do you have a piece of hardware that takes ages to startup? Systemd has a utility to profile and graph the boot sequence by time. It will literally tell you what is happening.
Use it and let us know how you get on.
https://embexus.com/2017/05/16/embedded-linux-fast-boot-tech...
Waiting more than 2 seconds to boot/start a device is like waiting more than 2 seconds for a webpage to load ... an eternity!
The opposite of this was the massive performance improvement that sqlite had a few years back. Many small incremental improvements that add up.
These 2 approaches are IMHO what you have to consider if you want to go fast.
Is this a typo!?
But I do see your point. Random file access speed isn't hugely different between a NVMe and SATA III drive.
https://web.archive.org/web/20070901234027/https://lightning...