OpenBSD on actual hardware
This post was published on 19 Mar 2025
Welcome back to my OpenBSD adventures. My new computer finally arrived, a Lenovo ThinkCentre M93p with an i5-4570, 32 GB of DDR3 RAM and a 256 GB SSD. I have decided to keep the 256 GB SSD that came with it as a boot drive and install a second drive for VM stuff. This meant having to learn how to actually do that on OpenBSD (or in the terminal in general). I haven’t really yet done any disk partitioning via the terminal on either Linux or OpenBSD to be honest! Additionally, I had to get vmm and vmd working and also figure out how to actually get sensor readings in OpenBSD. I also wanted to find out how to change the frequency / power mode of the processor so that it would have a lower power consumption. The VM stuff will be discussed in a separate blog post, however.
For a lot of this, I heavily referenced various OpenBSD man pages as well as the very helpful FAQ on their website; I initially thought that something called FAQ would have maybe a dozen or so questions like “Who invented OpenBSD?” or “When was OpenBSD first released”, but as it turns out, the FAQ is actually insanely helpful and makes for a great addition to the man pages. There is also a website that provides offline copies of the OpenBSD FAQ over on si3t.ch/misc/logiciel-libre/openbsd/offfaq/.
Hardware information and optimisation
As said previously, this is an old ThinkCenter M93p SFF that I got off eBay for around €50 with an old i5-4570 and I forgot that the old Intel Core i5 processors didn’t actually have hyperthreading! So 4C/4T. I was happy to find one that actually had 32 GB of RAM in it for this price, this is going to be very helpful for running multiple VMs. It’s missing two of its PCIe slot covers, but that honestly doesn’t matter too much to me. Additionally, it runs very quietly on idle and it also has four SATA connectors and an (empty) 5.25” drive bay, so I am honestly kind of tempted to just put a bunch of drives into this and use it as a second NAS but using only OpenBSD-native tools? But… maybe some other time. But anyway, in this section I want to look at various tools to retrieve some hardware information or change the CPU clocks to make it a bit less power-hungry (if possible).
Temperature information
The first thing I wanted to find out after installing OpenBSD was how the CPU temperature was holding up and my first instinct was to simply type doas pkg_add lm-sensors as that’s the program I typically use on Linux for tasks such as finding out CPU temperature or fan speed. That, however, did not work and I tried installing lm_sensors (with an underscore instead of a dash) and that also didn’t work. I then did some googling and quickly found out what the lm actually stands for: Linux monitoring. Thus, it should’t surprise me that the Linux Monitoring Sensors program wouldn’t work on OpenBSD! After some more research, I found out that you can use the built-in sysctl command to get hardware information, including temperature sensors. Running simply sysctl, however, just produces a very long list of variables and finding the information you want can be a bit difficult.
Sure, you could simply pipe the output of sysctl into something like grep and find what you’re looking for that way, but you can also instruct sysctl to output only the information you need. In this case, to get information regarding the hardware sensors, you can run sysctl hw.sensors which will produce an output that should look similar to this:
[hex@:/home/hex]> sysctl hw.sensors hw.sensors.cpu0.temp0=25.00 degC hw.sensors.cpu0.frequency0=3450000000.00 Hz hw.sensors.cpu1.frequency0=3400000000.00 Hz hw.sensors.cpu2.frequency0=3450000000.00 Hz hw.sensors.cpu3.frequency0=3350000000.00 Hz hw.sensors.acpitz0.temp0=27.80 degC (zone temperature) hw.sensors.acpitz1.temp0=29.80 degC (zone temperature)
As you can tell, the computer is actually running really cool with the CPU temperature being at 25°C and two other unspecified temperature sensors being at 27.80°C and 29.80°C respectively. I am honestly quite surprised at these numbers and hope they’re actually correct; even though it’s currently still winter here in Germany, my room is currently at around 20°C and the CPU being just 5°C above ambient temperature while idle despite it being this old is quite impressive! Power usage is less impressive, with the entire system using around 20 W while idle according to my wattmeter. My two other servers combined use around 45 W and they have a bunch of things running on them (including my NAS, so two HDDs as well!).
Clock speeds
You can also see the clock speed of each of the four CPU cores and this does appear to be the current clock speed, not the maxiumum clock speed or anything like that; and this made me wonder if it would be somehow possible to change the CPU governor to be a bit more aggressive with its downclocking and potentially save some power. The way to do that on OpenBSD appears to be the command apm which, upon running it without any arguments or flags, produces the following output:
[hex@:/home/hex]> apm Battery state: absent, 0% remaining, unknown life estimate AC adapter state: not known Performance adjustment mode: manual (3201 MHz)
Obviously I don’t have a battery attached to this PC, but it does tell us that the current performance adjustment mode is set to manual; and speaking of “manual”, if you check the man page for apm, it gives you a bunch of flags you can use to change the performance mode. Apparently, the standard mode is -A which is stands for “automatic”; I am not quite sure why mine defaulted to manual but okay. Changing it to “auto” resulted in the same clock speeds as “manual”, however. By using the flags -H or -L, you can seemingly set the CPUs to either always use the highest or the lowest clock speed respectively and setting apm -L results in the following output:
[hex@:/home/hex]> apm Battery state: absent, 0% remaining, unknown life estimate AC adapter state: not known Performance adjustment mode: manual (800 MHz)
This seems to have worked but the (idle) power draw appears to have remained the same so I have decided to just leave it on auto for now. There is a package called `obsdfreq´ that might be helpful, but I haven’t tried that out yet. There some information about it here: dataswamp.org/%7Esolene/2022-04-21-openbsd-71-fan-noise-temperature.html.
Adding a new drive
As a second drive, I simply added a Silicon Power A55 1 TB SATA SSD and threw it into the 5.25” drive bay because I don’t have a proper mount for it; but considering it’s not an actual HDD, I don’t think that not having it mounted properly really matters all that much, it doesn’t have any moving parts in it after all! This is also not necessarily an endorsement for this particular SSD, but I have been happy with the SSDs from SP and they’re pretty cheap, I got this one for around €40 and considering this isn’t going to be anything mission-critical, I don’t think it should matter too much! It’ll mostly be storing my VM data and a bunch of other stuff that’ll get backed up to my NAS anyway.
The first thing I did after putting the SSD into the computer was to run lsblk to see if it was recognised by the system; what I did not expect was the following:
[hex@:/home/hex]> lsblk ksh: lsblk: not found
As it turns out, OpenBSD does not actually have the lsblk command and I don’t think it’s possible to install it either. Once again, we need to use the sysctl command we used earlier for this task and to find out what disks are currently connected to the system and what they are called, we need to run sysctl hw.disknames which spews out the following hw.disknames=sd0:,sd1:f1d2587769f84534 wherein sd1 is the boot disk and sd0 is the newly-added 1 TB SSD and the long string of letters and numbers is the DUID, OpenBSD’s equivalent of the UUID used on Linux. But how do you know which disk is which? You can run df -h which gives you the following output:
Filesystem Size Used Avail Capacity Mounted on /dev/sd1a 986M 138M 798M 15% / /dev/sd1l 121G 670M 114G 1% /home /dev/sd1d 3.9G 10.0K 3.7G 1% /tmp /dev/sd1f 23.4G 1.4G 20.8G 7% /usr /dev/sd1g 986M 321M 615M 35% /usr/X11R6 /dev/sd1h 19.4G 233M 18.2G 2% /usr/local /dev/sd1k 5.8G 2.0K 5.5G 1% /usr/obj /dev/sd1j 4.8G 2.0K 4.6G 1% /usr/src /dev/sd1e 28.7G 9.5M 27.2G 1% /var
As you can see, the root partition is clearly mounted on /dev/sd1a and so the sd1 disk has to be our boot drive. Another way to see the disks attached to the system is to look at dmesg. However, the command to do this is a bit unwieldy; nevertheless, its output clearly shows both drives, their name and their sizes:
[hex@:/home/hex]> dmesg | grep -E '(sd[0-9]|wd[0-9])' sd0 at scsibus1 targ 0 lun 0: <ATA, SPCC Solid State, X111> t10.ATA_SPCC_Solid_State_Disk_HI4RA1SS15GE43DOWUXZ sd0: 976762MB, 512 bytes/sector, 2000409264 sectors, thin sd1 at scsibus1 targ 3 lun 0: <ATA, SanDisk SD7SB6S-, X351> naa.5001b444a487e6c0 sd1: 244198MB, 512 bytes/sector, 500118192 sectors, thin root on sd1a (f1d2587769f84534.a) swap on sd1b dump on sd1b
Now that we know what our new drive is called, we can go and do the partitioning. The first thing I did here was to run doas fdisk -e sd0 to interactively edit the disk. Then I ran doas disklabel -E sd0 to create a partition. And then in the end I ran doas newfs sd0a to format the disk.
fdisk commands
[hex@:/home/hex]> doas fdisk -e sd0
Enter 'help' for information
sd0: 1> print G
Disk: sd0 geometry: 124519/255/63 [2000409264 Sectors]
Offset: 0 Signature: 0x0
Starting Ending LBA Info:
#: id C H S - C H S [ start: size ]
-------------------------------------------------------------------------------
0: 00 0 0 0 - 0 0 0 [ 0: 0G] Unused
1: 00 0 0 0 - 0 0 0 [ 0: 0G] Unused
2: 00 0 0 0 - 0 0 0 [ 0: 0G] Unused
3: 00 0 0 0 - 0 0 0 [ 0: 0G] Unused
sd0: 1> reinit
Disk: sd0 geometry: 124519/255/63 [2000409264 Sectors]
Offset: 0 Signature: 0xAA55
Starting Ending LBA Info:
#: id C H S - C H S [ start: size ]
-------------------------------------------------------------------------------
0: 00 0 0 0 - 0 0 0 [ 0: 0 ] Unused
1: 00 0 0 0 - 0 0 0 [ 0: 0 ] Unused
2: 00 0 0 0 - 0 0 0 [ 0: 0 ] Unused
*3: A6 0 1 2 - 124519 182 63 [ 64: 2000409200 ] OpenBSD
Use 'write' to update disk.
sd0*: 1> print G
Disk: sd0 geometry: 124519/255/63 [2000409264 Sectors]
Offset: 0 Signature: 0xAA55
Starting Ending LBA Info:
#: id C H S - C H S [ start: size ]
-------------------------------------------------------------------------------
0: 00 0 0 0 - 0 0 0 [ 0: 0G] Unused
1: 00 0 0 0 - 0 0 0 [ 0: 0G] Unused
2: 00 0 0 0 - 0 0 0 [ 0: 0G] Unused
*3: A6 0 1 2 - 124519 182 63 [ 64: 954G] OpenBSD
sd0*: 1> write
Writing MBR at offset 0.
sd0: 1> quit
disklabel commands
[hex@:/home/hex]> doas disklabel -E sd0 Label editor (enter '?' for help at any prompt) sd0> p G OpenBSD area: 64-2000409264; size: 953.9G; free: 953.9G # size offset fstype [fsize bsize cpg] c: 953.9G 0 unused sd0> a a offset: [64] size: [2000409200] FS type: [4.2BSD] sd0*> p G OpenBSD area: 64-2000409264; size: 953.9G; free: 0.0G # size offset fstype [fsize bsize cpg] a: 953.9G 64 4.2BSD 8192 65536 1 c: 953.9G 0 unused sd0*> w sd0> q
After all of this has been done, I created a new mount point for the disk under /mnt/ssd1 and mounted it using doas mount /dev/sd0a /mnt/ssd1. Running df -h now shows us that the drive has indeed been mounted as we get shown the following line: /dev/sd0a 946G 8.0K 899G 1% /mnt/ssd1. However, because I actually want the disk to be mounted on boot, I had to go and edit the /etc/fstab file as well. Running sysctl hw.names shows us the ID of the newly-formatted drive:
[hex@:/home/hex]> sysctl hw.disknames hw.disknames=sd0:43f8f447d5ac5441,sd1:f1d2587769f84534
I, therefore, went into /etc/fstab and looked at the entries already present there. The content of that file looks as follows:
f1d2587769f84534.b none swap sw f1d2587769f84534.a / ffs rw 1 1 f1d2587769f84534.l /home ffs rw,nodev,nosuid 1 2 f1d2587769f84534.d /tmp ffs rw,nodev,nosuid 1 2 f1d2587769f84534.f /usr ffs rw,nodev 1 2 f1d2587769f84534.g /usr/X11R6 ffs rw,nodev 1 2 f1d2587769f84534.h /usr/local ffs rw,wxallowed,nodev 1 2 f1d2587769f84534.k /usr/obj ffs rw,nodev,nosuid 1 2 f1d2587769f84534.j /usr/src ffs rw,nodev,nosuid 1 2 f1d2587769f84534.e /var ffs rw,nodev,nosuid 1 2
The layout seems quite clear, and so I simply copied the /home entry and replaced the ID and the partition with the one I just created. The new entry, thus, looks like this: 43f8f447d5ac5441.a /mnt/ssd1 ffs rw,nodev,nosuid 1 2, wherein 43f8f447d5ac5441 is the ID for the disk and .a shows what partition I want to mount, namely a. I then rebooted the computer by running doas reboot -p. This… did not work, the computer just wouldn’t turn back on. So I grabbed a screen and connected it to the computer (I had been connected via SSH up until this point) and I noticed that it just didn’t want to boot into OpenBSD anymore. I thought I had accidentally wiped some OpenBSD partition, but I checked the BIOS and noticed that the boot SSD (the 256 GB one) had been removed from the BIOS’ / UEFI’s “Automatic Boot Order” sequence, having been replaced by the newly added 1 TB SSD. So I went and changed the settings and then it finally booted up again. What a strange thing though, I don’t think I have ever had a BIOS / UEFI remove boot entries before.
At any rate, after finally being back in my OpenBSD installation, I checked the output of df -h and was very happy to see that my /etc/fstab entry seems to have worked, the drive was correctly mounted upon boot! My own user account hex was unable to actually write to it, but doing a doas chown -R /mnt/ssd1 hex:hex resolved that issue.
And now that all of this is out of the way, I can finally start messing around with VM stuff which is what I’ll be talking about in the next blog post ^v^
