New FreeBSD Boot Loader Menu

FreeBSD. It is Free (in the truest sense; with a capital-F) and is a descendant of Berkeley Systems Distribution (specifically BSD-Lite v4.2/4.4), which originated from the University of Berkeley, about 2.5 miles away from where I live (though I’m not a student, nor have I ever been). FreeBSD is an amazingly versatile and flexible UNIX operating system with ancestry reaching back decades.

This entry is for those persons already well versed in this well-edified system.

I would like to announce a completely new — written from scratch — boot menu for the FreeBSD operating system. It is today that I release the code that I’ve been developing for nearly 5 years. Code to enhance the level of options provided to the user at each and every boot of this venerable OS.

Historically, the original menu offered by FreeBSD featured our beloved helper-daemon mascot, named “Beastie.” But soon after, this menu was revamped to [a] lay-rest our triton-carrying/sneaker-wearing assistant in favor of the less-controversial textual “FreeBSD” banner and [b] imbue the menu with new options.

Currently, the default boot menu offers booting normally as well as options for the following:

  • Booting with ACPI support disabled (if you’re running an i386 compatible system)
  • Booting into “Safe Mode” (implies disabling ACPI)
  • Booting verbose
  • Booting into single-user mode

However, one of the things that is not currently possible is the ability to boot into any combination of the aforementioned options. That is to explain, you cannot boot into single-user mode with ACPI disabled but verbosity enabled. The reason for this is obvious as once a menu option has been selected, the system proceeds to boot with those options rather than allowing additional selections to be made. See below.

The Standard FreeBSD Boot Menu

Enter my new menu (pictured below in the following paragraphs), first created in 2006 internally for a proprietary custom installer, now generalized for the rest of the world and being released for all to enjoy. This new loader does not proceed to boot the system after selecting a menu option but rather updates the menu to display the option status, allowing the user to toggle any number of multiple options before pressing ENTER to finally boot with the displayed options.

And for those like myself that balked when Beastie exited stage-left, I have a nice surprise. Some time back, the FreeBSD community held a contest for artists to create a new logo for the FreeBSD project. The results of which can be viewed here:

When the contest ended, I had my fun in running the graphics through some Image-to-ASCII conversion programs without much luck. Months later, I doubled-down my efforts still to no avail, attempting to create an ASCII-art version of the new orb to display at boot time. Six months later, I succeeded in producing a bi-color ASCII-art representation of the “horny orb” logo easily recognizable as the FreeBSD logo. This gem (as well as a B&W copy) have been added to the latest “beastie.4th” module for your viewing pleasure and is enabled by default upon installation.

Here you can lay your eyes on the final edition of the first-offering being made to the public today:

New FreeBSD Boot Loader Menu

Installing the new boot loader menu couldn’t be easier. After downloading the FreeBSD package from, use the pkg_add(1) command to install the package, and finally reboot.

Other additions that you will notice are that the replacement menu does not load right away. Another enhancement is that there is a 2 second delay before launching the menu where the user can press Ctrl-C to escape the menu, allowing immediate booting or escape to the loader prompt. Something that the current menu does not allow for. See below.

Loading the New Menu

The new menu is a system of ANS/FICL Forth (a reverse-polish stack-based language) modules that extend (but do not replace) the standard FreeBSD boot loader (/boot/loader). An interesting note about this package is that it will backup any files that will be replaced during installation to the file /var/backups/loader_menu.backup.tgz. Should you decide that you do not like the new and improved boot loader, you can uninstall it, returning your system back to the original boot loader by using the pkg_delete(1) utility (the backup will automatically be restored upon pkg_delete(1)).

With this initial offering, there are only two short-comings which should certainly be livable for most if not all:

1. The menu that we are replacing only conditionally displays the option to disable ACPI support (based on whether you are running an i386 compatible system), whereas the new loader always presents this option. This should be of no concern unless you’re running a non-i386/amd64 system (such as sparc, pc98, ppc, etc.).

2. The ability to boot into single-user mode by pressing “s” and boot verbose by pressing “v”, etc. is not enabed. The proponents for these options on the FreeBSD-Questions mailing list were clear in that they liked these options because they allowed “one-key” booting into a special mode. However — with the new menu — even if I enabled the use of those keys as shortcuts for toggling these options in the new stateful menu, the user would still have to press an additional key to boot (‘1’ or ENTER). So the primary principle use — one-key booting into a special mode — is no longer capable, unless I add these keys not as togglers for the visible menu items but invisible hot-keys for immediately booting into single/verbose mode. I’ll have to sleep on that (maybe as a concession for power-users as invisible options are obviously less than intuitive).

However, don’t let those misgivings dissuade you. All but the most ardent and stringent of surveyors will find those to be shortcomings and overall I predict your experience will be a rather pleasing one.

Some other nice additions are that if/when you select the option to escape to the loader prompt, you are given a way to get back to the menu (simply type “menu” and press ENTER), allowing you to perform work under the hood and then return to the menu as desired (without losing track of the status of the menu options even). As shown below:

Escaping to the Loader Prompt

Overall, the new stateful nature of this menu over the old makes it far less likely that a user will need to reboot if they hit the wrong key. The only mistake that could result in wasted cycles would be if they prematurely hit #1 to boot or hit #7 to reboot. All other options would simply toggle a menu item (except for #6 to escape to the loader prompt, to which they can immediately return to the menu if desired).

Last, but certainly not least, I’m including a completely rewritten password-checking module to replace the existing one (I couldn’t get the standard one to work). See below.

New Password Checking Module

I hope that you like what I’ve developed, and your feedback is certainly welcome. I’ll be cross-posting this to the FreeBSD mailing lists, announcing in RSS feeds, and updating all simultaneously to coincide with this blog-post.


XCode Update Woes – With Solution!

I’ve found that when you upgrade versions of XCode, that you lose the ability to compile against older SDK’s (and therefore, the ability to make a binary targeted for the older platforms). This is further annoying by the fact that every sample project that you download from Apple that is slightly older (by that I mean 6 months), you have to go in and “Edit Project Settings” to change the SDK from “4.0 Missing” to “iOS 4.3” before you can build/compile, install to device, or even run the App (I’m not complaining — a missing SDK is surely something worthy in commanding such manual intervention but — If you’re loading up over 200 sample apps from Apple, it gets quite tedious having to modify each project before being able to install it to the device).

I found the solution to all this, and you’ll be surprised at how much work Apple makes us do in order to maintain backward compatibility. This problem had me on the ropes for 2 weeks while I tried to figure out how to — with *either* the new XCode 4 or the still-offered legacy XCode 3.2.6 (both released last month) — compile ANY code for my iPhone 3G which — due to Apple’s decisioning — cannot update to the latest iOS. Without the below solution, I would not be able to compile code for the iPhone 3G without downgrading XCode. However, with the below solution, I can use the latest and greatest XCode with the older SDKs to compile code for the older devices.

Step 1: Stay up to date, but make backups!

Whenever Apple issues a new XCode installer, that installer only comes with the SDKs that they want to provide you. Currently, that’s only iOS 4.3 (note: the Device SDK is different than the Simulator SDK). Running said installer will wipe-out any existing old SDKs, leaving you only with what they have provided you in the latest installer. This is certainly cause for alarm, because if your device doesn’t use one of the provided SDKs, you cannot publish for that device. However, there are no rules for the AppStore that says you must baseline your app to a specific SDK, so whatever baseline you want to choose is fine with Apple — as long as it runs smoothly on the Device SDKs that Apple will test your App against.

Naturally, you’ll want to prevent the loss of any existing older SDKs before you install. Go to the Finder (by clicking the “Finder” icon in the Dock, or clicking the desktop background image, for example), and then select from the menubar Go->Go To Folder… (or simply press Apple+Shift+G). This will bring up a dialog prompt allowing you to go to a directory based on UNIX pathname. Enter the text “/Developer/Platforms/iPhoneOS.platform/Developer/SDKs” (without quotes) and press ENTER (aka return). This will open the directory where the SDKs are installed. Before installing the latest XCode Developer Tools from Apple, backup everything in this directory.

Step 2: If you want to install additional SDKs (one’s that you don’t have).

Visit this webpage to find links to the old Developer Tools.

NOTE: We’re not going to be installing these developer tools, but rather we’ll rip-open the images and pluck out only the SDK information (not XCode and associated developer tools such as gcc and friends).

Once you’ve downloaded the SDK, it should automatically mount on your desktop (if you’re using Safari anyway) as a disk image named “Xcode and iPhone SDK”. Within this disk image is a hidden directory named “Packages”. Since it is hidden, the simplest way to access this directory is to once-again use the Go->Go To Folder… menubar item (or press Apple+Shift+G), entering “/Volumes/Xcode and iPhone SDK/Packages” (without quotes) and pressing ENTER. This will allow you to browse the hidden “Packages” directory on the read-only disk image containing the Developer Tools. Within this directory are files named similar to:


…ad nauseum. Go ahead and double-click any of these “*.pkg” files to launch the SDK installer (which will install ONLY to the directory “/Developer/Platforms/iPhoneOS.platform/Developer/SDKs”.

As you launch the Installer, be aware that we’ll have to make some adjustments to allow the installation to occur. When prompted to select the target installation disk (immediately after clicking “Continue” on the initial dialog) click the hard disk that you want to install to (even if it’s already highlighted) to cause a “Choose Folder…” button to appear. Click the “Choose Folder…” button and pick somewhere that is writable as you (if you attempt to install to the default location, the installation will fail — because the installer did not pre-authenticate with root privileges as is done in the main-installer opposed to these sub-installers). I chose to make a new directory on my Desktop. After the installation is complete, you should have a “Developer/Platforms/iPhoneOS.platform/Developer/SDKs/{version}” directory in the target installation directory that you chose. This “{version}” directory will need to be plucked from where you installed it and dropped into the “/Developer/Platforms/iPhoneOS.platform/SDKs/” directory.

Once you’ve installed a new SDK, you’ll need to restart XCode.

Immediately after installing the device SDK required by any Apple Sample code and restarting XCode, you’ll then be able to simply select “Device” from the arch menu (at the top-left of the project window), and press Apple+R to run the app on your connected device. No more need to go into the project settings to change the default SDK (sometimes needs to be done for each sub-target) to one that exists.

Happy coding,
Devin Teske