* On 7.6 `bwmf0` was detected and works great, even in AP mode. However, my latest Node project core dumped when running `npm install` and nothing I tried got it working (short of recompiling Node)
* On 7.7 (today's release) `npm install` is working perfect
Not worth an entire blog post, but just goes to show improvements in OpenBSD over time on the Pi 4 :)
rollcat · 3d ago
What's your experience with OpenBSD on RasPi4 specifically? I've found it's pretty poor at handling unexpected power loss - the FS requires interactive fsck during next boot, which means repositioning the box near your computer, pulling out a serial dongle, figuring out the correct GPIOs, etc. Big hassle for a box that's supposed to sit unattended.
accrual · 2d ago
Yeah, I would agree getting into the Pi 4 is a little troublesome if it's intended to be headless.
Mine hosts a LAN using the built-in wireless adapter (bwmf0) so it's easy to SSH in, but if it's stuck in single user mode, this doesn't work.
With a spare HDMI monitor and USB keyboard it's not too difficult to get back in, but it's a hassle without these laying around.
I also tested a USB-KVM style solution: I used a mini HDMI adapter connected to an inexpensive USB capture card which let me view the console in OBS Studio. I used a regular keyboard to enter commands, but I also discovered there are "RS232 USB HID emulators" which are DE-9 serial on one end and USB on the other, allowing one to type characters into a serial session (e.g. PuTTY) and have them pop out the other end as an emulated USB keyboard. I didn't end up testing this, but in theory it would give you a basic KVM or crash cart style setup to get back into the Pi. The total price would have been around $40-50, much less than a real USB KVM like the Startech Notecons01. [0]
Another idea is to use a power brick with pass-through charging. Many good Anker batteries support this and some of them are the size of the Pi - so one could easily setup a long lasting UPS for the Pi for $30-40. At around 2.5 watts idling, a 10,000 mAh battery should easily give 6-8 hours of charge which should be enough to survive brief outages and prevent an unclean shutdown. A basic USB-C charging meter will show the Pi's power draw as well.
Other than that, the next best thing is to mount as much of the system read-only as possible to help reduce the chances of needing to fsck.
FWIW, I'm using a basic Apacer 32GB microSD card and haven't had any issues with failed writes or endurance or anything like that.
Eh I thought so. Mitigating a software problem in hardware (while Linux doesn't have this problem) feels like a step backward. I absolutely adore OpenBSD, but the file system is its weakest point.
accrual · 2d ago
> What's your experience with OpenBSD on RasPi4 specifically
Power loss and single user mode complications aside, OpenBSD 7.7 runs fantastic on the Pi 4. It feels no different from a standard AMD64 install for most tasks. I haven't used the GPIO pins under OpenBSD but it otherwise works like any other system. :)
accrual · 4d ago
Congrats on another release, OpenBSD team!
I'm happily using OpenBSD as my core router, my Minecraft server, a laptop OS, and on my retro PCs. Currently updating my Raspberry Pi 4 to 7.7 as well.
NoWordsKotoba · 4d ago
I haven't used OpenBSD since the 3.x days, but I did dearly love it at the time. I'm so glad they're still working on it.
rubyfan · 4d ago
me too, it was an amazing experience that I still compare to current options and long for its simplicity.
No comments yet
anyfoo · 4d ago
Still use it for my “home server” and a few others, still love it!
I’m actually genuinely excited when a new version comes out, taking time to read the changelog.
jmclnx · 4d ago
Congratulations, my upgrades start tomorrow or maybe the next day I am sure all will go well and easy.
ksec · 4d ago
Wondering how it compares to FreeBSD in terms of performance. OpenBSD used to be slower but in the past 3-4 years there were bunch of optimisations landed.
I guess I will have to wait for another phoronix benchmarks.
ninjin · 4d ago
I think it depends greatly on your use case. Mine has been OpenBSD on a bare-metal server, VPS, old laptop (N3540), and underpowered desktop (x7425E). For day-to-day desktop work, even the old laptop keeps up and the underpowered desktop feels snappy at most times.
You might think that OpenBSD on its own incurs a massive performance hit (at least I used to think that), but when I compared it against Alpine Linux on that underpowered desktop it was really not different enough for say video playback/encoding that I could tell much of a difference. Yes, OpenBSD is slower, but I would guess the margin is maybe 5% which is certainly not what I expected. Maybe for other workloads it is very different from my experience, but I am a user and not expert benchmarker so I can not give a better answer.
Where there is a difference is when you have multiple jobs hitting syscalls hard. Say, heavy disk access. On Linux this will not cause your cursor to freeze momentarily, delay the launch of other programs, or your audio playback to halt or distort, but on OpenBSD this happens even on something as powerful as a 3950X when I tried it. I am not enough of a kernel hacker to tell exactly what the issue is, but I suspect it is that OpenBSD's kernel has very limited preemption. This is not great, but it is not enough of an annoyance to deter me from using it on some of my desktops.
Other than the above, the experience of maintaining a server or desktop with OpenBSD is amazing. Top-notch documentation, everything is a flag in rc.conf.local or text file in /etc, and the base system is capable enough to run all the services I need and for my other uses ports has me covered. Plus, it gets better with every release. 7.7 comes with massive improvements to the USB video subsystem that has fixed every device I had that previously did not work with OpenBSD.
My annual donations will keep coming, but I wish I was rich enough to fund or good enough of a kernel hacker to work on whatever it is that the kernel needs to address the last few snags and I would happily run OpenBSD on every box I have.
myaccountonhn · 4d ago
7.5 was also quite slow for desktop IME. Maybe the last two releases have sped things up.
What Id love is a journaling file system and extended attributes personally...
wakeywakeywakey · 4d ago
> What Id love is a journaling file system.
Same; that would really improve the remote router scenario. I've had a router refuse to boot up after a power outage until I manually ran a disk check. I'd like to at least be able to force start-up no matter what, but journaling is the proper fix.
accrual · 4d ago
Agreed! I think the only other solution (at present) is to mount as much of the system read-only as possible to minimize the risk of needing to `fsck` after an unclean shutdown. That and putting it behind a UPS, but of course that only lasts so many hours.
> This repository will be abandoned once Linux or FreeBSD is stabilized with write support. OpenBSD is not the main area of interest.
This doesn't inspire confidence. OpenBSD is famous for how well the base system is integrated (even compared to other BSDs). I wouldn't trust base's stability to an arbitrary set of patches.
myst · 4d ago
What’s your use case?
bangonkeyboard · 4d ago
A note to myself for future upgrades, from the upgrade guide:
• Check available disk space in /usr. Verify that the /usr partition has a size of at least 1.1G. With less space the upgrade may fail and you should consider reinstalling the system instead.
When this says "available disk space," it means "total" disk space of the /usr partition, not "free" space. I had less than 1.1GB of unused free space on /usr and had to verify that that was fine before proceeding.
I had 6.7 running on 32MB of RAM recently. I'll have to give 7.7 a try. ;)
fsiefken · 3d ago
yes, with the latest linux kernel it's not really possible, even though gpt4o mentioned it might be possible if you hand compile the kernel, leave out all the modules and strip out everything you don't strictly need so there's some memory left for something like busybox.
At that point it'd be cheaper/easier to arrange 64 Mbyte of RAM in the old pentiums. With Raspberry Pi's having 4 GB these day it'll be perhaps just be a painful exercise.
https://www.openbsd.org/images/LifeOfAFish.png
https://www.openbsd.org/images/puffy77.gif
t-shirts, hoodies, stickers on openbsdstore.com
[0] https://www.openbsd.org/papers/asiabsdcon2009-release_engine...
https://www.youtube.com/watch?v=i7pkyDUX5uM
* On 7.5 the built-in `bwmf0` was not detected
* On 7.6 `bwmf0` was detected and works great, even in AP mode. However, my latest Node project core dumped when running `npm install` and nothing I tried got it working (short of recompiling Node)
* On 7.7 (today's release) `npm install` is working perfect
Not worth an entire blog post, but just goes to show improvements in OpenBSD over time on the Pi 4 :)
Mine hosts a LAN using the built-in wireless adapter (bwmf0) so it's easy to SSH in, but if it's stuck in single user mode, this doesn't work.
With a spare HDMI monitor and USB keyboard it's not too difficult to get back in, but it's a hassle without these laying around.
I also tested a USB-KVM style solution: I used a mini HDMI adapter connected to an inexpensive USB capture card which let me view the console in OBS Studio. I used a regular keyboard to enter commands, but I also discovered there are "RS232 USB HID emulators" which are DE-9 serial on one end and USB on the other, allowing one to type characters into a serial session (e.g. PuTTY) and have them pop out the other end as an emulated USB keyboard. I didn't end up testing this, but in theory it would give you a basic KVM or crash cart style setup to get back into the Pi. The total price would have been around $40-50, much less than a real USB KVM like the Startech Notecons01. [0]
Another idea is to use a power brick with pass-through charging. Many good Anker batteries support this and some of them are the size of the Pi - so one could easily setup a long lasting UPS for the Pi for $30-40. At around 2.5 watts idling, a 10,000 mAh battery should easily give 6-8 hours of charge which should be enough to survive brief outages and prevent an unclean shutdown. A basic USB-C charging meter will show the Pi's power draw as well.
Other than that, the next best thing is to mount as much of the system read-only as possible to help reduce the chances of needing to fsck.
FWIW, I'm using a basic Apacer 32GB microSD card and haven't had any issues with failed writes or endurance or anything like that.
[0] https://www.startech.com/en-us/server-management/notecons01
Power loss and single user mode complications aside, OpenBSD 7.7 runs fantastic on the Pi 4. It feels no different from a standard AMD64 install for most tasks. I haven't used the GPIO pins under OpenBSD but it otherwise works like any other system. :)
I'm happily using OpenBSD as my core router, my Minecraft server, a laptop OS, and on my retro PCs. Currently updating my Raspberry Pi 4 to 7.7 as well.
No comments yet
I’m actually genuinely excited when a new version comes out, taking time to read the changelog.
I guess I will have to wait for another phoronix benchmarks.
You might think that OpenBSD on its own incurs a massive performance hit (at least I used to think that), but when I compared it against Alpine Linux on that underpowered desktop it was really not different enough for say video playback/encoding that I could tell much of a difference. Yes, OpenBSD is slower, but I would guess the margin is maybe 5% which is certainly not what I expected. Maybe for other workloads it is very different from my experience, but I am a user and not expert benchmarker so I can not give a better answer.
Where there is a difference is when you have multiple jobs hitting syscalls hard. Say, heavy disk access. On Linux this will not cause your cursor to freeze momentarily, delay the launch of other programs, or your audio playback to halt or distort, but on OpenBSD this happens even on something as powerful as a 3950X when I tried it. I am not enough of a kernel hacker to tell exactly what the issue is, but I suspect it is that OpenBSD's kernel has very limited preemption. This is not great, but it is not enough of an annoyance to deter me from using it on some of my desktops.
Other than the above, the experience of maintaining a server or desktop with OpenBSD is amazing. Top-notch documentation, everything is a flag in rc.conf.local or text file in /etc, and the base system is capable enough to run all the services I need and for my other uses ports has me covered. Plus, it gets better with every release. 7.7 comes with massive improvements to the USB video subsystem that has fixed every device I had that previously did not work with OpenBSD.
My annual donations will keep coming, but I wish I was rich enough to fund or good enough of a kernel hacker to work on whatever it is that the kernel needs to address the last few snags and I would happily run OpenBSD on every box I have.
What Id love is a journaling file system and extended attributes personally...
Same; that would really improve the remote router scenario. I've had a router refuse to boot up after a power outage until I manually ran a disk check. I'd like to at least be able to force start-up no matter what, but journaling is the proper fix.
https://github.com/kusumi/makefs
Maybe? As a starting point?
This doesn't inspire confidence. OpenBSD is famous for how well the base system is integrated (even compared to other BSDs). I wouldn't trust base's stability to an arbitrary set of patches.
• Check available disk space in /usr. Verify that the /usr partition has a size of at least 1.1G. With less space the upgrade may fail and you should consider reinstalling the system instead.
When this says "available disk space," it means "total" disk space of the /usr partition, not "free" space. I had less than 1.1GB of unused free space on /usr and had to verify that that was fine before proceeding.
https://www.openbsd.org/lyrics.html
At that point it'd be cheaper/easier to arrange 64 Mbyte of RAM in the old pentiums. With Raspberry Pi's having 4 GB these day it'll be perhaps just be a painful exercise.