What I was talking about was not virtualized. VMs start even faster. On the other hand, if you need to restart that much, you're really doing something wrong.
There is always room for improvement. Like if you set the initramfs dep based, the whole process speeds up, but on a kernel upgrade it tends to error out. Why?
Why enumerate usb devices on boot, when you have zero devices that need usb? Raid speed testing... and the list goes on.
> Why enumerate usb devices on boot, when you have zero devices that need usb?
Are you sure? On servers there are generally a couple of USB based devices which handle BMC, hardware debug logging, etc. Just because you don't have physical ports, this doesn't mean the USB bus is empty and silent.
When you connect to a server via BMC and request the console, you get two USB devices at least. One for mouse, one for keyboard. More devices appear if you attach virtual volumes remotely.
> Raid speed testing...
Because Linux kernel is stateless. There's no guarantee that you're booting on the same processor (make, model, family, even system bus layout) as the last boot. Moreover, there's no guarantee that you're not rebooting because of an unmaskable MCE which is fired because you lost half of your vector units (SSE/AVX blocks) or half of your FPU units, or any other CPU IP block (because you fried them) and you're in limp mode now...
I have seen tons of these events and similar ones first hand. I'll prefer my systems to spend three more seconds to boot successfully so I can debug them rather than the kernel makes some assumptions and catches fire in a completely unrecoverable state leaving me stranded.
> This isn't about your or my use case and/or preferences.
Exactly! This is why Linux kernel does and shall ship with a configuration which supports everything out of the box, even if it's slow. Because it covers everyone's use cases that way.
If you need to trim it down to fit to your system(s), you should be able to do it. Debian has a mechanism called "Targeted Kernel" which removes the modules which won't be used on your system automatically during kernel upgrades.
Nobody is stopping you from doing whatever you want with your system to boot it faster.
For me, I'm fine with the Kernel as is, because some of my servers already take multiple minutes to initialize the plethora of devices on themselves. So a three second delay changes nothing on a system which is rebooted once a month at most.
Same applies to my desktop systems, which are either on or at S3 sleep, which wake in <3 seconds anyway (I wait for the monitor to come back mostly).
Sigh... we are going in circles. You like the slow boot. You like suspending things, I'm against it. I'd rather not elaborate, because you will like the opposite of it, no matter what.
No, we are not. It's not a matter of slow vs. fast. It's a matter of resilient vs. fragile.
I prefer to have a resilient system in most cases, regardless of the form factor. If I was preparing an image for an embedded system, I'd go speed all the way down, within the limits of pragmatism.
I work in high performance computing. Speed is what we need, what we engineer for. However, resiliency is an equally important and valid concern. So, if I'm losing 5 seconds once a month (or once three-four months in case of desktop systems), that's a perfectly acceptable trade-off for a resilient system.
When a system tests its memory for 30 seconds, and initializes the motherboard and other devices for 3 minutes, losing 3 seconds on a bloody RAID speed test doesn't matter.
Oh, one of the latest servers we have exposes its management interface as a LAN port over USB, as I found out yesterday.
A modern system with a connected network can boot quite fast. Windows' instant boot is not boot actually, it's thawing hibernation.
One of the biggest features touted by systemd is "embarrassingly parallel" booting capabilities, which Parallel SYS-V already sported.
IOW, Linux already can boot pretty quickly given no hardware device is holding it back.