Boot Ergonomics
- 5 minutes read - 997 wordsOn startup on most Unix machines, it’s common to see diagnostic data as the system starts up. In my book, FreeBSD shares too damn much.
Step 1: Taming the Boot Menu Logo
Open up /boot/loader.conf and add:
loader_logo="none"
What’s this do? It removes the FreeBSD logo from the boot menu.
⚠️ Be careful! Confusion lies ahead! ⚠️
Now it just so happens that the mascot is called “Beastie.” So you might think
that beastie_disable, as we’re about to see or that you read about in the
loader.conf(5) man page, would disable the image; it does not: it
disables the boot menu itself!
But now that you know that it’s an option, you might think: Well, heck I don’t need this menu; let’s disable it. I strongly advise against this. Part of FreeBSD’s charm is its ability to let you make boot-time adjustments/recovery if your system or disk goes sideways. Even if we’re “Just Focusing,” its possible we might need this.
👀 TOIMPROVE: It’s unfortunate that the semantics are muddled here. A “beastie menu” suggests that it’s a special type of menu. Really it’s the “boot options” menu; that’s a bit new-user hostile.
Step 2: Speeding Up the Boot Menu
Still in /boot/loader.conf, consider adding another line:
autoboot_delay=2
This tells the boot menu to reduce its default wait time before activating the default kernel from the boot menu to 2 seconds. However, two seconds is quite brief – you’ll need to be attentive if you want to interrupt the boot sequence because something broke. If you’re not going to be doing too much system monkeying, it might be OK to have this be very small.
Step 3: Covering Up Kernel Diagnostics
After we get past the boot menu, FreeBSD will want to test the hardware and register it with the operating system. This is very chatty.
In /boot/loader.conf, add:
boot_mute="YES"
This places a graphical overlay on the screen during the kernel’s hardware initialization and diagnostic process. You’ll get a FreeBSD text-mark and that “Beastie” orb graphic – more on that orb in a moment.
Based on a mailing list discussion I was in, tying this overlay behavior to a
flag called boot_mute is now likely an error. The flag was intended to
squelch all boot output for networking devices that were built on FreeBSD and
needed to be silent about their diagnostic data. Unfortunately, this flag is
now used for “drop an overlay.” It’s very confusing.
Step 4: Silencing RC Script Console Noise
FreeBSD, following the grand UNIX tradition, uses RC scripts to boot up various
daemons. And they are chatty. While boot_mute wallpapered over (literally)
the kernel output, these scripts still love to talk.
Look, it’s ridiculous that so many smart people are trying to figure out how to make messages from the system go away. And I don’t mean just myself, to wit: vermaden and rldane and my own pull request and the insane lengths that helloSystem has gone to. Stop making this hard, FreeBSD.
👀 TOIMPROVE: Please give us a simple way to wallpaper over the RC scripts Maybe dumping the content into the bit-bucket is wrong (maybe not, too), but just make boot_mute’s behavior extend – please.
Step 4: Silencing Console Noise
When Unix was first deployed, it was run on machines that lived in computer rooms (and later data centers) far away from most users. But the computer (“server”) often had a special screen/keyboard combo near the machine called a “console.” If something went wrong, the administrators would use that console to access the machine directly (often via a baby-blue serial cable).
Most folks would connect over a network. These were at “regular” terminals.
FreeBSD honors these roots by making the first virtual terminal the default dump for console events. So while you’re there acting like a user (i.e. on a “terminal”) something goes wrong from an administrative perspective (WiFi lost connection for a few seconds) and suddenly that noise is in the middle of your screen while you were trying to “Just Focus.”
Irritation around this lead me to explore the
vt_core
to figure out how to customize this relationship (ultimately abandoned, but I
learned a lot!). My plan was to have virtual terminal behave like a running-log
terminal screen while I logged in on virtual terminal 1. It would be a very
gnarly change. So….let’s just send all those events to a file.
Update /etc/syslog.conf to redirect console events:
- Modify the configuration to send events to
/var/log/console.log - Create the log file:
# touch /var/log/console.log
# chmod 600 /var/log/console.log
- Restart the system logging daemon:
# /etc/rc.d/syslogd restart
This ensures that log events don’t interrupt your primary console, keeping things clean and quiet.
The Ongoing Challenge
So for now, let’s call this a step forward.
Here’s a milestone! We have a functional system, and we can start using and installing userspace apps. Let’s get our graphical tools in place so that we can read PDFs, browse sites, consult videos, and Just Focus.
A Word About Beastie
Reader: I do not care for Beastie. It’s not some religious resistance to Satan-adjacent iconography. I just feel like it’s kinda juvenile – the sort of mascot I’d expect to see as a back shoulder tattoo on a bleached-blonde at a Van Halen concert, perched on her boyfriend’s (Ronny) shoulders.
More critically, this mascot probably torpedoes some of FreeBSD’s corporate sponsorship opportunities. Given the choice between donating to a cute tubby penguin or a demon-adjacent orb, you know which way the conservative (see: 2024-2025) business crowd will lean.
I’d much rather talk about FreeBSD’s great features than explain away d(a)emon iconography. Looking at a recent interview with Greg Kroah-Hartman gkh, Linux kernel maintainer, he’s talking return on investment, he’s talking about open-source as a strategic imperative, he’s talking about a reliable and distributed maintenance process. He doesn’t have to address “so, uh, are you guys into Satan or something?“1