Re-learning to type… again! (From Neo to Bone)

Summary

After using an ergonomical keyboard layout for more than half a decade, I felt that I might try something new. My old layout (Neo) works great, but after learning of a newer variant (Bone), I wanted to try it out – and am fascinated by what the human brain is capable of doing.

Article

[New to Gemini? Have a look at my Gemini FAQ.]

The actual post can be found here (if you are using a native Gemini client):

gemini://gemini.circumlunar.space/users/kraileth/neunix/2021/relearning_to_type.gmi

If you want to use a webproxy to read it from your web browser, follow this Link.

Multi-OS PXE-booting from FreeBSD 12: Linux, illumos and more (pt. 4)

[New to Gemini? Have a look at my Gemini FAQ.]

This article was bi-posted to Gemini and the Web; Gemini version is here: gemini://gemini.circumlunar.space/users/kraileth/neunix/2021/multi-os_pxe-booting_from_fbsd_pt4.gmi

Post 1 of this mini series is about what lead me to do this in the first place, features a little excursion for people new to PXE and details the setup of a FreeBSD router.
Post 2 discusses setting up the required daemons for DHCP, TFTP and HTTP / FTP. Each component that is not in FreeBSD’s base system is briefly discussed and two options to pick from are covered.
Post 3 covers the NBP (pxelinux), boot menu configuration and adding all the major BSD operating systems (with the exception of DragonFly that I could not get to work) as PXE-boot options.

In this post we are going to add some Linux distributions to the list as well as illumos and some other Open Source operating systems. If you are not familiar with pxelinux and configuring its menu, please see the previous post for more information. You will also find an explanation on going with flat menus if you prefer that – in this article I’ll make use of sub-menus.

Menu preparations

First is a bit of preparation work. I’m going to add three more sub-menus to the main menu – follow along with any or all that are relevant to you. On your PXE boot server, edit the file main configuration file for pxelinux:

# vi /usr/local/tftpboot/pxelinux.cfg/default

Append the following blocks:

LABEL linux-distros
        MENU LABEL Linux Distributions
        KERNEL vesamenu.c32
        APPEND pxelinux.cfg/linux

LABEL illumos-distros
        MENU LABEL illumos Distributions
        KERNEL vesamenu.c32
        APPEND pxelinux.cfg/illumos

LABEL other-oses
        MENU LABEL Other Operating Systems
        KERNEL vesamenu.c32
        APPEND pxelinux.cfg/other

Next is creating the configuration files for the sub-menus we just referenced. We’ll start with Linux:

# vi /usr/local/tftpboot/pxelinux.cfg/linux

Let’s put the menu title and an option to go back to the main menu in there:

MENU TITLE PXE Boot Menu (Linux)

LABEL main-menu
        MENU LABEL Main Menu
        KERNEL vesamenu.c32
        APPEND pxelinux.cfg/default

Now the same thing for illumos:

# vi /usr/local/tftpboot/pxelinux.cfg/illumos

Insert this text:

MENU TITLE PXE Boot Menu (illumos)

LABEL main-menu
        MENU LABEL Main Menu
        KERNEL vesamenu.c32
        APPEND pxelinux.cfg/default

And finally for the other systems:

# vi /usr/local/tftpboot/pxelinux.cfg/other

Again put the default stuff in there:

MENU TITLE PXE Boot Menu (Other)

LABEL main-menu
        MENU LABEL Main Menu
        KERNEL vesamenu.c32
        APPEND pxelinux.cfg/default

Alright, everything is prepared. So we can add some actual boot options for our PXE boot server!

Ubuntu

Making Ubuntu available over PXE is not very hard to do. We first need the (very recently released) ISO. It’s a big file and thus it makes sense to check the downloaded image for transmission errors – for that reason we’re getting the checksum file, too. The ISO is needed for the installation, so we’re going to make it available over HTTP by putting it in the right location:

# mkdir -p /usr/local/www/pxe/linux/ubuntu
# fetch https://releases.ubuntu.com/20.04/ubuntu-20.04.2-live-server-amd64.iso -o /usr/local/www/pxe/linux/ubuntu/ubuntu-20.04.2-live-server-amd64.iso
# fetch https://releases.ubuntu.com/20.04/SHA256SUMS -o /tmp/SHA256SUMS
# grep -c `sha256 /usr/local/www/pxe/linux/ubuntu/ubuntu-20.04.2-live-server-amd64.iso | awk '{ print $NF }'` /tmp/SHA256SUMS
# rm /tmp/SHA256SUMS

Make sure that the grep command line returns 1. If it doesn’t, remove the ISO and checksum file and re-download. We need the kernel and the init ramdisk available via TFTP, so we first extract the ISO to a temporary location. I found 7zip a good fit for extracting, so install it if you don’t have it on your system. Now copy off what we need and remove the directory again:

# 7z x /usr/local/www/pxe/linux/ubuntu/ubuntu-20.04.2-live-server-amd64.iso -o/tmp/ubuntu
# mkdir -p /usr/local/tftpboot/linux/ubuntu
# cp /tmp/ubuntu/casper/vmlinuz /usr/local/tftpboot/linux/ubuntu
# cp /tmp/ubuntu/casper/initrd /usr/local/tftpboot/linux/ubuntu
# rm -r /tmp/ubuntu

With all the system data in place we only need to add a boot menu entry for it:

# vi /usr/local/tftpboot/pxelinux.cfg/linux

Add the following to the file and save:

LABEL ubuntu-server-pxe-install
        MENU LABEL Install Ubuntu 20.04 (PXE)
        KERNEL linux/ubuntu/vmlinuz
        INITRD linux/ubuntu/initrd
        APPEND root=/dev/ram0 ramdisk_size=1500000 ip=dhcp url=http://10.11.12.1/linux/ubuntu/ubuntu-20.04.2-live-server-amd64.iso

Since pxelinux supports fetching via HTTP, you can also serve both the kernel and initrd via that protocol instead. If you want to do that, simply move the files to the other location:

# mv /usr/local/tftpboot/linux/ubuntu/vmlinuz /usr/local/tftpboot/linux/ubuntu/initrd /usr/local/www/pxe/linux/ubuntu

Then edit the menu definition again:

# vi /usr/local/tftpboot/pxelinux.cfg/linux

And adjust the menu definition like this:

        KERNEL http://10.11.12.1/linux/ubuntu/vmlinuz
        INITRD http://10.11.12.1/linux/ubuntu/initrd

And that’s it. Once you’ve restarted inetd, Ubuntu will be available as an option for PXE clients booting off of your server. It takes quite a while to push all the bits of the large ISO across the wire (’cause Ubuntu…) but it works.

AlmaLinux

What’s AlmaLinux some people may ask? Well, it’s one of the candidates for the succession of CentOS 8 after that was killed off by IBM. There are other candidates, but if you ask me, this one is the most promising right now. And since it’s available already (though in Beta currently), we’re not going to waste our time with dying CentOS but rather aim for the future of an enterprisy Linux distribution with Alma.

Obviously the first thing to do is getting it on our machine. I suggest getting the DVD which comes with all the packages available; if you know that you only do very basic installations, you may get the x86_64-minimal.iso one instead. Since it’s a pretty big ISO (8 GB!), checking for integrity is something I wouldn’t recommend skipping:

# mkdir -p /usr/local/www/pxe/linux/alma
# fetch https://repo.almalinux.org/almalinux/8.3-beta/isos/x86_64/AlmaLinux-8.3-beta-1-x86_64-dvd1.iso -o /usr/local/www/pxe/linux/alma/AlmaLinux-8.3-beta-1-x86_64-dvd1.iso
# fetch https://repo.almalinux.org/almalinux/8.3-beta/isos/x86_64/CHECKSUM -o /tmp/CHECKSUM
# grep -c `sha256 /usr/local/www/pxe/linux/alma/AlmaLinux-8.3-beta-1-x86_64-dvd1.iso | awk '{ print $NF }'` /tmp/CHECKSUM
# rm /tmp/CHECKSUM

If the grep command line does not return 1, delete both files and re-fetch, then run the check again. As soon as we have a good copy, we can extract the contents, making it available over HTTP. Permissions are wrong after extraction with all the directories missing the executable bit (rendering all their content inaccessible to the web server). So we fix this quickly, too:

# 7z x /usr/local/www/pxe/linux/alma/AlmaLinux-8.3-beta-1-x86_64-dvd1.iso -o/usr/local/www/pxe/linux/alma/sysroot
# find /usr/local/www/pxe/linux/alma -type d | xargs chmod 0755

The next step is to make kernel and init ramdisk available via TFTP:

# mkdir /usr/local/tftpboot/linux/alma
# cp /usr/local/www/pxe/linux/alma/sysroot/images/pxeboot/vmlinuz /usr/local/www/pxe/linux/alma/sysroot/images/pxeboot/initrd.img /usr/local/tftpboot/linux/alma

And finally we need to edit the Linux menu:

# vi /usr/local/tftpboot/pxelinux.cfg/linux

The definition to append looks like this:

LABEL alma-pxe-install
        MENU LABEL Install AlmaLinux 8.3 BETA (PXE)
        KERNEL linux/alma/vmlinuz
        INITRD linux/alma/initrd.img
        APPEND ip=dhcp inst.stage2=http://10.11.12.1/linux/alma/sysroot inst.xdriver=vesa

If you think that requiring X11 to install an OS is a reasonable choice and prefer the graphical installer, leave out the inst.xdriver=vesa option in the APPEND line. Also you can serve kernel and initrd via HTTP if you like. To do so, move the boot files:

# mv /usr/local/tftpboot/linux/alma/vmlinuz /usr/local/tftpboot/linux/alma/initrd.img /usr/local/www/pxe/linux/alma

Then edit the menu again:

# vi /usr/local/tftpboot/pxelinux.cfg/linux

And make the following changes:

        KERNEL http://10.11.12.1/linux/alma/vmlinuz
        INITRD http://10.11.12.1/linux/alma/initrd.img

Now your PXE server is ready to serve AlmaLinux.

Devuan Beowulf

Let’s add Devuan to the list next. Why Devuan and not Debian proper you ask? Well, because it has much cooler release names! Ok, of course not (the names are cooler, though!). Because of Init freedom.

While I don’t use Devuan (or Debian) myself, I’ve been supporting the fork since it started, sharing the first ISOs via Torrent and such. I very much dislike the “Bwahaha, you’ll never manage to fork XYZ!!!!11″ stance that some very loud people in the Linux community display. I felt ashamed for my fellow Open Source supporters when it happened to the MATE desktop and I did again when people dismissed Devuan like that. Let me emphasize: This ridiculing is not the Debian project’s fault. But the choice of opening their doors widely to Systemd while discriminating against everything else is. Hence: Devuan.

If you prefer Debian instead, there’s not too much to change: Substitute the directory name, grab Debian’s netboot archive instead and you’re good to go. First thing to do is to get the netboot image, extract it and copying kernel and initrd over:

# fetch https://pkgmaster.devuan.org/devuan/dists/beowulf/main/installer-amd64/current/images/netboot/netboot.tar.gz -o /tmp/netboot.tar.gz
# mkdir /tmp/devuan && tar -C /tmp/devuan -xvf /tmp/netboot.tar.gz
# mkdir /usr/local/tftpboot/linux/devuan
# cp /tmp/devuan/debian-installer/amd64/linux /tmp/devuan/debian-installer/amd64/initrd.gz /usr/local/tftpboot/linux/devuan
# rm -r /tmp/devuan /tmp/netboot.tar.gz

Then we have to edit the Linux boot menu configuration:

# vi /usr/local/tftpboot/pxelinux.cfg/linux

Simply add the following block to the file and save:

LABEL devuan-pxe-install
        MENU LABEL Install Devuan Beowulf (PXE)
        KERNEL linux/devuan/linux
        INITRD linux/devuan/initrd.gz
        APPEND vga=788

And yes, that’s already it. Debian does a pretty good job when it comes to PXE installing! If you prefer to serve the boot files via HTTP, just move the files:

# mkdir -p /usr/local/www/pxe/linux/devuan
# mv /usr/local/tftpboot/linux/devuan/linux /usr/local/tftpboot/linux/devuan/initrd.gz /usr/local/www/pxe/linux/devuan

Then edit the menu config again:

# vi /usr/local/tftpboot/pxelinux.cfg/linux

Now substitute the respective lines with these:

        KERNEL http://10.11.12.1/linux/devuan/linux
        INITRD http://10.11.12.1/linux/devuan/initrd.gz

Done. You can boot into the Devuan installer via PXE.

Alpine Linux 3.13

One last Linux example here is for a long-time favorite distribution of mine: Alpine Linux. It’s a very light-weight, security-oriented distribution based on Musl Libc. Alpine is well fit for embedded use and can run diskless and entirely from RAM – of course traditional installations are possible, too. Most people probably know it because it’s used frequently with Docker.

Adding Alpine to the mix is very simple. Let’s get and extract the netboot archive first:

# fetch https://dl-cdn.alpinelinux.org/alpine/v3.13/releases/x86_64/alpine-netboot-3.13.1-x86_64.tar.gz -o /tmp/alpine-netboot-3.13.1-x86_64.tar.gz
# mkdir /tmp/alpine && tar -C /tmp/alpine -xvf /tmp/alpine-netboot-3.13.1-x86_64.tar.gz

Now we copy off kernel, initrd as well as the modloop:

# cp /tmp/alpine/boot/vmlinuz-lts /tmp/alpine/boot/initramfs-lts /usr/local/tftpboot/linux/alpine
# mkdir /usr/local/www/pxe/linux/alpine
# cp /tmp/alpine/boot/modloop-lts /usr/local/www/pxe/linux/alpine

Finally edit the Linux menu config:

# vi /usr/local/tftpboot/pxelinux.cfg/linux

Put the following in there and save:

LABEL alpine-pxe-install
        MENU DEFAULT
        MENU LABEL Alpine Linux 3.13 (PXE)
        KERNEL linux/alpine/vmlinuz-lts
        INITRD linux/alpine/initramfs-lts
        APPEND ip=dhcp modloop=http://10.11.12.1/linux/alpine/modloop-lts alpine_repo=http://dl-cdn.alpinelinux.org/alpine/edge/main

And that’s really it! If you wish to use HTTP only, move two files:

# mv /usr/local/tftpboot/linux/alpine/* /usr/local/www/pxe/linux/alpine

Then edit the menu again:

# vi /usr/local/tftpboot/pxelinux.cfg/linux

And change the following lines:

        KERNEL http://10.11.12.1/linux/alpine/vmlinuz-lts
        INITRD http://10.11.12.1/linux/alpine/initramfs-lts

That’s all, you’re good to go.

SmartOS

SmartOS is a gem unknown to many. It’s an illumos distribution (OpenSolaris-derivative) meant to operate fully in live-mode. That is: It uses the machine’s hard disk(s) only for storage – the OS is always booted via PXE. This means updating is as easy as booting a newer image! Due to its nature it’s really no wonder that it has the most advanced, stunningly simple PXE process of all the systems that I’ve covered so far. You just get the image file:

# mkdir -p /usr/local/www/pxe/illumos/smartos
# fetch https://us-east.manta.joyent.com/Joyent_Dev/public/SmartOS/smartos-latest-USB.img.gz -o /usr/local/www/pxe/illumos/smartos/smartos-latest-USB.img.gz

Then you edit the illumos menu config:

# vi /usr/local/tftpboot/pxelinux.cfg/illumos

Paste in the following block and save:

LABEL smartos-pxe
        MENU LABEL SmartOS (PXE)
        KERNEL memdisk
        INITRD http://10.11.12.1/illumos/smartos/smartos-latest-USB.img.gz
        APPEND harddisk raw

And that’s really it! There is no next step (except for enjoying your new system(s))!

Tribblix

Tribblix is a retro style illumos distribution that you might enjoy if you are a Solaris veteran. I did not succeed to get it working with pxelinux which seems to have trouble loading the illumos kernel. Fortunately, PXE-booting Tribblix using iPXE is officially supported. Yes, in a previous article I wrote that I decided to use pxelinux instead, but since there’s no other way (that I know of… please comment if you know how to get it work with just pxelinux!), we’re going down that route here.

The first thing to do is to make sure we’re able to chain-load iPXE. FreeBSD provides a package for it which we’re going to install. Then we make the required program available via http:

# pkg install -y ipxe
# mkdir -p /usr/local/www/pxe/other/ipxe
# cp /usr/local/share/ipxe/ipxe.pxe /usr/local/www/pxe/other/ipxe

Next is adding a menu item to select iPXE. So we need to edit the respective config file:

# vi /usr/local/tftpboot/pxelinux.cfg/illumos

Let’s add the following block and save the file:

LABEL tribblix-over-ipxe
        MENU LABEL Tribblix 0m24 (iPXE)
        KERNEL pxechn.c32
        APPEND http://10.11.12.1/other/ipxe/ipxe.pxe

This will be enough to chain-load iPXE. It’s not of too much use, yet, though. If you select it, it’ll request an IP address and use the PXE-related info it gets from the DHCP server to – load pxelinux. Press CTRL-B when it loads to break the automatic behavior and be dropped to a console prompt. However we can’t do much with it, yet, since we’re missing the OS data.

The location to use is a bit odd here. This is due to hard-coded paths in the image, I assume. At least I could not get it working using the scheme that I use for the other examples. Anyway, time to fetch the kernel and the ramdisk image:

# mkdir -p /usr/local/www/pxe/m24/platform/i86pc/kernel/amd64
# fetch http://pkgs.tribblix.org/m24/platform/i86pc/kernel/amd64/unix -o /usr/local/www/pxe/m24/platform/i86pc/kernel/amd64/unix
# fetch http://pkgs.tribblix.org/m24/platform/i86pc/boot_archive -o /usr/local/www/pxe/m24/platform/i86pc/boot_archive

Now that we have the data in place, we could manually boot up Tribblix. But there’s an easier way by creating a script which we can invoke and that simply does the rest. Let’s create it in the tftp directory (it’s small and using TFTP means we have less to type because we can omit the http://10.11.12.1/ part):

# vi /usr/local/tftpboot/tribblix.ipxe

Paste the following into the file and save:

#!ipxe
kernel http://10.11.12.1/m24/platform/i86pc/kernel/amd64/unix
initrd http://10.11.12.1/m24/platform/i86pc/boot_archive
boot

That’s it. Drop to iPXE’s prompt as described above and request an IP address; then simply chainload the script. Tribblix will boot to the installer:

iPXE> dhcp
Waiting for link-up on net0... ok
Configuring (net0 10:bf:48:df:e9:65)...... ok
iPXE> chain tribblix.pxe

Yes, this is somewhat less convenient than other options shown here. And in fact it can be avoided. The problem being that creating a more convenient solution is also a little bit more involved and simply beyond the scope of this article. If you’re interested in doing it, do some reading on your own. What you want to research is embedding the script into iPXE.

OmniOSce r151036

After struggeling with getting OmniOSce to PXE-boot to no avail for days I gave up and moved on to Tribblix. I wish I had done it the other way round; Peter Tribble has posted an article on his blog on how to do it with iPXE. And since I gave in and used it in my example above, I figured that I might as well return and give OmniOSce a try again. And really: Using iPXE instead of pure pxelinux – I got it working.

Caution, though: What is described here is a fully automated (unattended) installation. It will destroy any data on the target machine without asking. If that’s not what you want, stay away. I wish I knew a way to just invoke the installer instead, but I don’t.

Of course we need the operating system kernel and image as well as the zfs stream to install:

# mkdir -p /usr/local/www/pxe/illumos/omniosce/platform/i86pc/amd64 /usr/local/www/pxe/illumos/omniosce/platform/i86pc/kernel/amd64
# fetch https://downloads.omnios.org/media/r151036/omniosce-r151036m.unix -o /usr/local/www/pxe/illumos/omniosce/platform/i86pc/kernel/amd64/unix
# fetch https://downloads.omnios.org/media/r151036/omniosce-r151036m.miniroot.gz -o /usr/local/www/pxe/illumos/omniosce/platform/i86pc/amd64/omniosce-r151036m.miniroot.gz
# gunzip /usr/local/www/pxe/illumos/omniosce/platform/i86pc/amd64/omniosce-r151036m.miniroot.gz
# fetch https://downloads.omnios.org/media/r151036/omniosce-r151036.zfs.xz -o /usr/local/www/pxe/illumos/omniosce/platform/i86pc/amd64/omniosce-r151036.zfs.xz

Next is the installer configuration. Kayak will look for a file at the location told to (see below in the script) – the filename it tries first is named after the MAC address of the interface used for DHCP. In my case the MAC is 10:bf:48:df:e9:65, so the file matching only this single machine would be called 10BF48DFE965 (use uppercase for the Hex values above 9 resembled by the letter symbols).

If it cannot find that file it will look for a file with the name of the first 11 digits, i.e. 10BF48DFE96. That would also match MAC addresses like 10BF48DFE961, 10BF48DFE96A, 10BF48DFE96E and the like. If there’s no such file, it will try to get one named after the first 10 digits and so on until it eventually tries “1” in my case (if your MAC starts with a different digit, you will have to use that).

I’m lazy here and use a single-digit name (and thus choose to play with fire since this configuration will potentially nuke the previous installation of any machine having a network card with a MAC address that starts with 1 and would be PXE-booting OmniOS by accident!):

# vi /usr/local/www/pxe/kayak/1

I put the following in there (your machines are likely different from mine; refer to the OmniOSce documentation for more information about about the configuration script):

BuildRpool c3t0d0
RootPW '$5$JQkyMDvv$pPzEUsvP/rLwURyrpwz5i1SfVqx2QiEoIdDA9ZrG271'
SetRootPW
SetHostname omnios
SetTimezone UTC
EnableDNS example.com
SetDNS 1.1.1.1 80.80.80.80
Postboot '/sbin/ipadm create-if rge0'
Postboot '/sbin/ipadm create-addr -T dhcp rge0/v4'
SendInstallLog

Now I create a menu entry for pxelinux by editing the configuration file:

# vi /usr/local/tftpboot/pxelinux.cfg/illumos

I add the following block and save:

LABEL omniosce-auto-over-ipxe
        MENU LABEL OmniOSce r151036 AUTOMATED INSTALLATION [dangerous!] (iPXE)
        KERNEL pxechn.c32
        APPEND http://10.11.12.1/other/ipxe/ipxe.pxe

Finally I create the script to “chainload” from iPXE:

# vi /usr/local/tftpboot/omniosce.ipxe

Here’s the content for that script:

!ipxe
kernel http://10.11.12.1/illumos/omniosce/platform/i86pc/kernel/amd64/unix -B install_media=http://10.11.12.1/illumos/omniosce/platform/i86pc/amd64/omniosce-r151036.zfs.xz,in
stall_config=http://10.11.12.1/illumos/omniosce
initrd http://10.11.12.1/illumos/omniosce/platform/i86pc/amd64/omniosce-r151036m.miniroot
boot

And that’s it. Like with Tribblix, use CTRL-B to get to an iPXE prompt, obtain an IP address and chainload the iPXE script – in this case the one for OmniOSce. If you did everything correct for your machine (depending on its MAC), kayak should erase your data and install OmniOSce on it instead.

FreeDOS 1.2

Why add FreeDOS? Well, why not? I’ve played with it quite a bit in my youth and happen to like it. It’s also simple to do and can in fact be useful (e.g. when you want to flash some firmware). As always, the first thing is to get and extract the archive. The zip file contains a virtual machine image, too, but we don’t need it and thus skip unzipping it:

# fetch http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/distributions/1.2/FD12FULL.zip -o /tmp/FD12FULL.zip
# unzip -d /tmp -x '*.vmdk' /tmp/FD12FULL.zip

Next step is putting the extracted image into the right place, to correct permissions and to compress it to save a fair bit of space:

# mkdir -p /usr/local/www/pxe/other/fdos
# mv /tmp/FD12FULL.img /usr/local/www/pxe/other/fdos
# chmod 0644 /usr/local/www/pxe/other/fdos/FD12FULL.img.gz
# gzip -9 /usr/local/www/pxe/other/fdos/FD12FULL.img

Finally edit the “other” boot menu config file:

# vi /usr/local/tftpboot/pxelinux.cfg/other

And add the following block:

LABEL fdos-pxe-install
       MENU LABEL Install FreeDOS 1.2 (PXE)
       KERNEL memdisk
       INITRD http://10.11.12.1/other/fdos/FD12FULL.img.gz
       APPEND harddisk raw

Done. You should be able to PXE-boot into FreeDOS now.

Plan 9

Back to the Unixy stuff – and (disregarding Inferno) the one OS that is more Unixy that Unix itself: Plan 9! I’m going with the 9front distribution here; it’s basically an example, anyway. There are not that many people out there who will want to actually provision a lot of servers with Plan 9, right? (If you are one of those, get in touch with me! I’d be interested in what you’re doing with it.)

As always we first need to get the image and put it in place:

# mkdir /usr/local/www/pxe/other/9front
# fetch http://9front.org/iso/9front-8013.d9e940a768d1.amd64.iso.gz -o /usr/local/www/pxe/other/9front/9front-8013.d9e940a768d1.amd64.iso.gz

Then the menu configuration needs to be edited:

# vi /usr/local/tftpboot/pxelinux.cfg/other

Paste in the following block:

LABEL 9front-pxe-install
       MENU LABEL Install 9front (PXE)
       KERNEL memdisk
       INITRD http://10.11.12.1/other/9front/9front-8013.d9e940a768d1.amd64.iso.gz
       APPEND iso raw

And that’s all there is to it.

Redox 0.6

Redox is an experimental OS is about implementing a POSIX-like operating system written in Rust. It’s using a modern microkernel architecture and made amazingly quick progress after the project started. I’m including it here because I think it’s a very interesting thing to follow.

To add Redox to the mix, you have to download the ISO first:

# mkdir /usr/local/www/pxe/other/redox
# fetch https://gitlab.redox-os.org/redox-os/redox/-/jobs/31100/artifacts/raw/build/img/redox_0.6.0_livedisk.iso.gz -o /usr/local/www/pxe/other/redox/redox_0.6.0_livedisk.iso.gz

Next and final step is editing the the menu configuration:

# vi /usr/local/tftpboot/pxelinux.cfg/other

and adding a block for Redox’ menu item:

LABEL redox-pxe-install
       MENU LABEL Install Redox OS (PXE)
       KERNEL memdisk
       INITRD http://10.11.12.1/other/redox/redox_0.6.0_livedisk.iso.gz
       APPEND iso raw

The current version seems to have introduced a regression regarding my test hardware. It boots but after setting the resolution, the computer simply restarts. Version 0.4.0 could boot up to the graphical login, though (but I couldn’t login due to missing input drivers I assume).

What’s missing?

I would have liked to add OpenIndiana, Haiku, Minix and ReactOS as well.

With both Haiku and ReactOS I failed to get them even booting. It might be possible to do it, but I ran out of ideas to try quickly and because of a lack of time didn’t try harder.

For OpenIndiana I didn’t even find proper documentation. Since I’m not very knowledgable with illumos, anyway, I eventually settled on having three other distributions covered and didn’t really try it out.

Minix is a special case. According to the documentation, PXE-booting should be possible with a ramdisk image. The project doesn’t provide them for download (or I didn’t find them) but building one from source is documented. So I checked out the source and ran the script to build it – and it failed. I tried again on a 64-bit machine and it failed again. Looks like cross-building Minix on FreeBSD did once work (documentation mentions FreeBSD 10), but this no longer seems to be the case. Not having any Linux machines around to try it on, I decided to skip it.

Conclusion

The 4 articles of this mini series detail how you can setup a PXE server on FreeBSD that will serve multiple operating systems depending on the menu item chosen by the user. With all the examples of Linux, illumos and various other Open Source operating systems in this article, you have plenty of choice for experimenting in your home lab!

This does not mean that there are not many, many more options available for free. If you know how to add more options – why not write about it yourself? Be sure to let me know, I’ll happily place a link to your work.

And as always: Feedback, suggestions for improvements and such are very welcome. Have fun!

Multi-OS PXE-booting from FreeBSD 12: PXE menu and *BSD (pt. 3)

[New to Gemini? Have a look at my Gemini FAQ.]

This article was bi-posted to Gemini and the Web; Gemini version is here: gemini://gemini.circumlunar.space/users/kraileth/neunix/2021/multi-os_pxe-booting_from_fbsd_pt3.gmi

Post 1 of this mini series is about what lead me to do this in the first place, features a little excursion for people new to PXE and details the setup of a FreeBSD router.
Post 2 discusses setting up the required daemons for DHCP, TFTP and HTTP / FTP. Each component that is not in FreeBSD’s base system is briefly discussed and two options to pick from are covered.

At the end of part 2, the situation is as follows: A client in the 10.11.12.0/24 subnet attempting to PXE boot will get an IP address via DHCP and be told where to get the NPB (Network Bootstrap Program). It will then attempt to fetch it via TFTP. There’s just one problem: That is not there, yet! We’ll fix that in a minute. When we’re done here, you’ll have a fully working PXE server that offers multiple BSD operating systems to boot into (Linux and more are covered in part 4). This article focuses on BIOS (“legacy”) booting; if you want to boot EFI-only machines you’ll have to adapt the configuration examples given here to that. I also assume using HTTP here – if you opted for FTP you will have to adapt the commands used in the examples.

Network Bootstrap Program

There are a lot of NBPs available. Usually each operating system has its own which is tuned towards its specific duty: FreeBSD has one, OpenBSD has another and Linux has several. These are not ordinary programs; they need to cope with a very resource-constrained environment and cannot depend on any external libraries. While writing boot code is challenging enough, adding network booting capabilities doesn’t make things any easier. This is why most NBPs are as simple as possible.

As a result of that, the NBPs usually know how to boot exactly one operating system. Since we want to set up a multi-OS PXE server this is quite unfortunate for our use case. There are two ways to work around this problem:

  1. Provide various NBPs and use DHCP to distinguish between clients
  2. Use an NBP that supports a menu to select which one to boot next

As usual there’s pros and cons to both. Letting DHCP do the magic requires a much more complex DHCP configuration. It’s also much less flexible. The boot menu approach is simple and flexible, but more complicated if you are also interested in automation. I do like automation, but I decided in favor of using a boot menu for this article because it’s easier to follow. It is also a good achievement to build upon once you’re comfortable with DHCP and feel ready for advanced settings.

It is possible to use one NBP to fetch and execute another one. This process is known as chainloading. For some operating systems that is the best choice to add them to a menu system.

There’s three popular options that we have for an NBP which fits our needs:

1. GRUB
2. PXELINUX (from Syslinux) and
3. iPXE

GRUB and I never made friends. I used it for a while after switching from LILO only to ditch it for Syslinux when I learned of that. I have to use it on many systems, but when I have a choice, I choose something else. The iPXE project is very interesting. It’s the most advanced (but also most involved) of the three options. If you’re curious about just how far you can take PXE booting, at least have a look at it. For this article, we’ll go with PXELINUX.

Pxelinux

Pxelinux is available via packages on FreeBSD. It does pull in some dependencies that I don’t want on my system however. For that reason we’re going to fetch the package instead of installing it. Then we extract it manually:

# pkg fetch -y syslinux
# mkdir /tmp/syslinux
# tar -C /tmp/syslinux -xvf /var/cache/pkg/syslinux-6.03.txz

Now we can cherry-pick the required files:

# cp /tmp/syslinux/usr/local/share/syslinux/bios/core/lpxelinux.0 /usr/local/tftpboot/pxelinux.0
# cp /tmp/syslinux/usr/local/share/syslinux/bios/com32/elflink/ldlinux/ldlinux.c32  /usr/local/tftpboot/
# cp /tmp/syslinux/usr/local/share/syslinux/bios/com32/menu/vesamenu.c32 /usr/local/tftpboot/
# cp /tmp/syslinux/usr/local/share/syslinux/bios/com32/lib/libcom32.c32 /usr/local/tftpboot/
# cp /tmp/syslinux/usr/local/share/syslinux/bios/com32/libutil/libutil.c32 /usr/local/tftpboot/
# cp /tmp/syslinux/usr/local/share/syslinux/bios/com32/modules/pxechn.c32 /usr/local/tftpboot/
# cp /tmp/syslinux/usr/local/share/syslinux/bios/memdisk/memdisk /usr/local/tftpboot/
# rm -r /tmp/syslinux

The first one is the modular NBP itself. It requires some modules – the c32 files. The pxechn and memdisk modules are optional – they are required for some of the operating systems examples here but not all. You can leave them out if you don’t need them. Restart the inetd service now and you will be able to PXE boot to the menu:

# service inetd restart

Keep in mind: Restart the inetd service whenever you added a file to or edited any in the tftpboot directory!

Tip 1: You can use make use of gzipped files as Pxelinux supports that. This way you can decrease loading times by serving smaller images over the net.

Tip 2: I’m using gzip in my examples but if you really want to fight for the last byte, use zopfli instead. It’s a compression program that produces gzip-compatible output but takes much more processor time to create optimized archives. As decompression time is unaffected it’s a price you have to pay only once. Consider using it if you want the best results.

Submenus

Pxelinux is hard-coded to load pxelinux.cfg/default via TFTP and use that as its configuration. If you plan to only use few of the OS examples shown here, that config is sufficient as you can put everything into there. Once you feel that your menu is becoming overly crowded, you can turn it into a main menu and make use of submenus to group things as I do it here. This works by putting the various OS entries in different config files.

If you don’t want submenus, skip the next step and put all the menu entries that go into something other than pxelinux.cfg/default in my examples right into that file instead – and leave out the reference back to the main menu since they don’t make any sense if you’re using a flat menu anyway.

In the previous post we already created the file /usr/local/tftpboot/pxelinux.cfg/default. Append the following to it to create a submenu for the BSDs we’re covering today:

MENU TITLE PXE Boot Menu (Main)

LABEL bsd-oses
        MENU LABEL BSD Operating Systems
        KERNEL vesamenu.c32
        APPEND pxelinux.cfg/bsd

Now create the file referenced there:

# vi /usr/local/tftpboot/pxelinux.cfg/bsd

and put the following text in there:

MENU TITLE PXE Boot Menu (BSD)

LABEL main-menu
        MENU LABEL Main Menu
        KERNEL vesamenu.c32
        APPEND pxelinux.cfg/default

Alright, preparation work is done, let’s finally add some operating system data!

FreeBSD 12.2

PXE booting FreeBSD is actually not such an easy thing to do if you want to avoid using NFS shares. Fortunately there is mfsBSD, a project that provides tools as well as releases of special FreeBSD versions that can be booted over the net easily. We’re going to use that.

There are multiple variants for download: The standard one, the “special edition” and a “mini edition”. The special edition comes with the distribution tarballs on the ISO – you may want to use that one for installation purposes. If you just want a FreeBSD live system (e.g. for maintenance and repairs) or use you owr mirror (see below), the standard edition is for you since it is much smaller and thus boots way faster.

Let’s make the image available via HTTP:

# mkdir -p /usr/local/www/pxe/bsd/fbsd
# fetch https://mfsbsd.vx.sk/files/iso/12/amd64/mfsbsd-12.2-RELEASE-amd64.iso -o /usr/local/www/pxe/bsd/fbsd/amd64/12.2-RELEASE/mfsbsd.iso
# gzip -9 /usr/local/www/pxe/bsd/fbsd/amd64/12.2-RELEASE/mfsbsd.iso

Now edit the pxelinux.cfg/bsd file and append:

LABEL fbsd-pxe-install
        MENU LABEL Install FreeBSD 12.2 (PXE)
        MENU DEFAULT
        KERNEL memdisk
        INITRD http://10.11.12.1/bsd/fbsd/amd64/12.2-RELEASE/mfsbsd.iso
        APPEND iso raw

That’s it. You can now PXE-boot into FreeBSD.

Installation using mfsBSD

Login with user root and password mfsroot. It includes a “zfsinstall” script that you may want to take a look at. There’s a lot more to mfsBSD, though. Its tools allow you to easily roll your own customized images. If a way to include packages or files, use a custom-built kernel and things like that sounds like something that would be useful for you, take a closer look. I cannot go into more detail here – it’s a topic of its own and would deserve an entire article dedicated to it. In case you just want to use the familiar FreeBSD installer bsdinstall, read on.

Mirroring distfiles and fixing bsdinstall

If you want to install FreeBSD over PXE more than once, it makes sense to provide a local distfile mirror. Since we have a fileserver running anyway, there’s really nothing more to it than getting the distfiles and putting them into the right place. At the very minimum get the following three files:

# fetch http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/12.2-RELEASE/MANIFEST -o /usr/local/www/pxe/bsd/fbsd/amd64/12.2-RELEASE/MANIFEST
# fetch http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/12.2-RELEASE/base.txz -o /usr/local/www/pxe/bsd/fbsd/amd64/12.2-RELEASE/base.txz
# fetch http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/12.2-RELEASE/kernel.txz -o /usr/local/www/pxe/bsd/fbsd/amd64/12.2-RELEASE/kernel.txz

Depending on which distfiles you usually install, also get any or all of the following files:

# fetch http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/12.2-RELEASE/base-dbg.txz -o /usr/local/www/pxe/bsd/fbsd/amd64/12.2-RELEASE/base-dbg.txz
# fetch http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/12.2-RELEASE/kernel-dbg.txz -o /usr/local/www/pxe/bsd/fbsd/amd64/12.2-RELEASE/kernel-dbg.txz
# fetch http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/12.2-RELEASE/lib32-dbg.txz -o /usr/local/www/pxe/bsd/fbsd/amd64/12.2-RELEASE/lib32-dbg.txz
# fetch http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/12.2-RELEASE/ports.txz -o /usr/local/www/pxe/bsd/fbsd/amd64/12.2-RELEASE/ports.txz
# fetch http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/12.2-RELEASE/src.txz -o /usr/local/www/pxe/bsd/fbsd/amd64/12.2-RELEASE/src.txz
# fetch http://ftp.freebsd.org/pub/FreeBSD/releases/amd64/12.2-RELEASE/tests.txz -o /usr/local/www/pxe/bsd/fbsd/amd64/12.2-RELEASE/tests.txz

At this point in time, bsdinstall is broken on mfsBSD. The reason is that the distfile manifest is missing. I think about getting this fixed upstream, so in the future try and see if the following part is obsolete before using it. But for now, let’s create a simple shell script in the webroot directory for convenience:

# vi /usr/local/www/pxe/fbsd.sh

Put the following into the script:

#!/bin/sh
ARCH=`uname -m`
RELEASE=`uname -r | cut -d"-" -f1`
mkdir -p /usr/freebsd-dist
fetch http://10.11.12.1/bsd/fbsd/${ARCH}/${RELEASE}-RELEASE/MANIFEST -o /usr/freebsd-dist/MANIFEST
bsdinstall

Now if you PXE-booted mfsBSD and logged in as root, you just need to execute the following command line and will then be able to use the installer as you are used to it:

# fetch http://10.11.12.1/fbsd.sh && sh fbsd.sh

When you are to select the installation source, there is an “Other” button at the bottom of the window. Choose that and point to your distfile mirror – in my example http://10.11.12.1/bsd/fbsd/amd64/12.2-RELEASE. Happy installing!

One more hint: You may want to look into the environment variables that bsdinstall(8) provides. I briefly attempted to automatically set the URL to the distfile mirror but couldn’t get it working. As I was already running out of time with this article I haven’t looked deeper into it. If anybody figures it out I’d appreciate sharing your solution here.

OpenBSD 6.8

Adding OpenBSD as an option is trivial. The project provides a ramdisk kernel used for installing the system and a NBP capable of loading it. Let’s get those two files in place – and while the ramdisk kernel is fairly small already, we can chop a couple of bytes off by compressing it:

# mkdir -p /usr/local/tftpboot/bsd/obsd
# fetch https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/pxeboot -o /usr/local/tftpboot/bsd/obsd/pxeboot
# fetch https://cdn.openbsd.org/pub/OpenBSD/6.8/amd64/bsd.rd -o /usr/local/tftpboot/bsd/obsd/6.8-amd64.rd
# gzip -9 /usr/local/tftpboot/bsd/obsd/6.8-amd64.rd

Now we only need to add the required lines to pxelinux.cfg/bsd:

LABEL obsd-pxe-install
        MENU LABEL Install OpenBSD 6.8 (PXE)
        KERNEL pxechn.c32
        APPEND bsd/obsd/pxeboot

That’s it, the OpenBSD loader can be booted! Since we don’t have the kernel in the assumed default location (“/bsd”) we’d need to tell the loader to “boot bsd/obsd/6.8-amd64.rd.gz”. The loader supports a configuration file, though. So for a little extra convenience we can make it pick up the kernel automatically like this:

# mkdir -p /usr/local/tftpboot/etc
# ln -s /usr/local/tftpboot/etc/boot.conf /usr/local/tftpboot/bsd/obsd/boot.conf
# echo "boot bsd/obsd/6.8-amd64.rd.gz" > /usr/local/tftpboot/bsd/obsd/boot.conf
# echo "# OpenBSD boot configuration" >> /usr/local/tftpboot/bsd/obsd/boot.conf

The pxeboot program comes with the configuraton file name of etc/boot.conf hard-coded. To keep things a little cleaner in the hierarchy that I use, I chose to set a symlink in the obsd directory for reference purposes. And that’s all.

NetBSD 9.1

Let’s add NetBSD! It’s somewhat similar to OpenBSD – but a bit more involved unfortunately. The reason is that the NBP by default does not support a configuration file. It has the ability to use one, but that needs to be activated first. Which is fair enough since it’s only a single command – on NetBSD that is! But let’s worry about this in a minute and first get the NBP as well as the install kernel:

# mkdir -p /usr/local/tftpboot/bsd/nbsd
# fetch https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.1/amd64/installation/misc/pxeboot_ia32.bin -o /usr/local/tftpboot/bsd/nbsd/pxeboot_ia32.bin
# fetch https://cdn.netbsd.org/pub/NetBSD/NetBSD-9.1/amd64/binary/kernel/netbsd-INSTALL.gz -o /usr/local/tftpboot/bsd/nbsd/netbsd-INSTALL.gz

Now we need to add the boot menu entry by adding the following lines to pxelinux.cfg/bsd:

LABEL nbsd-pxe-install
        MENU LABEL Install NetBSD 9.1 (PXE)
        KERNEL pxechn.c32
        APPEND bsd/nbsd/pxeboot_ia32.bin

This is sufficient to load and execute the NetBSD loader. That will then complain that it cannot find the kernel and no hints about NFS were given. Now we have three options:

  1. Manually point the loader to the correct kernel each time
  2. Give the required hint via DHCP
  3. Try to enable the loader configuration

Typing in “tftp:bsd/nbsd/netbsd-INSTALL.gz” is probably fair enough if you are doing NetBSD installs very rarely but it gets old quickly. So let’s try out option two!

Modifying DHCP config for NetBSD

The DHCP server needs to be configured to pass a different Boot File name option when answering the NetBSD loader than otherwise. This is done by matching class information. This topic is beyond the scope of this article, so if you are interested, do some reading on your own. I won’t leave you hanging, though, if you just need to get things working.

Here’s what you have to add to the configuration if you’re using Kea – for example right before the “loggers” section:

    "client-classes": [
        {
            "name": "NetBSDloader",
            "test": "option[vendor-class-identifier].text == 'NetBSD:i386:libsa'",
            "boot-file-name": "tftp:bsd/nbsd/netbsd-INSTALL.gz"
        }
    ],

And here the same thing if you are using DHCPd:

if substring (option vendor-class-identifier, 0, 17) = "NetBSD:i386:libsa" {
    if filename = "netbsd" {
        filename "tftp:bsd/nbsd/netbsd-INSTALL.gz";
    }
}

Restart your DHCP server and you should be good to go.

After accomplishing the easy way via DHCP, I also went down to explore the boot.cfg road but ultimately failed. I’m documenting it here anyway in case somebody wants to pick up where I decided to leave it be.

Enabling boot.cfg in the loader

To mitigate the risk of polluting my main system by doing something stupid I chose to do all of this using my unprivileged user. The first thing I did, was fetching and extracting the basic NetBSD 9.1 sources:

% mkdir -p netbsd-9.1 && cd netbsd-9.1
% fetch ftp://ftp.netbsd.org/pub/NetBSD/NetBSD-9.1/source/sets/src.tgz
% tar xvzf src.tgz

The sources for the installboot program we’re looking for are in usr/src/usr.sbin/installboot. I tried to get that thing to build by pointing the compiler at additional include directories and editing quite some header files, hoping to resolve the conflicts with FreeBSD’s system headers and problems like that. It can probably be done but that would take a C programmer – which I am not.

Fortunately NetBSD is the portability star among the BSDs and should be buildable on many other systems. I’ve never done this before but here was the chance. So I installed CVS and checked out the rest of the NetBSD src module:

% doas pkg install -y cvs
% cd netbsd-9.1/usr
% cvs -d anoncvs@anoncvs.NetBSD.org:/cvsroot checkout -r netbsd-9-1-RELEASE -P src

When exploring the source tree, I found a build script that obviously does all the magic required here. Be warned however that this builds a full cross-toolchain including the complete GCC compiler! Then it builds the “tools” subset of the NetBSD code (which includes the installboot that we’re looking for). On my old and slow Atom-based system this process took 6 hours:

% cd src
% ./build.sh -U -m amd64 -T ~/nbsd tools
===> build.sh command:    ./build.sh -U -m amd64 -T /home/kraileth/nbsd tools
===> build.sh started:    Thu Feb  3 00:13:41 CET 2021
===> NetBSD version:      9.1
===> MACHINE:             amd64
===> MACHINE_ARCH:        amd64
===> Build platform:      FreeBSD 12.2-RELEASE-p1 amd64
===> HOST_SH:             /bin/sh
===> No $TOOLDIR/bin/nbmake, needs building.
===> Bootstrapping nbmake
checking for sh... /bin/sh
checking for gcc... cc

[...]

install ===> config
#   install  /home/kraileth/nbsd/bin/nbconfig
mkdir -p /home/kraileth/nbsd/bin
/home/kraileth/nbsd/bin/amd64--netbsdelf-install -c  -r -m 555 config /home/kraileth/nbsd/bin/nbconfig
===> Tools built to /home/kraileth/nbsd
===> build.sh ended:      Thu Feb  3 6:26:25 CET 2021
===> Summary of results:
         build.sh command:    ./build.sh -U -m amd64 -T /home/kraileth/nbsd tools
         build.sh started:    Thu Feb  4 07:13:41 CET 2021
         NetBSD version:      9.1
         MACHINE:             amd64
         MACHINE_ARCH:        amd64
         Build platform:      FreeBSD 12.2-RELEASE-p1 amd64
         HOST_SH:             /bin/sh
         No $TOOLDIR/bin/nbmake, needs building.
         Bootstrapping nbmake
         MAKECONF file:       /etc/mk.conf (File not found)
         TOOLDIR path:        /home/kraileth/nbsd
         DESTDIR path:        /usr/home/kraileth/netbsd-9.1/usr/src/obj/destdir.amd64
         RELEASEDIR path:     /usr/home/kraileth/netbsd-9.1/usr/src/obj/releasedir
         Created /home/kraileth/nbsd/bin/nbmake
         Updated makewrapper: /home/kraileth/nbsd/bin/nbmake-amd64
         Tools built to /home/kraileth/nbsd
         build.sh ended:      Thu Feb  4 12:26:25 CET 2021
===> .

The “-U” flag enables some trickery to build as an unprivileged user. With “-m” you specify the target architecture (I did use i386 but modified the above lines as that will be what most people will want to use instead!). Finally the “-T” switch allows to specify the installation target directory and the “tools” is the make target to use.

When it was done, I did the following (as root):

# cp /usr/local/tftpboot/bsd/nbsd/pxeboot_ia32.bin /usr/local/tftpboot/bsd/nbsd/pxeboot_ia32.bin.bak
# /usr/home/kraileth/netbsd-9.1/usr/src/tools/installboot/obj/installboot -eo bootconf /usr/local/tftpboot/bsd/nbsd/pxeboot_ia32.bin

This should enable the boot config file on the pxeboot loader. It does change the file and probably even makes the right change. I tried to enable module support via installboot, too and that obviously worked (the NFS module was loaded the next time I chainloaded the NetBSD loader). But for some reason I could not get boot.cfg to do what I wanted. Probably I don’t understand the file properly…

While it’s a bit disappointing to stop so close to the goal, messing with NetBSD so much already took much more time away from the other BSDs than I had imagined. And since I could at least offer a working way this was when I decided to move on.

DragonFly BSD

I attempted to get DragonFly BSD to work but failed. I briefly tried out a setup that includes NFS shares but it didn’t work completely either: Kernel booted but failed to execute /sbin/init for some reason or another. Also I don’t really want to cover NFS in this series – there’s enough material in here already. And without NFS… Well, DragonFly BSD has the same problem that FreeBSD has: It will boot the kernel but then be unable to mount the root filesystem.

While I guess that the mfsBSD approach could likely work for DF, too, this is something much more involved than reasonable for our topic here. I would really like to cover DragonFly here, too, but that’s simply a bit too much. If anybody knows how to get it working – please share your knowledge!

HardenedBSD 12-STABLE

HardenedBSD being a FreeBSD fork, inherited the same characteristics as vanilla FreeBSD. Which means that PXE booting the standard images is not an easy thing to do. HardenedBSD uses the same installer, bsdinstall however and for that reason it’s possible to install HardenedBSD by using mfsBSD as prepared above in the FreeBSD section. We only need to point the installer to a different distfile mirror. Let’s create that one now:

# mkdir -p /usr/local/www/pxe/bsd/hbsd/amd64/12-STABLE
# fetch https://ci-01.nyi.hardenedbsd.org/pub/hardenedbsd/12-stable/amd64/amd64/BUILD-LATEST/MANIFEST -o /usr/local/www/pxe/bsd/hbsd/amd64/12-STABLE/MANIFEST
# fetch https://ci-01.nyi.hardenedbsd.org/pub/hardenedbsd/12-stable/amd64/amd64/BUILD-LATEST/base.txz -o /usr/local/www/pxe/bsd/hbsd/amd64/12-STABLE/base.txz
# fetch https://ci-01.nyi.hardenedbsd.org/pub/hardenedbsd/12-stable/amd64/amd64/BUILD-LATEST/kernel.txz -o /usr/local/www/pxe/bsd/hbsd/amd64/12-STABLE/kernel.txz

As with FreeBSD, there are some optional distfiles you may or may not want to mirror, too. Provide what you need for your installations:

# fetch https://ci-01.nyi.hardenedbsd.org/pub/hardenedbsd/12-stable/amd64/amd64/BUILD-LATEST/base-dbg.txz -o /usr/local/www/pxe/bsd/hbsd/amd64/12-STABLE/base-dbg.txz
# fetch https://ci-01.nyi.hardenedbsd.org/pub/hardenedbsd/12-stable/amd64/amd64/BUILD-LATEST/kernel-dbg.txz -o /usr/local/www/pxe/bsd/hbsd/amd64/12-STABLE/kernel-dbg.txz
# fetch https://ci-01.nyi.hardenedbsd.org/pub/hardenedbsd/12-stable/amd64/amd64/BUILD-LATEST/src.txz -o /usr/local/www/pxe/bsd/hbsd/amd64/12-STABLE/src.txz
# fetch https://ci-01.nyi.hardenedbsd.org/pub/hardenedbsd/12-stable/amd64/amd64/BUILD-LATEST/tests.txz -o /usr/local/www/pxe/bsd/hbsd/amd64/12-STABLE/tests.txz

Now we’re creating a convenience script for HardenedBSD:

# vi /usr/local/www/pxe/hbsd.sh

Put the following into the script:

#!/bin/sh
ARCH=`uname -m`
MAJOR=`uname -r | cut -d"." -f1`
mkdir -p /usr/freebsd-dist
fetch http://10.11.12.1/bsd/hbsd/${ARCH}/${MAJOR}-STABLE/MANIFEST -o /usr/freebsd-dist/MANIFEST
bsdinstall

Now fire up mfsBSD, login as root and simply run the following command line to start the installer:

# fetch http://10.11.12.1/hbsd.sh && sh hbsd.sh

Select the “Other” button when asked for the installation source. Choose that and point to your distfile mirror – in my example http://10.11.12.1/bsd/hbsd/amd64/12-STABLE. And that’s it.

MidnightBSD 2.0

Since MidnightBSD is a FreeBSD fork as well, it also suffers from the well-known problems related to PXE booting. Again mfsBSD comes to the rescue. Let’s create the distfile mirror first:

# mkdir -p /usr/local/www/pxe/bsd/mbsd/amd64/2.0-RELEASE
# fetch https://discovery.midnightbsd.org/releases/amd64/2.0.3/MANIFEST -o /usr/local/www/pxe/bsd/mbsd/amd64/2.0-RELEASE/MANIFEST
# fetch https://discovery.midnightbsd.org/releases/amd64/2.0.3/base.txz -o /usr/local/www/pxe/bsd/mbsd/amd64/2.0-RELEASE/base.txz
# fetch https://discovery.midnightbsd.org/releases/amd64/2.0.3/kernel.txz -o /usr/local/www/pxe/bsd/mbsd/amd64/2.0-RELEASE/kernel.txz

Pick any or all of the remaining optional distfiles to be mirrored, too, if you need them:

# fetch https://discovery.midnightbsd.org/releases/amd64/2.0.3/lib32.txz -o /usr/local/www/pxe/bsd/mbsd/amd64/2.0-RELEASE/lib32.txz
# fetch https://discovery.midnightbsd.org/releases/amd64/2.0.3/doc.txz -o /usr/local/www/pxe/bsd/mbsd/amd64/2.0-RELEASE/doc.txz
# fetch https://discovery.midnightbsd.org/releases/amd64/2.0.3/base-dbg.txz -o /usr/local/www/pxe/bsd/mbsd/amd64/2.0-RELEASE/base-dbg.txz
# fetch https://discovery.midnightbsd.org/releases/amd64/2.0.3/kernel-dbg.txz -o /usr/local/www/pxe/bsd/mbsd/amd64/2.0-RELEASE/kernel-dbg.txz
# fetch https://discovery.midnightbsd.org/releases/amd64/2.0.3/lib32-dbg.txz -o /usr/local/www/pxe/bsd/mbsd/amd64/2.0-RELEASE/lib32-dbg.txz
# fetch https://discovery.midnightbsd.org/releases/amd64/2.0.3/src.txz -o /usr/local/www/pxe/bsd/mbsd/amd64/2.0-RELEASE/src.txz
# fetch https://discovery.midnightbsd.org/releases/amd64/2.0.3/mports.txz -o /usr/local/www/pxe/bsd/mbsd/amd64/2.0-RELEASE/mports.txz

And here’s the convenience script:

# vi /usr/local/www/pxe/mbsd.sh

Put the following into it:

#!/bin/sh
ARCH=`uname -m`
RELEASE="2.0"
mkdir -p /usr/freebsd-dist
fetch http://10.11.12.1/bsd/mbsd/${ARCH}/${RELEASE}-RELEASE/MANIFEST -o /usr/freebsd-dist/MANIFEST
bsdinstall

Now you can PXE-boot mfsBSD as prepared in the FreeBSD section. After logging in as root execute the following command line that will take you to the installer:

# fetch http://10.11.12.1/mbsd.sh && sh mbsd.sh

When given the choice to select the installation source make sure to select “Other” and point to the right URL – in my example it would be http://10.11.12.1/bsd/mbsd/amd64/2.0-RELEASE, then install the OS as you’re used to.

Watch out for some options in the installer, though! MidnightBSD is mostly on par with FreeBSD 11.4. If you enable e.g. newer hardening options that the installer knows but the target OS doesn’t, you might run into trouble (not sure, tough, I didn’t think of this until after my test installation).

What’s next?

I didn’t plan this post to get that long, especially NetBSD surprised me. Eventually I decided to cover HardenedBSD and MidnightBSD as well and accept that this is a BSD-only article. So the next one will add various Linuxen and other operating systems to the mix.