NOTES
This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon

Headlines

OpenBSD is the Perfect OS post Nuclear Apocalypse

Multiprocess support for LLDB

News Roundup

I ported the new Hare compiler to OpenBSD

Writing my first OpenBSD game using Godot

FreeBSD 13 on Thinkpad T460s

Beastie Bits

Open Source Voices interview with Deb Goodkin
Tachyum Successfully Runs FreeBSD in Prodigy Ecosystem, Expands Open-Source OS Support
MidnightBSD Minor Update 2.1.7
LibreSSL 3.5.2 Released
OpenBGPD 7.3 is out
Playing the game Bottomless on OpenBSD
Windows Central: OpenBSD already has a version for Apple Silicon
OpenBSD Webzine #9 is out
In the "Everone makes mistakes catagory" : I forgot to enable compression on ZFS
"Ken Thompson is a singularity" ~Brian Kernighan

Tarsnap

• This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups.

Feedback/Questions

• Ben - Securing FreeBSD

• Dave - BSD certifications

• Sam - maintaining a port

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv ***

NOTES
This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon

Headlines

Restoring a Tadpole SPARCbook 3 Part 1: Introduction

The FreeBSD Boot Process

News Roundup

Debugging an ioctl Problem on OpenBSD

Why my game PC runs FreeBSD and Kubuntu

DNSSEC, Badgers, and Orcs, Oh My!

Beastie Bits

• [LibreSSL 3.5.0 development branch released](https://undeadly.org/cgi?action=article;sid=20220301063844)
• [OpenSSH updated to 8.9](https://undeadly.org/cgi?action=article;sid=20220301063428)
• [Recent developments in OpenBSD, 2022-02-21 summary](https://undeadly.org/cgi?action=article;sid=20220221060700)

Tarsnap

• This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups.

Feedback/Questions

Jonathan - X-Wing and Tie Fighter
Joshontech - pool options

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv ***

NOTES
This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon

Headlines

Using FreeBSD’s pkg-audit

The 20 year old bug that went to Mars

It's rare that you come across a bug so subtle that it can last for two decades. But, that's exactly what has happened with the Lempel-Ziv-Oberhumer (LZO) algorithm. Initially written in 1994, Markus Oberhumer designed a sophisticated and extremely efficient compression algorithm so elegant and well architected that it outperforms zlib and bzip by four or five times their decompression speed.

I was impressed to find out that his LZO algorithm has gone to the planet Mars on NASA devices multiple times! Most recently, LZO has touched down on the red planet within the Mars Curiosity Rover, which just celebrated its first martian anniversary on Tuesday.

In the past few years, LZO has gained traction in file systems as well. LZO can be used in the Linux kernel within btrfs, squashfs, jffs2, and ubifs. A recent variant of the algorithm, LZ4, is used for compression in ZFS for Solaris, Illumos, and FreeBSD.

With its popularity increasing, Lempel-Ziv-Oberhumer has been rewritten by many engineering firms for both closed and open systems. These rewrites, however, have always been based on Oberhumer's core open source implementation. As a result, they all inherited a subtle integer overflow. Even LZ4 has the same exact bug, but changed very slightly.

Because the LZO algorithm is considered a library function, each specific implementation must be evaluated for risk, regardless of whether the algorithm used has been patched. Why? We are talking about code that has existed in the wild for two decades. The scope of this algorithm touches everything from embedded microcontrollers on the Mars Rover, mainframe operating systems, modern day desktops, and mobile phones. Engineers that have used LZO must evaluate the use case to identify whether or not the implementation is vulnerable, and in what format.

News Roundup

FreeBSD on Slimbook -- 14 months of updates

LLDB FreeBSD kernel core dump support

Steam on OpenBSD

Beastie Bits

• [OpenSSH Agent Restriction](http://undeadly.org/cgi?action=article;sid=20211220061017)
• [OpenBSD’s Clang upgraded to version 13](http://undeadly.org/cgi?action=article;sid=20211220060327)
• [Cool, but obscure X11 tools](http://cyber.dabamos.de/unix/x11/)

Tarsnap

• This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups.

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv

  ---

NOTES
This episode of BSDNow is brought to you by Tarsnap and the BSDNow Patreon

Interview - Solene Rapenne - solene+www@dataswamp.org / [@solene@bsd.network](@solene@bsd.network (mastodon))

https://dataswamp.org/~solene/2021-07-26-old-computer-challenge-after.html

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv ***

Special Guest: Solène Rapenne.

NOTES
This episode of BSDNow is brought to you by Tarsnap

Headlines

TrueNAS is Multi-OS

There was a time in history where all that mattered was an Operating System (OS) and the hardware it ran on — the “pre-software era”, if you will. Your hardware dictated the OS you used.
Once software applications became prominent, your hardware’s OS determined the applications you could run. Application vendors were forced to juggle the burden of “portability” between OS platforms, choosing carefully the operating systems they’d develop their software to. Then, there were the great OS Wars of the 1990s, replete with the rampant competition, licensing battles, and nasty lawsuits, which more or less gave birth to the “open source OS” era.
The advent of the hypervisor simultaneously gave way to the “virtual era” which set us on a path of agnosticism toward the OS. Instead of choosing from the applications available for your chosen OS, you could simply install another OS on the same hardware for your chosen application. The OS became nothing but a necessary cog in the stack.
TrueNAS open storage enables this “post-OS era” with support for storage clients of all UNIX flavors, Linux, FreeBSD, Windows, MacOS, VMware, Citrix, and many others. Containerization has carried that mentality even further. An operating system, like the hardware that runs it, is now just thought of as part of the “infrastructure”.

---

Encrypted ZFS on NetBSD 9.0, for a FreeBSD guy

I had one of my other HP Microservers brought back from the office last week to help with this working-from-home world we’re in right now. I was going to wipe an old version of Debian Wheezy/Xen and install FreeBSD to mirror my other machines before thinking: why not NetBSD?

---

News Roundup

FreeBSD's New Code of Conduct

• FreeBSD Announcement Email

Gaming on OpenBSD

While no one would expect this, there are huge efforts from a small team to bring more games into OpenBSD. In fact, now some commercial games works natively now, thanks to Mono or Java. There are no wine or linux emulation layer in OpenBSD.
Here is a small list of most well known games that run on OpenBSD:

---

'dig' a little deeper

I knew the existence of the dig command but didn't exactly know when and how to use it. Then, just recently I encountered an issue that allowed me to learn and make use of it.

---

HAMMER2 and periodic snapshots

The first version of HAMMER took automatic snapshots, set within the config for each filesystem. HAMMER2 now also takes automatic snapshots, via periodic(8) like most every repeating task on your DragonFly system.

• git: Implement periodic hammer2 snapshots ***

Tarsnap

• This weeks episode of BSDNow was sponsored by our friends at Tarsnap, the only secure online backup you can trust your data to. Even paranoids need backups.

Feedback/Questions

• Cy - OpenSSL relicensing
• Christian - lagg vlans and iocage
• Brad - SMR ***
• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv ***

Headlines

DragonFlyBSD's Kernel Optimizations Are Paying Off

DragonFlyBSD lead developer Matthew Dillon has been working on a big VM rework in the name of performance and other kernel improvements recently. Here is a look at how those DragonFlyBSD 5.5-DEVELOPMENT improvements are paying off compared to DragonFlyBSD 5.4 as well as FreeBSD 12 and five Linux distribution releases. With Dillon using an AMD Ryzen Threadripper system, we used that too for this round of BSD vs. Linux performance benchmarks.
The work by Dillon on the VM overhaul and other changes (including more HAMMER2 file-system work) will ultimately culminate with the DragonFlyBSD 5.6 release (well, unless he opts for DragonFlyBSD 6.0 or so). These are benchmarks of the latest DragonFlyBSD 5.5-DEVELOPMENT daily ISO as of this week benchmarked across DragonFlyBSD 5.4.3 stable, FreeBSD 12.0, Ubuntu 19.04, Red Hat Enterprise Linux 8.0, Debian 9.9, Debian Buster, and CentOS 7 1810 as a wide variety of reference points both from newer and older Linux distributions. (As for no Clear Linux reference point for a speedy reference point, it currently has a regression with AMD + Samsung NVMe SSD support on some hardware, including this box, prohibiting the drive from coming up due to a presumed power management issue that is still being resolved.)
With Matthew Dillon doing much of his development on an AMD Ryzen Threadripper system after he last year proclaimed the greatness of these AMD HEDT CPUs, for this round of testing I also used a Ryzen Threadripper 2990WX with 32 cores / 64 threads. Tests of other AMD/Intel hardware with DragonFlyBSD will come as the next stable release is near and all of the kernel work has settled down. For now it's mostly entertaining our own curiosity how well these DragonFlyBSD optimizations are paying off and how it's increasing the competition against FreeBSD 12 and Linux distributions.

---

What are the differences between OpenBSD and Linux?

Maybe you have been reading recently about the release of OpenBSD 6.5 and wonder, "What are the differences between Linux and OpenBSD?"
I've also been there at some point in the past and these are my conclusions.
They also apply, to some extent, to other BSDs. However, an important disclaimer applies to this article.
This list is aimed at people who are used to Linux and are curious about OpenBSD. It is written to highlight the most important changes from their perspective, not the absolute most important changes from a technical standpoint.
Please bear with me.

• A terminal is a terminal is a terminal
• Practical differences
• Security and system administration
• Why philosophical differences matter
• So what do I choose?
• How to try OpenBSD ***

News Roundup

NetBSD 2019 Google Summer of Code

We are very happy to announce The NetBSD Foundation Google Summer of Code 2019 projects:

• Akul Abhilash Pillai - Adapting TriforceAFL for NetBSD kernel fuzzing
• Manikishan Ghantasala - Add KNF (NetBSD style) clang-format configuration
• Siddharth Muralee - Enhancing Syzkaller support for NetBSD
• Surya P - Implementation of COMPAT_LINUX and COMPAT_NETBSD32 DRM ioctls support for NetBSD kernel
• Jason High - Incorporation of Argon2 Password Hashing Algorithm into NetBSD
• Saurav Prakash - Porting NetBSD to HummingBoard Pulse
• Naveen Narayanan - Porting WINE to amd64 architecture on NetBSD

The communiting bonding period - where students get in touch with mentors and community - started yesterday. The coding period will start from May 27 until August 19.
Please welcome all our students and a big good luck to students and mentors! A big thank to Google and The NetBSD Foundation organization mentors and administrators! Looking forward to a great Google Summer of Code!

Reducing that contention

The opening keynote at EuroBSDCon 2016 predicted the future 10 years of BSDs. Amongst all the funny previsions, gnn@FreeBSD said that by 2026 OpenBSD will have its first implementation of SMP. Almost 3 years after this talk, that sounds like a plausible forecast... Why? Where are we? What can we do? Let's dive into the issue!

• State of affairs

Most of OpenBSD's kernel still runs under a single lock, ze KERNEL_LOCK(). That includes most of the syscalls, most of the interrupt handlers and most of the fault handlers. Most of them, not all of them. Meaning we have collected & fixed bugs while setting up infrastructures and examples. Now this lock remains the principal responsible for the spin % you can observe in top(1) and systat(1).
I believe that we opted for a difficult hike when we decided to start removing this lock from the bottom. As a result many SCSI & Network interrupt handlers as well as all Audio & USB ones can be executed without big lock. On the other hand very few syscalls are already or almost ready to be unlocked, as we incorrectly say. This explains why basic primitives like tsleep(9), csignal() and selwakeup() are only receiving attention now that the top of the Network Stack is running (mostly) without big lock.

• Next steps

In the past years, most of our efforts have been invested into the Network Stack. As I already mentioned it should be ready to be parallelized. However think we should now concentrate on removing the KERNEL_LOCK(), even if the code paths aren't performance critical.

• See the Article for the rest of the post

fnaify 1.3 released - more games are "fnaify & run" now

This release finally addresses some of the problems that prevent simple running of several games.
This happens for example when an old FNA.dll library comes with the games that doesn't match the API of our native libraries like SDL2, OpenAL, or MojoShader anymore. Some of those cases can be fixed by simply dropping in a newer FNA.dll. fnaify now asks if FNA 17.12 should be automatically added if a known incompatible FNA version is found. You simply answer yes or no.

Another blocker happens when the game expects to check the SteamAPI - either from a running Steam process, or a bundled steam_api library. OpenBSD 6.5-current now has steamworks-nosteam in ports, a stub library for Steamworks.NET that prevents games from crashing simply because an API function isn't found. The repo is here. fnaify now finds this library in /usr/local/share/steamstubs and uses it instead of the bundled (full) Steamworks.NET.dll.
This may help with any games that use this layer to interact with the SteamAPI, mostly those that can only be obtained via Steam.

vmctl(8): command line syntax changed

The order of the arguments in the create, start, and stop commands of vmctl(8) has been changed to match a commonly expected style. Manual usage or scripting with vmctl must be adjusted to use the new syntax.
For example, the old syntax looked like this:

# vmctl create disk.qcow2 -s 50G

The new syntax specifies the command options before the argument:

# vmctl create -s 50G disk.qcow2

Something that Linux distributions should not do when packaging things

Right now I am a bit unhappy at Fedora for a specific packaging situation, so let me tell you a little story of what I, as a system administrator, would really like distributions to not do.
For reasons beyond the scope of this blog entry, I run a Prometheus and Grafana setup on both my home and office Fedora Linux machines (among other things, it gives me a place to test out various things involving them). When I set this up, I used the official upstream versions of both, because I needed to match what we are running (or would soon be).
Recently, Fedora decided to package Grafana themselves (as a RPM), and they called this RPM package 'grafana'. Since the two different packages are different versions of the same thing as far as package management tools are concerned, Fedora basically took over the 'grafana' package name from Grafana. This caused my systems to offer to upgrade me from the Grafana.com 'grafana-6.1.5-1' package to the Fedora 'grafana-6.1.6-1.fc29' one, which I actually did after taking reasonable steps to make sure that the Fedora version of 6.1.6 was compatible with the file layouts and so on from the Grafana version of 6.1.5.
Why is this a problem? It's simple. If you're going to take over a package name from the upstream, you should keep up with the upstream releases. If you take over a package name and don't keep up to date or keep up to date only sporadically, you cause all sorts of heartburn for system administrators who use the package. The least annoying future of this situation is that Fedora has abandoned Grafana at 6.1.6 and I am going to 'upgrade' it with the upstream 6.2.1, which will hopefully be a transparent replacement and not blow up in my face. The most annoying future is that Fedora and Grafana keep ping-ponging versions back and forth, which will make 'dnf upgrade' into a minefield (because it will frequently try to give me a 'grafana' upgrade that I don't want and that would be dangerous to accept). And of course this situation turns Fedora version upgrades into their own minefield, since now I risk an upgrade to Fedora 30 actually reverting the 'grafana' package version on me.

---

Beastie Bits

• [talk] ZFS v UFS on APU2 msata SSD with FreeBSD
• NetBSD 8.1 is out
• lazyboi – the laziest possible way to send raw HTTP POST data
• A Keyboard layout that changes by markov frequency
• Open Source Game Clones
• EuroBSDcon program & registration open ***

Feedback/Questions

• John - A segment idea
• Johnny - Audio only format please don't
• Alex - Thanks and some Linux Snaps vs PBI feedback

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv ***

##Headlines
###Assembly language on OpenBSD amd64+arm64

This is a short introduction to assembly language programming on OpenBSD/amd64+arm64. Because of security features in the kernel, I have had to rethink a series of tutorials covering Aarch64 assembly language on OpenBSD, and therefore this will serve as a placeholder-cum-reminder.

OpenBSD, like many UNIX and unix-like operating systems, now uses the Executable and Linkable Format (ELF) for its binary libraries and executables. Although the structure of this format is beyond the scope of this short introduction, it is necessary for me to explain part of one of the headers.

Within the program header there are sections known as PT_NOTE that OpenBSD and other systems use to distinguish their ELF executables - OpenBSD looks for this section to check if it should attempt to execute the program or not.

• Our first program: in C!

It’s often a good idea to prototype your assembly programs in a high level language such as C - it can then double up as both a set of notes and a working program that you can debug and compile into assembly language to compare with your own asm code.

• See the article for the rest on:
• Our first program: in x86-64 Asm (AT&T/GAS syntax)
• Our first program: in inline x86-64 assembly
• Our first program: in x86-64 asm (NASM syntax)
• Our first program: in ARMv8 AArch64 assembly

###Using bhyve for FreeBSD Development

• The Hypervisor

The bhyve hypervisor requires a 64-bit x86 processor with hardware support for virtualization. This requirement allows for a simple, clean hypervisor implementation, but it does require a fairly recent
processor. The current hypervisor requires an Intel processor, but there is an active development branch with support for AMD processors.
The hypervisor itself contains both user and kernel components. The kernel driver is contained in the vmm.ko module and can be loaded either at boot from the boot loader or at runtime. It must
be loaded before any guests can be created. When a guest is created, the kernel driver creates a device file in /dev/vmm which is used by the user programs to interact with the guest.
The primary user component is the bhyve(8) program. It constructs the emulated device tree in the guest and provides the implementation for most of the emulated devices. It also calls the kernel driver to execute the guest. Note that the guest always executes inside the driver itself, so guest execution time in the host is counted as system time in the bhyve process.
Currently, bhyve does not provide a system firmware interface to the guest (neither BIOS nor UEFI). Instead, a user program running on the host is used to perform boot time operations including loading the guest operating system kernel into the guest’s memory and setting the initial guest state so that the guest begins execution at the kernel’s entry point. For FreeBSD guests, the bhyveload(8) program can be used to load the kernel and prepare the guest for execution. Support for some other operating systems is available via the grub2-bhyve program which is available via the sysutils/grub2-bhyve port or as a prebuilt package.
The bhyveload(8) program in FreeBSD 10.0 only supports 64-bit guests. Support for 32-bit guests will be included in FreeBSD 10.1.

• See the article for the very technical breakdown of the following:

• Network Setup

• Bridged Configuration

• Private Network with NAT

• Using dnsmasq with a Private Network

• Running Guests via vmrun.sh

• Configuring Guests

• Using a bhyve Guest as a Target

• Conclusion

The bhyve hypervisor is a nice addition to a FreeBSD developer’s toolbox. Guests can be used both to develop new features and to test merges to stable branches. The hypervisor has a wide variety of uses beyond developing FreeBSD as well.

##News Roundup
###Games on FreeBSD

What do all programmers like to do after work? Ok, what do most programers like to do after work? The answer is simple: play a good game! Recently at the Polish BSD User Group meetup mulander was telling us how you can play games on OpenBSD. Today let’s discuss how this looks in the FreeBSD world using the “server only” operating system.

• XNA based games

One of the ways of playing natively is to play indie games which use XNA. XNA is a framework from Microsoft which uses .NET, for creating games. Fortunately, in the BSD world we have Mono, an open source implementation of Microsoft’s .NET Framework which you can use to run games. There is also FNA framework which is a reimplementation of XNA which allows you to run the games under Linux. Thomas Frohwein, from OpenBSD, prepared a script, fnaify. Fnaify translate all dependencies used by an FNA game to OpenBSD dependencies.
I decided to port the script to FreeBSD. The script is using /bin/sh which in the case of OpenBSD is a Korn Shell.

I didn’t test it with many games, but I don’t see any reason why it shouldn’t work with all the games tested by the OpenBSD guys. For example, with:

• Cryptark

• Rouge Legacy

• Apotheon

• Escape Goat

• Bastion

• CrossCode

• Atom Zombie Smasher

• Open-Source games

In FreeBSD and OpenBSD we also will find popular games which were open sourced. For example, I spend a lot of time playing in Quake 3 Arena on my FreeBSD machine. You can very simply install it using pkg: # pkg install ioquake3

Then move the files for the skins and maps to the .ioquake3 directory from your copy of Quake. In the past I also played UrbanTerror which is a fully open source shooter based on the Quake 3 Arena engine. It’s is also very easy to install it from ports: # pkg install iourbanterror

In the ports tree in the games directory you can find over 1000 directories, many of them with fully implemented games. I didn’t test many games in this category, but you can find some interesting titles like:

• openxcom (Open-source re-implementation of the original X-Com)
• openjazz (Free re-implementation of the Jazz Jackrabbit™ game engine)
• corsixth (Open source re-implementation of Theme Hospital)
• quake2
• openra (Red Alert)
• openrct2 (Open source re-implementation of RollerCoaster Tycoon 2)
• openmw (Open source engine reimplementation of the game Morrowind)

All those titles are simply installed through the packages. In that case I don’t think FreeBSD has any difference from OpenBSD.

• Wine

One of the big advantages of FreeBSD over OpenBSD is that FreeBSD supports wine. Wine allows you to run Windows applications under other operating systems (including mac). If you are a FreeBSD 11 user, you can simply fetch wine from packages: # pkg install i386-wine

To run Windows games, you need to have a 32-bit wine because most of the games on Windows are built on 32-bits (maybe this has changed – I don’t play so much these days). In my case, because I run FreeBSD-CURRENT I needed to build wine from ports. It wasn’t nice, but it also wasn’t unpleasant. The whole step-by-step building process of a wine from ports can be found here.

• Summary

As you can see there are many titles available for *BSDs. Thanks to the FNA and fnaify, OpenBSD and FreeBSD can work with indie games which use the XNA framework. There are many interesting games implemented using this framework. Open source is not only for big server machines, and there are many re-implementations of popular games like Theme Hospital or RollerCoaster Tycoon 2. The biggest market is still enabled through wine, although its creates a lot of problems to run the games. Also, if you are an OpenBSD user only this option is not available for you. Please also note that we didn’t discuss any other emulators besides wine. In OpenBSD and FreeBSD there are many of them for GameBoy, SNES, NeoGeo and other games consoles.

###FreeBSD For Thanksgiving

I’ve been working on FreeBSD for Intel for almost 6 months now. In the world of programmers, I am considered an old dog, and these 6 months have been all about learning new tricks. Luckily, I’ve found myself in a remarkably inclusive and receptive community whose patience seems plentiful. As I get ready to take some time off for the holidays, and move into that retrospective time of year, I thought I’d beat the rush a bit and update on the progress
Earlier this year, I decided to move from architect of the Linux graphics driver into a more nebulous role of FreeBSD enabling. I was excited, but also uncertain if I was making the right decision.
Earlier this half, I decided some general work in power management was highly important and began working there. I attended BSDCam (handsome guy on the right), and led a session on Power Management. I was honored to be able to lead this kind of effort.
Earlier this quarter, I put the first round of my patches up for review, implementing suspend-to-idle. I have some rougher patches to handle s0ix support when suspending-to-idle. I gave a talk MeetBSD about our team’s work.
Earlier this month, I noticed that FreeBSD doesn’t have an implementation for Intel Speed Shift (HWPstates), and I started working on that.
Earlier this week, I was promoted from a lowly mentee committer to a full src committer.
Earlier today, I decided to relegate my Linux laptop to the role of my backup machine, and I am writing this from my Dell XPS13 running FreeBSD

vandamme 13.0-CURRENT FreeBSD 13.0-CURRENT #45 881fee072ff(hwp)-dirty: Mon Nov 19 16:19:32 PST 2018 bwidawsk@vandamme:/usr/home/bwidawsk/usr/obj/usr/home/bwidawsk/usr/src/amd64.amd64/sys/DEVMACHINE amd64

6 months later, I feel a lot less uncertain about making the right decision. In fact, I think both opportunities would be great, and I’m thankful this Thanksgiving that this is my life and career. I have more plans and things I want to get done. I’m looking forward to being thankful again next year.

###hammer2: no space left on device on Dragonfly BSD

• The Issue

hammer2 does not actually delete a file when you rm or unlink it. Since recovery of the file is possible (this is the design of hammer2), there will still be an entry taking up data. It’s similar to how git works.
Even with 75% usage listed here, the filesystem could still have filled up. If you are using it as your root filesystem, then attempts to clean up data may fail. If the kernel panics over this, you will see something like this.

• The Fix

If you have a recent enough version of the rescue ramdisk installed, on bootup you can press ‘r’ and access the rescue ramdisk. Your provider will have to offer some sort of remote interface for interacting with the operating system before it boots, like VNC or IPMI. You can then mount your filesystem using:

[root@ ~]# mkdir /tmp/fs
[root@ ~]# mount_hammer2 -o local /dev/vbd0s1a /tmp/fs

If you receive an error that /sbin/hammer2 is not found, then your rescue ramdisk is not up to date enough. In that scenario, download the latest 5.2 iso from dragonflybsd.org and boot from the cd-rom on your virtual machine or physical device. Just login as root instead of installer.
If the mount does succeed, then all you have to do is run the following twice:

[root@ ~]# /sbin/hammer2 bulkfree /tmp/fs

If you do not have enough memory on your machine, you may need to mount swap. Add your swap partition to the /etc/fstab and then do:

[root@ ~]# swapon -a

Once you have ran the bulkfree command twice, the usage reported by df -h will be correct. However, there is a chance on reboot that a core dump will be placed in /var/crash/ so be prepared to have plenty of space free in case that happens. You should also delete any files you can and run the bulkfree operation twice afterwards to clear up additional space.

##Beastie Bits

• BSD Pizza Night - Portland
• bsd@35c3: …the place for you…*NIX!
• Project Trident PreRelease Image now available
• Play Stardew Valley on OpenBSD
• GUI Wrapper for OpenBSD mixerctl
• qtv - QuickTextViewer

##Feedback/Questions

• Ron - Ideas for feedback section
• Paulo - SDIO Firmware
• Dan - Some fun ZFS questions about labels

• Send questions, comments, show ideas/topics, or stories you want mentioned on the show to feedback@bsdnow.tv