I purposely chose a non-catchy title so that it would be more easily found by the search engines as this one has been a challenge for me in my last several laptop installs and I always manage to fix it after fiddling around for a while. This time around, I thought I’d actually produce a decent (hopefully!) write-up on just how I go about addressing the problem from scratch. This will provide two benefits: 1) I’ll have a nice step by step the next time I install my machine <grin>; and 2) It might help some other intrepid soul who is running into the same issue!
While the FAQ is always the best place to go for the most up to date steps on formatting and installing a system, I tend to run a “weird” setup that it seems like confounds the installer and most easily-accessible information. What I normally do in my Thinkpad laptops is install a second (or third) SSD or NVMe drive and then dedicate the entire disk to a given operating system. For example, if I’m running Windows 10 and OpenBSD 6.9 on my Thinkpad T480, I install Windows on the first drive (so that if my machine falls into evil hands and they power it on, it will just default boot into Windows and they might not even suspect OpenBSD is on the machine) and then I install OpenBSD onto the second drive. I then use the UEFI or BIOS boot menu to choose the OpenBSD drive to boot from.
I started off by installing Windows from a USB key to the primary drive in the laptop. As is my custom, after install, I put on all of the drivers and used the group policy editor to increase the BitLocker encryption from 128-bit AES to 256-bit AES. I also edited the registry to allow Outlook’s OST file to expand beyond the pitiful limit that it defaults to. After a reboot, I start the BitLocker encryption process and connect my email accounts.
If you are installing OpenBSD on a drive that has previously had something on it, it’s always a good idea to erase that drive. I use an open source tool for Windows called Eraser if I’m on Windows or good old dd if I’m on Linux. Eraser’s UI is a bit weird. It requires that you create a task that you can “run manually”, select the disk to be erased (in my cased “Hard disk 1”) and then select an erasure method (I use Pseudorandom 1-pass), then run the task manually.
I then download the install69.img file from my favorite mirror (https://openbsd.cs.toronto.edu/pub/OpenBSD) and use Rufus to transfer it to a bootable USB drive. I reboot, hit <F12> to get a boot menu from the UEFI, select my USB drive and then boot into the OpenBSD installer.
The first thing I do is look at my dmesg to see what devices my drives have been attached to:
# dmesg | grep -i sd
This shows (in my case) that my Windows drive is connected to sd0, my blank drive that I will put OpenBSD on is connected to sd1 and my USB installer device is connected to sd2. Next, I need to create the necessary /dev devices:
# cd /dev # sh ./MAKEDEV sd1 # sh ./MAKEDEV sd2
If you do a quick ls, you should see that the MAKEDEV script created the necessary device files and you should be good to proceed to the next step. Next, we want to initialize the sd1 drive to a GPT partitioning scheme and create the initial EFI partition on the disk. Fun fact, the EFI partition (while its own partition type) is formatted using FAT32 so thanks Windows 95! Here’s how you do this:
# fdisk -iy -g -b 960 sd1 # newfs_msdos /dev/rsd1i
Note my use of the /dev/r device (the raw device) and not the /dev/sd1i (normal device) in that second command. I’m not entirely sure if that is necessary, but the nice Reddit post that sparked me to think about how to do this did so why not, eh? If you get a weird error message trying to run newfs_msdos, it is likely that you have some previous partitioning data on that drive and it would be a good idea to completely erase it (see above).
Now, we need to mount the new partition, create the necessary directory structure that UEFI looks for and put the UEFI loader file from our installer USB drive into that directory:
# mount /dev/sd2i /mnt # mount /dev/swd1i /mnt2 # mkdir -p /mnt2/efi/boot # cp /mnt/efi/boot/* /mnt2/efi/boot
Now, we need to create the slice in the OpenBSD partition for the encrypted filesystem (you can skip this if you want to not have an encrypted drive):
# disklabel -E sd1 a a [ENTER] offset: the default given size: * type: RAID w [ENTER] q [ENTER]
At this point, we have a slice set up as type “RAID” so we need to use the bioctl program to set up the encryption information along with the drive’s encryption password:
# bioctl -c C -l /dev/sd1a softraid0
You should see in the response to the above command the name of the new “virtual” encrypted disk. That is the disk that you will be installing OpenBSD onto. When you reach the question in the installation program about “Which disk is the root disk?”, enter that value (in my case, sd4). When i tasks whether or not you want to “Use (W)hole disk MBR, whole disk (G)PT or (E)dit?”, pick the MBR option (I know, this is counter intuitive but trust me here).
After the installer reboots the system, I press the [F12] key to get the boot menu (your key might be different if you aren’t running a Thinkpad) and select the disk I have installed OpenBSD on. I am immediately presented with the password prompt to decrypt the encrypted slice “virtual” disk and, upon entering it, I get the boot prompt. Everything proceeds as normal from that point forward and I am presented with the login prompt for my new system.
Updated Laptop Setup
If you are still with me and want to see how I set up my OpenBSD desktop (I get criticized slightly for making it “too heavy” with “too many packages” but I have to use Ubuntu as well for what I do and I like to have the UI be as consistent across the two operating systems as I can. Therefore I install Gnome 3 along with some gnome tweaks and plugins that give me the same theme and dock as Ubuntu.
To start out, I log in as root and enable my user account:
# echo "permit persist keepenv [my_non_root_user] as root" > /etc/doas.conf
At this point, I log out and back in as my unprivileged user account and work from there using the doas command to escalate privileges when needed. I start out by updating my system:
$ doas syspatch
Now, set up power management (this is a laptop):
$ doas rcctl enable apmd $ doas rcctl set apmd flags -A $ doas rcctl start apmd
I also add the following line to /etc/rc.conf.local (I haven’t cracked the code on how to do this with rcctl yet):
Now I need to make sure that I have the right level of resources available to my non-privileged user for tools like nextcloudclient (which opens a TON of files during its synchronization process). To do this I typically put myself in the “staff” and “operator” groups:
$ doas usermod -G staff MY_USERNAME $ doas usermod -G operator MY_USERNAME $ doas usermod -L staff MY_USERNAME
I then make the following changes to the “staff” section in /etc/login.conf:
... staff:\ :datasize-cur=4096M\ :datasize-max=infinity\ :maxproc-max=512:\ :maxproc-cur=256:\ :openfiles-max=102400:\ :openfiles-cur=102400
I then have to add a line to /etc/sysctl.conf to take complete the work on allowing more open files on this system:
Now that I have modified all of this stuff and patched the system, it’s a good time to reboot.
Next, I add all of the packages I can’t live without (I know it seems like a small list, but they pull in a lot of others):
$ doas pkg_add gnome gnome-tweaks gnome-extras firefox chromium libreoffice nextcloudclient keepassxc \ aisleriot evolution evolution-ews tor-browser shotwell gimp vim colorls cups reposync
A few changes to /etc/rc.conf.local are needed to boot into Gnome3:
$ doas rcctl disable xenodm $ doas rcctl enable multicast messagebus avahi_daemon gdm cupsd
To avoid taking a kernel panic in my use-case (I have multiple monitors connected through a Lenovo Thunderbolt/USB-C dock), I have to manually switch to the Intel DRM driver in my /etc/X11/xorg.conf by adding the following section:
Section "Device" Identifier "Intel Graphics" Driver "intel" EndSection
At this point, it’s time to reboot and go into GUI land. If you run into a situation where you have a monitor mirrored and no way to turn that feature off, I have found that turning all of the monitors off and back on generally fixes things. Once I have everything the way I would like it, I then download the yaru-remix-complete theme and install it manually by doing this:
$ cd ~ $ mkdir .themes $ cd .themes $ mv ~/Downloads/yaru-remix-complete-20.04.tar.xz . $ unxz yaru-remix-complete-20.04.tar.xz $ tar xf yaru-remix-complete-20.04.tar $ mv themes/* . $ rmdir themes % doas mv icons/* /usr/local/share/icons $ rmdir icons $ doas mv wallpaper/* /usr/local/share/backgrounds/gnome $ rmdir wallpaper $ rm yaru-remix-complete-20.04.tar
Now launch gnome-tweaks and from the “Extensions” tab, turn on “user-themes”. Restart gnome-tweaks, go to the “Appearance” tab and select “Yaru-remixt” for applications, icons, and shell. On the “Top Bar” tab, enable “Battery Percentage” and “Weekday”. In the “Window Titlebars” tab, enable “Maximize” and “Minimize”.
Next, we want to put the wonderful extension Dash-To-Dock into the environment. To download it, go to https://extensions.gnome.org/extension/307/dash-to-dock/ and pick the right sehll version and extension version to match your install of Gnome shell. You will have to manually install it because the Gnome shell extension integration doesn’t appear to be enabled for OpenBSD:
$ cd ~/Downloads $ unzip dash-to-docmicxgx.gmail.com.v67.shell-extension.zip $ cat metadata.json
The value for “uuid” in that file is what you want to use in the next step:
$ mkdir -p ~/.email@example.com $ cd ~/.firstname.lastname@example.org $ unzip ~/Downloads/dash-to-docmicxgx.gmail.com.v67.shell-extension.zip
At this point, reboot to pick up the changes you’ve made, log in and launch gnome-tweaks again. On the “Extensions” tab, enable dash to dock. From the settings gear icon, select “extend to edge” and “show on all monitors” and you should have a very serviceable dock that is quite similar to the one in Ubuntu.
I then switch the terminal to “White on Black” for a better look and a 16-point font, and pin my favorite apps to the dock. Now for some terminal-level tweaks. I typically edit my ~/.profile file and add a couple of things:
export PS1="\[033[01;32m\]\u@\h\[\033[00m\]:\[033[01;34m\]\w[\033[00m\]$ " export ENV=$HOME/.kshrc export CVSROOT=/home/cvs
I then edit the ~/.kshrc file to add some aliases:
alias ls="colorls -G" alias vi="vim"
A couple of other changes I typically make include turning off suspend when I’m plugged in (Settings | Power | Automatic Suspend), setting Firefox as my default browser (Settings | Default Applications), and setting my Time Format to “AM/PM” instead of “24-hour” (Settings | Date & Time).
I also take a moment to switch to “View -> User Interface -> Tabbed” in the Write, Calc, and Present applications in LibreOffice. This gives an interface reminiscent of the one in Microsoft Office – which I find helpful in terms of standardizing my workflow across operating systems.
After installing the appropriate browser security plugins and configuration changes from my favorite https://privacytools.io site, it’s time to set up CVS on my system for development purposes. To do this, I always double-check the AnonCVS link from the OpenBSD website left navigation panel and follow the steps to:
- Pre-load the source tree (for src, sys, ports and xenocara)
- Follow the instructions to give your non-root user write access to the src, ports and xenocara directories
- Mirror the repository with reposync (Note: I have had the best luck using anoncvs.comstyle.com as my mirror)
I then typically will add a crontab entry to keep things in sync:
$ doas crontab -e ... 0 */4 * * * * -n su -m cvs -c "reposync rsync://anoncvs.comstyle.com/cvs /home/cvs"
After syncing up my NextCloud data and my email data, I now have what I consider to be a secure, fully-functional OpenBSD laptop, configured the way I like it.