What is the minimum boot time of FreeBSD?

I think one would need to define what is being timed.
Power off to login prompt? Big difference between console and X/graphical login.
Not sure what is "right" but simply it needs to be defined.
 
The FreeBSD init system just takes a looooong time and although I am just running it in a VM right now when I actually use FreeBSD for desktop usage the bootup time might be a problem. When windows took too long to boot I would end up doing nothing productive. It breaks the flow. I am gonna use the OpenRC or Runit systems but I was just wondering is it possible to make the time even shorter like clear Linux? (I know this goes against the forum rules but I am just curious)

I noticed a probably important difference between booting a Windows 10 box (boss laptop HP EliteBook) and my FreeBSD v 13 (Lenovo ThinkCentre with SSD). Regulary I push the power buttons the same time, just to see who wins the race.

W10 is rather fast in getting to the user login, but after that it takes ages to get an fully functional GUI. The system doesn't give much feedback, but when starting a program often there comes a dialog that the system is busy with things needed for that package. Sometimes the wi-fi connects automatically, sometimes not (it is set not to connect automatically)

FreeBSD boots fast. Searching the wi-fi SSID and syncing time takes some time. Then I'll have to log in to my account and start x (with an alias called 'x'). That happens just as fast as you can type your accountname, password and hitting 'x <enter>'.

In the end the FreeBSD box is always ready for use first !

It seems that FreeBSD is handling all basics before letting anyone login. That means that the system is ready for use. W10 presents itself, but isn't ready for use when showing something graphical. 'Boot philosophy' -- tech optimized (FBSD) or showcase (W10)...

If you want I can stopwatch both and post it here together with hardware specs.

[20220531 edited] I 'stopwatched' both my FreeBSD 13.1 box and W10 boss-box. Below are the times in this speed test:

From Power-button (HW) to login screen primary user
W10 = 35 secs
FBSD = 42 secs

From login (uname, passwd, <Enter>) to a working environment
W10 = 3m 02 secs, fully functional (loading system resources after starting a program) = 4m 11 secs
FBSD = < 1 sec, immediately usable TTY, after typing 'x' (alias for startx the same, immediately operational GUI (x11-wm/cwm)

Conclusion
The W10 operating system is very good in window dressing -- suggesting it is ready to use, but needs lots of stuff after putting app(e)aling graphics on the screen.

FreeBSD is honestly straigtforward -- when a user is able to login, the box immediately is fully operational, both in TTY as in GUI

Declaration of possible conflicting interests: a started CWM session has nothing to show and therefore is always faster. My preoccupied and verified attitude towards W10 needs no further explanation on this targeted forum.

Disclaimer: measuring time is accurate-ish, because hitting three hardware start buttons on three different devices in the same time is humanly challenging.
 
Last edited:
I noticed a probably important difference between booting a Windows 10 box (boss laptop HP EliteBook) and …

HP EliteBook 8570p here. Colleagues previously used this model with Windows 10. I use persistent L2ARC (two thumb drives), which greatly improves things; there's nothing comparable for Windows for this hardware. Comparing would be like apples versus oranges.
 
It takes roughly 18 seconds from invoking bhyve (to run a guest FreeBSD13.1-STABLE running GENERIC) to the first ping and another 7 seconds to logging in via ssh. This includes getting a host address via DHCP. Far too slow :)
 
  • Like
Reactions: mer
Some times fast boot is convenient, you may be happy getting a coffee but other people are happy not getting a coffee...

It interests OS devs and they get to do it without malignant systemd cancer.
 
I'm not saying a fast boot is a bad thing, but one needs to define "what is being timed". Most Windows systems boot to a graphical login pretty quickly even with fast boot disabled, but if you log in right away the system is not completely done booting. I consider "booted" meaning "fully booted", at least to a console, basically what used to be called run level 3 (networking, multiuser). So all network devices configured and up, all devices in use configured and up.

Heck a fast boot time is not a bad thing for servers because in a failure case, the services are up and running quicker.

If you look at what happens during the init phases, there are some tasks that don't depend on anything and nothing depends on them, other tasks that don't depend on anything but others require them, others that both depend and are required on. Much like things in the ports tree.
The sequencing of the tasks is the biggest driver (my opinion) of the boot time. One can do the "thundering herd" where everything starts at the same time, perhaps competing with each other, perhaps completing incorrectly and needing to be restarted (think WiFi and networking). Or one can try and add the dependencies so tasks are only started when all their prerequisites are satisfied; this gives each task a greater chance of succeeding the first time.
The thundering herd often "boots faster" but the system may not be completly booted to a usable state.
The sequencing (in theory) always boots completely and correctly, but may be slower. Of course as soon as one "fixes" something they may break the sequencing.

I think instead of figuring out the last seconds of a boot, proper suspend/resume would be a more interesting path (my opinion). But there is a lot there that depends on the specific hardware, how it is actually wired and do the device drivers correctly initialize the device on resume (not a trivial task).

Sorry for the too many words.
 
Heck a fast boot time is not a bad thing for servers because in a failure case, the services are up and running quicker.

2/3 and more of the boot time on a server are spent for POST of the system and various controllers. The OS is by far the smallest factor when (re)booting a server. And I ABSOLUTELY don't care if the OS takes 10 or even 30 seconds longer to boot, as long as it comes up reliable and predictable/reproducible.
 
And I ABSOLUTELY don't care if the OS takes 10 or even 30 seconds longer to boot, as long as it comes up reliable and predictable/reproducible.
This is my position also, even for my home desktops, but I acknowledge others have different needs.
 
If your 'mission critical' service is running on a single server, you're doing it wrong. Who cares how long it takes for a single node to boot if I have several other nodes running and serving requests?
 
And I ABSOLUTELY don't care if the OS takes 10 or even 30 seconds longer to boot, as long as it comes up reliable and predictable/reproducible.
An OS booting and being reliable and predictable/reproducible, that goes without saying as it's the entire point of an OS booting...

Prove you truly don't care add some sleep in somewhere, random between 0 and 3600 seconds. You might have time for more than one coffee.
 
Today i profiled my 13.1-RELEASE on bare metal using the method described here:

What is loader.efi doing so long?
 

Attachments

  • tslog.png
    tslog.png
    73.3 KB · Views: 84
It wait 10sec to show you the menu.
To add to that: That duration can be adjusted via autoboot_delay="10" in boot/loader.conf where the unit is seconds.

Personally, I find myself leaving it to the standard 10 seconds on servers but setting it to something more sensible like 2 seconds on desktops.
 
You can turn it off completely if you want. But it's going to make booting to single user mode, or selecting a different kernel or BE a little more challenging.
 
  • Like
Reactions: mer
You can turn it off completely if you want. But it's going to make booting to single user mode, or selecting a different kernel or BE a little more challenging.
How would one go about doing that if the boot menu is disabled/skipped entirely? Does it involve booting a Live system, mounting the FS and setting some magic flag somewhere before booting? :D

I'm asking for a friend.
 
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
cryptodev_load="YES"
zfs_load="YES"

autoboot_delay=1
efi_max_resolution="1680x1050"
#hw.syscons.disable=1
screen.depth=8
This is my loader.conf. I changed the UEFI bootorder to start directly freebsd. As you can see: The loader.efi is still the biggest chunk. At least 50% of the time is the loader.efi with an autoboot_delay of 1.
 

Attachments

  • tslog.png
    tslog.png
    66 KB · Views: 68
schorsch_76
What if you add the following to your loader.conf? This means "don't wait for usb probing to finish before continuing the boot".
It does mean that sometimes you may not have things like a mouse cursor immediately but if you are not booting/mounting external USB
drives to boot from, it's reasonably safe or at least is has been for me.

hw.usb.no_boot_wait="1"

EDIT:
Not sure but are you booting from encrypted devices? That could have an impact as they are decrypted which takes memory and time.
 
I'm assuming that loader.efi is searching for zfs to import the zroot pool and then to load the /boot.config and kernel and if you have multiple disks/partitions this can take more time.
 
mer
I boot from an unencrypted Samsung 870 Evo 1TB SSD device (FreeBSD), 860 Evo 1TB (Linux) and 850 Evo 500GB (Windows) on the machine.

This is my Layout of all online disks:
Code:
gpart show
=>        40  1953525088  ada0  GPT  (932G)
          40      409600     1  efi  (200M)
      409640  1953115488     2  freebsd-zfs  (931G)

=>        34  1953525101  ada1  GPT  (932G)
          34        2014        - free -  (1.0M)
        2048      204800     1  efi  (100M)
      206848     4194304     2  linux-data  (2.0G)
     4401152  1949123983     3  !ca7d7ccb-63ed-4c53-861c-1742536059cc  (929G) (encrypted luks)

=>       34  976773101  ada2  GPT  (466G)
         34       2014        - free -  (1.0M)
       2048    4194304     1  efi  (2.0G)
    4196352  962221696     2  ms-basic-data  (459G)
  966418048        384        - free -  (192K)
  966418432    1187840     3  ms-recovery  (580M)
  967606272       4096        - free -  (2.0M)
  967610368    1054720     4  ms-recovery  (515M)
  968665088       2048        - free -  (1.0M)
  968667136    1814528     5  ms-recovery  (886M)
  970481664    4194304     6  linux-data  (2.0G)
  974675968     204800     7  efi  (100M)
  974880768      32768     8  ms-reserved  (16M)
  974913536     204800     9  efi  (100M)
  975118336    1654799        - free -  (808M)

On the 500G SSD i have an Efi Partition with starts grub. For this freebsd boot time check, I changed the UEFI default boot to the loader.efi from the 1TB FreeBSD SSD.

The system is also reasonable fast i guess. On Linux (including the unlock of the device) its up in under 30 secs. Also Win10 starts very fast.

This is the system info:
Code:
inxi -F
System:
  Host: Hammerhead Kernel: FreeBSD 13.1-RELEASE amd64 bits: 64
    Console: pty pts/1 OS: FreeBSD 13.1-RELEASE
Machine:
  Type: Desktop System: ASUS product: N/A v: N/A serial: N/A
  Mobo: ASUSTeK model: ROG STRIX B550-F GAMING v: Rev X.0x
    serial: xxxxxxxxxxxxxxxxx UEFI: American Megatrends v: 2201 rev: 5.17
    date: 04/07/2021
CPU:
  Info: 16-core model: AMD Ryzen 7 3700X bits: 64 type: MCP MCM cache:
    L2: 4 MiB note: check
  Speed (MHz): 3593 min/max: N/A cores: No OS support for core speeds.
Graphics:
  Device-1: AMD Curacao PRO [Radeon R7 370 / R9 270/370 OEM] driver: vgapci
  Device-2: HD Pro Webcam C920 type: USB driver: N/A
  Display: server: X.Org 1.20.14 driver: loaded: modesetting unloaded: vesa
    resolution: 1: 1680x1050~60Hz 2: 1680x1050~60Hz
  OpenGL: renderer: AMD Radeon HD 8800 Series (PITCAIRN DRM 3.35.0
    13.1-RELEASE LLVM 13.0.1)
    v: 4.6 Mesa 21.3.8
Audio:
  Device-1: AMD Oland/Hainan/Cape Verde/Pitcairn HDMI Audio [Radeon HD 7000
  Series]
    driver: none
  Device-2: AMD Starship/Matisse HD Audio driver: hdac
  Sound Server-1: OSS v: 2009061500 running: yes
  Sound Server-2: PulseAudio v: 14.2 running: yes
Network:
  Device-1: Intel I350 Gigabit Network driver: igb
  IF: igb0 state: no carrier speed: N/A duplex: N/A mac: a0:36:9f:00:82:3e
  Device-2: Intel I350 Gigabit Network driver: igb
  IF: igb1 state: active speed: 1000baseT duplex: full-duplex
    mac: a0:36:9f:00:82:3f
Bluetooth:
  Device-1: CSR8510 A10 type: USB driver: N/A
  Report: No OS support. Is a comparable bluetooth tool available?
RAID:
  Device-1: zroot type: zfs status: ONLINE level: linear raw: size: 928 GiB
    free: 866 GiB zfs-fs: size: 899.25 GiB free: 807.91 GiB
  Components: Online: 1:
Drives:
  Local Storage: total: raw: 2.27 TiB usable: 4.06 TiB used: 58.29 GiB (1.4%)
  ID-1: /dev/ada0 vendor: Samsung model: SSD 870 EVO 1TB SVT02B6Q
    size: 931.51 GiB scheme: GPT
  ID-2: /dev/ada1 vendor: Samsung model: SSD 860 EVO 1TB RVT03B6Q
    size: 931.51 GiB scheme: GPT
  ID-3: /dev/ada2 vendor: Samsung model: SSD 850 EVO 500GB EMT03B6Q
    size: 465.76 GiB scheme: GPT
Partition:
  ID-1: / size: 821.9 GiB used: 13.99 GiB (1.7%) fs: zfs
    logical: zroot/ROOT/default
  ID-2: /tmp size: 809.32 GiB used: 1.41 GiB (0.2%) fs: zfs
    logical: zroot/tmp
  ID-3: /usr/home size: 815.44 GiB used: 7.53 GiB (0.9%) fs: zfs
    logical: zroot/usr/home
  ID-4: /var/log size: 807.91 GiB used: 965 KiB (0.0%) fs: zfs
    logical: zroot/var/log
  ID-5: /var/tmp size: 807.91 GiB used: 24 KiB (0.0%) fs: zfs
    logical: zroot/var/tmp
Swap:
  ID-1: swap-1 type: partition size: 32 GiB used: 0 KiB (0.0%)
    dev: /dev/zvol/zroot/swap
Sensors:
  System Temperatures: cpu: 42.1 C mobo: N/A
  Fan Speeds (RPM): N/A
Info:
  Processes: 118 Uptime: 53m Memory: 31.88 GiB used: 4.65 GiB (14.6%)
  Shell: Bash inxi: 3.3.11
 
This is the Result with just the FreeBSD SSD attached: 70 sec instead of 72 sec.

And this are the 20 top long lasting functions.
Code:
./stackcollapse-tslog.pl < ts.log | sh supercollapse.sh | head -n20
67470759036 interp_init
57309920784 BIOS
22762042776 317 /sbin/rtsol
14855929380 autoload_font
12667152157 _sleep
12463797132 kvprintf
11232296208 cons_probe
7637027724 1180 sleep
4526271000 hammer_time;DELAY
3826980900 343 sleep
3822667308 344 sleep
3668996087 kernel
2970714456 179 kldload
2337738912 472 /etc/rc.d/netif
2087294112 VFS_MOUNT zfs
1693931652 twiddle
1623312576 DEVICE_ATTACH atkbd;DELAY
1425531960 1294 /etc/rc.d/zfsd
996503509 1030 /etc/rc.d/devmatch
987635592 efipart_readwrite
 

Attachments

  • tslog.png
    tslog.png
    66.5 KB · Views: 69
I updated my BIOS/UEFI and my boottime got down to 61 sec, The time was "cut off" the BIOS part.

Setting in loader.conf the console to "console=nullconsole" the boottime gets down to 48 sec.

tslog1: new BIOS
tslog2: new BIOS + nullconsole
 

Attachments

  • tslog1.png
    tslog1.png
    65.6 KB · Views: 63
  • tslog2.png
    tslog2.png
    61.6 KB · Views: 62
Back
Top