[HN Gopher] Booting Linux in five seconds (2008)
___________________________________________________________________
Booting Linux in five seconds (2008)
Author : butz
Score : 51 points
Date : 2022-07-29 15:15 UTC (7 hours ago)
(HTM) web link (lwn.net)
(TXT) w3m dump (lwn.net)
| jvanderbot wrote:
| > It [Ubuntu] spends 12 seconds running modprobe running a shell
| running modprobe, which ends up loading a single module.
|
| Is this a typo!?
| JoshTriplett wrote:
| 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.
| bo1024 wrote:
| Don't forget how slow spinning hard drives were (are)!
| majewsky wrote:
| 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.
| sllabres wrote:
| Linux: < 1 second into a custom gui application
|
| https://embexus.com/2017/05/16/embedded-linux-fast-boot-tech...
| amelius wrote:
| Embedded products should probably use the hibernate/suspend
| functionality more often.
|
| Waiting more than 2 seconds to boot/start a device is like
| waiting more than 2 seconds for a webpage to load ... an
| eternity!
| HunterWare wrote:
| 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.
| sagarm wrote:
| hibernate doesn't require any power; the kernel "just"
| restores userspace from swap instead of going through the
| normal boot sequence.
| okso wrote:
| The four steps that take time when booting a Linux system are:
|
| * 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.
| bool3max wrote:
| 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.
| vladvasiliu wrote:
| > You can use `dmesg --boot` to analyze the boot of the Linux
| kernel.
|
| 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-zen
| rahimnathwani wrote:
| I just ran systemd-analyze on a low-power machine running
| debian buster. The last two lines of output were:
|
| 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.
| jjoonathan wrote:
| 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.
| sentientslug wrote:
| On my MSI board I think it's called Fast Boot or Fast
| Startup. Also not sure of the wording but an option to skip
| splash screen.
| Alupis wrote:
| 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.
| butz wrote:
| I've used `systemd-analyze` for whole boot process overview.
| Thanks to your suggestions I can dig deeper.
|
| Startup finished in 12.132s (firmware) + 1.822s (loader) +
| 2.106s (kernel) + 1.352s (initrd) + 10.098s (userspace) =
| 27.513s
| tecoholic wrote:
| 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?
|
| [1] - https://askubuntu.com/questions/1380790/is-it-possible-
| to-st...
| vinay_ys wrote:
| 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.
| gorkish wrote:
| 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.
| advisedwang wrote:
| My own experience is that systemd + SSD got me to 5s boot time
| (typing in LUKS passphrase takes me as long as the rest!)
| amelius wrote:
| They should write this stuff in Haskell, so booting can happen
| lazily and you can start using your computer instantly.
| caiobegotti wrote:
| 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.
| butz wrote:
| 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?
| weberer wrote:
| I'm going to guess its the BIOS taking up most of that time.
| Ubuntu and Manjaro both boot for me in less than 10 seconds.
| smoldesu wrote:
| 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.
| edgyquant wrote:
| Not sure what you're using but all my Linux boxes have boot
| instantly since I switched to ssds. I run a handful of hard
| drives, dedicated gpu, etc
| yjftsjthsd-h wrote:
| 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.
| andai wrote:
| 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.
| draxil wrote:
| 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.
| bxparks wrote:
| > I seldom reboot since linux hibernate got good
|
| 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.
| Faf wrote:
| Run Kodi, press S then select Suspend.
| yjftsjthsd-h wrote:
| 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.
| outworlder wrote:
| > 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).
|
| By modern hardware, I assume you are using a SSD.
| ggm wrote:
| 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.
| derefr wrote:
| > so e.g. raid disk arrays delay boot time to cohere and
| stabilise before they do cam control.
|
| 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?
| Alupis wrote:
| 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.
| JoshTriplett wrote:
| > 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.
| Alupis wrote:
| 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.
| JoshTriplett wrote:
| 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).
| Alupis wrote:
| 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.
| JoshTriplett wrote:
| > I still am not seeing the reason why this physical
| server needs to be capable of coming online in seconds.
|
| Spinning up in response to requests, without having to be
| constantly running (and being billed for).
| Alupis wrote:
| 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.
| znpy wrote:
| > Physical servers tend to have extreme uptimes,
|
| 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.
| Alupis wrote:
| 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".
| kevin_thibedeau wrote:
| 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.
| Alupis wrote:
| 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.
| fmajid wrote:
| RAM tests can be quite time-consuming. Not sure why they
| aren't parallelized.
| bitwize wrote:
| 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.
| corrral wrote:
| Lakka boots Linux on an RPi _and_ loads a (DRM--not X or
| Wayland) GUI in under 5s. Off an SDCard, at that.
| butz wrote:
| Interesting, it is based on LibreELEC. Might consider it when
| building own RPi appliances.
| sgtnoodle wrote:
| 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.
| nicbou wrote:
| I have the same experience with Windows. I launch Windows to
| play the same two games since 5 years, at it regularly fails
| at that simple task.
| zmxz wrote:
| 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.
| just_boost_it wrote:
| 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.
| noSyncCloud wrote:
| >It had at least three pages of full screen pop ups begging
| me to update to windows 11.
|
| Haven't booted into non-enterprise Windows for years (only
| use it for work) so this comment absolutely sent me. Thanks -
| needed a laugh
| vladvasiliu wrote:
| 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.
| dinvlad wrote:
| 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.
| sgtnoodle wrote:
| I run Arch. It seems like, in my case, its startup time is
| dominated by systemd networking coming up. It's pretty fast
| though.
| wyager wrote:
| Consoles used to be better about this, but now it's the exact
| same BS. The only console that makes an effort not to waste
| your time is the switch.
| mastax wrote:
| 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.
| numpad0 wrote:
| I wonder if it has to do with hardware stability, that the
| power supply or VRM could be unstable if pushed from 0 to 250W
| in 5s.
| lostmsu wrote:
| This would have to be re-verified, but my anecdata is that most
| of the time my rig spends loading NVidia driver.
| doliveira wrote:
| > 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.
| weberer wrote:
| 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.
| sgtnoodle wrote:
| 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.
| NickRandom wrote:
| 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.
| duffyjp wrote:
| I just timed my 4th gen i7 laptop booting Manjaro, and from
| power button to login screen was 12 seconds.
|
| What hardware are you referring to?
| throw10920 wrote:
| Depends on what distro you're running. If you haven't made time
| to move off Ubuntu, like me, than about 5 seconds is just
| loading Snap volumes :)
| checkyoursudo wrote:
| 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 takes ages to boot to login.
| danieldk wrote:
| _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.)
| SahAssar wrote:
| 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.
___________________________________________________________________
(page generated 2022-07-29 23:01 UTC)