What is the minimum boot time of FreeBSD?

Really? So Hyper-V, Virtualbox and VMWare don't work on Windows?


A base install of FreeBSD doesn't enable much by default (only devd(8), syslogd(8), sshd(8) and perhaps sendmail(8)). But X and KDE (assuming that because you mentioned sddm) are not part of base OS install. You enabled those yourself.
No I mean like how heavy windows already is to be running VMs

And right now in the vm its completely a base install nothing else installed yet
I mean other linux distributions by sddm
 
Let's define "boot time" as: time it takes from power coming on (which may be when the laptop comes out of sleep) to useful functionality, which may be serving network packets, having a shell login prompt, or a desktop environment responding to keyboard and mouse.

Single most important factor: Is the machine actually booting (re-initializing the hardware, OS kernel and all services), or is it just restoring from a hibernate or sleep state. May OSes (in particular MacOS and Windows) do not actually boot when you open a laptop or turn it on. So then the question becomes: How to enable sleep/hibernate when using FreeBSD on that particular hardware.

Second factor: Disk IO. With SSDs (including NVMe) as boot disks, one can get the boot time to around 10 seconds and below. With spinning disks, it's hard to get below 20-30 seconds (can be way more if lots of services are enabled).

Third factor: Hardware initialization, which mostly is BIOS, and (as SirDice already said) initialization of disk controllers. On a large enterprise-grade server with hundreds of (spinning) disks attached, this can take 10-15 minutes, because all those disks have to be spun up.

The OP is talking about using different init systems. My intuition is that this is a fool's errand, and won't make a significant difference. Similarly, creating a custom kernel (for example without modules, and only the needed drivers compiled in) no longer makes a significant difference.
 
… You don't need to reboot as often because there aren't kernel updates every other day. …

True, however there can be a reboot with precautionary use of a new ZFS boot environments before a package upgrade. Updates to ports are more frequent than updates to the (RELEASE) kernel.

… Windows 10 isn't shutting down, it is only hibernating …

Also, Windows 10 can start quickly without hibernation.

… i don't care if my system needs 10 seconds or 60 seconds …

More than sixty here (see above). For myself, I'm largely carefree about the duration.

… 4GB is barely enough for even a single OS with a full-blown DE, especially bloated ones like KDE/Gnome, …

That's somewhat disputable, however this is a base system topic; quote me elsewhere if you'd like to discuss. Thanks.
 
Colin Percival has been doing a lot of work in making faster boots on AWS - don't think he's too far off ClearLinux.

I think most of his progress reports are on Twitter - this is an old blog post so don't pay too much attention to these numbers (just might give you an idea where to go and dig).

 
According to Ed Maste, Colin's got it down to 9.5 seconds. See one of the foundation videos for information (video 2, around 6 minutes in if I recall correctly). This is from 28 seconds.
 
According to Ed Maste, Colin's got it down to 9.5 seconds. See one of the foundation videos for information (video 2, around 6 minutes in if I recall correctly). This is from 28 seconds.
Yep, here are links to the Video and Wiki for more information. The wiki also links to Colin's site which has a link to his Patreon if anyone wants to support his work.
 
This is also a always from to time recurring theme. Characteristic of it is, that the one that brings it always know that systemd is supposedly faster and that there are alternative init systems like OpenRC and runit that solves the problem that is not a problem. Init seems to be a problem, because due to this perceived knowledge it is made guilty of a slow booting that have other causes. Or perhaps just because the system does not boot at the minimum time, and hence that is too long. I do not find other explanation for these complaints against init. The danger of it is that some developers take these complaints seriously and we get another cool change for the sake change that bring real problems.
 
Characteristic of it is, that the one that brings it always know that systemd is supposedly faster and that there are alternative init systems like OpenRC and runit that solves the problem that is not a problem.

We were running several TrueOS clients which used OpenRC for nearly 2 years as a test case. For simple systems it might even work - but bring in just *some* e.g. network dependencies and it quickly falls apart on a regular basis. And it wasn't considerably faster than simple init - in fact the vanilla FreeBSD clients usually booted a little bit faster...
Shutdown/Reboot was almost never reliable and kept over 50% of those clients hanging at shutdown. I don't know if this (known!) Problem ever got fixed and I really don't care... I submitted a few patches to rc-scripts to make booting more reliable and most of them were reverted by later updates for the sake of "make booting faster". So the focus seems to be the same as with systemd: they don't want to bring up all systems reliable, but only a small subset of simple hosts in short times so marketing droids have something to brag about...
So OpenRC in the case of TrueOS solved a "problem" that never existed with being not better at what it tried to improve but introducing *real* problems left and right...

(I won't get started with systemd here, this won't end well...)

As it was already stated multiple times: On a cold boot nowadays with NVMes the system often takes longer to finish POST and hand over to the boot loader than the OS itself needs to boot. And if you are constantly in such a hurry that 5, 10 even 30 seconds more or less for a once-per-day task (in case of your laptop/desktop) are absolutely life-critical, you should really prepare for a heart-attack in the near future. Especially if you've traded in reliability at boot with "moh' speed" and thus have to get annoyed over a halfway-booted system once a week.
 
For example the change in the boot loader, taking away forth and putting lua.

IIRC the switch to lua was primarily done to ease maintaining and extending the boot loader while also removing some arcane stuff that has been there for ages and nobody even remembered or could figure out what it was doing but caused problems with EFI on a regular basis.
I think there even was an interview about that (partial) rewrite and the reasons for moving from forth to lua in the old "BSD now" show back when it wasn't just an audio podcast.

I generally find the "current" FreeBSD boot loader very reliable and flexible and never had issues, even when switching between EFI to BIOS booting or moving around disks it 'just works'™ absolutely reliable. So in this regard I think the upgrade was well done and really solved actual problems.
 
I generally find the "current" FreeBSD boot loader very reliable and flexible
Perhaps it is so. I was told in the list that the following problem has nothing to do with the rewrite:


It was very persistent. Was it endly solved?
 

13.1-RELEASE loader in the EFI system partition (ESP)​


The release notes say that the bootloader was updated with many improvements and that the boot time is cut to half comparing to 13.0. …

From TSLOG boot profiling : freebsd:

1652727341743.png


For flame graphs of this type, I'm not sure how much represents the time taken by what's in the ESP (after copying what's required to the partition).

I'll ask in Reddit.
 
I have tried to make these kind of graphs but always failed.
Is there a tutor for making these graphs Graham ?
Is there a "minimum kernel version ?"
 
Brendan Greggs website and his various articles and blog posts on FlameGraph are probably the best and most thorough starting points you can get.
I was loosely following his articles and presentations about the topic, but never found the time to really dig into it myself.
 
For flame graphs of this type, I'm not sure how much represents the time taken by what's in the ESP (after copying what's required to the partition).

Without reference to any graph, here's a comment from the developer: <https://old.reddit.com/r/freebsd/comments/s67ymv/-/i8utndz/?context=1>

… Is there a tutor for making these graphs Graham ?
Is there a "minimum kernel version ?"


– Alain, uppermost there's a link to the wiki, which links to Colin's repo with mkflame.sh. The wiki includes a graph for 11.1-RELEASE, and so on.
 
Reading and rereading this thread, the only thing that comes to mind is:
Do none of you drink coffee?

Power on/boot a system, walk away grab a cup of coffee, drink it and you've taken 2-5 minutes. Walk back to your system and it should be up for at least 3 minutes. That is my experience at least.

Some systems have issues (not problems) when probing USB devices. There are loader options you can set to not wait for these to finish, so the only thing is you may need to wait starting X for the mouse to get mounted.

Init systems have always been:
What depends on what, what can we start "now" what can we start "later".
All of that relies on a person correctly elucidating dependencies.
OpenRC is not bad, way better than systemd, but my opinion, not really better than current FreeBSD init.

Suspend/hibernate is a different story; why? a lot of success depends on the hardware and the drivers talking to it. Does the HW need to be "cold started" or can it be "warm started"? That is unclear for a lot of HW devices.

Now for me personally, I don't really care because I don't shut my systems down or suspend/hibernate. That makes "boot time" uninteresting to me.
 
Back
Top