I strongly suspect it would give you the content of the kernel log ring buffer (what "dmesg" alone gives you), but up until the time that userspace comes up, probably.
A 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.
Correct me if I'm wrong but nowadays you can completely skip the "bootloader" step by using EFISTUB, i.e. having the UEFI firmware load the kernel as an UEFI executable.
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.
Yes, and it's quite comfortable. If you don't want to use external media, many boards also come with a builtin UEFI shell which is quite powerful. From there you can simply execute the kernel with the desired cmdline. (like ./vmlinuz root=...)
I did a `systemd-analyze citical-chain` and noticed that `snapd.service` took the most amount of time. So I edited the `/lib/systemd/system/snapd.service` based on the suggestion here [1] and set `After=network-online.start`.
The critical-chain time has from ~12 sec to ~4sec. Here is full `systemd-analyze`
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?
snapd doesn't block your interactivity. You can start typing in your password and login and start to launch your app, meanwhile the user space startup sequence is still running.
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.
re: bios settings, any keywords I should look for?
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.
Were you using UEFI mode, Fast Boot mode, and an NVMe drive? Boot times should only be a few seconds at most under similar configurations.
"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.
So I've mostly learnt from you but it's also possible I'm right here so I'd say- you can very well boot into firmware from bootloaders too. Systemd-boot has one default entry on my installation and I believer grub allows u too. Gonna actually go lookup grub because I need that entry
You'd be surprised how faster the boot time back in those days got simply by disabling the kernel's printk! It was mostly for fun, of course, and there were alternative special-purposed inits too. I worked on a couple low-tier "netbooks" projects and the fastest we got was between 7-10 seconds but it wasn't worth the trouble and 15-30 seconds of boot time [to a fully functional desktop] back in 2008 was already fantastic anyway.
I have a 5950X CPU, a gen 4 PCI-E NVME, and a 6800xt GPU. I normally run linux, but I wanted to play a computer game in VR last night like a jerk. I rebooted into Windows 10. It had at least three pages of full screen pop ups begging me to update to windows 11. I launched Steam. It took about 10 seconds to load, then restarted itself to update, then downloaded about 1GB of game files and did about 5GB of disk IO, over about 5 minutes. Launching VR took about 30 seconds, with at least one error message. The game didn't work with an obscure error message, and so I spent 10 minutes and a reboot updating my graphics drivers. That didn't work, so I tried deleting the game's config file. That didn't work, and so I unplugged all but one monitor. I finally got the game to work, and I had to restart it twice to tweak the graphics settings since I had deleted the config. So, about half an hour of hassle to play a game for about half an hour of gameplay.
I seldom post on annoyances, but what you wrote is such a similar experience to mine.
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.
The best thing about Windows 11 is that it finally pushed me to go to Linux, and I switched to Pop OS. I had played around with Mint 10 or so years ago, so honestly, I was braced for a whole lot of friction and little irritations, missing drivers, hours on stack overflow, that kind of thing. The best way I can describe the actual feeling was like putting on aftersun after getting sunburned. It's honestly bizarre that I can feel the absense of intrusion as the OS just does its thing in the background.
Its always real hard o make these decisions. It was between Mint, Ubuntu and Pop. Pop comes with nvidia drivers, and I liked the window tiling and keyboard shortcuts.
> It triggers my bios update - to my surprise, I had no idea an OS can do that.
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.
Apologies if you're already aware of this, but DoTA is one of the first games Valve ported to Linux, so it should play just fine (some say better) without requiring to boot into Windows.
It works on Linux, but there's constant stuttering when the game starts. I do play it on Linux, however it's easier to boot into Windows when it comes to odd LAN party here and there and playing games with friends without looking into which Proton runtime to use and such :)
Thanks for the heads up, I did know but I appreciate the intent!
Proton is not needed because it's a native version. The stuttering might be due to uncached shaders, which now steam downloads periodically, so it shouldn't be an issue.
Windows has a lot of tasks that are scheduled to run infrequently. Search indexing, checking for updates, TRIM and defragmenting, antivirus scans etc. However if you only boot Windows infrequently, then those tasks will run every time you boot. I've seen this happen many times where someone who uses Windows infrequently is always greeted with a slow computer which encourages them to stop using Windows altogether.
Microsoft should really fix that one of these days.
I use my playstation very rarely. I have almost this same experience every time. Lots of systems seem to want to 'update the world' if you have not used them in a few months.
Man, I don't know. I only use Windows for gaming, and I'm as much annoyed by it as the next guy, but I'm always impressed with how fast it boots compared to Linux (Arch with i3). Granted, apart from Steam, nothing's installed. But on Linux, not much is started in the background before I log in, either.
This on a 2013 Xeon 2667v2 (ivy bridge) with a PCIe 3 NVMe.
Same here - since upgrading to NVME SSD my boot times were 3-5 sec (!) with Win10, and 5-10 sec with Win11. I think there's at least something they're doing right, and normal Linux desktop has a long way to go still (mine still easily takes 1 min on the same system..)
I think among the three, MacOS takes the crown though - easily takes 5 minutes to boot, at least on an enterprise system.
I dual boot Windows and Linux on my home computer, Windows is quick to start (if I can keep the is reasonably clean) but Linux was still faster.
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.
Do you remember drive caddies that fit into 5.25 bays?
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.
Your motherboard probably has a header for a chassis intrusion switch, and presumably grub is open source, so you could probably do that with a few hours of hacky coding. Or, you could use an Arduino Leonardo and simply emulate a keyboard that pushes the right sequence of keystrokes at the right time.
wow. my macbook takes about 6 seconds to get to a login screen from a cold boot. maybe you've got some network shenanigans going on due to the enterprise environment?
I also run Arch. `systemd-analyze critical-chain` shows that the longest Linux step is `systemd-udev-settle.service`. The UEFI step is longer still, and I don't have a classic bootloader, I use efistub.
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).
Some of it is that it's not an explicit goal. Also, some of that time is spent doing things that are actually useful to some people, or doing things that the system needs to do unless someone tells it not to. For example, it might spend time waiting for hardware to settle, then querying what hardware there is, then loading drivers for the hardware. If you know in advance what hardware there is and how long until it starts up and know that you won't need anything else, you can disable it, but for a generic OS that boots on arbitrary hardware and works, it has value.
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.
I've been wondering about that... Linux seems to spend a lot of time investigating the hardware, as though it's booting for the first time, and not the thousandth. I basically never change system hardware, so it would make more sense to hold Shift or something while booting to trigger that stuff.
I'd generally prefer a machine that copes with whatever it finds rather than keeping state, which is a recipe for trouble. I've booted an old disk on a different hardware and have it be fine. I've also seen windows folk change some hardware and have their machine freak out.
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.
Windows has gotten surprisingly good in this regard in the last few versions, you can now swap out the SSD into a different machine and it should just work. (You may invoke the vengeful spirit of Gates, which deactivates your license, but the drivers work, at least...)
I would be interested in making it optional - maybe even a setting to cache the hw config unless you pick a different option at boot time (separate item in bootloader menu). But being able to adapt when it does come up is extremely useful - I've moved drives from one machine to another plenty of times, so having the ability to do that kind of thing matters to me.
To clarify my own comment, I did not mean that I don't want Linux to know how to handle new hardware (a fantastic feature indeed), I just mean that there is no need to waste my time every single
boot, when I know I'm booting the same config as the day before. If I do add something (or migrate the drive), I can just boot into a "rescan everything" mode and then what is usually a waste of time becomes actually useful.
On a VM, you often don't. I get login: on a bhyve virtual debian or FreeBSD in seconds.
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.
Depends on the specific server hardware of course. Generally, yes the hardware RAID controller does consume a great deal of time (often displaying a splash screen with progress on the console, if one is connected at boot).
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.
> Generally speaking, for a server, boot time is not a factor. Nobody needs their physical server to boot and be ready in 5 seconds
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.
I'm curious what that use-case might be, if you are able to elaborate.
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.
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.
In that context, does it not make more sense to rent the infrastructure instead of host in-house? Or, use commodity hardware that does not have all the redundancy and resiliency baked in at the hardware level - after all, it's completely unnecessary for short-lived services.
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".
> In that context, does it not make more sense to rent the infrastructure instead of host in-house?
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.
Many people want to use physical servers via the same kind of infrastructure that gets used for VMs. Consider something comparable to AWS's `.metal` instance types or the Kubernetes "bare metal" provider, for running things that don't run in a VM (such as VMs, since nested virtualization is variously unavailable or slow).
Perhaps I'm just "old-school", but I still am not seeing the reason why this physical server needs to be capable of coming online in seconds. When renting a physical server, typically one understands the trade offs they are making versus operating a pure VM infrastructure, even for development purposes. VM's alleviate concerns about hardware for the most part.
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.
Is this not the perfect (and intended) use case for VM's, Containers, "Serverless" Functions and other mechanisms that all ride on top of already booted physical hardware?
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.
My system boots slow because I have a legacy SCSI card installed and it's boot ROM takes ages to get running and scan the bus. Servers are more likely to have these sort of facilities onboard.
Absolutely. Although I wouldn't peg this to just legacy support - in my experience even modern SAS arrays take ages to come online.
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.
>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.
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.
> If Linux could boot in 5 seconds on low tier hardware in 2008, why do I need to wait ~30 seconds to boot it on modern hardware in 2022?
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).
> Once you understand your computer has 16 cores running at 3GHz and yet doesn't boot up in .2 nanoseconds you understand everything they have taken from you.
I recently got a new work laptop that doesn't support sleep mode (s3). Apparently its something that the vendor has to support in the BIOS. Dell says they're not going to support it anymore since Windows uses some fake sleep mode nowadays so they can collect telemetry 24/7, and they don't want to put in the effort just for Linux users. I can't believe we're going so far backwards with technology these days.
To be fair, those 16 cores probably don't work at all until an obscure microcontroller configures them. It's probably running in the Mhz range, off of a flash or EEPROM chip. It's potentially copying in several MB of firmware into other obscure things. Still, that should only be 100ms or so.
No idea but I can cold boot a Deb VM containing full Samba and Emby Media server installations and have it responding and serving media in under 4 seconds.
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 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.
With Gentoo/OpenRC using a minimal config and compiled kernel and booting from an efistub with built-in kernel cmd pointing to the root filesystem, my desktop boots from cold to login screen in about 8 seconds.
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.)
Yeah, I don't reboot the macbook more than once every many weeks so it's not a big deal or anything. On the other hand, my super speedy linux doesn't quite know how to hibernate right, while the macbook does and wakes up again like a champ--like instantly. You win some and lose some.
I have similar boot times on arch/systemd with efistub too, and with some basic optimization I get to sub 5s. At least for ubuntu there is a large layer of crap (snap, etc) that keeps it from being performant, and for other distros I'm guessing they have their own choices of what blocks the graphical target.
I put a full, persistent Gentoo install on a usb drive (like a little 250GB flash drive) with a universal (e.g. livecd, BIG) kernel and disk encryption, and even that only takes about 30 seconds to get to the login screen on any relatively modern hardware.
Loading from a flash drive.
Some distributions make some ... interesting choices w/r/t performance. I guess.
Because your distro's boot chain is a garbage fire?
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.
If you're on a sufficiently fast SSD, you can boot Linux with a desktop environment in less than 5 seconds. Your "modern hardware" is probably getting throttled by flash storage or something.
A common use case for this is things like car/plane instruments/nav/etc. You don't want that sucking power all the time when your vehicle is parked for 1 week or two, but you do want a quick transition from POR to usable UI up and running.
Hibernate has the disadvantage of needing a clean shutdown and increasing write cycles. You'd rather avoid the need to design for both. Additionally many embedded devices don't have perfect firmware and behave "weird" after a while (see planes needing a reboot every few months), which you'd extend over power cycles with this.
Back about 20 years ago when I did my first Car PC, I got ~3s boots to graphical UI (SDL Framebuffer) using LinuxBIOS (now coreboot) and a very well curated set of hardware. I do remember that I was using the EPIA M VIA Mini ITX board (one of the first Mini ITX boards) and I had a special adapter that let me switch between two BIOS chips.
No, it isn't. modprobe has a configuration file, and one of the directives in the configuration file is "if asked to load this module, run this command instead". And that command is sometimes "go figure out which module to really load". So "running modprobe running a shell running modprobe" was correct.
And by now, lazy programmers have made their programs so fat that SATA SSDs feel as fast as HDDs felt back in the day. Now everyone is hailing NVMe SSDs as our savior.
My wife's gaming laptop has an NVMe drive. My aging gaming PC with a SATA III SSD objectively boots slower than hers. Games start faster on her laptop too.
But I do see your point. Random file access speed isn't hugely different between a NVMe and SATA III drive.
I use a Linux desktop and a MacBook for various things, and one of the things I appreciate most about my desktop is how fast it boots. I'm not sure if I configured anything special, I use xubuntu with i3, but it takes around 5s to boot and 1s to shutdown.
* 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.