OpenBSD 7.7 released with updated hardware support, 9Front ships second update of 2025

Fresh from their respective bunkers, OpenBSD 7.7 and a new version of Plan 9 fork 9Front have dropped, bringing hardened security, obscure charm, and, oddly enough, artwork from the same designer. OpenBSD 7.7's striking cover art by Tomáš Rodr OpenBSD 7.7's striking cover art, copyright Tomáš Rodr - click to enlarge OpenBSD …

[thames]

No problems so far

I installed OpenBSD 7.7 in a KVM VM on Sunday evening when it came out. I use it in a testing environment, running a series of automated tests alongside a dozen other targets. I have had no problems with it so far, it worked just like 7.6 except for updated packages.

[BinkyTheMagicPaperclip]

Upgrades are always welcome

So easy to apply with sysupgrade too - type command, make cup of tea, done!

I might have to revisit the wireless capability, as last time I checked (a few years now) it was rather spotty. I had issues running OpenBSD as an access point, and eventually gave up and bought a dedicated AP (which mostly worked much better, but not entirely, because one particular mobile has abysmal wireless capability and was actually more stable under the older OpenBSD chipset I was using. Every thing else was far faster on the new AP.)

It'd be nice to have a more modern file system in OpenBSD, but as I generally use it on firewalls it hasn't been much of an issue. One grubby little secret of FreeBSD is that ZFS isn't actually completely resilient - mirrored swap in particular can fail under low memory conditions. The workarounds are either don't mirror your swap (stupid), or use gmirror to mirror it. However gmirror needs to be set up from the command line - particularly on a modern UEFI system. You should also allocate an EFI partition considerably in excess of 1M (suggested by one guide online), I just selected 1G to be sure. Mirror the EFI partition or don't stick it in fstab, otherwise your install won't actually be resilient on reboot!

I've also had a crash in FreeBSD's disk driver take out my ZFS on root mirror, requiring recovery from install media. Not difficult to do, and it only happened once, but it's still a little concerning.

[idoak]

Re. OpenBSD's partitioning scheme

OpenBSD was the second OS I tried afted I'd decided to leave Windows behind, way back in 2004 (the first was RedHat, which was, and remains, unsavoury).

Getting used to BSD labels ('slices' in FreeBSD parlance) did take a bit of effort, IIRC, but, really, it's not that complicated. On x86 it's actually quite convenient if you're dual-booting from the same disk, since everything is contained in a single primary partition.

[Liam Proven]

Re: Re. OpenBSD's partitioning scheme

> Getting used to BSD labels ('slices' in FreeBSD parlance) did take a bit of effort, IIRC, but, really, it's not that complicated.

I will take your word for it, but still, this is sort of missing the main point here.

Last time around, I enumerated them. There were 9 volumes in the default install:

https://www.theregister.com/2024/10/10/version_76_openbsd_of_theseus/

And as I mentioned 3 years ago:

https://www.theregister.com/2022/04/22/openbsd_71_released_including_apple/

... that means that given a 16GB virtual drive, just installing the relatively small Xfce desktop left insufficient room to install Firefox.

_That_ is the problem here. I need to foresee the future, correctly predict what I will install someday and how much space it will take where.

I lack the gift of precise precognition so I can't. Result: problem. You can't reassign this stuff by dragging a slider in Gparted as if it were Linux.

25+ years ago, the proprietary Unixes were getting LVM, where you can resize volumes on the fly and the OS reallocates the underlying disk blocks for you. Today, in Linux, LVM is needlessly overcomplicated, overlaps significantly with the functionality of tools such as Btrfs, OpenZFS, bcachefs etc., and to an approximation the only people using it are those who want full-disk encryption via LUKS, poor schmucks.

But on OpenBSD the core LVM functionality would be a big win. Here's a dollop of disk space, divide it into a dozen subvolumes if you want, some executable, some writable, some modifiable, some SUID-able, whatever -- but adjust usage as you need, on the fly, as I install stuff, so that nothing ever goes over 75% used.

As it is today, you can't. You just need knowledge, judgement, and the patience to reinstall your OS repeatedly until you know what you will need.

[thames]

Re: Re. OpenBSD's partitioning scheme

I get the impression that most OpenBSD users are using it as an appliance-like server. They set it up to do one thing and it just does that one thing. They interact with it on occasion via SSH. In a minimal install It doesn't seem to get a lot of updates, so it's fairly painless from a maintenance perspective. As a result of this, there probably isn't a lot of pressure to change the file system compared to other things that may be on the "to do" list.

[BinkyTheMagicPaperclip]

Re: Re. OpenBSD's partitioning scheme

Pretty much. I love OpenBSD but it's not a great desktop, and the OpenBSD team have, and will continue to, put security before everything else. That's moderately fine in an appliance, less so for a desktop.

If you stick to the functionality purely in base and don't use anything really obscure you're unlikely to run into many issues.

OpenBSD is a lot better as a desktop than it used to be - you've got the usual browser, Libreoffice, and moderately decent graphics chipset support. vmm allows for other OS to be virtualised - but with no graphics, so that's a tad limiting. WINE is a complete non starter (it's also not great under FreeBSD - Linux's API coverage is an order of magnitude better).

There's been a lot of ongoing grumbling about the file system, but OpenBSD are very strict about licensing (which is why ZFS isn't on there), and are also generally pretty conservative. It's the only BSD where I would be happy to run -current.

[Brave Coward]

Re: Re. OpenBSD's partitioning scheme

@Liam,

May I respectfully ask you why people wanting full-disk encryption via LUKS are fully entitled to be called 'poor schmucks'?

[Altrux]

Re: Re. OpenBSD's partitioning scheme

I've used LUKS for many years, on my /home partition, and never had an issue. It's generally setup post-install, certainly on Ubuntu, but I use a 'stub' /home in the root partition to do the OS installation, then map in the encrypted home partition later on. This means if you ever lose/break the encrypted /home, you can at least still boot and login to the machine without it complaining about a missing /home dir.

[Missing Semicolon]

Re: Re. OpenBSD's partitioning scheme

All of my laptops, being subject to the possibility of being left somewhere, use the installer's default LVM/LUKs encryption scheme. How else would you secure them?

[Liam Proven]

Re: Re. OpenBSD's partitioning scheme

> May I respectfully ask you why people wanting full-disk encryption via LUKS are fully entitled to be called 'poor schmucks'?

Second try -- my browser ate my 1st.

Well, on one hand, I went for the cheap laugh of the rhyme.

But on the other, this is my view of the value of encryption:

https://xkcd.com/538/

I have seen so many posts from people who want to recover data but have lost the passwords, or their disk is dying, or they just want to adjust the disk layout, but they can't because it's encrypted.

I do not encrypt anything and turn it off wherever I can.

The safe smart way, if someone must, is to have a separate `/home` and encrypt only that. This reduces the impact ob performance and there's a chance you can still use your computer to some limited extent in the event of a failure.

Any encryption system which requires the flaming dumpster of LVM2 can be thrown into the fire and incinerated.

[BinkyTheMagicPaperclip]

Re: Re. OpenBSD's partitioning scheme

As I understand it the issue with only encrypting one partition is it provides a greater attack surface to be able to decrypt your given example of /home. Also, there's the possibility of unwanted data leaking into swap or possibly other files in non /home partitions.

Otherwise though, I tend to agree with your xkcd view. I tried using full disc encryption on OpenBSD and it works brilliantly, and is very straightforward to set up. Problem is it does come with a noticeable performance penalty, and makes sharing the disk with other operating systems impossible. Also, whilst work has statutory and contractual requirements to ensure data is kept secure and encrypted, I'm not kidding myself that anyone really wants to see a lot of technical stuff and many cat pictures on my personal laptop. I backed up my data to a non encrypted USB stick, re-installed without, and have never needed to revisit it again.

[Liam Proven]

Re: Re. OpenBSD's partitioning scheme

> there's the possibility of unwanted data leaking into swap or possibly other files in non /home partitions.

Yes, there is, but really, seriously, who among us is important enough to anyone else that _anyone_ is going to go to those lengths?

There is a Singaporean chap that haunts various Linux mailing lists who has named himself after a jelllyfish. He thinks the Singaporean government is spying on him, injecting malware into all his devices, and in his desperation to avoid it, he lashes together Byzantine combinations of poorly-chosen FOSS.

But he is, I am afraid, suffering paranoid schizophrenia or something.

We are not spies. We are not billionaires. _Nobody cares that much_. Most of us only have a moderate swap file these days when affordable single-user PCs have double-digit numbers of gigs of RAM and it's affordable to have _terabytes of RAM_.

A 2GB swapfile is an insane amount of plaintext and nobody cares enough to go through the output.

I worked for a large Linux vendor who insisted on FDE on all workers' laptops. I wrote docs, FFS, and the docs' source code WERE HOSTED ON GITHUB.

Nobody is going run l0phtcrack or whatever to find my password when everything I do is public anyway. But my machine's performance was slowed from SSD to HDD level because of corporate paranoia.

Sorry to break it to you, but *nobody cares*.

Unless you are important enough to have bodyguards, nobody cares enough about you to hit you with a $5 wrench for your passwords. They don't. Get over yourself. Let it go.

If someone is important to have bodyguards, then the sad news is, they use Macs or more likely iPads and it's all irrelevant anyway.

Spend the effort on making the desktop Mac-level in polish and stop pissing about with bloody encryption.

[K555]

Re: Re. OpenBSD's partitioning scheme

>> But on the other, this is my view of the value of encryption: https://xkcd.com/538/

If someone wants to take my car they can break into my house and take my car keys off the hook. So I'll just leave them in the ignition.

My takeaway from the cartoon is to remember that all security is fallible and the exploitable link will be usually be the squishy bit with opposable thumbs. However, it's not a single point that negates the value of encryption.

Awkwardness is key. If my work laptop goes walkies, by far the highest probability is that it's some opportunistic scally who's made off with it and is really not going to escalate to GBH and torture so they can read my e-mails. And the fact that it's encrypted means I don't have to spend any time racking my brain as to weather I had managed to leave something sensitive on there that I shouldn't have (and I firmly believe it should be both encrypted and treated like it's NOT encrypted) or getting paranoid and having to spend weeks on due diligence in case some customer data made it out there. Get a new laptop, move along.

>> I have seen so many posts from people who want to recover data but have lost the passwords, or their disk is dying

The problem here is not encryption.

[Matt Dainty]

Re: Re. OpenBSD's partitioning scheme

You can float the idea to Theo, just don your asbestos underpants beforehand.

[idoak]

Re: Re. OpenBSD's partitioning scheme

I dig ya.

I ran into similar sort of problems when I had OpenBSD on my main laptop for some years (eventually it was hardware support that nudged me on to Linux).

Like others have said here, on server(ish) machines this is less of an issue, and nobody uses the default scheme offered by the installer (which seems to cater to developers' needs more thsn anyone else). I suppose it's just not very high on the todo list.

[An_Old_Dog]

Re: Re. OpenBSD's partitioning scheme

First, an analogy:

1. Customer: "Why doesn't this Formula One race car have automatic transmission, a spare tire, six seats, an audio/video entertainment system, a GPS map display, air conditioning, power windows, and a 20-gallon saddle tank?! I want all that stuff!"

2. Dealer: "We could add those features at additional cost, and the customizations will extend the required delivery time. Might I suggest you consider the Cadillac Escalade, which already has these features?"

3. Customer: "No. I want the F1 racer, with the stuff I said."

4. Dealer: "As you wish."

5. Much-later, the customer drives his shiny-new, heavily-modified F1 racer onto the track, and stomps the throttle. The car slowly accelerates down the track.

6. Customer: (angrily) "Why is this car so godamned-slow?!"

Second, a more-technical answer:

1. I don't personally know how LVM works, but I presume it allocates blocks out of a common pool and links them in to/unlinks them from the various logical volumes as requested by the user. This increases the randomisation of block locations within a given logical volume, which increases the average number of seeks (head movement required) needed to access a particular block, which increases the access time.

You may say, "But MY system has an SSD! It has no moving heads!" Fine; see points 2 and 3, below.

2. OpenBSD is not targetted at desktop users. It is targetted at a wide range of systems, from development boards to data centres. Dev boards frequently do not have video framebuffers, just serial ports. And, there are petabytes of data which reside on moving-head discs, vs on SSDs.

3. If you want to be fast-and-dirty on your desktop install, you could create just two partitions, '/' and '/home'.

4. "You just need knowledge, judgement, and the patience to reinstall your OS repeatedly until you know what you will need."

This is true. See point 2 above.

[Liam Proven]

Re: Re. OpenBSD's partitioning scheme

> Second, a more-technical answer:

The thing is that you are mixing up, not only your metaphors but your tech levels.

LVM was a solved problem in the 20th century. Unix OSes that were 1% the size of OpenBSD 7.7 did LVM, and they did it on mid-1990s hardware whose performance was outdone by the lowest level of elderly kit OpenBSD supports today -- and that is pretty damned elderly.

_This is not hard_.

It's not bells and whistles. It's not luxury features that don't belong in a sportscar.

It's ABS or traction control. It's a basic and by now easy feature that if fitted to the sportscar _makes it go faster and handle better_ DESPITE the extra weight.

It's also an excellent opportunity to show that a very simple easy implementation of LVM does not need the bloat and complexity of ZFS, let alone Linux LVM2.

OpenBSD pursues simplicity and correctness, but it ignores vitally important lessons of simplicity and correctness which _already exist in the wider Unix family_.

For instance, the ruthless simplicity of Plan 9.

Example -- make a simple rule: you can't #include a file that #includes other files. You have a one-time cost of going through your source tree looking for duplication and in return you get a compiler that can run _3 orders of magnitude_ faster.

OpenBSD is amazing at what it does, but the truth is that there are other projects in the same greater family tree which achieve order-of-magnitude reductions in code size or improvements in execution speed, because they do things that are more radical than even the radical people behind OpenBSD will consider.

Which is one of two reasons I wrote about OpenBSD and 9front together here.

1: the new filesystem in 9front was designed by someone who aspires to get it into OpenBSD as well.

2: the same artist did the cover art for both.

I wanted to draw 2 lines connecting these two data points, because two lines can delineate a shape or an area, which means the coverage of things included are a power greater: it's not twice as big, it's to the power of 2 bigger.

Forget *2. Think about ^2.

[Sudosu]

I often wonder

Why many governments do not run an OS like OpenBSD as it is far more secure than many of the alternatives, especially for basic workload types.

I use it for my WordPress sites (moved from Ubuntu a while back) as I had some upgrade issues with Ubuntu over the years.

I have been contemplating moving from my Exchange server to OpenSMTPD on OpenBSD but it is a big switch, so I have been procrastinating.

[Liam Proven]

Re: I often wonder

> Why many governments do not run an OS like OpenBSD

Because they are barely competent to run RHEL with a techie there to deploy it for them?

[NickHolland]

Re: I often wonder

Security is everyone's top priority ... second to only everything else (i.e., absolute last place). They won't adjust anything in their decision and selection process if it means moving away from the bells and whistles they want, or are used to, or learned ten years ago.

Governments are even worse than businesses in that regard. Not their data, not there benefit, not their money, no consequences. ZERO motivation to do things well.

As for moving Exchange to ... well, anything, be aware your users will protest. They also want Security only if it means no change to anything. And as mediocre of an e-mail and calendar system Outlook/Exchange is...it's what people are used to.