A critical look at NetBSD’s installer

[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/2025/installing_bsd_pt3.gmi
The first part of this series was about FreeBSD’s installer and the second covered OpenBSD’s installation program.
This is a longer article and it has the most images that I ever included in one. While writing the other two articles didn’t take me too long, this one has has occupied several evenings / nights over the course of about three weeks.
NetBSD is an OS that I installed only a couple of times over the years, so I’m not very familiar with its installer, sysinst. This fact was actually what led to this article (or the whole series rather): Talking to a NetBSD developer at EuroBSDcon 2023, I mentioned my impression that NetBSD was harder to install than it needed to be. He was interested in my perspective as a relative newcomer, and so I promised to take a closer look and write about it. While it certainly took me long enough, I finally get to do this. So let’s take a look at NetBSD’s installer, shall we? The version explored here is NetBSD 10.1 on amd64.
Installing a simple graphical NetBSD system
Sysinst is menu-driven like FreeBSD’s installer, but the two are quite different. This is not a direct comparison, but I’m going to mention other installers where appropriate. Like in the previous two articles, I’m going to install the OS twice: One time using the standard VGA console and once to assess how well it works over serial. Both installations will be in VMs just for the sake of convenience.
Language settings
The first screen that the installer presents is the language selection. If you’re used to more mainstream operating systems, you may be surprised that there’s only four languages in addition to English. But hey: Many other installers are available in English only, and if you’re somebody who’s more comfortable with German, (Castilian) Spanish, French, or Polish than with English, it’s nice to have the option!
I like that there’s a short introduction text at the top which briefly explains how to navigate the installer. This is very nice for newcomers! Assigning each item an alphabetic hotkey is also a great mechanic that makes navigating the installer a breeze even if there’s a lot of options (FreeBSD’s choice of numeric hotkeys is obviously inferior as soon as there are more than ten items).
After selecting the language, the installer presents a list of supported keyboard layouts. Again, NetBSD’s installer does not offer the most comprehensive list ever, but there are some surprises. Given the relatively short list, your preferred keymap may not be available.
You probably wouldn’t expect that somebody invested the effort to make Icelandic available, would you? And there’s also things like “German (NEO2)”, a relatively obscure ergonomic variant (that I’ve actually used in the past before adopting BONE whith is basically NEO3). Not even FreeBSD offers NEO2, BTW. Those unusual cases are strong indicators of the NetBSD project being happy to include contributions. So if you consider making a keymap for your layout, another option in the list could probably be yours!
Next is the main menu that allows the user to either install a fresh system, upgrade an existing one, reboot and so on. Like in the menu before, the text at the top did not change. But it didn’t have to since once again the menu options are self-explanatory.
The next screen presents some information on the steps of the installation process and asks if that is what the user wants to do. It’s concise and to the point – I like it. It means an additional key press, but it’s helpful for newcomers.
Preparing the hard disk
Now sysinst needs to know the installation target. I believe a more detailed explanation at the top would be beneficial. It’s probably nitpicking to point out that “Extended partitioning” is not exactly an answer to the question “On which disk do you want to install NetBSD?”. That aside, I genuinely believe this screen could be improved. Something like “Select a single disk as the installation target or choose ‘extended partitioning’ for softraid, a logical volume manager or device encryption.” would be better. Probably mentioning that ‘wd*’ means IDE or SATA drives, ‘sd*’ is for SCSI or external USB drives and ‘ld*’ are logical drives like VirtIO drives and NVME could be helpful as well.
The next screen does not have any explanatory text at all – another missed opportunity. While people who install NetBSD probably know it, would it hurt to mention that MBR is the scheme that older BIOS systems expect while GPT is required for EFI systems? I guess it wouldn’t.
The partition options and the description text for GPT are fine.
The default partition layout makes sense: One big partition for /, another for swap and a tmpfs-backed one for /tmp – and of course the FAT partition that is required for EFI booting. Since splitting out /usr and /var is common, both are suggested but have a size of 0, so they won’t be used unless the proposed layout is edited.
In general the top text is fine. While the explanation of the plus sign is helpful, I would appreciate a hint on how to select the partition that receives the plus. It took me quite a while to find out that when defining a partition size it can simply be appended! This was not immediately obvious to me.
Partition sizes and file systems
Editing partition sizes is easy enough. However the fact that giving /usr a size that is not 0 by default moves the plus sign to it even if *not* added to the size entered is quite confusing. It makes the plus mechanic appear magic even though it really isn’t. To be honest, before taking a closer look at sysinst, I assumed that it was not possible to add the plus e. g. to /home like I would have liked to do! Up until recently this was one of the things that bugged me about NetBSD’s installer. I read The NetBSD Guide‘s chapter on the installation and that info is not in there, either.
While it’s quite common for installers to allow specifying the unit as a suffix to the size, NetBSD does this differently. Sysinst allows for changing the unit via an option in the menu. It’s definitely useful to be able to switch to GB when partitioning large drives (and I guess due to the portability aspect of NetBSD it may make sense for some architectures to allow entering sectors or cylinders for more control).
The drawback with NetBSD’s method is that this makes the EFI partition appear as 0 GB as it’s only 128 MB. Allowing for input sizes like ’20g’ and ‘128m’ would be more flexible. Then again setting the EFI partition’s size (or just leaving it alone altogether) before switching units of course also works. Maybe displaying the size as 0.1 or something instead of 0 in that case would still make sense?
Adding more partitions is easy to do; the first menu option below the table will let you do that. Sysinst asks for a mountpoint in that case and adds the new partition to the table. Not being able to cancel the operation with ESC feels a little weird. If the box said “Mount point (leave empty to cancel)?: ” or something like that it would be clear how to abort adding another partition.
I simulated fat-fingering the input here by “accidentally” creating a “/s” partition. Much to my frustration I did not find out how to delete partitions from the table! Yes, since /usr and /var are initially of size 0, one can deduce that allocating no space to it will probably make the installer discard them. It’s details like these that make sysinst feel somewhat unfriendly and leave a negative impression.
I also don’t like that it’s not possible (or I was at least unable to find out how to do it) to change the mount point once the table entry is there. These two problems are also likely much worse with an MBR slice as BSD disklabels have a maximum number of partitions. If you’re doing a complex layout, better get it right the first time! It’s probably less of a problem for regular NetBSD users, but people who are new to an OS and are giving it a first try are not *that* unlikely to change their mind over the partitioning. The feeling of being unable to undo a mistake is discouraging.
Two new partitions added – one as a deliberate mistake
After finishing the partitioning, an overview of the layout is presented that the user can either accept – or cancel the installation. Again as a user I can’t say that I feel in control here. This screen basically asks: “Is this ok?”. And the only option besides “yes, go ahead” is “no, let me start over completely”. How about “let me go back to the partition editor and fix one small mistake”? Why isn’t there an option to modify this layout, and can I only accept or discard it? Again, this is probably not so much a problem for people who regularly install NetBSD. As someone who does so infrequently, I’m not entirely satisfied with this.
Next is another screen that gives the user the chance of “yes” and “no”. While it feels a bit redundant, I think it makes sense to make sure people are aware that at this point the changes will be written to the drive and data previously on it will be destroyed. It could probably still be another window over the last screen rather than a separate one. That’s a relatively minor point, though.
Writing the system to disk
Acknowledging the previous question, sysinst creates the partitions and filesystem(s). Now the user gets to choose which components of the OS to install. I like the options as well as the text.
Selecting the distribution sets
Now the user has to select the source for the distribution sets. The text only mentions FTP and NFS as requiring a network while this is of course the case for HTTP as well. I assume that this is because the other two are traditional sources while HTTP was added later but the text was not updated. This is of course another nit-picky one.
Selecting the installation source
With the source selected, the actual installation (unpacking of the distribution sets) begins. What I find a little strange is that while there is a progress bar, it’s for every single distribution tarball individually. There’s no global progress displayed anywhere! And since NetBSD consists of a respectable number of sets, I actually kind of miss this. Fortunately the system is fairly slim (especially compared to many other operating systems) and so the installation doesn’t take too long (even on machines with old, slow drives).
When all the sets were extracted, there’s an information screen letting the user know that the new system can now be configured. While in theory the process could be streamlined and this screen be dropped, the completion of the data transfer is probably significant enough to warrant it.
System configuration
The first thing that the installer lets you do to configure the system is setting a root password. While this is not technically necessary, basically everybody will want to do that, so it’s a logical choice to present it automatically.
Afterwards, sysinst presents a very nice configuration menu with various options that allow for convenient configuration of some basics. The “Configure additional items as needed.” would be fine – if all options were self-explanatory. For newcomers however, they aren’t. I would suggest changing “Enable xdm” to “Enable xdm (X11 display manager)”, “Enable cgd” to “Enable cgd (cryptographic disk driver)” and “Enable lvm” to “Enable lvm (logical volume manager)”.
You usually want to configure the network on your system. If you select the appropriate menu item, you get a list of detected interfaces to pick from. I’m going to make my usual suggestion here: Consider adding the MAC address for each interface!
While it’s often perfectly obvious which one you want to select, this is not always the case. I don’t know how often NetBSD is being deployed in datacenters these days, but servers often have several interfaces and it can be very beneficial for the admins to decide based on the MAC address which one is which (especially since you cannot expect penguins to be familiar with BSD interface naming!). 😉
Next is selecting the network media type. Not setting it means attempting autoconfiguration. This is another case where sysinst gives me a weird feeling. From the presented information alone I have no clue if leaving it empty will cause the installer to send DHCP requests or if it’s just going to assume 1000baseT full duplex or something for the media type. Also making this a text input rather than a list to pick from automatically (pun intended) makes people wonder what the supported values are. This is not ideal from a UX perspective.
Setting the network media type
Even when leaving the field empty to enable autoconfiguration, a menu pops up asking you if that’s really what you wanted to do. That feels very redundant and is another strong indication that this section of the installer could use an overhaul.
After that, sysinst asks for the hostname of the machine. Since there’s no standard way of handling this, I always appreciate it when the installer provides a clue as to whether it expects an FQDN or the short form. As I have the habit of using the former, the first time I installed NetBSD I of course noticed my mistake in the next screen.
NetBSD expects the short form for the hostname, so in the next screen it asks for the domain name. If DHCP was used, it proposes the domain name it got from it. My suggestion would be to either indicate on the previous screen that only the short form is acceptable, or to indicate that either form is and to skip this screen if an FQDN was entered as the hostname.
In the next screen, sysinst will provide a summary of the network parameters and ask the user whether they are ok.
If the user accepts them, the installer offers to write the configuration to disk. This is super helpful for people new to NetBSD who will certainly enjoy a working network connection before having to dig into the documentation just for that! However there might be use cases where people use an installation network to access the distfiles while the actual production network settings are different. So I guess presenting the choice to the user is the right thing to do.
Make network configuration persistent?
Next is configuring the time zone. NetBSD defaults to UTC which is a sensible choice. Users who prefer localtime can select items from a list.
If a continent was chosen in step 1 (like Europe in my case), another list of zones in that area are now presented.
Choosing an item selects it and makes sysinst jump to the “Exit” menu item which is a nice convenience.
Most people will not want to use only the base system, so making the pkgin package manager available is something that is commonly done. Luckily sysinst makes doing this really easy. In this screen, the installer allows you to configure the remote repository, protocol to use and so on.
Once repository access has been configured, sysinst installs pkgin and uses it to update the package summary.
When that’s done, the installer lets you know that pkgin has been successfully installed.
Some people prefer to (or have to) build packages from source. Sysinst assists in installing the Pkgsrc tree on the system, too. Doing this is quite similar to the previous action: The user first needs to configure a remote source …
… and then the compressed tarball is getting downloaded and extracted. Very convenient!
Fetching and installing pkgsrc
Another very common thing that a lot of people will want to do is creating an unprivileged user. This works without any fancy dialog windows by just asking for input of the name.
It then asks whether to add the user to the wheel group, which is excellent. For newcomers (especially from Linux) I’d love to see a little explanation that this means allowing the user to use the ‘su’ command to become root. Otherwise this is fine.
Then you get to select which of the three shells that the base system provides to use. This works effectively.
Finally you are asked to set the password for the user. Altogether the process is pretty bare bones as you can neither customize the home directory nor can you pick the UID or assign the user to additional groups. But you can always create (or modify) users manually after booting into the installed system, right?
There are other options here, but they are simply on/off switches. The last item is for finishing the configuration.
The last screen after the installation gives new users some valuable advice like reading afterboot(8) (you installed the man set, right?) and customizing /etc/rc.conf.
After acknowledging this, the installer returns to the main menu, where you can choose to reboot into the newly installed system.
Back on the main menu for rebooting
Installation over serial
To explore more of the installer, this time I’m aiming for a more customized installation fit for a server.
To be able to install via serial, it’s necessary to escape to the loader prompt and then issue the command:
consdev=com0,115200
Setting the console to serial in the loader
Changing the console to serial resets the terminal screen. Now it’s possible to just ask the loader to boot the kernel regularly:
boot
Booting the installation system
Just before the installer starts, it asks for the type of terminal that is connected. It needs to know this to make the best use of available features. I’m going with xterm here.
The first screen of the installer is the same as in the previous installation which used the video console.
The same is true for the main menu …
… and the information screen about the installation procedure.
I’ve given this machine two virtual drives, so this time I could choose which one to install to.
Selecting the installation target
While for the first installation I’ve taken the straight-forward path, this time I went with the extended partitioning. This portion of the installer allows for cryptographic volumes, virtual disk images, logical volume management and software raids in addition to more complex partitioning in general. The text contains the instructions to follow and works well for that matter.
Selecting one of the drives opens a menu with various configuration options. People who only ever go the standard path through the installer miss out on a lot of its capabilities! At least I was surprised by the many options when I first explored extended partitioning. Beforehand I considered sysinst to be quite limited, but that is obviously not the case.
Configuration options for a drive
I went with “Format as RAID”, but since the drive is empty, sysinst first asks about which partitioning schema to use. Your options here are GPT, MBR or BSD disklabels.
Selecting the partitioning schema
The installer went ahead and proposed a partition of type RAID for me. It would span the entire available space.
Accepting the the partition (going with the proposal or changing the size) takes you back to the partitioning menu. A new partition dk0 has appeared in the list and ld0’s status has changed to USED. (As a newcomer I ask myself what dk is, though. A search in the manpages does not solve the mystery.)
RAID partition created on the first drive
I did the same thing for the second drive and as expected, dk1 appeared.
The next step is to select “Create Software RAID”, which opens a window with configuration options.
Selecting “Disks:” lets the user add or remove disks from the RAID array.
Choosing “Add” allows to add members to the array. I think this is a little cumbersome, especially if you want to assemble a large RAID with several members. I would suggest getting rid of the window that’s used to add or remove disks and instead provide one where available disks can be marked as member or unused. That would streamline RAID creation.
After adding disks dk0 and dk1 as RAID members and not selecting any spares, the next thing to do is to choose the RAID level. Sysinst obviously does not take disk requirements into account: It offers RAID 5 even though that requires three or more disks while only two were added. So that’s another thing that could be improved.
I went with creating a mirror. Besides selecting the disks to use and the RAID level I left everything else alone.
The RAID configuration was done, but the list does not reflect that. The text said to select “Save Changes” after configuring a RAID, so that’s what needs to be done next.
RAID configured but not created, yet
What then happened again surprised me: The RAID is being built by supposedly writing parity information! This is very weird. I selected mirroring and RAID 1 does not use parity information – mirroring means having the same data on both drives after all! But this is probably raidctl(8)’s fault which simply calls mirrored data “parity” as well.
After the sync is complete, the new raid0 device appears in the list. According to the information it is a RAID 1 with two disks and 0 spares. It appears that what I intended to do has worked out.
Now the RAID can be partitioned like the disks beforehand. The same menu window is used for that. This time I go with editing the partitions.
The RAID array doesn’t contain any data, yet, so it needs a partitioning schema, first. It’s possible to use GPT or disklabels, here.
Partition schema selection for the array
Going with GPT, the user is then presented with an empty partition list and the option to add partitions.
Adding a new partition presents the user with various options like partition type, size, mount point and so on.
Other than the default FFSv2, there are various other types that you can pick from. There’s also “other type” which opens another menu with less common options like vinum, FreeBSD’s old volume manager.
I changed everything required to make this new partition be the EFI system partition required to boot from on EFI systems.
When creating a new partition for a filesystem that is going to be mounted, mount options can be selected.
After adding a swap partition I added a third one for the root filesystem with the values shown on the screenshot below.
While doing much more comprehensive partitioning is of course possible, I don’t think it’s necessary to do that here. A simple layout on a software RAID should be fine for the test system.
It appears that this section of the installer was re-used from the standard partitioning path. This is why the text says “This is your last chance to change” the partitions – which is not true. Accepting the partitioning returns you to the extended partition menu from where you could just choose to edit it again. It’s a small inaccuracy, though.
The new partitions appear in the list on the main extended partitioning menu now. So everything is ready to proceed to the actual installation.
The instructions didn’t say that the latest changes need to be saved again, but if you just try to go ahead, sysinst will simply ask you if you want to save or not.
Like in the previous installation, the next choice is the distribution sets to be installed. I’ll go for a custom installation this time.
Selecting the distribution sets
The standard selection of sets is fairly minimal. I would suggest to at least include the manpages by default!
Custom installation: Standard selection of sets
I chose to install the compiler toolchain (so that Pkgsrc would be usable) as well as the manpages (of course!) and miscellaneous (simply because I have no idea what’s in it).
Custom installation: A couple more sets enabled
To not simply repeat the first installation, I’m going with HTTP as the source for the sets instead of the local medium.
This of course triggers network configuration which was only done after the installation in the previous attempt. I’m not providing screenshots of the other configuration steps as they are identical.
Selecting the network interface
After the network is configured, the mirror to fetch the sets from needs to be selected.
And then the installation begins! Or not, since the filesystem for some reason turns out to be read-only …
Pain points
The above section ending rather abruptly is not due to any malice on my side trying to break poor little sysinst. In fact I tried to do several dozen installations over the past three weeks, trying out various setups. Truth be told: I’ve failed time and time again.
I didn’t mention it before, but after the first installation I wanted to show a screenshot of the graphical NetBSD system. The installation succeeded, but the system would panic during boot. Bhyve is more of a niche thing and not among the hypervisors supported by NetBSD, so I’m not complaining. But I haven’t been able to finish *any* installation after picking extended partitioning. Going with a software RAID makes the FS read-only. Trying to create a simple LVM lead to this:
Status: Command failed > Command: lvm pvcreate -ffy /dev/rdk2 > Hit enter to continue > --- > Device /dev/rdk2 not found (or ignored by filtering)
I read the first few chapters of The NetBSD Guide, hoping to better understand what I was doing wrong. It’s a good document but unfortunately pretty outdated, too. When I read “The examples from this chapter were created with NetBSD 8.0.”, I got a feeling what to expect (that version was released 7 years ago, in 2018).
I honestly don’t mind that the image explaining partitioning uses DOS as the other operating system in a dual-boot setup. But the guide does not even mention GPT at all! It’s all legacy MBR which is not terribly helpful for newer machines at this point. Also much to my surprise, the extended partitioning is not even covered. Yes, Software RAID, LVM and friends are covered, but only how to set them up via the CLI on a running system. Sorry, I don’t want to do that, I want to install to a more flexible means of storage than a bare disk with fixed partition sizes!
The system console messages appearing on the screen and messing up parts of the installer can be very annoying, too. Maybe just start sysinst on different virtual terminal to get rid of this?
Installing on real hardware presented me with other problems – and even standard installations can fail. On one machine it took incredibly long – the modules.txr.xz set alone took half an hour with the installation at times going to as slow writes as roughly 4 KiB/s or even stalling entirely. The base set took over 1.5 hours! I assume NetBSD might be struggling with the NVMe? To add insult to injury when it was finally done with all the sets (I had picked a full installation…), this was the result:
Status: Command failed > Command: /sbin/fsck_ffs -p -q /dev/dk0 > Hit enter to continue > --- > /dev/rdk0: BAD SUPER BLOCK: CAN'T FIND SUPERBLOCK > > /dev/rdk0: UNEXPECTED INCONSISTENCY; RUN fsck_ffs MANUALLY.
I tried my luck in the opposite direction and used one of the older laptops that I have. The installer started regularly but at one point simply dropped me to a shell, saying “sysinst terminated.”
The error message was something along the lines of “Screen too narrow (70 + 5 > 64) for menu”. I was able to solve that by connecting a VGA monitor to it, but that was unexpected nevertheless. This little experiment proved useful, though, as it revealed a portion of sysinst that I had not seen before: The installer told me that this machine didn’t provide strong entropy and gave me several options for dealing with that. It’s really nice that NetBSD did great work in that regard!
Conclusion
Well, after all those problems I encountered, you might expect me to condemn sysinst. I won’t. In fact I like the general workflow – minus the weird parts. Sysinst has a lot of neat ideas in addition to some quirks. As mentioned at the beginning, I like the hotkey system a lot. Trying to reserve “x” to finish a screen is one nice detail. I really like the configuration options after the installation. That part is very well done.
On the other hand, network autoconfiguration is weird. I miss the option to decide on configuring the system for v4 only for example. A couple of things could certainly be improved, but few things are perfect. The elephant in the room though is the major problems that I ran into. I often find myself exploring less common paths in programs, which sometimes leads to uncovering bugs. It’s not just sysinst but it happens to me often when I use something not just superficially.
When I sat down to concern myself with the NetBSD installer, I expected that my major critique would be that it doesn’t do ZFS – which is a shame since the availability of that filesystem is one of the things that make NetBSD appeal to me. Various other problems have definitely overshadowed this, though. I remain hopeful that these issues can be addressed, and perhaps the solution lies in clearer guidance for users. As I said, I’m not very familiar with NetBSD. But I’d like to change that fact in the long run. And ideally at some point I’d be able to say: “Of course it runs NetBSD!”
What’s next?
In the next article I’ll take a closer look at DragonFly BSD’s installer.
What's Your Reaction?






