RootForum Community

DragonFly BSD Digest.
https://dragonflydigest.com/

FreeBSD Patch Level Table.
https://bokut.in/freebsd-patch-level-table/

FreeBSD End of Life Date.
https://endoflife.date/freebsd

Phoronix BSD News Archives.
https://phoronix.com/linux/BSD

OpenBSD Journal.
https://undeadly.org/

Call for Testing.
https://callfortesting.org/

Call for Testing – Production Users Call.
https://youtube.com/@callfortesting/videos

BSD Now Weekly Podcast.
https://www.bsdnow.tv/

Nixers Newsletter.
https://newsletter.nixers.net/entries.php

BSD Cafe Journal.
https://journal.bsd.cafe/

DragonFly BSD Digest – Lazy Reading – In Other BSDs.
https://dragonflydigest.com

FreeBSD Git Weekly.
https://freebsd-git-weekly.tarsnap.net/

FreeBSD Meetings.
https://youtube.com/@freebsdmeetings

Sheridan Computers.
https://youtube.com/@sheridans/videos

EOF

2026-06-08 04:26:34 UTC

So yeah, I was caught up in the Meta/Facebook layoffs in March 2026.

There are a lot of parallels to the 2001 dot com bust, and I'd like to just briefly touch on one of them now.

There's been a lot of layoffs over the last year or three in tech. I think the tech market has seen what, more than 100,000 in the last year alone? And most of those aren't due to performance. There are a lot of very smart people who've spent quite a few years learning how to build, debug and maintain all kinds of interesting stuff.

And they're now in the marketplace.

When this happened in 2000/2001, you had a whole lot of people who learned how to build internet tech and infrastructure at companies that were pushing the boundaries with things. And they were let go, due to downturns, change of focus, all kinds of reasons.

A lot of those people went off to eventually build the new stuff that likely overtook a lot of those internet and telco companies in the 90s.

I think this is going to happen with the layoffs from Meta/Facebook and other technology companies. Meta ran (runs?) a huge research arm in Reality Labs pushing the boundaries in AR, XR, wearable/portable technology. There have been plenty of public technology demonstrations showing all the stuff going on before the current AI trend.

Just over in Reality Labs - people learned how to build stuff from ASIC design up through optics, display, camera technology, highly miniaturized electronic design and power, all the fun stuff around 2D/3D audio and video stuff on wearable glasses (how do you provide head and world locked surfaces to your applications and not have it be so laggy that it gives people headaches?), making it all work over wifi, and then .. well imagine the lessons learned in what can and can't work in manufacturing the devices and where the pain points are in current technology. (And yes, a lot more I can't talk about, for hopefully obvious reasons.)

That knowledge is now embedded in a few hundred people, soon to be a few thousand people, who are being laid off. And that's just reality labs - the other people spread throughout the company and other technology companies have gathered a lot of experience about how to make and grow technology "stuff", what works and what doesn't.

At some point some of those people are going to make startups that do really amazing things. The technology underpinning a lot of what people have been trying to make now will get better (and I will argue that right now it is good enough - if you're willing to shift your focuses a little) and things will appear that will knock the socks off the current offerings. They're not what you would view as "founders" in the bay area tech scene. They're the people who know how to make things work, not necessarily the people who got rich early on in the scene.

Just like what happened after the dot com bust of 2001.

I've heard from a few people now that those they're hiring from Meta and other large technology companies are top notch and know what they're doing. You can't spend 10 years at a company that heavily invested in cutting edge R&D and not learn a thing or two.

I think its their loss, and .. eventually, everyone elses gain.

2026-06-06 00:00:00 UTC

The third release candidate build for the FreeBSD 15.1 release cycle is now available. ISO images for the amd64, armv7, aarch64, powerpc64, powerpc64le, and riscv64 architectures are FreeBSD mirror sites.

2026-06-05 08:31:34 UTC

Most of the time, the whole point of ZFS is that your data does not get corrupted. But during development you sometimes need the opposite: a controlled, reproducible corruption, so you can watch self-healing kick in, see what a scrub reports, or just understand how a file maps onto the physical disk. There is no better exercise than breaking one byte on purpose and seeing ZFS notice.

2026-06-05 01:02:03 UTC

Codex ist die Shell von OpenAI zur Unterstützung von Softwareentwicklung mit Large Language Models. Es ist eine Anwendung, die auf dem Computer läuft, also dort Dateien verändern und Kommandos ausführen kann.

Man kann Codex verwenden, um sich Software schreiben zu lassen. Wenn man das jedoch naiv macht bekommt man keine guten Ergebnisse. Tatsächlich ist es dringend notwendig, die Abläufe und Prozesse bei der Softwareentwicklung zu kennen und zu verstehen, um sinnvolle Ergebnisse zu erzielen.

LLM Driven Development ist also nicht “Mache mir eine Anwendung, die … tut.” So etwas funktioniert für kleine Beispiele, Snippets oder Demo-Code auf Stackoverflow-Größe.

Größere Projekte brauchen immer noch Führung, Leitlinien, Planung, und auch Review, Umbaupausen, und Aufräumarbeiten. Software besteht aus Anforderungen, Entscheidungen, Konventionen, Tests, Bugs, Altlasten, Sicherheitsgrenzen, Deployment-Krempel und einer Menge nicht ausgesprochener Annahmen.

Und das ist genau die Aufgabe des Menschen dabei: Den Kram überwachen, nicht ausgesprochene Annahmen identifizieren und korrigieren, schriftlich fixieren und dann Nacharbeiten zum Aufräumen veranlassen.

Ein LLM-Agent kann damit arbeiten. Aber nur, wenn man ihm diesen Kram in einer Form gibt, die er benutzen kann.

Kontext ist Material

Ein LLM hat kein Projektgedächtnis im menschlichen Sinn. Es hat ein Kontextfenster.

Das Kontextfenster ist die Menge an Tokens, die das Modell in einem Lauf aktiv sehen kann. Tokens sind nicht Wörter, sondern Wortstücke. Für uns reicht als Vorstellung: Kontext ist begrenzt, auch wenn moderne Modelle inzwischen sehr große Fenster haben.

Kleine Aufgaben passen in ein paar tausend Tokens. Ernsthafte Coding-Aufgaben profitieren schnell von 30k Tokens und mehr, weil Auftrag, relevante Dateien, Tests, Fehlermeldungen, Projektregeln und bisherige Entscheidungen gleichzeitig sichtbar sein müssen. Für Refactorings, Audits und Architekturfragen sind 100k Tokens oder mehr angenehm.

Aber groß ist nicht automatisch gut.

In langen Kontexten werden Informationen schlechter gefunden, besonders wenn sie irgendwo in der Mitte liegen. Das Problem ist bekannt als Lost in the Middle . Ein großes Kontextfenster ist also keine Müllhalde. Es ist ein Arbeitstisch. Wenn der Arbeitstisch vollgemüllt ist, findet auch der Agent den Schraubendreher nicht mehr.

Die praktische Regel ist einfach: Der aktive Kontext muss die konkrete Arbeit tragen, nicht das ganze Projekt abbilden.

Oder anders herum: Das Projekt kann sehr viel größer als der aktive Kontext sein, aber man muss das Projektumfeld so strukturieren, dass das Modell sich in der Codebasis zurechtfindet und sich einen aktiven Kontext bauen kann, der für die aktuelle Aufgabe geeignet ist.

`AGENTS.md`

Der Einstiegspunkt für Codex ist AGENTS.md.

OpenAI beschreibt AGENTS.md als Projektinstruktion: Codex liest diese Dateien vor der Arbeit und baut daraus eine Instruktionskette. Die offizielle Dokumentation sagt auch, dass Codex vom Projekt-Root zum aktuellen Verzeichnis läuft und nähere Instruktionen später im Prompt stehen, also spezifischer wirken. Siehe Custom instructions with AGENTS.md .

Das ist wichtig, weil AGENTS.md nicht “im Gedächtnis bleibt”. Präziser: AGENTS.md wird als Projektkontext geladen und beeinflusst die Arbeit, solange diese Instruktionen im aktiven Kontext verfügbar sind und nicht durch spätere, spezifischere Instruktionen verdrängt werden.

Eine gute AGENTS.md ist kurz, dicht und langweilig.

Sie sagt:

was das Projekt ist
welche Werkzeuge benutzt werden
welche Befehle für Formatierung, Linting und Tests gelten
wo Code, Tests, Dokumentation und interne Entwicklungsartefakte liegen
welche Regeln der Agent nicht brechen soll

Konkrete Befehle sind besser als fromme Wünsche.

Also nicht:

Bitte teste sorgfältig.

Sondern:

Formatierung: uv run ruff format src tests
Linting: uv run ruff check --fix src tests
Tests: uv run pytest

Progressive Discovery

Eine AGENTS.md soll nicht das ganze Projekt erklären.

Sie soll auf weitere Dateien zeigen. Das ist Progressive Discovery: Der Agent bekommt zuerst Orientierung und findet Details erst dann, wenn sie für die konkrete Aufgabe relevant sind.

Das entspricht dem allgemeinen Prinzip der Progressive Disclosure , das OpenAI bei Codex-Skills explizit beschreibt: zuerst nur Name, Beschreibung und Pfad, die vollständigen Instruktionen erst bei Bedarf.

Für ein Repository funktioniert das genauso.

Die AGENTS.md verweist zum Beispiel auf:

development/index.md für interne Entwicklungsartefakte
development/security-boundary.md für die Sicherheitskante der Anwendung
development/decisions/ für Architekturentscheidungen
development/epic-001-.../tickets.md für konkrete Arbeitspakete

Wichtig ist, dass der Verweis erklärt, was dort steht. Ein bloßer Dateiname ist eine Schnitzeljagd, der Agent muss die Datei immer noch in den Kontext laden um zu sehen, was drin ist und ob sie nützlich ist. Eine Zeile Kontext ist ein Wegweiser. Das Modell kann ihn benutzen um vorab zu entscheiden, ob die Datei geladen werden sollte.

`README.md` ist nicht `AGENTS.md`

Die README.md ist für Nutzer. Sie erklärt Installation, Konfiguration und Benutzung.

Die AGENTS.md ist für Entwickler und Agenten. Sie erklärt, wie an der Software gearbeitet wird.

Es ist wichtig, diese Trennung aufrechtzuerhalten. Einmal, damit die Dateien für den Menschen sinnvoll bleiben, und zum anderen, weil das auch Teil des Kontext-Managements für Agents ist.

Expected Application Shape

Ein hilfreiches internes Artefakt ist eine Expected Application Shape. Das ist kein Industriestandard, sondern ein nützlicher Projektbegriff.

Gemeint ist: Wie soll die Anwendung ungefähr aussehen?

Welche Module gibt es? Welche Verantwortung gehört wohin? Wo werden neue Dateien angelegt? Welche Schichten dürfen miteinander sprechen? Welche Dinge gehören ausdrücklich nicht zusammen?

Das muss am Anfang nicht perfekt sein. Wir können tatsächlich das Modell benutzen, um darüber zu iterieren und das schrittweise zu verbessern während die Anwendung wächst. Zu Beginn muss das nur gut genug sein, damit ein Agent nicht neue Funktionalität in irgendeine zufällig passende Datei stopft, weil dort schon etwas ähnliches steht.

Wir verwenden die Expected Application Shape also, um Drift zu verringern. Das ist kein Ersatz für eine richtige Architektur, aber andererseits wollen wir uns ja auch inkrementell an etwas heran arbeiten, damit wir herausfinden, was wir eigentlich wollen.

Progressive Refinement

Der wichtigste Trick ist, den Agenten nicht direkt von “Idee” nach “Code” springen zu lassen.

Man verfeinert Material schrittweise:

Beobachtung -> User Story -> Ticket -> Test -> Code -> Audit -> neues Ticket

Das nenne ich hier Progressive Refinement. Im Scrum-Umfeld ist Product Backlog Refinement der etablierte Begriff für einen Teil davon. Progressive Refinement ist etwas breiter: Es beschreibt den ganzen Artefaktfluss in agentischer Entwicklung.

Eine Beobachtung ist noch keine User Story. Eine User Story ist noch kein Ticket. Ein Ticket ist noch kein Test. Ein Test ist noch kein Code.

Das sind unterschiedliche Artefakte mit unterschiedlichen Qualitätskriterien. Wenn man diesen Unterschied ignoriert, bekommt man Slop. Schnell, viel, plausibel, falsch.

Die Qualität der frühen Artefakte bestimmt stark die Qualität der späteren Arbeit. Ein schlechtes Ticket erzeugt schlechten Code. Ein guter Agent macht daraus nur schneller schlechten Code. Daher ist es entscheidend, gerade die frühen Artefakte zu lesen, zu verstehen und ggf. um Entscheidungen anzureichern.

Es hat sich herausgestellt, dass es sehr hilfreich ist, dem Model ein Sicherheitsventil anzubieten. Das heißt, man kann im Prompt erlauben, am Ende des erstellten oder umgewandelten Artefaktes die Sektionen “Open Questions”, “Risks” und “Gaps” anzulegen. Wenn dem Modell also bei der Arbeit etwas auffällt, das hilfreich sein könnte, dann ist das eine Einladung, hier Nachrichten zu hinterlassen.

Markdown als Arbeitsformat

Markdown ist ein gutes Format.

Es ist lesbar, diffbar, versionierbar und für Menschen wie LLMs einfach zu verarbeiten. Man kann Codex Beobachtungen strukturieren lassen, daraus User Stories erzeugen, diese in Tickets zerlegen, die Tickets implementieren lassen und danach ein Audit-Artefakt schreiben lassen.

Ein mögliches Layout:

/
 README.md
 AGENTS.md
 src/
 tests/
 docs/
 development/
 index.md
 security-boundary.md
 decisions/
 0001-use-flask-for-api-boundary.md
 epic-001-image-render-api/
 user-stories.md
 tickets.md
 audit.md
 notes.md

/docs/ ist hier Nutzer- und Betreiber-Dokumentation. /development/ ist internes Arbeitsmaterial. Letzteres verwenden wir dann, um Code und Tests erzeugen zu lassen.

Der agentische Sicherheitskontext gehört besser in /development/security-boundary.md. Das ist etwas anderes als eine GitHub SECURITY.md.

Tests zuerst

LLM Driven Development braucht Tests.

Nicht “wäre schön”, sondern braucht.

Der Agent soll bei nichttrivialer Arbeit zuerst Tests schreiben, die die erwartete API Shape und das gewünschte Verhalten festlegen. Diese Tests sollen zuerst fehlschlagen. Dann wird Code geschrieben, bis sie grün sind.

Das ist Red-Green-Development. Man kann das mit Outside-In TDD kombinieren: erst das Verhalten an der Außenseite beschreiben, dann die innere Implementierung entstehen lassen.

Das passt gut zu Agenten, weil Tests dem Agenten eine Zielscheibe geben. Ohne Zielscheibe optimiert das LLM auf plausible Antwort. Mit Zielscheibe optimiert es wenigstens auf reproduzierbares Verhalten.

Natürlich können Tests auch schlecht sein. Triviale Tests, die nur die Implementierung nacherzählen, sind wertlos. Gute Tests sichern Verhalten ab und überleben ein Refactoring.

(Zum Nachlesen in “Growing Object-Oriented Software, Guided by Tests” , “GOOS”.)

Audits sind Teil der Pipeline

Ein Audit ist kein Ereignis am Ende. Es ist ein Artefakt in der Pipeline.

Ein Security Audit kann development/security-boundary.md lesen: Welche Eingaben gibt es? Welche Rollen? Welche externen Systeme? Welche Secrets? Welche Netzwerkkontakte? Welche Erwartungen gelten?

Daraus entstehen Findings. Aus Findings entstehen Tickets. Tickets werden priorisiert, geprüft, implementiert und getestet.

Dasselbe gilt für Refactoring Audits. Alle zwei oder drei Sprints kann man den Agenten fragen:

welcher Code ist unbenutzt?
welche Duplikate sind sinnvoll zusammenzuführen?
welche Module sprengen ihre erklärte Verantwortung?
passt die tatsächliche Struktur noch zur Expected Application Shape?

Das Ergebnis ist wieder audit.md mit gezielter Kritik. Die editieren wir, und bitten dann das Modell, diese Kritik in “actionable tickets” in eine tickets.md umzuwandeln.

Und ja: Ein Codex Security Audit ersetzt keinen professionellen Security Review für kritische Systeme. Aber als wiederholbares Review-Werkzeug ist es nützlich.

Mehrere Agenten, eine Wahrheit

Codex verwendet AGENTS.md. GitHub Copilot kennt repositoryweite Instruktionen wie .github/copilot-instructions.md und inzwischen ebenfalls AGENTS.md. Claude Code verwendet CLAUDE.md. JetBrains Junie unterstützt ebenfalls AGENTS.md. Andere Werkzeuge haben wieder andere Dateien.

Wenn man mehrere Agenten im selben Repository benutzt, entsteht schnell Instruktions-Drift: eine Regel steht in Datei A, die gegenteilige Regel steht in Datei B, und beide Agenten tun jeweils plausibel das Falsche.

Die pragmatische Lösung ist: AGENTS.md als kanonische Orientierungsdatei pflegen und tool-spezifische Dateien kurz halten, sofern das jeweilige Tool das erlaubt.

Zum Beispiel:

Read AGENTS.md for repository conventions.

Das ist nicht perfekt. Aber es ist besser als fünf lange Regelwerke, die alle ein bisschen anders falsch sind.

Fazit

LLM Driven Development ist vor allem Kontextarbeit.

Man schreibt nicht nur Prompts. Man schreibt Arbeitsmaterial: Projektregeln, Architekturentscheidungen, Sicherheitsgrenzen, User Stories, Tickets, Tests und Audits.

Der Agent ist dann kein magischer Entwickler. Er ist ein sehr schneller, sehr wörtlicher Mitarbeiter mit begrenztem Kurzzeitgedächtnis, der gut arbeitet, wenn man ihm gute Arbeitsunterlagen gibt.

Das ist weniger spektakulär als “AI schreibt meine App”. Es ist aber deutlich näher an echter Softwareentwicklung.

Und es hat den angenehmen Nebeneffekt, dass auch Menschen das Projekt besser verstehen. Das ist fast verdächtig.

Quellen

2026-06-04 06:17:00 UTC

MMO-20044 geht in den regulären Betrieb.

Die Testphase ist abgeschlossen, der Produktionsserver läuft

Was gespielt wird: ein browserbasiertes Space-MMO. Rohstoffe abbauen, forschen, reisen, handeln, andere Spieler angreifen. Das Ziel ist der Genesis-Planet: wer ihn auf Level 5 bringt, startet einen 48-Stunden-Countdown. Läuft der durch, ist die Season vorbei und der Spieler gewinnt.

Technik: Python/FastAPI, PostgreSQL, HTMX. Kein JavaScript-Framework, kein Build-Step. Alles läuft serverseitig.

Registrierung ist offen unter zockertown.de/mmo-20044 . Spielstände aus der Testphase wurden nicht übernommen, alle starten neu.

Ein fetter Dank geht an die Spieler der Betaphase, die Fehler gemeldet und Verbesserungen vorgeschlagen haben. Das hat den Start besser gemacht, als er ohne dieses Feedback geworden wäre.

Was "20044" bedeutet: demnächst.

2026-05-24 18:48:19 UTC

This post has been replaced by a newer post.
This is the Dell R730 host known as r730-01.

For reference, the previous post on this server is still available.

This host has undergone major storage changes over the past few weeks. This post will reflect those changes

This is my primary developer server in my basement.

[18:39 r730-01 dvl ~] % uname -a
FreeBSD r730-01.int.unixathome.org 15.0-RELEASE-p9 FreeBSD 15.0-RELEASE-p9 GENERIC amd64

gpart

[18:39 r730-01 dvl ~] % gpart show
=>        40  7814037088  nda0  GPT  (3.6T)
          40  7814036000     1  freebsd-zfs  (3.6T)
  7814036040        1088        - free -  (544K)

=>        40  7814037088  nda1  GPT  (3.6T)
          40  7814036000     1  freebsd-zfs  (3.6T)
  7814036040        1088        - free -  (544K)

=>        40  7814037088  nda2  GPT  (3.6T)
          40  7814036000     1  freebsd-zfs  (3.6T)
  7814036040        1088        - free -  (544K)

=>        40  7814037088  nda3  GPT  (3.6T)
          40  7814036000     1  freebsd-zfs  (3.6T)
  7814036040        1088        - free -  (544K)

=>       40  488397088  nda4  GPT  (233G)
         40       1024     1  freebsd-boot  (512K)
       1064        984        - free -  (492K)
       2048    4194304     2  freebsd-swap  (2.0G)
    4196352  484200448     3  freebsd-zfs  (231G)
  488396800        328        - free -  (164K)

=>        40  7814037088  nda5  GPT  (3.6T)
          40  7814036000     1  freebsd-zfs  (3.6T)
  7814036040        1088        - free -  (544K)

=>        40  1953525088  nda6  GPT  (932G)
          40  1953525088     1  freebsd-zfs  (932G)

=>        40  1953525088  nda7  GPT  (932G)
          40  1953525088     1  freebsd-zfs  (932G)

=>        40  7814037088  nda8  GPT  (3.6T)
          40  7814036000     1  freebsd-zfs  (3.6T)
  7814036040        1088        - free -  (544K)

=>       40  242255584  ada0  GPT  (116G)
         40       2008        - free -  (1.0M)
       2048     409600     1  efi  (200M)
     411648   16777216     2  freebsd-swap  (8.0G)
   17188864  225066760     3  freebsd-zfs  (107G)

=>       40  242255584  ada1  GPT  (116G)
         40       2008        - free -  (1.0M)
       2048     409600     1  efi  (200M)
     411648   16777216     2  freebsd-swap  (8.0G)
   17188864  225066760     3  freebsd-zfs  (107G)

=>        40  1562824288  da0  GPT  (745G)
          40  1562824288    1  freebsd-zfs  (745G)

=>        40  1562824288  da2  GPT  (745G)
          40  1562824288    1  freebsd-zfs  (745G)

=>        40  1562824288  da4  GPT  (745G)
          40  1562824288    1  freebsd-zfs  (745G)

=>        40  1562824288  da1  GPT  (745G)
          40  1562824288    1  freebsd-zfs  (745G)

=>        40  1562824288  da6  GPT  (745G)
          40  1562824288    1  freebsd-zfs  (745G)

=>        40  1562824288  da3  GPT  (745G)
          40  1562824288    1  freebsd-zfs  (745G)

=>        40  1562824288  da5  GPT  (745G)
          40  1562824288    1  freebsd-zfs  (745G)

=>        40  1562824288  da7  GPT  (745G)
          40  1562824288    1  freebsd-zfs  (745G)

=>        40  7814037088  da13  GPT  (3.6T)
          40  7814036000     1  freebsd-zfs  (3.6T)
  7814036040        1088        - free -  (544K)

=>        40  7814037088  da12  GPT  (3.6T)
          40  7814036000     1  freebsd-zfs  (3.6T)
  7814036040        1088        - free -  (544K)

=>        40  7814037088  da11  GPT  (3.6T)
          40  7814037088     1  freebsd-zfs  (3.6T)

=>        40  7814037088  da8  GPT  (3.6T)
          40  7814037088    1  freebsd-zfs  (3.6T)

=>        40  7814037088  da10  GPT  (3.6T)
          40  7814037088     1  freebsd-zfs  (3.6T)

=>        40  7814037088  da9  GPT  (3.6T)
          40  7814037088    1  freebsd-zfs  (3.6T)

zpool list

[18:39 r730-01 dvl ~] % zpool list -v
NAME                                SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
data01                             5.81T  6.37G  5.81T        -         -     2%     0%  1.00x    ONLINE  -
  raidz2-0                         5.81T  6.37G  5.81T        -         -     2%  0.10%      -    ONLINE
    gpt/Y7P0A022TEVE                745G      -      -        -         -      -      -      -    ONLINE
    gpt/Y7P0A02ATEVE                745G      -      -        -         -      -      -      -    ONLINE
    gpt/Y7P0A02DTEVE                745G      -      -        -         -      -      -      -    ONLINE
    gpt/Y7P0A02GTEVE                745G      -      -        -         -      -      -      -    ONLINE
    gpt/Y7P0A02LTEVE                745G      -      -        -         -      -      -      -    ONLINE
    gpt/Y7P0A02MTEVE                745G      -      -        -         -      -      -      -    ONLINE
    gpt/Y7P0A02QTEVE                745G      -      -        -         -      -      -      -    ONLINE
    gpt/Y7P0A033TEVE                745G      -      -        -         -      -      -      -    ONLINE
data02                              928G   297G   631G        -         -    51%    31%  1.00x    ONLINE  -
  mirror-0                          928G   297G   631G        -         -    51%  32.0%      -    ONLINE
    gpt/S6WSNJ0T208743F             932G      -      -        -         -      -      -      -    ONLINE
    gpt/S6WSNJ0T207774T             932G      -      -        -         -      -      -      -    ONLINE
data03                             7.25T  1.68T  5.57T        -         -    52%    23%  1.00x    ONLINE  -
  mirror-0                         3.62T   871G  2.77T        -         -    52%  23.4%      -    ONLINE
    gpt/WD_22492H800867            3.64T      -      -        -         -      -      -      -    ONLINE
    gpt/WD_230151801284            3.64T      -      -        -         -      -      -      -    ONLINE
  mirror-1                         3.62T   854G  2.79T        -         -    52%  23.0%      -    ONLINE
    gpt/WD_230151801478            3.64T      -      -        -         -      -      -      -    ONLINE
    gpt/WD_230151800473            3.64T      -      -        -         -      -      -      -    ONLINE
data04                             29.1T  9.02T  20.1T        -         -     8%    30%  1.00x    ONLINE  -
  raidz2-0                         29.1T  9.02T  20.1T        -         -     8%  31.0%      -    ONLINE
    gpt/S7KGNU0Y722875X            3.64T      -      -        -         -      -      -      -    ONLINE
    gpt/S7KGNU0Y915666E            3.64T      -      -        -         -      -      -      -    ONLINE
    gpt/S7KGNU0Y912937J            3.64T      -      -        -         -      -      -      -    ONLINE
    gpt/S7KGNU0Y912955D            3.64T      -      -        -         -      -      -      -    ONLINE
    gpt/S7U8NJ0Y716854P            3.64T      -      -        -         -      -      -      -    ONLINE
    gpt/S7U8NJ0Y716801F            3.64T      -      -        -         -      -      -      -    ONLINE
    gpt/S757NS0Y700758M            3.64T      -      -        -         -      -      -      -    ONLINE
    gpt/S757NS0Y700760R            3.64T      -      -        -         -      -      -      -    ONLINE
zroot                               107G  66.2G  40.8G        -         -    44%    61%  1.00x    ONLINE  -
  mirror-0                          107G  66.2G  40.8G        -         -    44%  61.9%      -    ONLINE
    gpt/zfs0_20170718AA0000185556   107G      -      -        -         -      -      -      -    ONLINE
    gpt/zfs1_20170719AA1178164201   107G      -      -        -         -      -      -      -    ONLINE

zpool status

[18:40 r730-01 dvl ~] % zpool status
  pool: data01
 state: ONLINE
  scan: scrub repaired 0B in 00:00:06 with 0 errors on Thu May 21 03:28:58 2026
config:

	NAME                  STATE     READ WRITE CKSUM
	data01                ONLINE       0     0     0
	  raidz2-0            ONLINE       0     0     0
	    gpt/Y7P0A022TEVE  ONLINE       0     0     0
	    gpt/Y7P0A02ATEVE  ONLINE       0     0     0
	    gpt/Y7P0A02DTEVE  ONLINE       0     0     0
	    gpt/Y7P0A02GTEVE  ONLINE       0     0     0
	    gpt/Y7P0A02LTEVE  ONLINE       0     0     0
	    gpt/Y7P0A02MTEVE  ONLINE       0     0     0
	    gpt/Y7P0A02QTEVE  ONLINE       0     0     0
	    gpt/Y7P0A033TEVE  ONLINE       0     0     0

errors: No known data errors

  pool: data02
 state: ONLINE
  scan: scrub repaired 0B in 00:06:09 with 0 errors on Wed May 20 03:55:38 2026
config:

	NAME                     STATE     READ WRITE CKSUM
	data02                   ONLINE       0     0     0
	  mirror-0               ONLINE       0     0     0
	    gpt/S6WSNJ0T208743F  ONLINE       0     0     0
	    gpt/S6WSNJ0T207774T  ONLINE       0     0     0

errors: No known data errors

  pool: data03
 state: ONLINE
  scan: scrub repaired 0B in 01:12:17 with 0 errors on Thu May 21 04:41:31 2026
config:

	NAME                     STATE     READ WRITE CKSUM
	data03                   ONLINE       0     0     0
	  mirror-0               ONLINE       0     0     0
	    gpt/WD_22492H800867  ONLINE       0     0     0
	    gpt/WD_230151801284  ONLINE       0     0     0
	  mirror-1               ONLINE       0     0     0
	    gpt/WD_230151801478  ONLINE       0     0     0
	    gpt/WD_230151800473  ONLINE       0     0     0

errors: No known data errors

  pool: data04
 state: ONLINE
  scan: scrub repaired 0B in 01:23:44 with 0 errors on Wed May 20 05:13:28 2026
config:

	NAME                     STATE     READ WRITE CKSUM
	data04                   ONLINE       0     0     0
	  raidz2-0               ONLINE       0     0     0
	    gpt/S7KGNU0Y722875X  ONLINE       0     0     0
	    gpt/S7KGNU0Y915666E  ONLINE       0     0     0
	    gpt/S7KGNU0Y912937J  ONLINE       0     0     0
	    gpt/S7KGNU0Y912955D  ONLINE       0     0     0
	    gpt/S7U8NJ0Y716854P  ONLINE       0     0     0
	    gpt/S7U8NJ0Y716801F  ONLINE       0     0     0
	    gpt/S757NS0Y700758M  ONLINE       0     0     0
	    gpt/S757NS0Y700760R  ONLINE       0     0     0

errors: No known data errors

  pool: zroot
 state: ONLINE
status: Some supported and requested features are not enabled on the pool.
	The pool can still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
	the pool may no longer be accessible by software that does not support
	the features. See zpool-features(7) for details.
  scan: scrub repaired 0B in 00:04:30 with 0 errors on Wed May 20 03:54:17 2026
config:

	NAME                               STATE     READ WRITE CKSUM
	zroot                              ONLINE       0     0     0
	  mirror-0                         ONLINE       0     0     0
	    gpt/zfs0_20170718AA0000185556  ONLINE       0     0     0
	    gpt/zfs1_20170719AA1178164201  ONLINE       0     0     0

errors: No known data errors

zfs list

[18:40 r730-01 dvl ~] % zfs list
NAME                                                                 USED  AVAIL  REFER  MOUNTPOINT
data01                                                               295G  3.72T   205K  none
data01/jail_within_jail                                              617M  3.72T   205K  none
data01/jail_within_jail/jails                                        617M  3.72T   205K  none
data01/jail_within_jail/jails/freshports                             617M  3.72T   617M  none
data01/mkjail                                                       3.83G  3.72T   926M  /var/db/mkjail
data01/mkjail/14.3-RELEASE                                          1.37G  3.72T  1.37G  /var/db/mkjail/14.3-RELEASE
data01/mkjail/15.0-RELEASE                                          1.55G  3.72T  1.55G  /var/db/mkjail/15.0-RELEASE
data01/reserved                                                      290G  4.00T   205K  none
data02                                                               317G   583G    96K  none
data02/freshports                                                    376K   583G    88K  none
data02/freshports/jailed                                             288K   583G    96K  none
data02/freshports/jailed/dvl-ingress01                               192K   583G    96K  none
data02/freshports/jailed/dvl-ingress01/distfiles                      96K   583G    96K  none
data02/jails                                                         296G   583G  9.54G  /jails
data02/jails/bacula                                                 16.6G   583G  16.5G  /jails/bacula
data02/jails/bacula-sd-02                                           3.32G   583G  3.19G  /jails/bacula-sd-02
data02/jails/bacula-sd-03                                           4.49G   583G  4.38G  /jails/bacula-sd-03
data02/jails/besser                                                 8.58G   583G  5.89G  /jails/besser
data02/jails/certs                                                  2.77G   583G  2.65G  /jails/certs
data02/jails/certs-rsync                                            2.76G   583G  2.66G  /jails/certs-rsync
data02/jails/cliff2                                                 2.82G   583G  2.70G  /jails/cliff2
data02/jails/dev-ingress01                                          4.41G   583G  4.24G  /jails/dev-ingress01
data02/jails/dev-nginx01                                            3.84G   583G  3.65G  /jails/dev-nginx01
data02/jails/dns-hidden-master                                      2.98G   583G  2.87G  /jails/dns-hidden-master
data02/jails/dns1                                                   5.23G   583G  5.12G  /jails/dns1
data02/jails/dvl-ingress01                                          7.29G   583G  6.60G  /jails/dvl-ingress01
data02/jails/dvl-nginx01                                            1.69G   583G  1.55G  /jails/dvl-nginx01
data02/jails/git                                                    4.85G   583G  4.66G  /jails/git
data02/jails/jail_within_jail                                        600M   583G   585M  /jails/jail_within_jail
data02/jails/mqtt01                                                 3.44G   583G  3.29G  /jails/mqtt01
data02/jails/mydev                                                  21.1G   583G  20.9G  /jails/mydev
data02/jails/mysql01                                                9.67G   583G  5.85G  /jails/mysql01
data02/jails/mysql02                                                8.72G   583G  8.66G  /jails/mysql02
data02/jails/nsnotify                                               2.99G   583G  2.86G  /jails/nsnotify
data02/jails/pg01                                                   65.6G   583G  63.9G  /jails/pg01
data02/jails/pg02                                                   12.8G   583G  12.1G  /jails/pg02
data02/jails/pg03                                                   11.0G   583G  10.4G  /jails/pg03
data02/jails/pkg01                                                  16.0G   583G  15.6G  /jails/pkg01
data02/jails/samdrucker                                             4.60G   583G  4.48G  /jails/samdrucker
data02/jails/serpico                                                2.89G   583G  2.76G  /jails/serpico
data02/jails/stage-ingress01                                        4.59G   583G  3.91G  /jails/stage-ingress01
data02/jails/stage-nginx01                                          2.11G   583G  1.96G  /jails/stage-nginx01
data02/jails/svn                                                    10.3G   583G  10.1G  /jails/svn
data02/jails/talos                                                  2.98G   583G  2.64G  /jails/talos
data02/jails/test-ingress01                                         2.29G   583G  2.14G  /jails/test-ingress01
data02/jails/test-nginx01                                           2.00G   583G  1.83G  /jails/test-nginx01
data02/jails/unifi01                                                19.4G   583G  13.9G  /jails/unifi01
data02/jails/webserver                                              11.9G   583G  11.6G  /jails/webserver
data02/reserved                                                       20G   603G    96K  none
data03                                                              2.04T  5.09T    96K  none
data03/acme-certs                                                   14.3M  5.09T    96K  none
data03/acme-certs/certs                                             7.29M  5.09T  5.84M  /jails/certs/var/db/acme/certs
data03/acme-certs/certs-for-rsync                                   6.89M  5.09T  4.29M  /jails/certs/var/db/certs-for-rsync
data03/jail_within_jail                                             1.08G  5.09T    96K  none
data03/jail_within_jail/jails                                       1.08G  5.09T    96K  none
data03/jail_within_jail/jails/freshports                            1.08G  5.09T  1.08G  none
data03/librenms-rrd                                                  145G  5.09T  26.7G  /jails/besser/var/db/librenms/rrd
data03/pg01                                                          385G  5.09T    96K  none
data03/pg01/freshports.dvl                                          37.1G  5.09T  27.6G  /jails/pg01/var/db/postgres.freshports.dvl
data03/pg01/postgres                                                 348G  5.09T   322G  /jails/pg01/var/db/postgres
data03/pg02                                                          434G  5.09T    88K  none
data03/pg02/postgres                                                 355G  5.09T   355G  /jails/pg02/var/db/postgres
data03/pg02/postgres.original                                       78.5G  5.09T  51.8G  /jails/pg02/var/db/postgres
data03/pg02/rsyncer                                                 1.01M  5.09T   144K  /jails/pg02/usr/home/rsyncer/backups
data03/pg03                                                          448G  5.09T    88K  none
data03/pg03/postgres                                                 448G  5.09T  19.6M  /jails/pg03/var/db/postgres
data03/pg03/rsyncer                                                  856K  5.09T   112K  /jails/pg03/usr/home/rsyncer/backups
data03/poudriere                                                     274G  5.09T    96K  /usr/local/poudriere
data03/poudriere/ccache                                             16.5M  5.09T   104K  /var/ccache
data03/poudriere/ccache/ccache.13amd64                                96K  5.09T    96K  /var/ccache/ccache.13amd64
data03/poudriere/ccache/ccache.amd64                                16.3M  5.09T  16.3M  /var/ccache/ccache.amd64
data03/poudriere/data                                                101G  5.09T  13.5G  /usr/local/poudriere/data
data03/poudriere/data/cache                                          428M  5.09T   300M  /usr/local/poudriere/data/cache
data03/poudriere/data/cronjob-logs                                  7.42M  5.09T  2.85M  /usr/local/poudriere/data/cronjob-logs
data03/poudriere/data/packages                                      86.2G  5.09T  64.9G  /usr/local/poudriere/data/packages
data03/poudriere/distfiles                                           152G  5.09T   152G  /usr/ports/distfiles
data03/poudriere/jails                                              4.21G  5.09T    88K  /usr/local/poudriere/jails
data03/poudriere/jails/143R4                                        1.40G  5.09T  1.40G  /usr/local/poudriere/jails/143R4
data03/poudriere/jails/143amd64                                     1.38G  5.09T  1.38G  /usr/local/poudriere/jails/143amd64
data03/poudriere/jails/150amd64                                     1.43G  5.09T  1.43G  /usr/local/poudriere/jails/150amd64
data03/poudriere/ports                                              17.5G  5.09T  3.25G  /usr/local/poudriere/ports
data03/poudriere/ports/default                                      4.00G  5.09T  3.07G  /usr/local/poudriere/ports/default
data03/poudriere/ports/main                                         1.60G  5.09T  1.60G  /usr/local/poudriere/ports/main
data03/poudriere/ports/pgeu_system                                  1.06G  5.09T  1.06G  /usr/local/poudriere/ports/pgeu_system
data03/poudriere/ports/testing                                      7.08G  5.09T  2.76G  /usr/local/poudriere/ports/testing
data03/poudriere/test                                                 96K  5.09T    96K  /usr/local/poudriere/test
data03/public                                                       23.4G  5.09T  23.4G  none
data03/repos                                                        8.92G  5.09T    88K  none
data03/repos/gitea                                                   785M  5.09T   313M  /jails/git/var/db/gitea
data03/repos/subversion                                             8.15G  5.09T  7.80G  /jails/svn/usr/local/svn/repos
data03/reserved                                                      362G  5.44T    96K  none
data04                                                              6.41T  14.2T   324K  none
data04/bacula                                                       5.98T  14.2T   205K  /jails/bacula-sd-03/usr/local/bacula
data04/bacula/volumes                                               5.98T  14.2T   205K  /jails/bacula-sd-03/usr/local/bacula/volumes
data04/bacula/volumes/DiffFile-03                                    608G  14.2T   158G  /jails/bacula-sd-03/usr/local/bacula/volumes/DiffFile-03
data04/bacula/volumes/FullFile-03                                   4.87T  14.2T  2.66T  /jails/bacula-sd-03/usr/local/bacula/volumes/FullFile-03
data04/bacula/volumes/IncrFile-03                                    529G  14.2T  52.2G  /jails/bacula-sd-03/usr/local/bacula/volumes/IncrFile-03
data04/bacula/working                                                478K  14.2T   264K  /jails/bacula-sd-03/usr/local/bacula/working
data04/freshports                                                    343G  14.2T   205K  none
data04/freshports/dev-ingress01                                      246G  14.2T   188K  none
data04/freshports/dev-ingress01/dvl-src                              201G  14.2T   201G  /jails/dev-ingress01/usr/home/dvl/src
data04/freshports/dev-ingress01/freshports                          30.3G  14.2T  2.99G  /jails/dev-ingress01/var/db/freshports
data04/freshports/dev-ingress01/freshports/cache                    6.83M  14.2T   299K  /jails/dev-ingress01/var/db/freshports/cache
data04/freshports/dev-ingress01/freshports/cache/html               6.21M  14.2T  1.83M  /jails/dev-ingress01/var/db/freshports/cache/html
data04/freshports/dev-ingress01/freshports/cache/spooling            341K  14.2T   205K  /jails/dev-ingress01/var/db/freshports/cache/spooling
data04/freshports/dev-ingress01/freshports/message-queues           26.5G  14.2T  32.3M  /jails/dev-ingress01/var/db/freshports/message-queues
data04/freshports/dev-ingress01/freshports/message-queues/archive   26.5G  14.2T  13.5G  /jails/dev-ingress01/var/db/freshports/message-queues/archive
data04/freshports/dev-ingress01/ingress                             10.4G  14.2T   282K  /jails/dev-ingress01/var/db/ingress
data04/freshports/dev-ingress01/ingress/latest_commits              1.22M  14.2T   230K  /jails/dev-ingress01/var/db/ingress/latest_commits
data04/freshports/dev-ingress01/ingress/message-queues              3.90M  14.2T  1.31M  /jails/dev-ingress01/var/db/ingress/message-queues
data04/freshports/dev-ingress01/ingress/repos                       10.4G  14.2T   256K  /jails/dev-ingress01/var/db/ingress/repos
data04/freshports/dev-ingress01/ingress/repos/doc                    744M  14.2T   672M  /jails/dev-ingress01/var/db/ingress/repos/doc
data04/freshports/dev-ingress01/ingress/repos/ports                 4.05G  14.2T  3.39G  /jails/dev-ingress01/var/db/ingress/repos/ports
data04/freshports/dev-ingress01/ingress/repos/src                   5.65G  14.2T  3.59G  /jails/dev-ingress01/var/db/ingress/repos/src
data04/freshports/dev-ingress01/jails                               5.14G  14.2T   222K  /jails/dev-ingress01/jails
data04/freshports/dev-ingress01/jails/freshports                    5.14G  14.2T   610M  /jails/dev-ingress01/jails/freshports
data04/freshports/dev-ingress01/jails/freshports/ports              4.55G  14.2T  3.98G  /jails/dev-ingress01/jails/freshports/usr/ports
data04/freshports/dev-ingress01/modules                             8.27M  14.2T  8.27M  /jails/dev-ingress01/usr/local/lib/perl5/site_perl/FreshPorts
data04/freshports/dev-ingress01/scripts                             7.04M  14.2T  7.04M  /jails/dev-ingress01/usr/local/libexec/freshports
data04/freshports/dev-nginx01                                       99.0M  14.2T   205K  none
data04/freshports/dev-nginx01/www                                   98.8M  14.2T   205K  /jails/dev-nginx01/usr/local/www
data04/freshports/dev-nginx01/www/freshports                        93.5M  14.2T  21.7M  /jails/dev-nginx01/usr/local/www/freshports
data04/freshports/dev-nginx01/www/freshsource                       5.17M  14.2T  5.17M  /jails/dev-nginx01/usr/local/www/freshsource
data04/freshports/dvl-ingress01                                     28.4G  14.2T   205K  none
data04/freshports/dvl-ingress01/dvl-src                              162M  14.2T   161M  /jails/dvl-ingress01/usr/home/dvl/src
data04/freshports/dvl-ingress01/freshports                          9.15G  14.2T   205K  /jails/dvl-ingress01/var/db/freshports
data04/freshports/dvl-ingress01/freshports/cache                    3.59M  14.2T   205K  /jails/dvl-ingress01/var/db/freshports/cache
data04/freshports/dvl-ingress01/freshports/cache/html               2.66M  14.2T  2.11M  /jails/dvl-ingress01/var/db/freshports/cache/html
data04/freshports/dvl-ingress01/freshports/cache/spooling            751K  14.2T   427K  /jails/dvl-ingress01/var/db/freshports/cache/spooling
data04/freshports/dvl-ingress01/freshports/message-queues           9.15G  14.2T  35.4M  /jails/dvl-ingress01/var/db/freshports/message-queues
data04/freshports/dvl-ingress01/freshports/message-queues/archive   9.07G  14.2T  9.07G  /jails/dvl-ingress01/var/db/freshports/message-queues/archive
data04/freshports/dvl-ingress01/ingress                             9.79G  14.2T   307K  /jails/dvl-ingress01/var/db/ingress
data04/freshports/dvl-ingress01/ingress/latest_commits               341K  14.2T   213K  /jails/dvl-ingress01/var/db/ingress/latest_commits
data04/freshports/dvl-ingress01/ingress/message-queues               580K  14.2T   358K  /jails/dvl-ingress01/var/db/ingress/message-queues
data04/freshports/dvl-ingress01/ingress/repos                       9.79G  14.2T   239K  /jails/dvl-ingress01/var/db/ingress/repos
data04/freshports/dvl-ingress01/ingress/repos/doc                    733M  14.2T   669M  /jails/dvl-ingress01/var/db/ingress/repos/doc
data04/freshports/dvl-ingress01/ingress/repos/ports                 3.50G  14.2T  3.36G  /jails/dvl-ingress01/var/db/ingress/repos/ports
data04/freshports/dvl-ingress01/ingress/repos/src                   5.58G  14.2T  3.40G  /jails/dvl-ingress01/var/db/ingress/repos/src
data04/freshports/dvl-ingress01/jails                               9.30G  14.2T   222K  /jails/dvl-ingress01/jails
data04/freshports/dvl-ingress01/jails/freshports                    9.30G  14.2T   609M  /jails/dvl-ingress01/jails/freshports
data04/freshports/dvl-ingress01/jails/freshports/ports              8.70G  14.2T  3.90G  /jails/dvl-ingress01/jails/freshports/usr/ports
data04/freshports/dvl-ingress01/modules                             5.53M  14.2T  5.53M  /jails/dvl-ingress01/usr/local/lib/perl5/site_perl/FreshPorts
data04/freshports/dvl-ingress01/scripts                             4.98M  14.2T  4.98M  /jails/dvl-ingress01/usr/local/libexec/freshports
data04/freshports/dvl-nginx01                                       38.1M  14.2T   205K  none
data04/freshports/dvl-nginx01/www                                   37.8M  14.2T   205K  none
data04/freshports/dvl-nginx01/www/freshports                        34.3M  14.2T  21.9M  /jails/dvl-nginx01/usr/local/www/freshports
data04/freshports/dvl-nginx01/www/freshsource                       3.25M  14.2T  3.25M  /jails/dvl-nginx01/usr/local/www/freshsource
data04/freshports/jailed                                            7.17G  14.2T   205K  none
data04/freshports/jailed/dev-nginx01                                2.57G  14.2T   205K  none
data04/freshports/jailed/dev-nginx01/cache                          2.57G  14.2T   205K  /var/db/freshports/cache
data04/freshports/jailed/dev-nginx01/cache/categories               2.50M  14.2T  2.33M  /var/db/freshports/cache/categories
data04/freshports/jailed/dev-nginx01/cache/commits                   555K  14.2T   367K  /var/db/freshports/cache/commits
data04/freshports/jailed/dev-nginx01/cache/daily                    30.4M  14.2T  30.2M  /var/db/freshports/cache/daily
data04/freshports/jailed/dev-nginx01/cache/general                  15.9M  14.2T  15.7M  /var/db/freshports/cache/general
data04/freshports/jailed/dev-nginx01/cache/news                      392K  14.2T   205K  /var/db/freshports/cache/news
data04/freshports/jailed/dev-nginx01/cache/packages                 35.2M  14.2T  35.0M  /var/db/freshports/cache/packages
data04/freshports/jailed/dev-nginx01/cache/pages                     205K  14.2T   205K  /var/db/freshports/cache/pages
data04/freshports/jailed/dev-nginx01/cache/ports                    2.49G  14.2T  2.49G  /var/db/freshports/cache/ports
data04/freshports/jailed/dev-nginx01/cache/spooling                  478K  14.2T   256K  /var/db/freshports/cache/spooling
data04/freshports/jailed/dvl-nginx01                                3.63M  14.2T   205K  none
data04/freshports/jailed/dvl-nginx01/cache                          3.43M  14.2T   333K  /var/db/freshports/cache
data04/freshports/jailed/dvl-nginx01/cache/categories                205K  14.2T   205K  /var/db/freshports/cache/categories
data04/freshports/jailed/dvl-nginx01/cache/commits                   469K  14.2T   299K  /var/db/freshports/cache/commits
data04/freshports/jailed/dvl-nginx01/cache/daily                     205K  14.2T   205K  /var/db/freshports/cache/daily
data04/freshports/jailed/dvl-nginx01/cache/general                   205K  14.2T   205K  /var/db/freshports/cache/general
data04/freshports/jailed/dvl-nginx01/cache/news                      375K  14.2T   205K  /var/db/freshports/cache/news
data04/freshports/jailed/dvl-nginx01/cache/packages                  205K  14.2T   205K  /var/db/freshports/cache/packages
data04/freshports/jailed/dvl-nginx01/cache/pages                     205K  14.2T   205K  /var/db/freshports/cache/pages
data04/freshports/jailed/dvl-nginx01/cache/ports                     682K  14.2T   512K  /var/db/freshports/cache/ports
data04/freshports/jailed/dvl-nginx01/cache/spooling                  427K  14.2T   256K  /var/db/freshports/cache/spooling
data04/freshports/jailed/stage-nginx01                              3.09G  14.2T   205K  none
data04/freshports/jailed/stage-nginx01/cache                        3.09G  14.2T   546K  /var/db/freshports/cache
data04/freshports/jailed/stage-nginx01/cache/categories             3.51M  14.2T  3.32M  /var/db/freshports/cache/categories
data04/freshports/jailed/stage-nginx01/cache/commits                 401K  14.2T   213K  /var/db/freshports/cache/commits
data04/freshports/jailed/stage-nginx01/cache/daily                  51.4M  14.2T  51.2M  /var/db/freshports/cache/daily
data04/freshports/jailed/stage-nginx01/cache/general                15.9M  14.2T  15.7M  /var/db/freshports/cache/general
data04/freshports/jailed/stage-nginx01/cache/news                    392K  14.2T   205K  /var/db/freshports/cache/news
data04/freshports/jailed/stage-nginx01/cache/packages               76.5M  14.2T  76.3M  /var/db/freshports/cache/packages
data04/freshports/jailed/stage-nginx01/cache/pages                   205K  14.2T   205K  /var/db/freshports/cache/pages
data04/freshports/jailed/stage-nginx01/cache/ports                  2.94G  14.2T  2.94G  /var/db/freshports/cache/ports
data04/freshports/jailed/stage-nginx01/cache/spooling                495K  14.2T   256K  /var/db/freshports/cache/spooling
data04/freshports/jailed/test-nginx01                               1.50G  14.2T   205K  none
data04/freshports/jailed/test-nginx01/cache                         1.50G  14.2T   503K  /var/db/freshports/cache
data04/freshports/jailed/test-nginx01/cache/categories              2.35M  14.2T  2.17M  /var/db/freshports/cache/categories
data04/freshports/jailed/test-nginx01/cache/commits                  205K  14.2T   205K  /var/db/freshports/cache/commits
data04/freshports/jailed/test-nginx01/cache/daily                   66.4M  14.2T  66.2M  /var/db/freshports/cache/daily
data04/freshports/jailed/test-nginx01/cache/general                 14.5M  14.2T  14.3M  /var/db/freshports/cache/general
data04/freshports/jailed/test-nginx01/cache/news                     486K  14.2T   299K  /var/db/freshports/cache/news
data04/freshports/jailed/test-nginx01/cache/packages                22.2M  14.2T  22.0M  /var/db/freshports/cache/packages
data04/freshports/jailed/test-nginx01/cache/pages                    205K  14.2T   205K  /var/db/freshports/cache/pages
data04/freshports/jailed/test-nginx01/cache/ports                   1.40G  14.2T  1.40G  /var/db/freshports/cache/ports
data04/freshports/jailed/test-nginx01/cache/spooling                 495K  14.2T   256K  /var/db/freshports/cache/spooling
data04/freshports/stage-ingress01                                   28.1G  14.2T   205K  none
data04/freshports/stage-ingress01/cache                             2.81M  14.2T   205K  /jails/stage-ingress01/var/db/freshports/cache
data04/freshports/stage-ingress01/cache/html                        2.27M  14.2T  1.77M  /jails/stage-ingress01/var/db/freshports/cache/html
data04/freshports/stage-ingress01/cache/spooling                     341K  14.2T   205K  /jails/stage-ingress01/var/db/freshports/cache/spooling
data04/freshports/stage-ingress01/freshports                        13.0G  14.2T   205K  none
data04/freshports/stage-ingress01/freshports/archive                12.7G  14.2T  12.7G  /jails/stage-ingress01/var/db/freshports/message-queues/archive
data04/freshports/stage-ingress01/freshports/message-queues          364M  14.2T   350M  /jails/stage-ingress01/var/db/freshports/message-queues
data04/freshports/stage-ingress01/ingress                           9.86G  14.2T   205K  /jails/stage-ingress01/var/db/ingress
data04/freshports/stage-ingress01/ingress/latest_commits             990K  14.2T   213K  /jails/stage-ingress01/var/db/ingress/latest_commits
data04/freshports/stage-ingress01/ingress/message-queues            3.13M  14.2T   384K  /jails/stage-ingress01/var/db/ingress/message-queues
data04/freshports/stage-ingress01/ingress/repos                     9.85G  14.2T  7.36G  /jails/stage-ingress01/var/db/ingress/repos
data04/freshports/stage-ingress01/jails                              613M  14.2T   222K  /jails/stage-ingress01/jails
data04/freshports/stage-ingress01/jails/freshports                   612M  14.2T   609M  /jails/stage-ingress01/jails/freshports
data04/freshports/stage-ingress01/ports                             4.60G  14.2T  4.01G  /jails/stage-ingress01/jails/freshports/usr/ports
data04/freshports/test-ingress01                                    33.0G  14.2T   205K  none
data04/freshports/test-ingress01/freshports                         16.7G  14.2T  2.95G  /jails/test-ingress01/var/db/freshports
data04/freshports/test-ingress01/freshports/cache                   2.95M  14.2T   205K  /jails/test-ingress01/var/db/freshports/cache
data04/freshports/test-ingress01/freshports/cache/html              2.42M  14.2T  2.07M  /jails/test-ingress01/var/db/freshports/cache/html
data04/freshports/test-ingress01/freshports/cache/spooling           341K  14.2T   205K  /jails/test-ingress01/var/db/freshports/cache/spooling
data04/freshports/test-ingress01/freshports/message-queues          13.0G  14.2T   102M  /jails/test-ingress01/var/db/freshports/message-queues
data04/freshports/test-ingress01/freshports/message-queues/archive  12.8G  14.2T  12.8G  /jails/test-ingress01/var/db/freshports/message-queues/archive
data04/freshports/test-ingress01/ingress                            11.1G  14.2T   273K  /jails/test-ingress01/var/db/ingress
data04/freshports/test-ingress01/ingress/latest_commits              862K  14.2T   213K  /jails/test-ingress01/var/db/ingress/latest_commits
data04/freshports/test-ingress01/ingress/message-queues             3.13M  14.2T   384K  /jails/test-ingress01/var/db/ingress/message-queues
data04/freshports/test-ingress01/ingress/repos                      11.1G  14.2T  7.26G  /jails/test-ingress01/var/db/ingress/repos
data04/freshports/test-ingress01/jails                              5.17G  14.2T   205K  /jails/test-ingress01/jails
data04/freshports/test-ingress01/jails/freshports                   5.17G  14.2T   610M  /jails/test-ingress01/jails/freshports
data04/freshports/test-ingress01/jails/freshports/ports             4.57G  14.2T  3.98G  /jails/test-ingress01/jails/freshports/usr/ports
data04/pg01                                                         25.9G  14.2T   205K  none
data04/pg01/rsyncer-backups                                         25.9G  14.2T  25.9G  /jails/pg01/home/rsyncer/backups
data04/vm                                                           62.1G  14.2T  7.52G  /usr/local/vm
data04/vm/FreeBSD-16.0-CURRENT                                      3.11G  14.2T  3.11G  /usr/local/vm/FreeBSD-16.0-CURRENT
data04/vm/FreeBSD-current                                            563K  14.2T   205K  /usr/local/vm/FreeBSD-current
data04/vm/freebsd-test                                               980M  14.2T   239K  /usr/local/vm/freebsd-test
data04/vm/freebsd-test/disk0                                         979M  14.2T   979M  -
data04/vm/hass                                                      47.2G  14.2T  21.2G  /usr/local/vm/hass
data04/vm/home-assistant                                             352M  14.2T   351M  /usr/local/vm/home-assistant
data04/vm/myguest                                                   2.95G  14.2T  2.94G  /usr/local/vm/myguest
zroot                                                               86.2G  17.5G    96K  /zroot
zroot/ROOT                                                          17.7G  17.5G    96K  none
zroot/ROOT/default                                                  17.7G  17.5G  14.9G  /
zroot/reserved                                                      20.0G  37.5G    96K  /zroot/reserved
zroot/tmp                                                           34.0M  17.5G   152K  /tmp
zroot/usr                                                            532M  17.5G    96K  /usr
zroot/usr/home                                                       532M  17.5G   525M  /usr/home
zroot/usr/ports                                                       96K  17.5G    96K  /usr/ports
zroot/usr/src                                                         96K  17.5G    96K  /usr/src
zroot/var                                                           34.2M  17.5G    96K  /var
zroot/var/audit                                                       96K  17.5G    96K  /var/audit
zroot/var/crash                                                       96K  17.5G    96K  /var/crash
zroot/var/log                                                       29.2M  17.5G  7.34M  /var/log
zroot/var/mail                                                       216K  17.5G   104K  /var/mail
zroot/var/tmp                                                       4.56M  17.5G  3.20M  /var/tmp

dmesg

[18:41 r730-01 dvl ~] % cat /var/run/dmesg.boot 
---<<BOOT>>---
Copyright (c) 1992-2025 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 15.0-RELEASE-p9 GENERIC amd64
FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2)
VT(efifb): resolution 1024x768
WARNING: sysctl vfs.zfs.arc_max is deprecated. Use vfs.zfs.arc.max instead.
CPU microcode: no matching update found
CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz (2300.12-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x306f2  Family=0x6  Model=0x3f  Stepping=2
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x7ffefbff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x21<LAHF,ABM>
  Structured Extended Features=0x37ab<FSGSBASE,TSCADJ,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,NFPUSG>
  Structured Extended Features3=0x9c000400<MD_CLEAR,IBPB,STIBP,L1DFL,SSBD>
  XSAVE Features=0x1<XSAVEOPT>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr
  TSC: P-state invariant, performance statistics
real memory  = 412312666112 (393212 MB)
avail memory = 403117969408 (384443 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: <DELL   PE_SC3  >
FreeBSD/SMP: Multiprocessor System Detected: 72 CPUs
FreeBSD/SMP: 2 package(s) x 18 core(s) x 2 hardware threads
random: registering fast source Intel Secure Key RNG
random: fast provider: "Intel Secure Key RNG"
random: unblocking device.
ioapic0 <Version 2.0> irqs 0-23
ioapic1 <Version 2.0> irqs 24-47
ioapic2 <Version 2.0> irqs 48-71
Launching APs: 1 61 48 17 13 70 45 56 44 43 27 30 35 22 42 16 49 46 64 4 23 51 65 40 15 9 31 57 37 67 66 54 3 39 55 69 60 28 38 8 20 41 24 47 11 21 58 6 10 62 25 34 12 18 5 50 26 14 63 68 2 19 71 32 59 52 53 33 7 36 29
random: entropy device external interface
kbd0 at kbdmux0
efirtc0: <EFI Realtime Clock>
efirtc0: registered as a time-of-day clock, resolution 1.000000s
smbios0: <System Management BIOS> at iomem 0x7af0a000-0x7af0a01e
smbios0: Entry point: v2.1 (32-bit), Version: 2.8, BCD Revision: 2.8
aesni0: <AES-CBC,AES-CCM,AES-GCM,AES-ICM,AES-XTS>
acpi0: <DELL PE_SC3>
acpi0: Power Button (fixed)
cpu0: <ACPI CPU> on acpi0
atrtc0: <AT realtime clock> port 0x70-0x71,0x74-0x77 irq 8 on acpi0
atrtc0: registered as a time-of-day clock, resolution 1.000000s
Event timer "RTC" frequency 32768 Hz quality 0
attimer0: <AT timer> port 0x40-0x43,0x50-0x53 irq 0 on acpi0
Timecounter "i8254" frequency 1193182 Hz quality 0
Event timer "i8254" frequency 1193182 Hz quality 100
hpet0: <High Precision Event Timer> iomem 0xfed00000-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 950
Event timer "HPET" frequency 14318180 Hz quality 350
Event timer "HPET1" frequency 14318180 Hz quality 340
Event timer "HPET2" frequency 14318180 Hz quality 340
Event timer "HPET3" frequency 14318180 Hz quality 340
Event timer "HPET4" frequency 14318180 Hz quality 340
Event timer "HPET5" frequency 14318180 Hz quality 340
Event timer "HPET6" frequency 14318180 Hz quality 340
Event timer "HPET7" frequency 14318180 Hz quality 340
Timecounter "ACPI-fast" frequency 3579545 Hz quality 900
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
pcib0: <ACPI Host-PCI bridge> on acpi0
pci0: <ACPI PCI bus> on pcib0
pci0: <dasp, performance counters> at device 8.2 (no driver attached)
pci0: <dasp, performance counters> at device 9.2 (no driver attached)
pci0: <dasp, performance counters> at device 11.1 (no driver attached)
pci0: <dasp, performance counters> at device 11.2 (no driver attached)
pci0: <dasp, performance counters> at device 16.1 (no driver attached)
pci0: <dasp, performance counters> at device 16.6 (no driver attached)
pci0: <dasp, performance counters> at device 18.1 (no driver attached)
pci0: <dasp, performance counters> at device 18.5 (no driver attached)
pcib1: <ACPI Host-PCI bridge> on acpi0
pci1: <ACPI PCI bus> on pcib1
pci1: <dasp, performance counters> at device 8.2 (no driver attached)
pci1: <dasp, performance counters> at device 9.2 (no driver attached)
pci1: <dasp, performance counters> at device 11.1 (no driver attached)
pci1: <dasp, performance counters> at device 11.2 (no driver attached)
pci1: <dasp, performance counters> at device 16.1 (no driver attached)
pci1: <dasp, performance counters> at device 16.6 (no driver attached)
pci1: <dasp, performance counters> at device 18.1 (no driver attached)
pci1: <dasp, performance counters> at device 18.5 (no driver attached)
acpi_syscontainer0: <System Container> on acpi0
acpi_syscontainer1: <System Container> on acpi0
apei0: <ACPI Platform Error Interface> on acpi0
pcib2: <ACPI Host-PCI bridge> port 0xcf8-0xcff numa-domain 0 on acpi0
pci2: <ACPI PCI bus> numa-domain 0 on pcib2
pcib3: <ACPI PCI-PCI bridge> at device 1.0 numa-domain 0 on pci2
pci3: <ACPI PCI bus> numa-domain 0 on pcib3
AVAGO MegaRAID SAS FreeBSD mrsas driver version: 07.709.04.00-fbsd
mrsas0: <AVAGO Invader SAS Controller> port 0x2000-0x20ff mem 0x92500000-0x9250ffff,0x92400000-0x924fffff at device 0.0 numa-domain 0 on pci3
mrsas0: FW now in Ready state
mrsas0: Using MSI-X with 72 number of vectors
mrsas0: FW supports <96> MSIX vector,Online CPU 72 Current MSIX <72>
mrsas0: mrsas_init_adapter: sc->reply_q_depth 0x740,sc->request_alloc_sz 0x1cf8, sc->reply_alloc_sz 0x3a00,sc->io_frames_alloc_sz 0x3a100
mrsas0: max sge: 0x46, max chain frame size: 0x400, max fw cmd: 0x39f sc->chain_frames_alloc_sz: 0xe7c00
mrsas0: Issuing IOC INIT command to FW.
mrsas0: IOC INIT response received from FW.
mrsas0: System PD created target ID: 0x0
mrsas0: System PD created target ID: 0x1
mrsas0: System PD created target ID: 0x2
mrsas0: System PD created target ID: 0x3
mrsas0: System PD created target ID: 0x4
mrsas0: System PD created target ID: 0x5
mrsas0: System PD created target ID: 0x6
mrsas0: System PD created target ID: 0x7
mrsas0: System PD created target ID: 0x8
mrsas0: System PD created target ID: 0x9
mrsas0: System PD created target ID: 0xa
mrsas0: System PD created target ID: 0xb
mrsas0: System PD created target ID: 0xc
mrsas0: System PD created target ID: 0xd
mrsas0: FW supports: UnevenSpanSupport=1

mrsas0: max_fw_cmds: 927  max_scsi_cmds: 911
mrsas0: MSI-x interrupts setup success
mrsas0: mrsas_ocr_thread
pcib4: <ACPI PCI-PCI bridge> at device 2.0 numa-domain 0 on pci2
pci4: <ACPI PCI bus> numa-domain 0 on pcib4
nvme0: <Generic NVMe Device> mem 0x92300000-0x92303fff at device 0.0 numa-domain 0 on pci4
pcib5: <ACPI PCI-PCI bridge> at device 2.1 numa-domain 0 on pci2
pci5: <ACPI PCI bus> numa-domain 0 on pcib5
nvme1: <Generic NVMe Device> mem 0x92200000-0x92203fff at device 0.0 numa-domain 0 on pci5
pcib6: <ACPI PCI-PCI bridge> at device 2.2 numa-domain 0 on pci2
pci6: <ACPI PCI bus> numa-domain 0 on pcib6
nvme2: <Generic NVMe Device> mem 0x92100000-0x92103fff at device 0.0 numa-domain 0 on pci6
pcib7: <ACPI PCI-PCI bridge> at device 2.3 numa-domain 0 on pci2
pci7: <ACPI PCI bus> numa-domain 0 on pcib7
nvme3: <Generic NVMe Device> mem 0x92000000-0x92003fff at device 0.0 numa-domain 0 on pci7
pcib8: <ACPI PCI-PCI bridge> at device 3.0 numa-domain 0 on pci2
pci8: <ACPI PCI bus> numa-domain 0 on pcib8
igb0: <Intel(R) I350 (Copper)> mem 0x91e00000-0x91efffff,0x91f0c000-0x91f0ffff at device 0.0 numa-domain 0 on pci8
igb0: EEPROM V1.67-0 Option ROM V19-b5-p12 eTrack 0x80000faa
igb0: Using 1024 TX descriptors and 1024 RX descriptors
igb0: Using 8 RX queues 8 TX queues
igb0: Using MSI-X interrupts with 9 vectors
igb0: Ethernet address: ec:f4:bb:ef:c9:54
igb0: netmap queues/slots: TX 8/1024, RX 8/1024
igb1: <Intel(R) I350 (Copper)> mem 0x91d00000-0x91dfffff,0x91f08000-0x91f0bfff at device 0.1 numa-domain 0 on pci8
igb1: EEPROM V1.67-0 Option ROM V19-b5-p12 eTrack 0x80000faa
igb1: Using 1024 TX descriptors and 1024 RX descriptors
igb1: Using 8 RX queues 8 TX queues
igb1: Using MSI-X interrupts with 9 vectors
igb1: Ethernet address: ec:f4:bb:ef:c9:55
igb1: netmap queues/slots: TX 8/1024, RX 8/1024
igb2: <Intel(R) I350 (Copper)> mem 0x91c00000-0x91cfffff,0x91f04000-0x91f07fff at device 0.2 numa-domain 0 on pci8
igb2: EEPROM V1.67-0 Option ROM V19-b5-p12 eTrack 0x80000faa
igb2: Using 1024 TX descriptors and 1024 RX descriptors
igb2: Using 8 RX queues 8 TX queues
igb2: Using MSI-X interrupts with 9 vectors
igb2: Ethernet address: ec:f4:bb:ef:c9:56
igb2: netmap queues/slots: TX 8/1024, RX 8/1024
igb3: <Intel(R) I350 (Copper)> mem 0x91b00000-0x91bfffff,0x91f00000-0x91f03fff at device 0.3 numa-domain 0 on pci8
igb3: EEPROM V1.67-0 Option ROM V19-b5-p12 eTrack 0x80000faa
igb3: Using 1024 TX descriptors and 1024 RX descriptors
igb3: Using 8 RX queues 8 TX queues
igb3: Using MSI-X interrupts with 9 vectors
igb3: Ethernet address: ec:f4:bb:ef:c9:57
igb3: netmap queues/slots: TX 8/1024, RX 8/1024
pcib9: <ACPI PCI-PCI bridge> at device 3.2 numa-domain 0 on pci2
pci9: <ACPI PCI bus> numa-domain 0 on pcib9
nvme4: <Generic NVMe Device> mem 0x91a00000-0x91a03fff,0x91a04000-0x91a040ff at device 0.0 numa-domain 0 on pci9
pci2: <unknown> at device 17.0 (no driver attached)
ahci0: <Intel Wellsburg AHCI SATA controller> port 0x3078-0x307f,0x308c-0x308f,0x3070-0x3077,0x3088-0x308b,0x3040-0x305f mem 0x92601000-0x926017ff at device 17.4 numa-domain 0 on pci2
ahci0: AHCI v1.30 with 4 6Gbps ports, Port Multiplier not supported
ahcich0: <AHCI channel> at channel 0 on ahci0
ahcich1: <AHCI channel> at channel 1 on ahci0
ahcich2: <AHCI channel> at channel 2 on ahci0
ahcich3: <AHCI channel> at channel 3 on ahci0
ahciem0: <AHCI enclosure management bridge> on ahci0
pci2: <simple comms> at device 22.0 (no driver attached)
pci2: <simple comms> at device 22.1 (no driver attached)
ehci0: <Intel Wellsburg USB 2.0 controller> mem 0x92603000-0x926033ff at device 26.0 numa-domain 0 on pci2
usbus0: EHCI version 1.0
usbus0 numa-domain 0 on ehci0
usbus0: 480Mbps High Speed USB v2.0
pcib10: <PCI-PCI bridge> at device 28.0 numa-domain 0 on pci2
pci10: <PCI bus> numa-domain 0 on pcib10
pcib11: <ACPI PCI-PCI bridge> at device 28.7 numa-domain 0 on pci2
pci11: <ACPI PCI bus> numa-domain 0 on pcib11
pcib12: <PCI-PCI bridge> at device 0.0 numa-domain 0 on pci11
pci12: <PCI bus> numa-domain 0 on pcib12
pcib13: <PCI-PCI bridge> at device 0.0 numa-domain 0 on pci12
pci13: <PCI bus> numa-domain 0 on pcib13
pcib14: <PCI-PCI bridge> at device 0.0 numa-domain 0 on pci13
pci14: <PCI bus> numa-domain 0 on pcib14
vgapci0: <VGA-compatible display> mem 0x90000000-0x90ffffff,0x91800000-0x91803fff,0x91000000-0x917fffff at device 0.0 numa-domain 0 on pci14
vgapci0: Boot video device
ehci1: <Intel Wellsburg USB 2.0 controller> mem 0x92602000-0x926023ff at device 29.0 numa-domain 0 on pci2
usbus1: EHCI version 1.0
usbus1 numa-domain 0 on ehci1
usbus1: 480Mbps High Speed USB v2.0
isab0: <PCI-ISA bridge> at device 31.0 numa-domain 0 on pci2
isa0: <ISA bus> numa-domain 0 on isab0
ahci1: <Intel Wellsburg AHCI SATA controller> port 0x3068-0x306f,0x3084-0x3087,0x3060-0x3067,0x3080-0x3083,0x3020-0x303f mem 0x92600000-0x926007ff at device 31.2 numa-domain 0 on pci2
ahci1: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported
ahcich4: <AHCI channel> at channel 0 on ahci1
ahcich5: <AHCI channel> at channel 1 on ahci1
ahcich6: <AHCI channel> at channel 2 on ahci1
ahcich7: <AHCI channel> at channel 3 on ahci1
ahcich8: <AHCI channel> at channel 4 on ahci1
ahcich9: <AHCI channel> at channel 5 on ahci1
ahciem1: <AHCI enclosure management bridge> on ahci1
pcib15: <ACPI Host-PCI bridge> numa-domain 1 on acpi0
pci15: <ACPI PCI bus> numa-domain 1 on pcib15
pcib16: <ACPI PCI-PCI bridge> at device 1.0 numa-domain 1 on pci15
pci16: <ACPI PCI bus> numa-domain 1 on pcib16
ix0: <Intel(R) X520 82599 (Dual SFP+)> port 0x9020-0x903f mem 0xc8600000-0xc86fffff,0xc8704000-0xc8707fff at device 0.0 numa-domain 1 on pci16
WARNING: Intel (R) Network Connections are quality tested using Intel (R) Ethernet Optics. Using untested modules is not supported and may cause unstable operation or damage to the module or the adapter. Intel Corporation is not responsible for any harm caused by using untested modules.
ix0: Using 2048 TX descriptors and 2048 RX descriptors
ix0: Using 16 RX queues 16 TX queues
ix0: Using MSI-X interrupts with 17 vectors
ix0: allocated for 16 queues
ix0: allocated for 16 rx queues
ix0: Ethernet address: a0:36:9f:83:e1:14
ix0: PCI Express Bus: Speed 5.0GT/s Width x8
ix0: Option ROM V19-b5-p12 eTrack 0x8000095d
ix0: netmap queues/slots: TX 16/2048, RX 16/2048
ix1: <Intel(R) X520 82599 (Dual SFP+)> port 0x9000-0x901f mem 0xc8500000-0xc85fffff,0xc8700000-0xc8703fff at device 0.1 numa-domain 1 on pci16
ix1: Using 2048 TX descriptors and 2048 RX descriptors
ix1: Using 16 RX queues 16 TX queues
ix1: Using MSI-X interrupts with 17 vectors
ix1: allocated for 16 queues
ix1: allocated for 16 rx queues
ix1: Ethernet address: a0:36:9f:83:e1:16
ix1: PCI Express Bus: Speed 5.0GT/s Width x8
ix1: Option ROM V19-b5-p12 eTrack 0x8000095d
ix1: netmap queues/slots: TX 16/2048, RX 16/2048
pcib17: <ACPI PCI-PCI bridge> at device 2.0 numa-domain 1 on pci15
pci17: <ACPI PCI bus> numa-domain 1 on pcib17
ahci2: <ASMedia ASM1062 AHCI SATA controller> port 0x8028-0x802f,0x8034-0x8037,0x8020-0x8027,0x8030-0x8033,0x8000-0x801f mem 0xc8400000-0xc84001ff at device 0.0 numa-domain 1 on pci17
ahci2: AHCI v1.20 with 2 6Gbps ports, Port Multiplier supported
ahci2: quirks=0xc00000<NOCCS,NOAUX>
ahcich10: <AHCI channel> at channel 0 on ahci2
ahcich11: <AHCI channel> at channel 1 on ahci2
pcib18: <ACPI PCI-PCI bridge> at device 3.0 numa-domain 1 on pci15
pci18: <ACPI PCI bus> numa-domain 1 on pcib18
nvme5: <Generic NVMe Device> mem 0xc8300000-0xc8303fff at device 0.0 numa-domain 1 on pci18
pcib19: <ACPI PCI-PCI bridge> at device 3.1 numa-domain 1 on pci15
pci19: <ACPI PCI bus> numa-domain 1 on pcib19
nvme6: <Generic NVMe Device> mem 0xc8200000-0xc8203fff at device 0.0 numa-domain 1 on pci19
pcib20: <ACPI PCI-PCI bridge> at device 3.2 numa-domain 1 on pci15
pci20: <ACPI PCI bus> numa-domain 1 on pcib20
nvme7: <Generic NVMe Device> mem 0xc8100000-0xc8103fff at device 0.0 numa-domain 1 on pci20
pcib21: <ACPI PCI-PCI bridge> at device 3.3 numa-domain 1 on pci15
pci21: <ACPI PCI bus> numa-domain 1 on pcib21
nvme8: <Generic NVMe Device> mem 0xc8000000-0xc8003fff at device 0.0 numa-domain 1 on pci21
uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
orm0: <ISA Option ROM> at iomem 0xed800-0xf17ff pnpid ORM0000 on isa0
vga0: <Generic ISA VGA> at port 0x3d0-0x3db iomem 0xb8000-0xbffff pnpid PNP0900 on isa0
coretemp0: <CPU On-Die Thermal Sensors> on cpu0
est0: <Enhanced SpeedStep Frequency Control> on cpu0
cpufreq0: <CPU frequency control> on cpu0
cpufreq1: <CPU frequency control> on cpu1
cpufreq2: <CPU frequency control> on cpu2
cpufreq3: <CPU frequency control> on cpu3
cpufreq4: <CPU frequency control> on cpu4
cpufreq5: <CPU frequency control> on cpu5
cpufreq6: <CPU frequency control> on cpu6
cpufreq7: <CPU frequency control> on cpu7
cpufreq8: <CPU frequency control> on cpu8
cpufreq9: <CPU frequency control> on cpu9
cpufreq10: <CPU frequency control> on cpu10
cpufreq11: <CPU frequency control> on cpu11
cpufreq12: <CPU frequency control> on cpu12
cpufreq13: <CPU frequency control> on cpu13
cpufreq14: <CPU frequency control> on cpu14
cpufreq15: <CPU frequency control> on cpu15
cpufreq16: <CPU frequency control> on cpu16
cpufreq17: <CPU frequency control> on cpu17
cpufreq18: <CPU frequency control> on cpu18
cpufreq19: <CPU frequency control> on cpu19
cpufreq20: <CPU frequency control> on cpu20
cpufreq21: <CPU frequency control> on cpu21
cpufreq22: <CPU frequency control> on cpu22
cpufreq23: <CPU frequency control> on cpu23
cpufreq24: <CPU frequency control> on cpu24
cpufreq25: <CPU frequency control> on cpu25
cpufreq26: <CPU frequency control> on cpu26
cpufreq27: <CPU frequency control> on cpu27
cpufreq28: <CPU frequency control> on cpu28
cpufreq29: <CPU frequency control> on cpu29
cpufreq30: <CPU frequency control> on cpu30
cpufreq31: <CPU frequency control> on cpu31
cpufreq32: <CPU frequency control> on cpu32
cpufreq33: <CPU frequency control> on cpu33
cpufreq34: <CPU frequency control> on cpu34
cpufreq35: <CPU frequency control> on cpu35
cpufreq36: <CPU frequency control> on cpu36
cpufreq37: <CPU frequency control> on cpu37
cpufreq38: <CPU frequency control> on cpu38
cpufreq39: <CPU frequency control> on cpu39
cpufreq40: <CPU frequency control> on cpu40
cpufreq41: <CPU frequency control> on cpu41
cpufreq42: <CPU frequency control> on cpu42
cpufreq43: <CPU frequency control> on cpu43
cpufreq44: <CPU frequency control> on cpu44
cpufreq45: <CPU frequency control> on cpu45
cpufreq46: <CPU frequency control> on cpu46
cpufreq47: <CPU frequency control> on cpu47
cpufreq48: <CPU frequency control> on cpu48
cpufreq49: <CPU frequency control> on cpu49
cpufreq50: <CPU frequency control> on cpu50
cpufreq51: <CPU frequency control> on cpu51
cpufreq52: <CPU frequency control> on cpu52
cpufreq53: <CPU frequency control> on cpu53
cpufreq54: <CPU frequency control> on cpu54
cpufreq55: <CPU frequency control> on cpu55
cpufreq56: <CPU frequency control> on cpu56
cpufreq57: <CPU frequency control> on cpu57
cpufreq58: <CPU frequency control> on cpu58
cpufreq59: <CPU frequency control> on cpu59
cpufreq60: <CPU frequency control> on cpu60
cpufreq61: <CPU frequency control> on cpu61
cpufreq62: <CPU frequency control> on cpu62
cpufreq63: <CPU frequency control> on cpu63
cpufreq64: <CPU frequency control> on cpu64
cpufreq65: <CPU frequency control> on cpu65
cpufreq66: <CPU frequency control> on cpu66
cpufreq67: <CPU frequency control> on cpu67
cpufreq68: <CPU frequency control> on cpu68
cpufreq69: <CPU frequency control> on cpu69
cpufreq70: <CPU frequency control> on cpu70
cpufreq71: <CPU frequency control> on cpu71
Timecounter "TSC-low" frequency 1149998212 Hz quality 1000
Timecounters tick every 1.000 msec
ugen0.1: <Intel EHCI root HUB> at usbus0
ugen1.1: <Intel EHCI root HUB> at usbus1
uhub0 numa-domain 0 on usbus0
uhub0: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus0
uhub1 numa-domain 0 on usbus1
uhub1: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus1
ZFS filesystem version: 5
ZFS storage pool version: features support (5000)
mrsas0: Disestablish mrsas intr hook
nvme4: Allocated 200MB host memory buffer
nvme5: Allocated 64MB host memory buffer
nvme8: Allocated 64MB host memory buffer
nda0 at nvme0 bus 0 scbus16 target 0 lun 1
nda0: <Samsung SSD 990 PRO 4TB 4B2QJXD7 S7KGNU0Y722875X>
nda0: Serial Number S7KGNU0Y722875X
nda0: nvme version 2.0
nda0: 3815447MB (7814037168 512 byte sectors)
nda1 at nvme1 bus 0 scbus17 target 0 lun 1
nda1: <Samsung SSD 990 PRO 4TB 4B2QJXD7 S7KGNU0Y915666E>
nda1: Serial Number S7KGNU0Y915666E
nda1: nvme version 2.0
nda1: 3815447MB (7814037168 512 byte sectors)
nda2 at nvme2 bus 0 scbus18 target 0 lun 1
nda2: <Samsung SSD 990 PRO 4TB 4B2QJXD7 S7KGNU0Y912937J>
nda2: Serial Number S7KGNU0Y912937J
nda2: nvme version 2.0
nda2: 3815447MB (7814037168 512 byte sectors)
nda3 at nvme3 bus 0 scbus19 target 0 lun 1
nda3: <Samsung SSD 990 PRO 4TB 4B2QJXD7 S7KGNU0Y912955D>
nda3: Serial Number S7KGNU0Y912955D
nda3: nvme version 2.0
nda3: 3815447MB (7814037168 512 byte sectors)
nda4 at nvme4 bus 0 scbus20 target 0 lun 1
nda4: <WDC WDS250G2B0C-00PXH0 233010WD 21280E800995>
nda4: Serial Number 21280E800995
nda4: nvme version 1.4
nda4: 238475MB (488397168 512 byte sectors)
nda5 at nvme5 bus 0 scbus21 target 0 lun 1
nda5: <Samsung SSD 990 EVO Plus 4TB 2B2QKXG7 S7U8NJ0Y716854P>
nda5: Serial Number S7U8NJ0Y716854P
nda5: nvme version 2.0
nda5: 3815447MB (7814037168 512 byte sectors)
nda6 at nvme6 bus 0 scbus22 target 0 lun 1
nda6: <Samsung SSD 980 PRO with Heatsink 1TB 4B2QGXA7 S6WSNJ0T208743F>
nda6: Serial Number S6WSNJ0T208743F
nda6: nvme version 1.3
nda6: 953869MB (1953525168 512 byte sectors)
nda7 at nvme7 bus 0 scbus23 target 0 lun 1
nda7: <Samsung SSD 980 PRO with Heatsink 1TB 4B2QGXA7 S6WSNJ0T207774T>
nda7: Serial Number S6WSNJ0T207774T
nda7: nvme version 1.3
nda7: 953869MB (1953525168 512 byte sectors)
nda8 at nvme8 bus 0 scbus24 target 0 lun 1
nda8: <Samsung SSD 990 EVO Plus 4TB 2B2QKXG7 S7U8NJ0Y716801F>
nda8: Serial Number S7U8NJ0Y716801F
nda8: nvme version 2.0
nda8: 3815447MB (7814037168 512 byte sectors)
ada0 at ahcich8 bus 0 scbus11 target 0 lun 0
ada0: <SATADOM-ML 3MG2-P M150821i> ACS-2 ATA SATA 3.x device
ada0: Serial Number 20170718AA0000185556
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 1024bytes)
ada0: Command Queueing enabled
ada0: 118288MB (242255664 512 byte sectors)
ada1 at ahcich9 bus 0 scbus12 target 0 lun 0
ada1: <SATADOM-ML 3MG2-P M150821i> ACS-2 ATA SATA 3.x device
ada1: Serial Number 20170719AA1178164201
ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 1024bytes)
ada1: Command Queueing enabled
ada1: 118288MB (242255664 512 byte sectors)
ses0 at ahciem0 bus 0 scbus6 target 0 lun 0
ses0: <AHCI SGPIO Enclosure 2.00 0001> SEMB S-E-S 2.00 device
ses0: SEMB SES Device
ses1 at ahciem1 bus 0 scbus13 target 0 lun 0
ses1: <AHCI SGPIO Enclosure 2.00 0001> SEMB S-E-S 2.00 device
ses1: SEMB SES Device
da0 at mrsas0 bus 1 scbus1 target 0 lun 0
da0: <TOSHIBA PX05SMB080Y AS0B> Fixed Direct Access SPC-4 SCSI device
da0: Serial Number Y7P0A02LTEVE
da0: 150.000MB/s transfers
da0: 763097MB (1562824368 512 byte sectors)
ses1: ada0,pass15 in 'Slot 04', SATA Slot: scbus11 target 0
ses1: ada1,pass16 in 'Slot 05', SATA Slot: scbus12 target 0
da2 at mrsas0 bus 1 scbus1 target 2 lun 0
da2: <TOSHIBA PX05SMB080Y AS0B> Fixed Direct Access SPC-4 SCSI device
da2: Serial Number Y7P0A033TEVE
da2: 150.000MB/s transfers
da2: 763097MB (1562824368 512 byte sectors)
da4 at mrsas0 bus 1 scbus1 target 4 lun 0
da4: <TOSHIBA PX05SMB080Y AS0B> Fixed Direct Access SPC-4 SCSI device
da4: Serial Number Y7P0A02QTEVE
da4: 150.000MB/s transfers
da4: 763097MB (1562824368 512 byte sectors)
da1 at mrsas0 bus 1 scbus1 target 1 lun 0
da1: <TOSHIBA PX05SMB080Y AS0B> Fixed Direct Access SPC-4 SCSI device
da1: Serial Number Y7P0A02MTEVE
da1: 150.000MB/s transfers
da1: 763097MB (1562824368 512 byte sectors)
da6 at mrsas0 bus 1 scbus1 target 6 lun 0
da6: <TOSHIBA PX05SMB080Y AS0B> Fixed Direct Access SPC-4 SCSI device
da6: Serial Number Y7P0A02GTEVE
da6: 150.000MB/s transfers
da6: 763097MB (1562824368 512 byte sectors)
da3 at mrsas0 bus 1 scbus1 target 3 lun 0
da3: <TOSHIBA PX05SMB080Y AS0B> Fixed Direct Access SPC-4 SCSI device
da3: Serial Number Y7P0A022TEVE
da3: 150.000MB/s transfers
da3: 763097MB (1562824368 512 byte sectors)
da5 at mrsas0 bus 1 scbus1 target 5 lun 0
da5: <TOSHIBA PX05SMB080Y AS0B> Fixed Direct Access SPC-4 SCSI device
da5: Serial Number Y7P0A02ATEVE
da5: 150.000MB/s transfers
da5: 763097MB (1562824368 512 byte sectors)
da7 at mrsas0 bus 1 scbus1 target 7 lun 0
da7: <TOSHIBA PX05SMB080Y AS0B> Fixed Direct Access SPC-4 SCSI device
da7: Serial Number Y7P0A02DTEVE
da7: 150.000MB/s transfers
da7: 763097MB (1562824368 512 byte sectors)
da13 at mrsas0 bus 1 scbus1 target 13 lun 0
da13: <ATA Samsung SSD 870 3B6Q> Fixed Direct Access SPC-4 SCSI device
da13: Serial Number S757NS0Y700760R
da13: 150.000MB/s transfers
da13: 3815447MB (7814037168 512 byte sectors)
da13: quirks=0x8<4K>
da12 at mrsas0 bus 1 scbus1 target 12 lun 0
da12: <ATA Samsung SSD 870 3B6Q> Fixed Direct Access SPC-4 SCSI device
da12: Serial Number S757NS0Y700758M
da12: 150.000MB/s transfers
da12: 3815447MB (7814037168 512 byte sectors)
da12: quirks=0x8<4K>
da11 at mrsas0 bus 1 scbus1 target 11 lun 0
da11: <ATA WDC  WDS400T2B0A 20WD> Fixed Direct Access SPC-4 SCSI device
da11: Serial Number 230151800473
da11: 150.000MB/s transfers
da11: 3815447MB (7814037168 512 byte sectors)
da8 at mrsas0 bus 1 scbus1 target 8 lun 0
da8: <ATA WDC  WDS400T2B0A 20WD> Fixed Direct Access SPC-4 SCSI device
da8: Serial Number 230151801478
da8: 150.000MB/s transfers
da8: 3815447MB (7814037168 512 byte sectors)
da9 at mrsas0 bus 1 scbus1 target 9 lun 0
da9: <ATA WDC  WDS400T2B0A 20WD> Fixed Direct Access SPC-4 SCSI device
da9: Serial Number 230151801284
da9: 150.000MB/s transfers
da9: 3815447MB (7814037168 512 byte sectors)
da10 at mrsas0 bus 1 scbus1 target 10 lun 0
da10: <ATA WDC  WDS400T2B0A 20WD> Fixed Direct Access SPC-4 SCSI device
da10: Serial Number 22492H800867
da10: 150.000MB/s transfers
da10: 3815447MB (7814037168 512 byte sectors)
GEOM_MIRROR: Device mirror/swap launched (2/2).
Trying to mount root from zfs:zroot/ROOT/default []...
uhub0: 2 ports with 2 removable, self powered
uhub1: 2 ports with 2 removable, self powered
ugen0.2: <vendor 0x8087 product 0x800a> at usbus0
uhub2 numa-domain 0 on uhub0
uhub2: <vendor 0x8087 product 0x800a, class 9/0, rev 2.00/0.05, addr 2> on usbus0
ugen1.2: <vendor 0x8087 product 0x8002> at usbus1
uhub3 numa-domain 0 on uhub1
uhub3: <vendor 0x8087 product 0x8002, class 9/0, rev 2.00/0.05, addr 2> on usbus1
Root mount waiting for: usbus0 usbus1
uhub2: 6 ports with 6 removable, self powered
uhub3: 8 ports with 8 removable, self powered
ugen0.3: <no manufacturer Gadget USB HUB> at usbus0
uhub4 numa-domain 0 on uhub2
uhub4: <no manufacturer Gadget USB HUB, class 9/0, rev 2.00/0.00, addr 3> on usbus0
ugen1.3: <ATEN UC-10KM V1.3.124> at usbus1
usbhid0 numa-domain 0 on uhub3
usbhid0: <ATEN UC-10KM V1.3.124, class 0/0, rev 1.10/1.00, addr 3> on usbus1
hidbus0: <HID bus> numa-domain 0 on usbhid0
hkbd0: <ATEN UC-10KM V1.3.124 Keyboard> numa-domain 0 on hidbus0
kbd1 at hkbd0
usbhid1 numa-domain 0 on uhub3
usbhid1: <ATEN UC-10KM V1.3.124, class 0/0, rev 1.10/1.00, addr 3> on usbus1
hidbus1: <HID bus> numa-domain 0 on usbhid1
uhub4: 6 ports with 6 removable, self powered
GEOM_ELI: Device mirror/swap.eli created.
GEOM_ELI: Encryption: AES-XTS 128
GEOM_ELI:     Crypto: accelerated software
acpi_wmi0: <ACPI-WMI mapping> on acpi0
acpi_wmi0: cannot find EC device
acpi_wmi1: <ACPI-WMI mapping> on acpi0
acpi_wmi1: cannot find EC device
hms0: <ATEN UC-10KM V1.3.124 Mouse> numa-domain 0 on hidbus1
hms0: 5 buttons and [XYW] coordinates ID=0
CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz (2300.00-MHz K8-class CPU)
  Origin="GenuineIntel"  Id=0x306f2  Family=0x6  Model=0x3f  Stepping=2
  Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
  Features2=0x7ffefbff<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,SDBG,FMA,CX16,xTPR,PDCM,PCID,DCA,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND>
  AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
  AMD Features2=0x21<LAHF,ABM>
  Structured Extended Features=0x37ab<FSGSBASE,TSCADJ,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,PQM,NFPUSG>
  Structured Extended Features3=0x9c000400<MD_CLEAR,IBPB,STIBP,L1DFL,SSBD>
  XSAVE Features=0x1<XSAVEOPT>
  VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr
  TSC: P-state invariant, performance statistics
bridge0: Ethernet address: 58:9c:fc:10:19:8c
bridge0: link state changed to UP
ix0: promiscuous mode enabled
lo0: link state changed to UP
lo1: link state changed to UP
lo2: link state changed to UP
ix0: link state changed to UP
pflog0: promiscuous mode enabled

sesutil show

[18:41 r730-01 dvl ~] % sudo sesutil show
ses0: ; ID: 3061686369656d30
Desc            Dev     Model                     Ident                Size/Status
Slot 00         -       -                         -                    Not Installed
Slot 01         -       -                         -                    Not Installed
Slot 02         -       -                         -                    Not Installed
Slot 03         -       -                         -                    Not Installed

ses1: ; ID: 3061686369656d31
Desc            Dev     Model                     Ident                Size/Status
Slot 00         -       -                         -                    Not Installed
Slot 01         -       -                         -                    Not Installed
Slot 02         -       -                         -                    Not Installed
Slot 03         -       -                         -                    Not Installed
Slot 04         ada0    SATADOM-ML 3MG2-P         20170718AA0000185556 124G
Slot 05         ada1    SATADOM-ML 3MG2-P         20170719AA1178164201 124G

jls

[18:41 r730-01 dvl ~] % jls
   JID  IP Address      Hostname                      Path
     1  10.55.0.73      dns1.int.unixathome.org       /jails/dns1
     2  10.55.0.44      cliff2.int.unixathome.org     /jails/cliff2
     3  10.55.0.151     mysql01.int.unixathome.org    /jails/mysql01
     4  10.55.0.89      mysql02.int.unixathome.org    /jails/mysql02
     5  10.55.0.150     pg01.int.unixathome.org       /jails/pg01
     6  10.55.0.32      pg02.int.unixathome.org       /jails/pg02
     7  10.55.0.34      pg03.int.unixathome.org       /jails/pg03
     8                  pkg01.int.unixathome.org      /jails/pkg01
     9  10.55.0.37      dev-ingress01.int.unixathome. /jails/dev-ingress01
    10  10.55.0.37      freshports                    /jails/dev-ingress01/jails/freshports
    11  10.55.0.81      dvl-ingress01.int.unixathome. /jails/dvl-ingress01
    12  10.55.0.81      freshports                    /jails/dvl-ingress01/jails/freshports
    13  10.55.0.40      test-ingress01.int.unixathome /jails/test-ingress01
    14  10.55.0.40      freshports                    /jails/test-ingress01/jails/freshports
    15  10.55.0.45      stage-ingress01.int.unixathom /jails/stage-ingress01
    16  10.55.0.45      freshports                    /jails/stage-ingress01/jails/freshports
    17  10.55.0.4       bacula.int.unixathome.org     /jails/bacula
    19  10.55.0.54      certs-rsync.int.unixathome.or /jails/certs-rsync
    20  10.55.0.112     certs.int.unixathome.org      /jails/certs
    21  10.55.0.30      git.langille.org              /jails/git
    22  10.55.0.6       svn.int.unixathome.org        /jails/svn
    23  10.55.0.3       webserver.int.unixathome.org  /jails/webserver
    24  10.55.0.10      mqtt01.int.unixathome.org     /jails/mqtt01
    25  10.55.0.33      bacula-sd-02.int.unixathome.o /jails/bacula-sd-02
    26  10.55.0.28      talos.int.unixathome.org      /jails/talos
    27  10.55.0.50      samdrucker.int.unixathome.org /jails/samdrucker
    28  10.55.0.49      bacula-sd-03.int.unixathome.o /jails/bacula-sd-03
    29  10.55.0.16      mydev.int.unixathome.org      /jails/mydev
    30  10.55.0.31      jail_within_jail.int.unixatho /jails/jail_within_jail
    31  10.55.0.24      serpico.int.unixathome.org    /jails/serpico
    32  10.55.0.53      dns-hidden-master.int.unixath /jails/dns-hidden-master
    33  10.55.0.20      nsnotify.int.unixathome.org   /jails/nsnotify
    34  10.55.0.131     unifi01.int.unixathome.org    /jails/unifi01
    37  10.55.0.42      test-nginx01.int.unixathome.o /jails/test-nginx01
    40  10.55.0.82      dvl-nginx01.int.unixathome.or /jails/dvl-nginx01
   380  10.55.0.46      stage-nginx01.int.unixathome. /jails/stage-nginx01
   381  10.55.0.39      dev-nginx01.int.unixathome.or /jails/dev-nginx01
  1034  10.55.0.27      besser.int.unixathome.org     /jails/besser

camcontrol devlist

[18:43 r730-01 dvl ~] % sudo camcontrol devlist
         at scbus1 target 0 lun 0 (pass0,da0)
         at scbus1 target 1 lun 0 (pass1,da1)
         at scbus1 target 2 lun 0 (pass2,da2)
         at scbus1 target 3 lun 0 (pass3,da3)
         at scbus1 target 4 lun 0 (pass4,da4)
         at scbus1 target 5 lun 0 (pass5,da5)
         at scbus1 target 6 lun 0 (pass6,da6)
         at scbus1 target 7 lun 0 (pass7,da7)
        at scbus1 target 8 lun 0 (pass8,da8)
        at scbus1 target 9 lun 0 (pass9,da9)
        at scbus1 target 10 lun 0 (pass10,da10)
        at scbus1 target 11 lun 0 (pass11,da11)
         at scbus1 target 12 lun 0 (pass12,da12)
         at scbus1 target 13 lun 0 (pass13,da13)
   at scbus6 target 0 lun 0 (ses0,pass14)
       at scbus11 target 0 lun 0 (pass15,ada0)
       at scbus12 target 0 lun 0 (pass16,ada1)
   at scbus13 target 0 lun 0 (ses1,pass17)
  at scbus16 target 0 lun 1 (pass18,nda0)
  at scbus17 target 0 lun 1 (pass19,nda1)
  at scbus18 target 0 lun 1 (pass20,nda2)
  at scbus19 target 0 lun 1 (pass21,nda3)
  at scbus20 target 0 lun 1 (pass22,nda4)
  at scbus21 target 0 lun 1 (pass23,nda5)
  at scbus22 target 0 lun 1 (pass24,nda6)
  at scbus23 target 0 lun 1 (pass25,nda7)
  at scbus24 target 0 lun 1 (pass26,nda8)

/etc/fstab

[18:43 r730-01 dvl ~] % cat /etc/fstab
# Device		Mountpoint	FStype	Options		Dump	Pass#
/dev/mirror/swap.eli		none	swap	sw		0	0

2026-06-02 19:09:49 UTC

From April 24–26, the FreeBSD community held its first regional hackathon in the Frankfurt area (Germany). The three-day event brought together 25 attendees, including seasoned project committers and guests interested in learning more about the FreeBSD community.

Participants traveled from several European countries to gather at the sponsored Innovation Lab venue. The location proved ideal for an international gathering, offering excellent transit connections across Europe via the Frankfurt (FRA) airport, regional train networks, and major highways. Hacking sessions began early in the morning and regularly continued late into the evening.

The event resulted in several notable contributions to the Project:

120 Bugs Closed: Attendees made significant progress on the FreeBSD PR queue, closing 120 bugs across the base system and ports collection.
SBOM Implementation: Significant work was completed to successfully implement Software Bill of Materials (SBOM) functionality within FreeBSD, enhancing the platform’s supply chain security and compliance capabilities.
German Translation of Sylve: Participants completed the German translation of Sylve, improving accessibility for local users.

In addition to the technical work, the event served as an opportunity for networking and collaboration across different areas of the Project. The FreeBSD Foundation sponsored a midday barbecue lunch, allowing attendees to discuss ongoing development and future planning in an informal setting.

We want to thank our location sponsors for hosting the event, the FreeBSD Foundation for providing financial support for the catering, and all the participants who traveled to make this hackathon a success. Given the productivity and positive turnout, we are looking forward to doing this again next year.

The post Recap of the April 2026 Frankfurt Area FreeBSD Hackathon – Sven Ruediger first appeared on FreeBSD Foundation.

2025-10-31 17:25:58 UTC

Introduction

Searching the internet has been both increasingly cumbersome and frightening due to privacy concerns with many of the major search engine providers (such as Google or Bing). Thankfully there are some other good options like Startpage, Qwant, and Mojeek. Some of them use results provided by the major providers like Google, and some of them are more independent. However, another option exists, and that’s to use an application like SearXNG that acts as a meta-search engine, “aggregating the results of other search engines” without “storing information about its users”.

I started using SearXNG quite some time ago by choosing a public instance, but have recently gone a bit further and installed my own self-hosted version of it on one of my Gentoo Linux servers. In this article, I’m going to outline the process of installing, configuring, and running a self-hosted SearXNG instance along with some troubleshooting tips and “gotchas” to avoid. Though the details are specific to Gentoo Linux, the concepts should be readily applicable to other Linux distributions.

For my setup, I chose to install SearXNG in the uWSGI application server and proxy it via the Apache web server using the mod_proxy_uwsgi module. The flow of data follows the following design:

For the remainder of this article, I will use the pretend domain name of my-secret-search-engine.com. Any place where that domain is listed, replace it with your respective domain name or IP address of your server.

Installation – Prerequisites

To start, SearXNG should run as a system user, so that user should be created accordingly:

useradd -s /bin/bash --system -m --home-dir /usr/local/searxng searxng

Now switch to that new user and create a Python virtual environment (venv) for installing and running the application and all of its dependencies. The Python venv is isolated from the overall system installation of Python so that there aren’t any conflicts with the system’s Python interpreter or module versions.

su - searxng
python -m venv /usr/local/searxng/searxng-pyvenv

The Python virtual environment needs to be activated in order to use it. It’s helpful to automatically activate it when switching to the ‘searxng’ user, which can be done by putting it in that user’s .bashrc:

echo "source /usr/local/searxng/searxng-pyvenv/bin/activate" >> /usr/local/searxng/.bashrc

To make sure that the automatic activation is working as intended, switch back to the root account and then back to the ‘searxng’ user:

exit
su - searxng

If the venv is activated, the name of the venv should be displayed before the standard BASH prompt:

# su - searxng
Last login: Thu Oct 24 14:52:00 UTC 2025 on pts/1
(searxng-pyvenv) searxng@my-secret-search ~ $

SearXNG has some prerequisite Python modules that need to be installed, so install them using Python’s own package manager, Pip:

pip install --upgrade pip setuptools wheel pyyaml msgspec typing_extensions pybind11

The Python modules needed are accurate as of this update on 02 June 2026, but the Official Installation Guide should be checked for up-to-date dependencies.

To see the modules and versions that are currently installed in the virtual environment, the freeze subcommand can be issued in Pip:

$ pip freeze
PyYAML==6.0.3
setuptools==80.9.0
wheel==0.45.1
msgspec==0.19.0

Installation – SearXNG application

SearXNG doesn’t currently offer packaged “releases”, so the way to install it is to clone their Git repository and build the application from that clone:

mkdir -p /usr/local/searxng/searxng-pyvenv/source/
git clone "https://github.com/searxng/searxng" "/usr/local/searxng/searxng-pyvenv/source"
cd /usr/local/searxng/searxng-pyvenv/source/
pip install --use-pep517 --no-build-isolation -e .

After the installation finishes, there will be many more modules listed in Pip (the exact modules and versions may change with subsequent SearXNG versions):

$ pip freeze
anyio==4.11.0
async-timeout==5.0.1
babel==2.17.0
blinker==1.9.0
Brotli==1.1.0
certifi==2025.10.5
click==8.3.0
fasttext-predict==0.9.2.4
Flask==3.1.2
flask-babel==4.0.0
h11==0.16.0
h2==4.3.0
hpack==4.1.0
httpcore==1.0.9
httpx==0.28.1
httpx-socks==0.10.0
hyperframe==6.1.0
idna==3.11
isodate==0.7.2
itsdangerous==2.2.0
Jinja2==3.1.6
lxml==6.0.2
markdown-it-py==3.0.0
MarkupSafe==3.0.3
mdurl==0.1.2
msgspec==0.19.0
Pygments==2.19.2
python-dateutil==2.9.0.post0
python-socks==2.7.2
pytz==2025.2
PyYAML==6.0.3
setproctitle==1.3.7
setuptools==80.9.0
six==1.17.0
sniffio==1.3.1
typer-slim==0.19.2
typing_extensions==4.14.1
valkey==6.1.1
Werkzeug==3.1.3
wheel==0.45.1
whitenoise==6.11.0

Installation – uWSGI application server

Now that the SearXNG application itself has been installed, it’s time to install the application server (before proceeding to configure both the application server and SearXNG itself). I chose to go with uWSGI. Since uWSGI supports many different application languages and various plugins, and seeing as they can be easily configured with Gentoo’s USE flags, they should be set before installing uWSGI:

# grep uwsgi /etc/portage/package.use 
www-servers/uwsgi -embedded -php python UWSGI_PLUGINS: -carbon -http -mongodblog -nagios -redislog -rrdtool pam

# emerge -av uwsgi

With the uWSGI server installed, it can be started automatically at boot time using Gentoo’s OpenRC init scripts:

cd /etc/conf.d
cp -v uwsgi uwsgi.searxng
ln -s /etc/init.d/uwsgi{,.searxng}
rc-update add uwsgi.searxng default

The above commands make a copy of the uWSGI configuration file specifically for SearXNG, and then create a new symlink of the uWSGI init script as /etc/init.d/uwsgi.searxng. Lastly, that new uwsgi.searxng init script is started at the default runlevel during the boot process.

Configuration – uWSGI application server

With both the SearXNG application and the uWSGI application server installed, it’s time to configure both of them accordingly. We’ll start with the uWSGI application server as it is more straightforward. First, we will copy the uWSGI template provided by SearXNG to the overall system location:

cp -v /usr/local/searxng/searxng-pyvenv/source/utils/templates/etc/uwsgi/apps-available/searxng.ini /etc/searxng/searxng.ini

Second, we will edit the uWSGI startup configuration to call this file:

echo 'UWSGI_EXTRA_OPTIONS="--ini /etc/searxng/searxng.ini"' >> /etc/conf.d/uwsgi.searxng

The full configuration file (excluding comments and blank lines) should look similar to the output below. The only other change that I made was to add a path for the log file. As such, the lines that I changed are in purple italics here, but feel free to make other changes for your particular setup or needs:

# grep -v "^#\|^$" /etc/conf.d/uwsgi.searxng 
UWSGI_SOCKET=
UWSGI_THREADS=0
UWSGI_PROGRAM=
UWSGI_XML_CONFIG=
UWSGI_PROCESSES=1
UWSGI_LOG_FILE=/var/log/uwsgi.log
UWSGI_CHROOT=
UWSGI_DIR=
UWSGI_PIDPATH_MODE=0750
UWSGI_USER=
UWSGI_GROUP=
UWSGI_EMPEROR_PATH=
UWSGI_EMPEROR_PIDPATH_MODE=0770
UWSGI_EMPEROR_GROUP=
UWSGI_EXTRA_OPTIONS="--ini /etc/searxng/searxng.ini"

Configuration – SearXNG application

With uWSGI being configured, it’s time to configure the SearXNG application itself. The configurations for it are handled by two separate files:

/etc/searxng/searxng.ini –> settings for running SearXNG as an application in uWSGI
/etc/searxng/settings.yml –> configuration options for the application itself

First, make the directory for storing these two settings files and copy them from the SearXNG sources:

mkdir -p /etc/searxng/
cp -v /usr/local/searxng/searxng-pyvenv/source/utils/templates/etc/uwsgi/apps-available/searxng.ini /etc/searxng/
cp -v /usr/local/searxng/searxng-pyvenv/source/utils/templates/etc/searxng/settings.yml /etc/searxng/

There are two versions of the settings.yml file that can be used:

/usr/local/searxng/searxng-pyvenv/source/utils/templates/etc/searxng/settings.yml
OR
/usr/local/searxng/searxng-pyvenv/source/searx/settings.yml

The first one (and the one used here) is much more compact and basically sets the defaults for most things, allowing for overrides where desired. I would strongly suggest using this first template unless you have a very specific reason to use the full one.

Starting with /etc/searxng/searxng.ini (which again is for configuring how the application will run inside the uWSGI server), here are the settings I suggest (pay close attention to the settings in purple italics as they are pertinent):

# grep -v "^#\|^$" /etc/searxng/searxng.ini 
[uwsgi]
uid = searxng
gid = searxng
env = LANG=C.UTF-8
env = LANGUAGE=C.UTF-8
env = LC_ALL=C.UTF-8
chdir = /usr/local/searxng/searxng-pyvenv/source/searx/ 
env = SEARXNG_SETTINGS_PATH=/etc/searxng/settings.yml
disable-logging = true
chmod-socket = 666
single-interpreter = true
master = true
lazy-apps = true
plugin = python313,asyncio313
enable-threads = true
workers = ${UWSGI_WORKERS:-%k}
threads = ${UWSGI_THREADS:-4}
module = searx.webapp
virtualenv = /usr/local/searxng/searxng-pyvenv
pythonpath = /usr/local/searxng/searxng-pyvenv/source/searxng
socket = /usr/local/searxng/run/socket
buffer-size = 8192
offload-threads = %k

Now for the SearXNG settings themselves (in /etc/searxng/settings.yml), the template yields the following options by default:

# grep -v "^#\|^  #\|^$" /usr/local/searxng/searxng-pyvenv/source/utils/templates/etc/searxng/settings.yml
use_default_settings: true
general:
  debug: false
  instance_name: "SearXNG"
search:
  safe_search: 2
  autocomplete: 'duckduckgo'
  formats:
    - html
server:
  secret_key: "ultrasecretkey"
  limiter: true
  image_proxy: true
valkey:
  url: valkey://localhost:6379/0

The only option that MUST be changed is the ‘secret_key’, and it can be done easily with:

sed -i -e "s/ultrasecretkey/$(openssl rand -hex 16)/g" /etc/searxng/settings.yml

There are many other options that can be set or unset, and they are fairly well documented. Here’s an example settings.yml file with some of the settings that I personally prefer, followed by a brief explanation of them:

# grep -v "^#\|^  #\|^$" /etc/searxng/settings.yml 
use_default_settings: true
general:
  debug: false
  instance_name: "My Secret Search Engine"
  enable_metrics: false
search:
  safe_search: 0
  autocomplete: ""
  formats:
    - html
server:
  secret_key: "YOUR_RANDOM_KEY"
  limiter: false
  image_proxy: true
  http_protocol_version: "1.1"
  method: "GET"
ui:
  theme_args:
    simple_style: black
  url_formatting: full

Option	Explanation
instance_name:	Setting it to your site's name will display it in the browser's title bar
enable_metrics: false	Various anonymous metrics; disabled for even better anonymity
safe_search: 0	Disables all "safe search" filtering
autocomplete: ""	Which autocomplete backend to use; in this case none
image_proxy: true	Uses your instance to proxy images for better anonymity
method: "GET"	Favours some ease of use over the more private "POST"
url_formatting: full	Shows the full URL of all links instead of a breadcrumb ("pretty")

Pay special attention to the ‘use_default_settings:’ declaration. I have included some additional syntax information about it in the “Troubleshooting and Gotchas” section at the bottom of the article.

Configuration – Apache web server

Now that both the uWSGI application server and the SearXNG application itself have been installed and configured, the last step is to proxy through the Apache web server.

Though uWSGI can be set up to handle HTTP requests directly—thus removing the need for Apache or a different web server—I prefer to keep it as a backend and let a dedicated web server manage HTTP connections.

Doing so requires two Apache modules: mod_proxy and mod_proxy_uwsgi. Linux distributions have different methods of enabling Apache modules, so consult your distribution’s documentation on doing so. In Gentoo, it is done by adding “proxy” and “proxy_uwsgi” to APACHE2_MODULES and re-emerging it.

It’s also important to load mod_proxy BEFORE mod_proxy_uwsgi, so make sure that the order is correct in the module-loading section of /etc/apache2/httpd.conf:

# grep proxy /etc/apache2/httpd.conf 
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_uwsgi_module modules/mod_proxy_uwsgi.so

As for the Apache vhost configuration, it is likely quite similar to any other site you have configured (and generic vhost configuration is outside the scope of this article). The parts that are specific to SearXNG are the proxy directives. Assuming that SearXNG is going to be accessed at the root of the domain, the proxy directives should look like:

## Removed these main directives from <Location> block for Certbot.
## This allows bypassing the proxy for the .well-known/ subdirectory for LetsEncrypt
        ProxyPreserveHost On
        ProxyPass /.well-known/ !
        ProxyPass / unix:/usr/local/searxng/run/socket|uwsgi://localhost/

        RequestHeader set X-Forwarded-Proto %{REQUEST_SCHEME}s
        RequestHeader set X-Script-Name /searxng
        RequestHeader set X-Real-IP %{REMOTE_ADDR}s
        RequestHeader append X-Forward-For %{REMOTE_ADDR}s

The ‘ProxyPass’ line in purple is the one that is responsible for proxying the HTTP request via UNIX socket to the uWSGI application server and vice-versa. After reloading Apache, your SearXNG instance should now be accessible. If it isn’t, you may find some additional pointers in the “Troubleshooting and Gotchas” section at the bottom of this article.

20260106 Update:
In the Apache vhost configuration above, I removed the whole block from the <Location> tags so that I could add in a bypass for the proxy (the line in orange). This allows for Certbot to renew the SSL certificate since that particular subdirectory is excluded from the proxied uWSGI application.

Updating the SearXNG application

As previously mentioned, SearXNG doesn’t publish releases so updating involves pulling down the latest Git master branch, updating dependencies, and then rebuilding. There are many different methods for performing these updates in Git, but my approach is:

su - searxng
cd /usr/local/searxng/searxng-pyvenv/source
git pull origin master
pip install --upgrade pip setuptools wheel pyyaml msgspec typing_extensions pybind11
pip install --upgrade --use-pep517 --no-build-isolation -e .
exit
/etc/init.d/uwsgi.searxng restart

The steps outlined in the code block above will:

Switch to the ‘searxng’ user, which will activate the Python virtual environment (assuming you followed the instructions in the ‘Installation – Prerequisites’ section of this article)
Change to the SearXNG source directory (Git)
Pull the latest files from SearXNG’s Git master branch
Use pip to update the dependencies
Use pip to rebuild the application using the latest sources
Switch back from the ‘searxng’ user back to root (“exit”)
Restart the uWSGI application server containing the SearXNG application

After these steps, SearXNG should be the latest version. This can be validated by checking the following line in the footer of the page. For example:

Powered by SearXNG – 2025.10.24+2cdbbb249

That line should show the date of the pull and the first 9 characters of the latest commit that was pulled.

Updating – Rolling back

In case a particular update causes a problem, it can be readily rolled back to the previous version you had installed by performing a git reset:

su - searxng
cd /usr/local/searxng/searxng-pyvenv/source
git reset --keep HEAD@{1}
pip install --upgrade --use-pep517 --no-build-isolation -e .
exit
/etc/init.d/uwsgi.searxng restart

Troubleshooting and Gotchas

If you run into problems with the installation or configuration steps throughout this article, some of the more common errors and pitfalls are listed here, separated into sections based on where the problem lies.

SearXNG application

The SearXNG settings are documented quite well, but I did run into a particular syntax discrepancy that caused unexpected results. When using the use_default_settings directive, there is a syntax difference based on whether or not any of the search engines will be modified.

If no engine modifications will be made:

WORKS:

use_default_settings: true

FAILS:

use_default_settings:

If, however, any engine modifications are present, the true value must be dropped.

WORKS:

use_default_settings:
  engines:
    remove:
      - google

FAILS:

use_default_settings: true
  engines:
    remove:
      - google

In the ‘fails’ scenarios, the uWSGI log will show errors related to various Python scripts with these lines being at or near the end of the trace:

File "/usr/local/searxng/searxng-pyvenv/source/searx/settings_loader.py", line 218, in load_settings
user_cfg = load_yaml(cfg_file)
File "/usr/local/searxng/searxng-pyvenv/source/searx/settings_loader.py", line 48, in load_yaml
raise SearxSettingsException(e, str(file_name)) from e
searx.exceptions.SearxSettingsException: mapping values are not allowed here
in "/etc/searxng/settings.yml", line 5, column 10
unable to load app 0 (mountpoint='') (callable not found or import error)
*** no app loaded. going in full dynamic mode ***

uWSGI application server

If the following error message appears in the uWSGI log:

bind(): No such file or directory [core/socket.c line 230]

it is likely that the path to the UNIX socket is not present or that the permissions are incorrect. Check the ‘socket =’ line in /etc/searxng/searxng.ini and make sure the path is there and that the permissions are 755 owned by the ‘searxng’ user:

# ls -lhd /usr/local/searxng/run/
drwxr-xr-x 2 searxng searxng 4.0K Oct 24 17:38 /usr/local/searxng/run/

Apache web server

Though the Apache vhost configuration for SearXNG is essentially just the proxy section listed above, there are many syntax errors that can arise from it. The ProxyPass line—which passes HTTP requests to the UNIX socket—can be particularly finicky about syntax:

ProxyPass unix:/usr/local/searxng/run/socket|uwsgi://localhost/

I found that only specifying the ‘uwsgi://’ protocol resulted in the application failing. In my case, I needed it to specifically reference ‘localhost’. As such, the following ProxyPass directive did not work for me:

ProxyPass unix:/usr/local/searxng/run/socket|uwsgi://

2026-06-01 17:32:50 UTC

The Instagram accounts for the Obama White House and the Chief Master Sergeant of the U.S. Space Force were briefly defaced with pro-Iranian images and messages over the weekend, after instructions began circulating on Telegram showing how to trick Meta’s “AI support assistant” bot into resetting account passwords.

A screenshot from a video released on Telegram claiming to show how Meta’s AI customer support bot could be tricked into resetting a target’s password.

On May 31, word began to spread on several Telegram instant message channels that Meta’s AI bot would happily add an email address to an existing account as part of the bot’s standard password reset flow.

A video released on Telegram by pro-Iran hackers claimed to document a remarkably simple exploit that appears to have involved using a VPN connection with an IP address that is in or near the target’s usual hometown, requesting a password reset for the account, and then choosing to chat with Meta’s AI support assistant. From there, the video shows the attacker told the bot to link the account in question to a new email address, after which the bot dutifully sent that address a one-time code that allowed a password reset.

The Telegram account that posted the video also linked to screenshots of pro-Iran images, videos and messages that defaced the hacked Instagram accounts, saying hackers had used the exploit to hijack a number of valuable (read: short) Instagram account names that allegedly have a resale value of more than a half million dollars.

Meta has not responded to requests for comment on the video’s claims, but Meta’s Andy Stone said on Twitter/X that the issue had been resolved and that they were securing impacted accounts. The security blog thecybersecguru.com reports that Meta pushed an emergency patch over the weekend, and clarified that no back end database was breached.

“Instagram has notoriously poor human support infrastructure,” Cybersecguru wrote. “Recovering a locked account – especially a high-value one can take weeks of back-and-forth with an automated ticketing system. Meta’s solution was to deploy a conversational AI layer to handle common recovery workflows: relinking a lost email address, triggering a password reset, verifying account ownership. The assistant, presumably, was supposed to reduce friction for legitimate users stuck in account-access hell.”

Ian Goldin, a threat researcher at Lumen’s Black Lotus Labs, said we’re entering unchartered security territory as more large online platforms start allowing AI chatbots to handle sensitive account recovery requests. Just like human customer support employees can be social engineered into providing unauthorized access to someone’s account, AI bots are equally eager to help and vulnerable to persuasion and trickery, he said.

“AI chatbots create interesting new attack surface, and we’re likely going to see a lot more of these kinds of attacks,” Goldin said.

Securing your various online accounts means taking full advantage of the most secure form of multi-factor authentication (MFA) offered (such as a passkey or security key). In this case, even using the least robust form of MFA that Instagram offers — a one-time code sent via SMS — likely would have blocked the exploit: The hackers who released the video on Telegram said their exploit failed to work against any accounts that had MFA enabled.

2026-06-01 15:16:41 UTC

These past two months have been incredibly busy. I didn't publish a status report for April 2026, so this status report will cover that, too.

We have mostly completed the migration from our self-hosted GitLab Enterprise instance to Radicle. There's still further work to be done, but the most crucial bits have made it over. We're also still working on ironing out some kinks in learning "the Radicle way". I hope soon to write an article chronicling our journey thus far.

I wrote documentation on how to bootstrap Radicle's local storage directory with src and ports. If you hope to someday submit issues and/or patches, following these bootstrap instructions will certainly ease the initial pain. I plan to include an export of these Radicle storage bootstrap archives with each official build. The current exports are not signed. I'm going to include the hashes in this signed email. I am working on a candidate patch to our build scripts to perform this export. The archives exported by our builder VMs will be signed with our normal ssh key-based signing method.

Fully fixing the release image generation (chiefly fixing generation of disc1.iso) is my first priority. Radicle bootstrap archive generation is my second priority. Radicle integration in our auto-sync is my third priority. Our commit emails came from GitLab. I need to replicate that functionality but with "the Radicle way." For now, I'm performing the sync myself when time permits (usually multiple times per day.)

The past couple months have also seen a number of FreeBSD security advisories, so we've published new builds for 16-CURRENT and 15-STABLE. Installer image generation is still somewhat broken, though I've seen some success with memstick.img. I plan to continue working on this until we're 100% fixed, though it will take time. It takes quite the number of hours to test even the smallest of changes. I get pretty much at most two attempts at testing fixes per day.

I spent some time studying Reticulum's code. I'm in the process of writing a shim to abstract how its backbone interface implementation uses select and friends. Back when I last looked at it, it required use of epoll. Simultaenously while I was working on that, I did notice the Reticulum project was working on a more portable backbone interface implementation. So I need to restart that research when the time comes.

I also spent a little bit of time with hbsdfw. I started work on forward-porting our 14-stable hbsdfw-specific patches to 15-STABLE. Then GitLab died, and my priorities switched to the Radicle migration. So I need to restart this research, too, when the time comes. I think I might target -CURRENT rather than 15-STABLE. That way, we don't have to periodically forward-port patches: we just maintain our patches against the naturally-evvolving hardened/current/master.

We completed the ISP account migration. Some pain is left to resolve. We lost support for our tunneled IPv6 (via Hurricane Electric's Tunnel Broker). I need to schedule a part of my day to capture some packets and get on the phone with some tech support folks on the side of both my ISP and HE. Until then, I've removed the AAAA DNS records for the relevant bits of infrastructure.

In src:

FreeBSD merged llvm 21 into base. We needed to fix one compilation error in HardenedBSD's code caught by llvm 21
Replace FreeBSD's README.md with our main wiki-based documentation.
Drop the -HBSD suffix in newvers.sh
Migrate hbsd-update-build to Radicle
Revert the release/ subdirectory to a known good-ish commit. This brought back generation of memstick.img
The hardening.pax.kmod_load_disable sysctl node logic was enhanced
Fix MK_LLVM_LINK_STATIC_LIBRARIES in src.opts.mk

In ports:

multimedia/ffmpeg build was fixed
ports-mgmt/pkg was updated to 2.7.5
ports-mgmt/poudriere-hbsd was updated to 3.4.8
A patch was brought in to fix the graphics/hdr_histogram port
hardenedbsd/secadm was updated to account for recent MAC hook changes by FreeBSD
Some incredibly basic support was implemented for downloading distfiles via Radicle HTTP
ports-mgmt/pkg was migrated to Radicle
The default llvm version was bumped to 21 for latest 16-CURRENT users
ports-mgmt/poudriere-hbsd was migrated to Radicle
COMPAT32 was disable for misc/compat{14,15}
PIE was disabled for devel/ccache4
net-p2p/reticulum was migrated to Radicle
hardenedbsd/secadm was migrated to Radicle

I want to say a heartfelt thank you to the Radicle folks. You've spent a lot of time in helping out. You didn't have to, but you chose to. And for that, I'm incredibly grateful. It's fun to see the Radicle network evolve.

==== BEGIN ARTIFACT HASHES ====
$ sha256 ports.tar.xz
SHA256 (ports.tar.xz) = b12f303b96b02b16744c1286868726ab4df43a06f6d28de3c247d4d1598f743b
$ wc -c ports.tar.xz
1472685664 ports.tar.xz
$ sha256 src.tar.xz
SHA256 (src.tar.xz) = 00301a70910127f4fd9564dca1be948e6b9909e864053a76b9197565768345cf
$ wc -c src.tar.xz
2069117660 src.tar.xz
==== END ARTIFACT HASHES ====

2026-06-01 14:58:00 UTC

Die Beta von MMO-20044 läuft seit ein paar Wochen, und es hat funktioniert: ein paar Spieler haben das Spiel gefunden, Feedback gegeben und Bugs aufgedeckt. Am Donnerstag, 04.06., geht die Beta zu Ende.

Direkt danach startet Season 1. Das bedeutet einen vollständigen Reset: alle Spieler, Planeten und Fortschritte werden gelöscht. Die Galaxie selbst bleibt erhalten.

Was Season 1 bringt

Das Spielziel ist jetzt klar definiert: wer als erstes den Genesis-Planeten auf Level 5 bringt, löst einen 48-Stunden-Countdown aus. Danach endet die Season. Der Sieger bekommt eine Trophäe, die dauerhaft im Profil sichtbar bleibt.

Dazu gibt es eine Rangliste, die sich an der Spielerzahl orientiert. Bei wenigen Spielern werden die besten drei angezeigt, bei mehr entsprechend mehr. Wer nicht in der Spitzengruppe steckt, sieht seine eigene Position mit den direkten Nachbarn.

Mitspielen

Das Spiel läuft unter zockertown.de/mmo. Registrierung ist offen, kein Account nötig außer einem Spielernamen und Passwort. Wer die Beta mitgemacht hat, muss sich neu registrieren.

MMO-20044 ist ein Browser-Spiel ohne Client, ohne App, ohne Push-Benachrichtigungen. Kein Tracking, keine Werbung, keine externen Ressourcen. Einloggen, schauen was passiert ist, Entscheidungen treffen, wieder ausloggen. Mehr ist es nicht, und das ist der Punkt.

2026-05-30 17:51:39 UTC

I now have a Dell R7425 with 12 x 12TB HDD in the basement.

A raidz2 zpool would give me about 120TB – with a significant resilver time.

I have also thought about a creating 6 x mirrors and striping across them. That would give me about 72TB – that’s still a lot.

However I do it, I’m going to label the partitions with the drive slot and serial number. I’m going to write a little helper script. I’m guessing by the time I finish writing this blog post, I could have done the labelling manually. However, if I have to redo the labelling because I messed up, I think that’s where the script will pay off.

Some background

This is the zpool status from r730-03:

[16:42 r730-03 dvl ~] % zpool status
  pool: data01
 state: ONLINE
  scan: scrub repaired 0B in 1 days 04:29:00 with 0 errors on Fri May 29 08:31:09 2026
config:

	NAME                   STATE     READ WRITE CKSUM
	data01                 ONLINE       0     0     0
	  mirror-0             ONLINE       0     0     0
	    gpt/SEAG_ZJV4HFPE  ONLINE       0     0     0
	    gpt/SEAG_ZHZ16KEX  ONLINE       0     0     0
	  mirror-1             ONLINE       0     0     0
	    gpt/SG_ZHZ03BAT    ONLINE       0     0     0
	    gpt/HGST_8CJW1G4E  ONLINE       0     0     0
	  mirror-2             ONLINE       0     0     0
	    gpt/SG_ZL2NJBT2    ONLINE       0     0     0
	    gpt/HGST_5PGGTH3D  ONLINE       0     0     0

errors: No known data errors

  pool: zroot
 state: ONLINE
status: Some supported and requested features are not enabled on the pool.
	The pool can still be used, but some features are unavailable.
action: Enable all features using 'zpool upgrade'. Once this is done,
	the pool may no longer be accessible by software that does not support
	the features. See zpool-features(7) for details.
  scan: scrub repaired 0B in 00:01:49 with 0 errors on Thu May 28 04:04:13 2026
config:

	NAME        STATE     READ WRITE CKSUM
	zroot       ONLINE       0     0     0
	  mirror-0  ONLINE       0     0     0
	    ada1p3  ONLINE       0     0     0
	    ada0p3  ONLINE       0     0     0

errors: No known data errors

Notice how the drives in data01 are labelled with the drive brand (e.g. Seagate) and the serial number (ZJV4HFPE).

This helps to correctly identify the drive you want to remove, should one need replacing.

These are the drives in the Dell R7425 (the hostname is r7425-01).

root@r7425-01:~ # sesutil show
ses0: <DP BP14G+EXP 2.52>; ID: 500056b345a433ff
Desc            Dev     Model                     Ident                Size/Status
Drive Slot 0    da0     ATA HGST HUH721212AL      8CGSV9DG             Unknown
Drive Slot 1    da1     ATA HGST HUH721212AL      8CGSXG6G             Unknown
Drive Slot 2    da2     ATA HGST HUH721212AL      8HGAWR3H             Unknown
Drive Slot 3    da3     ATA HGST HUH721212AL      8CGSVS3G             Unknown
Drive Slot 4    da4     ATA HGST HUH721212AL      8CGSB6YG             Unknown
Drive Slot 5    da5     ATA HGST HUH721212AL      8CGSZ0VG             Unknown
Drive Slot 6    da6     ATA HGST HUH721212AL      8CGSZY5G             Unknown
Drive Slot 7    da7     ATA HGST HUH721212AL      8CGSV8YG             Unknown
Drive Slot 8    da8     ATA HGST HUH721212AL      8CGS875G             Unknown
Drive Slot 9    da9     ATA HGST HUH721212AL      8CGSBA2G             Unknown
Drive Slot 10   da10    ATA HGST HUH721212AL      8CGSX4UG             Unknown
Drive Slot 11   da11    ATA HGST HUH721212AL      8CGSDEHG             Unknown
Drive Slot 12   da12    ATA ST1000NM0018-2F2      ZFA0NVQD             Unknown
Drive Slot 13   -       -                         -                    Not Installed
Drive Slot 14   da13    ATA MTFDDAK480TDN         191821E45D17         Unknown
Drive Slot 15   da14    ATA MTFDDAK480TDN         191821E45DA1         Unknown
Drive Slot 16   -       -                         -                    Not Installed
Drive Slot 17   -       -                         -                    Not Installed

Some notes:

Slots 0-11 are in the front of the chassis. They are the main data drives and are the subjects of this blog post.
Slot 12 is mounted in the rear of the chassis and is a 1TB drive
slots 14-15 are 2.5″ SSDs mounted internally – they contain the zroot

From the past

I went searching my blog for zpool create and found Copying everything off a zpool, destroying it, creating a new one, and copying everything back – in there, I found this command:

sudo gpart add -a 4K -i 1 -t freebsd-zfs -s 1953520000 -l S59VNS0N809087J_S00 da0

Let’s write a script to output that.

Listing the drives

This is my starting point:

root@r7425-01:~ # sesutil show | grep 'Drive Slot' | grep -vE 'Drive Slot (12|13|14|15|16|17)'
Drive Slot 0    da0     ATA HGST HUH721212AL      8CGSV9DG             Unknown
Drive Slot 1    da1     ATA HGST HUH721212AL      8CGSXG6G             Unknown
Drive Slot 2    da2     ATA HGST HUH721212AL      8HGAWR3H             Unknown
Drive Slot 3    da3     ATA HGST HUH721212AL      8CGSVS3G             Unknown
Drive Slot 4    da4     ATA HGST HUH721212AL      8CGSB6YG             Unknown
Drive Slot 5    da5     ATA HGST HUH721212AL      8CGSZ0VG             Unknown
Drive Slot 6    da6     ATA HGST HUH721212AL      8CGSZY5G             Unknown
Drive Slot 7    da7     ATA HGST HUH721212AL      8CGSV8YG             Unknown
Drive Slot 8    da8     ATA HGST HUH721212AL      8CGS875G             Unknown
Drive Slot 9    da9     ATA HGST HUH721212AL      8CGSBA2G             Unknown
Drive Slot 10   da10    ATA HGST HUH721212AL      8CGSX4UG             Unknown
Drive Slot 11   da11    ATA HGST HUH721212AL      8CGSDEHG             Unknown
root@r7425-01:~ #

Let’s save that into a file:

root@r7425-01:~ # sesutil show | grep 'Drive Slot' | grep -vE 'Drive Slot (12|13|14|15|16|17)' > data_drives
root@r7425-01:~ # cat data_drives
Drive Slot 0    da0     ATA HGST HUH721212AL      8CGSV9DG             Unknown
Drive Slot 1    da1     ATA HGST HUH721212AL      8CGSXG6G             Unknown
Drive Slot 2    da2     ATA HGST HUH721212AL      8HGAWR3H             Unknown
Drive Slot 3    da3     ATA HGST HUH721212AL      8CGSVS3G             Unknown
Drive Slot 4    da4     ATA HGST HUH721212AL      8CGSB6YG             Unknown
Drive Slot 5    da5     ATA HGST HUH721212AL      8CGSZ0VG             Unknown
Drive Slot 6    da6     ATA HGST HUH721212AL      8CGSZY5G             Unknown
Drive Slot 7    da7     ATA HGST HUH721212AL      8CGSV8YG             Unknown
Drive Slot 8    da8     ATA HGST HUH721212AL      8CGS875G             Unknown
Drive Slot 9    da9     ATA HGST HUH721212AL      8CGSBA2G             Unknown
Drive Slot 10   da10    ATA HGST HUH721212AL      8CGSX4UG             Unknown
Drive Slot 11   da11    ATA HGST HUH721212AL      8CGSDEHG             Unknown
root@r7425-01:~ #

gpart create

Next, let’s compose a command to create gpart partitions on each drive.

NOTE, this command creates the partitions, it’s not echoing out the commands for you to run later…

root@r7425-01:~ # cat data_drives | cut -f 4 -w | xargs -n 1 -I % gpart create -s gpt %
da0 created
da1 created
da2 created
da3 created
da4 created
da5 created
da6 created
da7 created
da8 created
da9 created
da10 created
da11 created
root@r7425-01:~ #

Next, let’s create a partition, and label it with the drive slot and the serial number.

Partition size?

On FreeBSD, it has been routine procedure to partition the drive and use a partition for the vdev, not the whole raw device. I recall reading the reasoning behind that. I will continue with that routine.

For that, I need to know drive size, and let’s look at this command for that information:

root@r7425-01:~ # diskinfo -v da0
da0
	512         	# sectorsize
	12000138625024	# mediasize in bytes (11T)
	23437770752 	# mediasize in sectors
	4096        	# stripesize
	0           	# stripeoffset
	1458933     	# Cylinders according to firmware.
	255         	# Heads according to firmware.
	63          	# Sectors according to firmware.
	ATA HGST HUH721212AL	# Disk descr.
	8CGSV9DG    	# Disk ident.
	mpr0        	# Attachment
	id1,enc@n500056b345a433fd/type@0/slot@1/elmdesc@Drive_Slot_0	# Physical path
	No          	# TRIM/UNMAP support
	7200        	# Rotation rate in RPM
	Not_Zoned   	# Zone Mode

root@r7425-01:~ #

We have 23,437,770,752 sectors (mediasize in sectors), each one being 512 bytes (sectorsize)

I’m going to leave 2.5M free at the end of that drive, just in case any replacement drive comes up a little bit short. 2.5M is 2,621,440 bytes. 2,621,440 bytes / 512 bytes per sector is 5,120 sectors.

The size on the gpart command will be 23,437,770,752 – 5,120 = 23,437,765,632

The partition add

The script I came up with is. This command echos the commands you want to run later.

root@r7425-01:~ # cat data_drives | awk '{  print "gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_" $3 "_" $8 " " $4 }'
gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_0_8CGSV9DG da0
gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_1_8CGSXG6G da1
gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_2_8HGAWR3H da2
gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_3_8CGSVS3G da3
gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_4_8CGSB6YG da4
gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_5_8CGSZ0VG da5
gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_6_8CGSZY5G da6
gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_7_8CGSV8YG da7
gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_8_8CGS875G da8
gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_9_8CGSBA2G da9
gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_10_8CGSX4UG da10
gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_11_8CGSDEHG da11

Let’s try running that first command:

root@r7425-01:~ # gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_0_8CGSV9DG da0
da0p1 added
root@r7425-01:~ # gpart show da0
=>         40  23437770672  da0  GPT  (11T)
           40  23437765632    1  freebsd-zfs  (11T)
  23437765672         5040       - free -  (2.5M)

root@r7425-01:~ # gpart show -l da0
=>         40  23437770672  da0  GPT  (11T)
           40  23437765632    1  slot_0_8CGSV9DG  (11T)
  23437765672         5040       - free -  (2.5M)

root@r7425-01:~ # ls -l /dev/gpt
total 0
crw-r-----  1 root operator 0xd1 May 30 16:27 efiboot0
crw-r-----  1 root operator 0xc5 May 30 16:27 efiboot1
crw-r-----  1 root operator 0xf5 May 30 17:34 slot_0_8CGSV9DG
root@r7425-01:~ #

That looks right. Let’s run the rest:

root@r7425-01:~ # gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_1_8CGSXG6G da1
da1p1 added
root@r7425-01:~ # gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_2_8HGAWR3H da2
da2p1 added
root@r7425-01:~ # gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_3_8CGSVS3G da3
da3p1 added
root@r7425-01:~ # gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_4_8CGSB6YG da4
da4p1 added
root@r7425-01:~ # gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_5_8CGSZ0VG da5
da5p1 added
root@r7425-01:~ # gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_6_8CGSZY5G da6
da6p1 added
root@r7425-01:~ # gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_7_8CGSV8YG da7
da7p1 added
root@r7425-01:~ # gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_8_8CGS875G da8
da8p1 added
root@r7425-01:~ # gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_9_8CGSBA2G da9
da9p1 added
root@r7425-01:~ # gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_10_8CGSX4UG da10
da10p1 added
root@r7425-01:~ # gpart add -a 4K -i 1 -t freebsd-zfs -s 23437765632 -l slot_11_8CGSDEHG da11
da11p1 added
root@r7425-01:~ # ls -l /dev/gpt
total 0
crw-r-----  1 root operator  0xd1 May 30 16:27 efiboot0
crw-r-----  1 root operator  0xc5 May 30 16:27 efiboot1
crw-r-----  1 root operator  0xf5 May 30 17:34 slot_0_8CGSV9DG
crw-r-----  1 root operator 0x135 May 30 17:36 slot_10_8CGSX4UG
crw-r-----  1 root operator 0x13b May 30 17:36 slot_11_8CGSDEHG
crw-r-----  1 root operator  0xff May 30 17:36 slot_1_8CGSXG6G
crw-r-----  1 root operator 0x105 May 30 17:36 slot_2_8HGAWR3H
crw-r-----  1 root operator 0x10b May 30 17:36 slot_3_8CGSVS3G
crw-r-----  1 root operator 0x111 May 30 17:36 slot_4_8CGSB6YG
crw-r-----  1 root operator 0x117 May 30 17:36 slot_5_8CGSZ0VG
crw-r-----  1 root operator 0x11d May 30 17:36 slot_6_8CGSZY5G
crw-r-----  1 root operator 0x123 May 30 17:36 slot_7_8CGSV8YG
crw-r-----  1 root operator 0x129 May 30 17:36 slot_8_8CGS875G
crw-r-----  1 root operator 0x12f May 30 17:36 slot_9_8CGSBA2G

So far so good.

The zpool create

I thought about this.. how best to mirror the drives. The drives are stacked 3 high and 4 across. I thought: put mirrored drives right beside each other. Would that help with future tasks?

Then I thought: hell, no, that might take some interesting maneuvers in the zpool create command…. Let’s keep this part simple.

Next, so I did not have to copy / paste the device names, I did this:

root@r7425-01:~ # cat data_drives | awk '{  print "/dev/gpt/slot_" $3 "_" $8}'
/dev/gpt/slot_0_8CGSV9DG
/dev/gpt/slot_1_8CGSXG6G
/dev/gpt/slot_2_8HGAWR3H
/dev/gpt/slot_3_8CGSVS3G
/dev/gpt/slot_4_8CGSB6YG
/dev/gpt/slot_5_8CGSZ0VG
/dev/gpt/slot_6_8CGSZY5G
/dev/gpt/slot_7_8CGSV8YG
/dev/gpt/slot_8_8CGS875G
/dev/gpt/slot_9_8CGSBA2G
/dev/gpt/slot_10_8CGSX4UG
/dev/gpt/slot_11_8CGSDEHG

And yes, those all exist:

root@r7425-01:~ # cat data_drives | awk '{  print "/dev/gpt/slot_" $3 "_" $8}' | xargs ls -l
crw-r-----  1 root operator  0xf5 May 30 17:34 /dev/gpt/slot_0_8CGSV9DG
crw-r-----  1 root operator 0x135 May 30 17:36 /dev/gpt/slot_10_8CGSX4UG
crw-r-----  1 root operator 0x13b May 30 17:36 /dev/gpt/slot_11_8CGSDEHG
crw-r-----  1 root operator  0xff May 30 17:36 /dev/gpt/slot_1_8CGSXG6G
crw-r-----  1 root operator 0x105 May 30 17:36 /dev/gpt/slot_2_8HGAWR3H
crw-r-----  1 root operator 0x10b May 30 17:36 /dev/gpt/slot_3_8CGSVS3G
crw-r-----  1 root operator 0x111 May 30 17:36 /dev/gpt/slot_4_8CGSB6YG
crw-r-----  1 root operator 0x117 May 30 17:36 /dev/gpt/slot_5_8CGSZ0VG
crw-r-----  1 root operator 0x11d May 30 17:36 /dev/gpt/slot_6_8CGSZY5G
crw-r-----  1 root operator 0x123 May 30 17:36 /dev/gpt/slot_7_8CGSV8YG
crw-r-----  1 root operator 0x129 May 30 17:36 /dev/gpt/slot_8_8CGS875G
crw-r-----  1 root operator 0x12f May 30 17:36 /dev/gpt/slot_9_8CGSBA2G

Next, I went one step farther:

root@r7425-01:~ # cat data_drives | awk '{  print "/dev/gpt/slot_" $3 "_" $8}' | xargs -n 2 echo  mirror
mirror /dev/gpt/slot_0_8CGSV9DG /dev/gpt/slot_1_8CGSXG6G
mirror /dev/gpt/slot_2_8HGAWR3H /dev/gpt/slot_3_8CGSVS3G
mirror /dev/gpt/slot_4_8CGSB6YG /dev/gpt/slot_5_8CGSZ0VG
mirror /dev/gpt/slot_6_8CGSZY5G /dev/gpt/slot_7_8CGSV8YG
mirror /dev/gpt/slot_8_8CGS875G /dev/gpt/slot_9_8CGSBA2G
mirror /dev/gpt/slot_10_8CGSX4UG /dev/gpt/slot_11_8CGSDEHG

That output now just needs a zpool create data01 in front of it. Let’s go.

Oh, that’s wrong. That failed. It created a zpool of two drives. I need trailing \ on each line.

I tried mucking about with the script. I failed. Instead, I copied the output to an editor, added the trailing \ and came up with this:

zpool create data01 \
mirror /dev/gpt/slot_0_8CGSV9DG /dev/gpt/slot_1_8CGSXG6G \
mirror /dev/gpt/slot_2_8HGAWR3H /dev/gpt/slot_3_8CGSVS3G \
mirror /dev/gpt/slot_4_8CGSB6YG /dev/gpt/slot_5_8CGSZ0VG \
mirror /dev/gpt/slot_6_8CGSZY5G /dev/gpt/slot_7_8CGSV8YG \
mirror /dev/gpt/slot_8_8CGS875G /dev/gpt/slot_9_8CGSBA2G \
mirror /dev/gpt/slot_10_8CGSX4UG /dev/gpt/slot_11_8CGSDEHG

And I ran it:

root@r7425-01:~ # zpool create data01 \
> mirror /dev/gpt/slot_0_8CGSV9DG /dev/gpt/slot_1_8CGSXG6G \
> mirror /dev/gpt/slot_2_8HGAWR3H /dev/gpt/slot_3_8CGSVS3G \
> mirror /dev/gpt/slot_4_8CGSB6YG /dev/gpt/slot_5_8CGSZ0VG \
> mirror /dev/gpt/slot_6_8CGSZY5G /dev/gpt/slot_7_8CGSV8YG \
> mirror /dev/gpt/slot_8_8CGS875G /dev/gpt/slot_9_8CGSBA2G \
> mirror /dev/gpt/slot_10_8CGSX4UG /dev/gpt/slot_11_8CGSDEHG

root@r7425-01:~ #

And I have:

root@r7425-01:~ # zpool list
NAME     SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
data01  65.4T   480K  65.4T        -         -     0%     0%  1.00x    ONLINE  -
zroot    436G  1.14G   435G        -         -     0%     0%  1.00x    ONLINE  -
root@r7425-01:~ # zpool status data01
  pool: data01
 state: ONLINE
config:

	NAME                      STATE     READ WRITE CKSUM
	data01                    ONLINE       0     0     0
	  mirror-0                ONLINE       0     0     0
	    gpt/slot_0_8CGSV9DG   ONLINE       0     0     0
	    gpt/slot_1_8CGSXG6G   ONLINE       0     0     0
	  mirror-1                ONLINE       0     0     0
	    gpt/slot_2_8HGAWR3H   ONLINE       0     0     0
	    gpt/slot_3_8CGSVS3G   ONLINE       0     0     0
	  mirror-2                ONLINE       0     0     0
	    gpt/slot_4_8CGSB6YG   ONLINE       0     0     0
	    gpt/slot_5_8CGSZ0VG   ONLINE       0     0     0
	  mirror-3                ONLINE       0     0     0
	    gpt/slot_6_8CGSZY5G   ONLINE       0     0     0
	    gpt/slot_7_8CGSV8YG   ONLINE       0     0     0
	  mirror-4                ONLINE       0     0     0
	    gpt/slot_8_8CGS875G   ONLINE       0     0     0
	    gpt/slot_9_8CGSBA2G   ONLINE       0     0     0
	  mirror-5                ONLINE       0     0     0
	    gpt/slot_10_8CGSX4UG  ONLINE       0     0     0
	    gpt/slot_11_8CGSDEHG  ONLINE       0     0     0

errors: No known data errors
root@r7425-01:~ #

2026-06-01 11:00:10 UTC

The Valuable News weekly series is dedicated to provide summary about news, articles and other interesting stuff mostly but not always related to the UNIX/BSD/Linux systems. Whenever I stumble upon something worth mentioning on the Internet I just put it here.

Today the amount information that we get using various information streams is at massive overload. Thus one needs to focus only on what is important without the need to grep(1) the Internet everyday. Hence the idea of providing such information ‘bulk’ as I already do that grep(1).

The Usual Suspects section at the end is permanent and have links to other sites with interesting UNIX/BSD/Linux news.

Past releases are available at the dedicated NEWS page.

UNIX

FreeBSD Foundation Executive Director Tries Daily Driving FreeBSD on Laptop.
https://tech.slashdot.org/story/26/05/24/213229/freebsd-foundation-executive-director-tries-daily-driving-freebsd-on-laptop

OpenSMTPD is Mail Server for Future.
https://nxdomain.no/~peter/time_for_opensmtpd.html

FreeBSD Foundation Laptop Compatibility List.
https://freebsdfoundation.github.io/freebsd-laptop-testing/

Beautiful/Modern Desktop Environment for FreeBSD with Omarchy Experience.
https://omfreebdy.dba.wtf/

OpenRiot Polished i3 Desktop for OpenBSD 7.9 with fish(1)/Helix/Polybar Tuned So Everything Works.
https://openriot.org/

Jailed Zigbee and HomeAssistant on FreeBSD.
https://brnrd.eu/misc/2026-02-07/jailed-zigbee-and-homeassistant-on-freebsd.html

Fixing My HomeAssistant Install on FreeBSD.
https://brnrd.eu/misc/2026-05-20/fixing-my-homeassistant-install-on-freebsd.html

Flatpak will Depend on systemd(1).
https://osnews.com/story/145071/flatpak-will-depend-on-systemd/

Sledgehammer Mosquito Swatter Peplaced.
https://daemondesktop.blogspot.com/2026/05/sledgehammer-mosquito-swatter-replaced.html

rrsync(1) Error About Unsafe / Arg.
https://dan.langille.org/2026/05/26/usr-local-sbin-rrsync-error-unsafe-arg-usr-home-rsyncer-backups/

Utilities for FreeBSD pkg(8) Tool.
https://brnrd.eu/freebsd/2026-05-23/utilities-for-freebsd-pkg.html

Changes in My Desktop Computing in 2026.
https://hracka.org/~logout/?2026-05-20_changes_in_my_desktop_computing_in_2026

LibreSSL 4.3.2 Released.
https://undeadly.org/cgi?action=article;sid=20260527055600

Do Not Make ZFS Re-Read What It Just Read.
https://oshogbo.com/blog/89/

Full Native ROCm FreeBSD Port.
https://racha.ca/myPosts/ROCmFreeBSD_pt1.html

AI Audit of FreeBSD.
https://blog.calif.io/p/an-ai-audit-of-freebsd

Wine 11.10 Released with VKD3D 2.0 and Improved VBScript Compatibility.
https://phoronix.com/news/Wine-11.10-Released

After Decades on Linux – FreeBSD Finally Gave Me Reason to Switch OS.
https://zdnet.com/article/freebsd-linux-review/

FreeBSD 15.1-RC2 Now Available.
https://lists.freebsd.org/archives/freebsd-stable/2026-May/004119.html

FreeBSD 15.1-RC2 is Now Live.
https://officialaptivi.wordpress.com/2026/05/31/freebsd-15-1-release-candidate-2-is-now-live/

Stream PostgreSQL to Apache Iceberg on S3 via Logical Replication Queryable Over PostgreSQL Wire Protocol.
https://github.com/viggy28/streambed

FreeBSD GELI vs Linux LUKS.
https://vivianvoss.net/blog/geli-vs-luks

Connect FreeBSD to OpenBSD Using WireGuard.
https://tumfatig.net/2026/connect-freebsd-to-openbsd-using-wireguard/

ZFS Helper Script for Labelling All Those Drives.
https://dan.langille.org/2026/05/30/zfs-a-helper-script-for-labelling-all-those-drives/

How to Fit FreeBSD Logo in Perfect Circle.
https://interfacecraft.online/blog/2026/how-to-fit-the-freebsd-logo-in-a-perfect-circle/

Manually Upgrade Plex on FreeBSD.
https://subnetspider.com/2026/05/25/manually-upgrade-plex-on-freebsd.html

Managing Cache and Direct IO for Databases on ZFS.
https://klarasystems.com/articles/managing-cache-and-direct-io-for-databases-on-zfs/

UNIX/Audio/Video

FreeBSD Jails Deep Dive: Through Thick and Thin.
https://youtube.com/watch?v=Dd_5OdFDP6A

BSD Now 665: 60 Puffies.
https://www.bsdnow.tv/665

Hardware

Childhood Computing.
https://lilysthings.org/blog/childhood-computing/

Black Hawk Down.
https://vivapowerpc.eu/20260527-1300_Black_Hawk_Down

OmniDrive Firmware Made Blu-Ray Drives 10x Better.
https://.com/watch?v=CuioEfLtVyo

Modos Paper Monitor.
https://crowdsupply.com/modos-tech/modos-paper-monitor

It is Hard to Justify Buying Framework 12.
https://jeffgeerling.com/blog/2026/its-hard-to-justify-framework-12/

Other

Windows Classic 3D Space Cadet Pinball Gets Physical Recreation.
https://arstechnica.com/gaming/2026/05/windows-classic-3d-space-cadet-pinball-is-getting-a-physical-re-creation/

LibreWolf 151.0.2 Released.
https://codeberg.org/librewolf/bsys6/releases/tag/151.0.2-1

How Good Max Verstappen is Really: GT3 Stats Shocked Real Endurance Drivers.
https://youtube.com/watch?v=kjTUT7WLfW4

Linux Foundation Announces DNS-AID Project to Advance Decentralized AI Agent Discovery.
https://linuxfoundation.org/press/linux-foundation-announces-dns-aid-project-to-advance-decentralized-ai-agent-discovery

Listening to Every Album: AC/DC.
https://82mhz.net/posts/2026/05/listening-to-every-album-ac-dc/

Usual Suspects

BSD Weekly.
https://bsdweekly.com/

DiscoverBSD.
https://discoverbsd.com/

DragonFly BSD Digest.
https://dragonflydigest.com/

FreeBSD Patch Level Table.
https://bokut.in/freebsd-patch-level-table/

FreeBSD End of Life Date.
https://endoflife.date/freebsd

Phoronix BSD News Archives.
https://phoronix.com/linux/BSD

OpenBSD Journal.
https://undeadly.org/

Call for Testing.
https://callfortesting.org/

Call for Testing – Production Users Call.
https://youtube.com/@callfortesting/videos

BSD Now Weekly Podcast.
https://www.bsdnow.tv/

Nixers Newsletter.
https://newsletter.nixers.net/entries.php

BSD Cafe Journal.
https://journal.bsd.cafe/

DragonFly BSD Digest – Lazy Reading – In Other BSDs.
https://dragonflydigest.com

FreeBSD Git Weekly.
https://freebsd-git-weekly.tarsnap.net/

FreeBSD Meetings.
https://youtube.com/@freebsdmeetings

Sheridan Computers.
https://youtube.com/@sheridans/videos

EOF

2026-05-31 00:00:00 UTC

The second release candidate build for the FreeBSD 15.1 release cycle is now available. ISO images for the amd64, armv7, aarch64, powerpc64, powerpc64le, and riscv64 architectures are FreeBSD mirror sites.

2026-05-30 16:00:00 UTC

Ich spiele selbst mit. Das wissen die meisten, die schon im globalen Chat unterwegs waren. Der Vorteil: ich merke recht schnell, wenn etwas nicht stimmt. Der Nachteil:
manchmal liegt der Entwickler in mir mit dem Spieler in mir im Clinch.

Aber zur Sache. Die Beta neigt sich dem Ende. In den nächsten Tagen kommt ein Reset, alle Spielstände werden zurückgesetzt, die Tester-Accounts fallen weg.

Wer bisher dabei war:

Danke. Es war ein holpriger Start mit einigen Bugs, aber das Feedback hat geholfen und einiges davon ist schon eingeflossen.

Die Abstimmung zum Spielziel habe ich ausgewertet. Das Saison-Modell hat gewonnen: ein klarer Zeitrahmen, ein klares Ziel, dann Reset und neue Runde.

Wie lang eine Saison geht und was den Sieger auszeichnet, dazu kommt noch ein separater Beitrag.

Bis zum Reset kommen noch ein paar Änderungen ins Spiel. Ich verrate noch nicht alles, aber: Planeten bekommen mehr Gewicht, nicht nur für die Produktion. Wer mehr davon hält, kommt auch in der Forschung weiter. Und eine der Rassen bekommt eine neue Technologie, die defensiv ausgerichtet ist. Welche das ist, findet sich im Spiel.

Für die erste Saison ist außerdem ein Abstimmungssystem geplant, direkt im Dashboard. Ich hatte bisher den globalen Chat dafür verwendet, was funktioniert hat, aber umständlicher war als es sein müsste.

Rückmeldungen wie immer: per Chat im Spiel, über das Feedback-Formular oder als Kommentar hier.

2026-05-28 17:23:00 UTC

Vor einigen Wochen hatte ich eine Idee: ein textbasiertes Browser-Space-MMO, angelehnt an ein Konzept, das ich 2004 mal skizziert hatte. Dass es in 22 Entwicklungssessions live gehen und eine aktive Community anziehen würde, hatte ich nicht erwartet. Dieser Artikel beschreibt, wie das möglich war.

Der ehrliche Spoiler: Ich hatte Hilfe

MMO-20044 wurde nicht allein von mir programmiert. Mein Entwicklungspartner heißt Claude, ein KI-Assistent von Anthropic. Aber "KI hat den Code geschrieben" trifft es nicht richtig. Die Realität ist differenzierter und, wie ich finde, interessanter.

Superpowers: Der Workflow macht den Unterschied

Das Entscheidende liegt nicht im KI-Modell selbst, sondern in einem Workflow-Framework namens Superpowers, einem strukturierten System für KI-gestützte Softwareentwicklung. Der Ablauf für jedes Feature sieht so aus:

Brainstorming: Ich beschreibe die Idee, die KI stellt gezielte Fragen, wir erarbeiten gemeinsam ein Design
Spec schreiben: Ein vollständiges Designdokument wird erstellt und von mir genehmigt
Implementierungsplan: Jede Aufgabe wird in kleine, testbare Schritte aufgeteilt
Subagent-Driven Development: Für jede Aufgabe wird ein frischer KI-Subagent beauftragt, der TDD (Test-Driven Development) folgt
Zwei Review-Stufen: Erst prüft ein Spec-Reviewer, ob die Anforderungen erfüllt sind, dann ein Code-Quality-Reviewer, ob der Code sauber ist

Das klingt aufwändiger als "schreib mir eine Funktion", und das ist es auch. Aber genau das macht den Unterschied zwischen Code-Snippets und einem echten Produkt.

Was ich beigetragen habe

Meine Rolle war die des Produktmanagers und Spieldesigners. Ich habe entschieden:

Welche Features gebaut werden (und welche nicht, YAGNI ist ein echtes Prinzip)
Wie das Spielgefühl sein soll: Ticks als Währung, prozedurales Universum, taktischer Kampf
Wann etwas gut genug ist und wann es noch überarbeitet werden muss
Wie auf Community-Feedback reagiert wird

Kein einziger Implementierungsvorschlag wurde blind übernommen. Jede Spec habe ich gelesen und freigegeben, jedes Feature im Browser getestet.

22 Sessions, 311 Tests, eine lebendige Community

Das Ergebnis nach 22 Entwicklungssessions:

Tick-Engine, prozedurales Universum, 8 Rassen mit eigenem Forschungsbaum
Kampfsystem mit Narrativ, Spionage, NPC-Handelsrasse
Planetenproduktion, Reisen, Besiedeln, Action-Queue
Auth, Admin-CLI, Feedback-System, Rangliste
Chat-System (Global + Direktnachrichten) mit Bad-Word-Filter und Ungelesen-Indikator
311 automatisierte Tests, kein manuelles Klicken um Regressionen zu finden

Was mich am meisten überrascht hat: Die Community ist aktiv. Spieler melden Exploits (1-Tick-Angriffe wurden am ersten Tag gefunden und gefixt), wünschen sich Features (parallele Forschungsslots kamen auf Feedback) und diskutieren im integrierten Chat über das Spielziel.

Was ich gelernt habe

KI-gestützte Entwicklung ist kein Autopilot. Der strukturierte Workflow, Spec vor Code, Tests vor Implementierung, Review nach jeder Aufgabe, ist nicht optional, sondern der Kern des Ansatzes. Ohne diesen Rahmen entstehen schnell technische Schulden, die jede Geschwindigkeit wieder auffressen.

Die Ideen kommen vom Menschen. Die KI kann keine gute Spielmechanik erfinden, die ich nicht zuvor als Anforderung formuliert habe. Was sie kann: diese Ideen zuverlässig, schnell und mit hoher Codequalität umsetzen.

Das Spiel ist kostenlos und werbefrei spielbar. Wer neugierig ist: zockertown.de/mmo/

2026-05-28 15:24:16 UTC

I have already mentioned one of my improvements to scrub in an earlier post, Teaching ZFS about time. In that post I also claimed that scrub can be expensive, and that we were looking for ways to limit the amount of data we actually want to scrub. A scrub on a multi-petabyte pool can run for days, and some of us want a smaller, easier check that everything is still going right.

2026-05-28 14:57:00 UTC

Update: Forschung, Kampf und Reisen verbessert

Das Feedback der ersten Tage hat direkt zu mehreren Verbesserungen geführt — das ist genau der Grund, warum ein offener Beta-Test so wertvoll ist.

Forschung: schneller und paralleler

Auf Wunsch mehrerer Spieler wurde die Forschungsdauer von 6 auf 3 Stunden halbiert. Zusätzlich gibt es jetzt zwei parallele Forschungsslots — ihr könnt also gleichzeitig zwei Technologien erforschen oder upgraden. Die Forschungsseite zeigt euch, wie viele Slots gerade belegt sind.

Exploit-Fix: 1-Tick-Angriffe

Ein cleverer Spieler hat entdeckt, dass man mit massenhaften 1-Tick-Angriffen anderen Spielern künstlich Siege bescheren konnte — und damit die Rangliste manipulierte. Das ist jetzt behoben: Ein Angriff kostet mindestens 50 Ticks, und auf denselben Spieler kann man nur einmal pro Stunde angreifen. Danke für den Hinweis!

Reisedauer sichtbar

Ebenfalls auf Feedback-Basis: Auf der Reiseseite steht jetzt neben den Tick-Kosten auch die Reisedauer in Stunden und Minuten — inklusive Bonus durch Antriebstechnologien.

Weiter so — jeder Hinweis hilft, das Spiel besser zu machen.

Bitte sagt auch eure Meinung zum Spielziel, bin gespannt

2026-05-28 07:03:00 UTC

Nach ein paar Tagen intensivem Testen mit einer kleinen Gruppe ist es jetzt offiziell: MMO-20044 hat einen eingebauten Chat — und der ist ab heute für alle Spieler freigeschaltet.

Was kann der Chat?

Zwei Bereiche auf einer Seite:

Global-Chat — alle Spieler sehen alle Nachrichten, ideal für Ankündigungen, Bündnisgesuche oder einfach Smalltalk zwischen den Sektoren
Direktnachrichten — private Unterhaltungen zwischen zwei Spielern, z.B. um einen gemeinsamen Angriff abzusprechen, ohne dass die anderen mitlesen

Der Chat aktualisiert sich alle 5 Sekunden automatisch, ohne dass die Seite neu geladen werden muss. Wer eine ungelesene Direktnachricht hat, sieht den Chat-Link in der Navigation in hellblau und gelb blinken — man verpasst also nichts.

Technischer Hintergrund (für Interessierte)

Der Chat läuft komplett ohne WebSockets — stattdessen fragt der Browser alle 5 Sekunden diskret beim Server nach neuen Nachrichten (HTMX-Polling). Nachrichten werden serverseitig auf problematische Inhalte geprüft, und Admins können jederzeit die Logs einsehen. Alte Nachrichten werden automatisch aufgeräumt: Global-Nachrichten nach 7 Tagen (die letzten 200 bleiben immer erhalten), Direktnachrichten nach 30 Tagen.

Und jetzt zur großen Frage: Was ist eigentlich das Spielziel?

Das Spiel läuft, die ersten Spieler erkunden die Galaxis, forschen, handeln, greifen sich gegenseitig an — aber ein klares Endziel fehlt noch. Das ist bewusst so, denn ich möchte euch entscheiden lassen, in welche Richtung es geht.

Drei Varianten stehen zur Debatte:

(A) Saison-Modell — Das Spiel läuft 4–6 Wochen, dann gibt es einen klaren Sieger (Rangliste), und das Universum wird zurückgesetzt. Alle starten wieder von vorne. Vorteil: klares Ziel, fairer Neustart, kein „der hat halt früher angefangen"-Problem.

(B) Persistente Welt mit Meilenstein-Sieg — Wer als erster einen bestimmten Meilenstein erreicht (z.B. 10 Planeten besiedelt oder eine bestimmte Punktzahl), gewinnt die aktuelle Runde — aber die Welt läuft weiter. Andere Spieler können weitermachen oder auf die nächste Runde hinarbeiten.

(C) Kein hartes Ziel — Die Rangliste bleibt das Maß aller Dinge, das Spiel läuft offen ohne Reset. Wer die meisten Ticks, Planeten und Siege hat, steht oben — und bleibt da, bis ihn jemand überholt.

Ich habe die Frage bereits im Global-Chat gestellt — schaut rein und gebt mir Feedback! Entweder direkt im Chat, per Direktnachricht, oder über das Feedback-Formular. Jede Meinung zählt.

Viel Spaß beim Chatten — und beim Pläneschmieden. 🚀

2026-05-27 09:36:00 UTC

Seit einigen Tagen läuft MMO-20044 in der Beta – und eine kleine, aber aktive Gruppe von Spielern nutzt das Spiel tatsächlich und schreibt mir, was ihnen auffällt. Konkret, direkt, manchmal schonungslos. Genau so soll das sein.

Zeit für einen kurzen Überblick: Was habt ihr gemeldet – und was ist daraus geworden?

Forschung ist jetzt mehr als ein einmaliges Häkchen

Ein häufiger Hinweis war, dass Forschung sich zu sehr nach einem Einmal-Klick anfühlt: erforscht, fertig, weiter. Das war richtig beobachtet. Jetzt gibt es für mehrere Technologien bis zu drei Stufen. Bergbau-Technologie auf Stufe 3 bringt spürbar mehr Rohstoff-Ertrag als Stufe 1. Schildtechnik und Pilotentraining skalieren ebenso – wer investiert, merkt den Unterschied im Kampf.

Planetenproduktion hängt jetzt wirklich an der Technik

Vorher hat ein Gesteinsplanet automatisch Rohstoffe produziert – egal ob Bergbau-Technologie erforscht war oder nicht. Das hat den Forschungsbaum ein bisschen sinnlos gemacht. Jetzt gilt: kein Tech, kein Ertrag. Und mit jeder Stufe steigt die Rate.

Feedback anonym senden – jetzt möglich

Bisher war das Feedback-Formular immer mit dem Spielernamen verknüpft. Wer lieber anonym schreiben wollte, hatte keine Wahl. Das ist behoben: Ihr könnt jetzt selbst entscheiden, ob ihr anonym, mit Spielernamen oder mit echtem Namen schreibt.

Kleinere Dinge

Die Laufschrift mit den Neuigkeiten im Spiel ist jetzt langsamer und weniger aufdringlich – mit einer kurzen Pause bevor sie von vorne beginnt.
Navigation-Links sind heller und besser lesbar.
Diverse Bugs, die ihr gemeldet habt, sind still und leise behoben.

Ein ehrliches Dankeschön an alle, die tatsächlich spielen und sich die Zeit nehmen, mir zu schreiben. Ihr seht Dinge, die ich als Entwickler nicht sehe – weil ich das Spiel kenne und ihr es entdeckt. Das macht einen echten Unterschied.

Das Spiel ist noch nicht fertig. Aber es macht schon jetzt mehr Spaß als der erste Deploy – das ist eure Leistung genauso wie meine.

→ MMO-20044 spielen

Eins noch — eine Frage an euch:

Wäre eine regelmäßige Übersicht interessant? Also: Was wurde gemeldet, was davon ist umgesetzt worden, was kommt als nächstes? Quasi ein kurzes „Aus der Werkstatt"-Update
nach jeder Entwicklungsrunde.

Schreibt mir gern eine kurze Rückmeldung — entweder per Feedback-Formular im Spiel oder direkt hier in den Kommentaren.

"MMO-20044 Beta: Danke für euer Feedback!" vollständig lesen

2026-05-26 16:28:00 UTC

Seit dem Beta-Start hat sich einiges getan im MMO-20044. Zwei neue Runden Entwicklung, zwei echte Verbesserungen die direkt spürbar sind.

Planeten arbeiten jetzt für euch

Bisher waren Planeten im Wesentlichen Standorte — man konnte sie besiedeln, aber sie taten nichts von alleine. Das hat sich geändert: Jeder Planetentyp produziert jetzt stündlich Ressourcen, passiv im Hintergrund.

Gesteinsplaneten liefern +10 Rohstoffe/Stunde
Ozeanplaneten liefern +10 Kristalle/Stunde
Gasplaneten liefern +3 Artefakte/Stunde

Das Dashboard zeigt jetzt auch an, was eure besiedelten Planeten stündlich produzieren — ein direkter Anreiz, die Galaxie zu erkunden und die richtigen Welten zu besiedeln.

Forschungsbaum endlich sichtbar

Den Forschungsbaum gab es schon länger, aber bisher war er etwas abstrakt. Jetzt gibt es eine echte Baumvisualisierung mit Unicode-Boxzeichen, die zeigt welche Technologien voneinander abhängen — und jede Tech hat eine kurze Beschreibung was sie bringt. Kein Raten mehr.

Feedback-Funktion

Ihr habt jetzt einen direkten Kanal: Im Spiel gibt es unter "Feedback" ein einfaches Textfeld. Was ihr schreibt landet bei mir — und der Kontext wird automatisch mitgeschickt: welche Planeten ihr habt, welche Technologien, was gerade läuft. Das hilft enorm beim Debuggen und beim Verstehen was im Spiel tatsächlich passiert.

Also: Wenn etwas komisch ist, wenn etwas nervt, oder wenn ihr eine Idee habt — einfach das Feedback-Formular nutzen. Ich lese alles.

Das Spiel läuft unter https://zockertown.de/mmo/.

2026-05-25 09:38:00 UTC

Vor ein paar Wochen habe ich angefangen, ein altes Spielkonzept von 2004 umzusetzen: ein tick-basiertes Browser-Space-Strategiespiel, solo betrieben, ohne Client-Download,
ohne 24/7-Zwang. Heute ist es soweit für die erste Runde Beta-Test.

Wer mitmachen will: https://zockertown.de/mmo/

---
Was ist das überhaupt?

Ein rundenbasiertes Weltraumspiel im Browser. Keine Echtzeit-Schlachten, kein ständiges Einloggen nötig. Das Spiel läuft über Ticks — die Grundwährung für alles: Forschung
starten, reisen, Planeten besiedeln, angreifen, spionieren.

Du bekommst 2 Ticks pro Minute, kannst bis zu 30.000 speichern (~10 Tage Inaktivität). Wer selten einloggt, verliert keinen Anschluss — aber wer aktiv ist und Ticks klug
einsetzt, hat einen echten Vorteil.

---
Ticks sind der knappe Faktor — das ist Absicht

Das klingt erst mal simpel, ist aber der zentrale Hebel des Spiels. Ticks kosten:

Aktion	Kosten	Bemerkung
Forschung starten	350–600 Ticks je nach Tech
Angriff	anteilig vom Kampfergebnis
Spionagesonde	200 Ticks	Um Angriffe zu planen
Reisen / Besiedeln	distanzabhängig
Handeln / Plündern	50 - 200 Ticks

Dazu kommen Wartezeiten:

Forschung dauert 6 Stunden, Besiedlung 1 Stunde, Reisen je nach Distanz und Antriebstechnik. Du kannst also nicht einfach mit einem Berg Ticks
alles auf einmal machen — Planung lohnt sich.

---
Was gibt es zu testen?

Forschungsbaum (13 Technologien)
Antriebe, Schilde, Waffen, Community-Bonusse — und neu: drei Spionagetechs. Wer die Grundvoraussetzungen erforscht, schaltet jeweils die nächste Stufe frei. Die Forschung
wird günstiger, je mehr Spieler sie bereits haben (Community-Bonus).

Kampfsystem
Taktisch, max. 10 % Zufall. Angriff kostet Ticks, bringt aber Beute wenn erfolgreich. Kampfberichte zeigen den genauen Verlauf.

Spionage (neu)
Bevor du angreifst, kannst du eine Sonde schicken. Je nach Forschungsstand deiner Rasse und der Abwehr des Gegners erfährst du mehr oder weniger: von einer groben
Einschätzung bis zum genauen Tick-Stand und der Rasse. Wird die Sonde abgefangen, erfährt der Verteidiger deinen Namen. Keine Spionagetechs? Kein Problem — dann greifst du
halt blind an.

Handel
Ein NPC-Händler fliegt regelmäßig verschiedene Systeme an und bietet Rohstoffe, Kristalle und Artefakte an — oder kauft. Wer zur richtigen Zeit am richtigen Ort ist,
profitiert.

Highscore
Ticks + Planeten × 500 + Technologien × 100 + Siege × 200 — wer was wie priorisiert, ist offen.

---
Was ist noch Beta?

- Balancing ist nicht final — Tick-Kosten, Kampfwerte und Wahrscheinlichkeiten können sich noch ändern
- Rassen-Portraits sind Platzhalter (SVG-Symbole), echte Bilder kommen später
- Spielziel / Win-Condition ist noch nicht implementiert — die aktuelle Runde läuft auf Highscore
- Fehler und Ungereimtheiten: einfach melden

---
Feedback

Direkt an mich — Forum, Nachricht, oder wie auch immer ihr mich erreicht.

Was fühlt sich falsch an, was fehlt, was nervt? Genau das interessiert mich jetzt.

2026-05-26 11:15:50 UTC

On Monday morning, I had eight emails each notifying me of a failed rsync attempt. This is one of those messages:

From: Cron Daemon <rsyncer@pg02.int.unixathome.org>
To: dan@langille.org
Subject: Cron <rsyncer@pg02> ~/bin/backup.sh > /dev/null
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <MAILTO=dan@langille.org>
X-Cron-Env: <PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:$HOME/bin; export PATH>
X-Cron-Env: <LOGNAME=rsyncer>
X-Cron-Env: <USER=rsyncer>
Date: Mon, 25 May 2026 02:02:00 +0000
Message-Id: <6a13ad98.43eb8.34b50ce7@pg02.int.unixathome.org>

/usr/local/sbin/rrsync error: unsafe arg: / ['', '/usr/home/rsyncer/backups']
rsync: connection unexpectedly closed (0 bytes received so far) [Receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(232) [Receiver=3.4.3]

Well, that’s a new one to me.

This post will eventually show you the solution, and if that’s what you need now, jump to the bottom.

If you’re not in a rush, I’m sure the following reading will be funny and a cure for your insomnia. Wow, … that sounds like Michael W. Lucas writing… Perhaps I should stop writing for free…

In this post:

FreeBSD 15.0
rsync-3.4.1
rsync-3.4.3
details on the python flavor of the net/rsync FreeBSD port

Here we go.

What I did yesterday

Yesterday, I logged into every host (by that, I mean jail, host, vm, etc) and did sudo pkg install rsync. To be honest, it only the hosts which had rsync-python installed. That package is a flavor of rsync compiled to include python as a dependency.

How did I know which hosts that was?

[21:04 pg01 dvl ~] % psql samdrucker
psql (18.4)
Type "help" for help.

samdrucker=# select * from hostswithpackageshowversion('rsync-python') order by host;
              host               |   package_version    
---------------------------------+----------------------
 r720-02-pg02.int.unixathome.org | rsync-python-3.4.1_6
 zuul.unixathome.org             | rsync-python-3.4.1_6
(2 rows)

samdrucker=#

That output is current as of last night, and I need to update those two hosts, but that’s the command I ran. See sysutils/samdruckerserver for more details about this package history tool I wrote.

Why would rsync need python?

Well, let me tell you…

Adding a missing dependency

In April 2025, a FreeBSD PR was filed to add a missing dependency: python. That first commit bit me in that rrsync disappeared. Note that is rrsync, not rsync. rrsync is “a script to setup restricted rsync users via ssh logins”. It means you can restrict an incoming ssh connection to rsync‘ing only specific things. See My solution for copying backups around the homelab.

flavor

Next, a flavor was added, net/rsync@python, named rsync-python. I installed that on all my hosts where rsync was installed.

And things were happy. Until they weren’t.

mariadb

It wasn’t until March 2026 that I filed a new PR – I use rrsync when copying backups to another location. With flavors, I can’t have both net/rsync and net/rsync-python, given that net/rsync is a dependency of databases/mariadb118-server…

And, by the way, the reasons for swapping to maria were frustrating. So far, just that one host has been migrated.

So, what to do…

We initially talked about two distinct ports, neither of which conflicted:

net/rsync-rrsync
net/rsync

Eventually, it was decided to go back to what we had before. I was OK with that. No worries.

Reverting from rsync-python to rsync

Yesterday, being a rainy Sunday of USA Memorial Day weekend, I did this on every host which had it:

[11:49 x8dtu dvl ~] % sudo pkg install rsync
Updating local repository catalogue...
local repository is up to date.
All repositories are up to date.
Checking integrity... done (1 conflicting)
  - rsync-3.4.3 [local] conflicts with rsync-python-3.4.1_6 [installed] on /usr/local/bin/rsync
Checking integrity... done (0 conflicting)
The following 2 package(s) will be affected (of 0 checked):

New packages to be INSTALLED:
	rsync: 3.4.3 [local]

Installed packages to be REMOVED:
	rsync-python: 3.4.1_6

Number of packages to be removed: 1
Number of packages to be installed: 1

Proceed with this action? [y/N]: y
[1/2] Deinstalling rsync-python-3.4.1_6...
[1/2] Deleting files for rsync-python-3.4.1_6: 100%
[2/2] Installing rsync-3.4.3...
[2/2] Extracting rsync-3.4.3: 100%
=====
Message from rsync-3.4.3:

--
Some scripts provided by rsync, such as rrsync,
require Python, which is not installed by default.

I went to bed, and woke up to the emails in question.

The solution

I could not figure out the problem at first. I installed the old package (rsync-python-3.4.1_6) – things worked. I installed the new package (rsync-3.4.3) – things broke.

I did a diff between the two rrsync scripts:

[11:49 x8dtu dvl ~] % diff -ruN /usr/local/sbin/rrsync ~/tmp/rrsync 
--- /usr/local/sbin/rrsync	2026-05-24 02:02:17.000000000 +0000
+++ /usr/home/dvl/tmp/rrsync	2026-05-25 11:49:17.323864000 +0000
@@ -46,7 +46,6 @@
   'compare-dest': 2,
   'compress-choice': 1,
   'compress-level': 1,
-  'compress-threads': 1,
   'copy-dest': 2,
   'copy-devices': -1,
   'copy-unsafe-links': 0,
@@ -60,7 +59,6 @@
   'delete-during': 0,
   'delete-excluded': 0,
   'delete-missing-args': 0,
-  'dirs': 0,
   'existing': 0,
   'fake-super': 0,
   'files-from': 3,
@@ -302,7 +300,6 @@
     if arg.startswith('./'):
         arg = arg[1:]
     arg = arg.replace('//', '/')
-    arg = arg.lstrip('/')
     if args.dir != '/':
         if HAS_DOT_DOT_RE.search(arg):
             die("do not use .. in", opt, "(anchor the path at the root of your restricted dir)")

I was sure that was the cause of the issue.

Searching for “/usr/local/sbin/rrsync error: unsafe arg: /” gave me:

This error is almost entirely caused by rrsync (restricted rsync), which is a wrapper script on the remote server meant to restrict users to specific directories and prevent them from escaping to the root / directory.

EH? I’m not doing that. (disclosure: oh yes I was!)

I could not see the cause of the problem, so I composed my social media post. In the process of that writing, I discovered the cause. It was a /.

It was the / in this file (and others like it). See the last line of the file.

[rsyncer@dbclone ~/backups/x8dtu-pg01/database-backup/postgresql]$ cat /home/rsyncer/bin/rsync-backup-from-x8dtu-pg01.sh
#!/bin/sh
#
# This file does a backup of each database on the server.
# It relies upon a file on the server to do the actual backup,
# then uses rsync to copy the files from the server to here.
#

# the ~/.ssh/authorized keys entry on the server must look like this:
#
# from="10.55.0.140",command="/usr/local/sbin/rrsync /usr/home/backups/" [ssh key goes here]
#
# invoking rrsync ensures the incoming rsync process is chrooted to /usr/home/dan/backups/
# Thus, BACKUPDIR is relative to that location.

BACKUPDIR=${HOME}/backups/x8dtu-pg01

IDENTITY_FILE_RSYNC=${HOME}/.ssh/id_ed25519.rsync.pg01.from.x8dtu
SERVER_TO_RSYNC=x8dtu.vpn.unixathome.org

cd ${BACKUPDIR}

#
# use rsync to get local copies
#
/usr/local/bin/rsync -e "/usr/bin/ssh -i ${IDENTITY_FILE_RSYNC}" --recursive -av --stats --progress --exclude 'archive' ${SERVER_TO_RSYNC}:/ ${BACKUPDIR}

What / you might ask? The one right after the hostname: ${SERVER_TO_RSYNC}:/

I removed that, everything worked.

Fixing more stuff

It seems I have a few of those:

[rsyncer@dbclone ~/bin]$ grep ':/ ' *
rsync-backup-from-aws-1-dump.sh:/usr/local/bin/rsync -e "/usr/bin/ssh -i ${IDENTITY_FILE_RSYNC}" --recursive -av --stats --progress --exclude 'archive' ${SERVER_TO_RSYNC}:/ ${BACKUPDIR}
rsync-backup-from-gelt.sh:/usr/local/bin/rsync -e "/usr/bin/ssh -i ${IDENTITY_FILE_RSYNC}" --recursive -av --stats --progress --exclude 'archive' --exclude Bacula ${SERVER_TO_RSYNC}:/ ${BACKUPDIR}
rsync-backup-from-mysql01.sh:/usr/local/bin/rsync -e "/usr/bin/ssh -i ${IDENTITY_FILE_RSYNC}" --recursive -av --stats --progress --exclude 'archive' ${SERVER_TO_RSYNC}:/ ${BACKUPDIR}
rsync-backup-from-mysql02.sh:/usr/local/bin/rsync -e "/usr/bin/ssh -i ${IDENTITY_FILE_RSYNC}" --recursive -av --stats --progress --exclude 'archive' ${SERVER_TO_RSYNC}:/ ${BACKUPDIR}
rsync-backup-from-papers.sh:/usr/local/bin/rsync -e "/usr/bin/ssh -i ${IDENTITY_FILE_RSYNC}" --recursive -av --stats --progress --exclude 'archive' ${SERVER_TO_RSYNC}:/ ${BACKUPDIR}
rsync-backup-from-pg01.sh:/usr/local/bin/rsync -e "/usr/bin/ssh -i ${IDENTITY_FILE_RSYNC}" --recursive -av --stats --progress --exclude 'archive' ${SERVER_TO_RSYNC}:/ ${BACKUPDIR}
rsync-backup-from-pg02.sh:/usr/local/bin/rsync -e "/usr/bin/ssh -i ${IDENTITY_FILE_RSYNC}" --recursive -av --stats --progress --exclude 'archive' ${SERVER_TO_RSYNC}:/ ${BACKUPDIR}
rsync-backup-from-pg03.sh:/usr/local/bin/rsync -e "/usr/bin/ssh -i ${IDENTITY_FILE_RSYNC}" --recursive -av --stats --progress --exclude 'archive' ${SERVER_TO_RSYNC}:/ ${BACKUPDIR}
rsync-backup-from-supernews.sh:/usr/local/bin/rsync -e "/usr/bin/ssh -i ${IDENTITY_FILE_RSYNC}" --recursive -av --stats --progress --exclude 'archive' ${SERVER_TO_RSYNC}:/ ${BACKUPDIR}
rsync-backup-from-tallboy.sh:/usr/local/bin/rsync -e "/usr/bin/ssh -i ${IDENTITY_FILE_RSYNC}" --recursive -av --stats --progress --exclude 'archive' ${SERVER_TO_RSYNC}:/ ${BACKUPDIR}
rsync-backup-from-x8dtu-pg01.sh~:/usr/local/bin/rsync -e "/usr/bin/ssh -i ${IDENTITY_FILE_RSYNC}" --recursive -av --stats --progress --exclude 'archive' ${SERVER_TO_RSYNC}:/ ${BACKUPDIR}
rsync-backup-from-x8dtu-pg02.sh:/usr/local/bin/rsync -e "/usr/bin/ssh -i ${IDENTITY_FILE_RSYNC}" --recursive -av --stats --progress --exclude 'archive' ${SERVER_TO_RSYNC}:/ ${BACKUPDIR}
rsync-backup-from-x8dtu.sh:/usr/local/bin/rsync -e "/usr/bin/ssh -i ${IDENTITY_FILE_RSYNC}" --recursive -av --stats --progress --exclude 'archive' ${SERVER_TO_RSYNC}:/ ${BACKUPDIR}
rsync-backup-from-zuul-mariadb01.sh:/usr/local/bin/rsync -e "/usr/bin/ssh -i ${IDENTITY_FILE_RSYNC}" --recursive -av --stats --progress --exclude 'archive' ${SERVER_TO_RSYNC}:/ ${BACKUPDIR}
rsync-backup-from-zuul-mysql.sh:/usr/local/bin/rsync -e "/usr/bin/ssh -i ${IDENTITY_FILE_RSYNC}" --recursive -av --stats --progress --exclude 'archive' ${SERVER_TO_RSYNC}:/ ${BACKUPDIR}
rsync-backup-from-zuul-pg01.sh:/usr/local/bin/rsync -e "/usr/bin/ssh -i ${IDENTITY_FILE_RSYNC}" --recursive -av --stats --progress --exclude 'archive' ${SERVER_TO_RSYNC}:/ ${BACKUPDIR}
rsync-backup-from-zuul-pg02.sh:/usr/local/bin/rsync -e "/usr/bin/ssh -i ${IDENTITY_FILE_RSYNC}" --recursive -av --stats --progress --exclude 'archive' ${SERVER_TO_RSYNC}:/ ${BACKUPDIR}
rsync.pg01.from.r720-02.sh:/usr/local/bin/rsync -e "/usr/bin/ssh -i ${IDENTITY_FILE_RSYNC}" --recursive -av --stats --progress --exclude 'archive' ${SERVER_TO_RSYNC}:/ ${BACKUPDIR}
rsync.pg02.from.r720-02.sh:/usr/local/bin/rsync -e "/usr/bin/ssh -i ${IDENTITY_FILE_RSYNC}" --recursive -av --stats --progress --exclude 'archive' ${SERVER_TO_RSYNC}:/ ${BACKUPDIR}

Time to update them all:

[rsyncer@dbclone ~/bin]$ joe $(grep -l ':/ ' *)

That finds each file with the string in question, and opens it into an editor for me. I could have done a global edit, changing every occurrence with review. I feel that’s too open to error.

Changed them all. Now I wait. I’ll post this entry tomorrow, after seeing how things go.

Tuesday morning

It is now Tuesday morning at 11:06 UTC – no errors. No monitoring flags. All good to go.

2026-05-25 13:21:49 UTC

Authorities in the Netherlands have arrested the co-owners of two related Internet hosting companies for operating IT infrastructure used by Russia to carry out cyberattacks, influence operations and disinformation campaigns inside the European Union. The two men were the focus of a 2025 KrebsOnSecurity story about how their hosting companies had assumed control over the technical infrastructure of Stark Industries Solutions, an Internet service provider sanctioned last year by the EU as a frequent staging ground for cyber mischief from Russia’s intelligence agencies.

An investigator with the Tax Intelligence and Investigation Service (FIOD), the Dutch financial crimes agency, during the raid. Image: FIOD.

The Dutch daily news outlet de Volkskrant reports that the Dutch financial crime agency FIOD on May 18 arrested a 57-year-old from Amsterdam and a 39-year-old from The Hague, charging them with violating sanctions law by directly or indirectly making economic resources available to EU-sanctioned entities.

The Dutch investigation focuses on Stark Industries, a sprawling hosting provider that materialized just two weeks before Russia invaded Ukraine. As detailed in this May 2024 deep-dive, Stark quickly became the source of massive distributed denial-of-service (DDoS) attacks against European targets, and emerged as a top supplier of proxy and anonymity services that showed up time and again in cyberattacks linked to Russia-backed hacking groups.

That report identified two Moldovan brothers — Ivan and Yuri Neculiti and their company PQHosting — who were providing one of Stark’s two main conduits to the larger Internet. In May 2025, the EU sanctioned PQHosting and the Neculiti brothers for aiding Russia’s hybrid warfare efforts. But as KrebsOnSecurity observed in September 2025, those sanctions failed to target Stark’s remaining connection to the Internet — an Internet service provider based in the Netherlands called MIRhosting.

MIRhosting is operated by Andrey Nesterenko, a 39-year-old Russian native who runs the business out of the Netherlands. News that PQHosting and the Neculiti brothers were about to be sanctioned by the EU leaked in the media nearly two weeks before the sanctions were announced last year. During that time, the Stark network assets were transferred from PQHosting to a new entity called the[.]hosting, under the control of the Dutch entity WorkTitans BV.

And as our September 2025 report showed, WorkTitans was controlled by Nesterenko and a 57-year-old from Amsterdam named Youssef Zinad. On top of that, WorkTitans was getting connectivity to the larger Internet solely through MIRhosting, where Zinad had worked previously.

On May 18, Dutch financial crime investigators arrested Nesterenko and Zinad, and searched three businesses in Enschede and Almere and two data centers in Dronten and Schiphol-Rijk. A statement from the Dutch authorities said they also seized laptops, telephones and more than 800 servers.

A message to the-hosting customers immediately after 800 of its servers were seized by Dutch authorities. The message says that unfortunately data stored on the server has been lost and cannot be recovered.

De Volkskrant said it reviewed data showing WorkTitans and MIRhosting were the most-used networks in pro-Russian attacks on Danish government bodies between November 13 and 19, 2025, the week of Denmark’s municipal elections.

The publication wrote that prior to Nesterenko’s arrest, the MIRhosting founder denied that he knew his servers had been misused by pro-Russian cybercriminals. “He said he had ended all services with the Neculiti brothers when the EU sanctions came into force in May 2025,” and the he “reserved all rights to take action against ‘harmful and incorrect publications,” de Volkskrant wrote.

MIRhosting released a statement saying it has initiated an internal investigation into the alleged facts concerning the elections in Denmark, and that it has temporarily paused services to WorkTitans as a precautionary measure while the matter is being reviewed further.

“Based on our preliminary findings, there are no indications that the services over which we exercise control were actually used to influence the Danish elections,” the statement reads. “No anomalies or spikes were observed in our network traffic during the period mentioned in the publication; had large-scale DDoS attacks occurred, such activity would have been evident. Furthermore, prior to the media publication, we had not received any complaints, abuse reports, or official requests regarding suspicious activities or misuse of our network. Meanwhile, our regular operational activities continue, and our service to our other clients remains fully intact.”

Born in Nizhny Novgorod, Russia, Mr. Nesterenko grew up as a piano prodigy who performed publicly at a young age. In 2004, Nesterenko founded MIRhosting’s parent Innovation IT Solutions Corp., which has the notable distinction of being the company responsible for hosting stopgeorgia[.]ru, a hacktivist website for organizing cyberattacks against Georgia that appeared at the same time Russian forces invaded the former Soviet nation in 2008. That conflict was thought to be the first war ever fought in which a notable cyberattack and an actual military engagement happened simultaneously.

Responding to questions shared via email, Nesterenko said MIRhosting does not support cybercrime, sanctions evasion, or illegal activity, and that the allegations and arrest by Dutch authorities have been extremely harmful to him and his company.

“The transition to the.hosting was not intended to evade sanctions,” Nesterenko wrote. “The hardware and customer portfolio had already been transferred to WorkTitans before the sanctions appeared. Closing or damaging a legitimate Dutch infrastructure company will not stop cybercrime, but it will harm many people who have done nothing wrong.”

Far less is public about the 57-year-old Zinad, who reportedly has been keeping a low profile since our story last year. De Volkskrant reported that Zinad blocked access to his LinkedIn account, had gone months without responding to emails, WhatsApp messages and phone calls, and told a colleague that illness was forcing him to lead a somewhat more reclusive life.

Mr. Zinad’s now-defunct LinkedIn profile. It was full of posts for MIRhosting’s services.

Mr. Nesterenko claims Zinad was never an employee of MIRhosting.

“He helped me and MIRhosting with certain business tasks under a normal business-to-business arrangement between companies,” Nesterenko explained.

However, in previous emails to KrebsOnSecurity, Nesterenko carbon copied Mr. Zinad (who had a @mirhosting.com email), explaining that he was part of the company’s legal team. Also, the Dutch website stagemarkt[.]nl lists Youssef Zinad as an official contact for MIRhosting’s offices in Almere.

Mr. Zinad has never responded to requests for comment. Nor did de Volkskrant have any luck tracking him down. The publication said it repeatedly asked Mr. Zinad (referred to here as simply “Z”), but he reportedly avoided every form of contact.

“‘I am unavailable but will respond to your message as soon as possible,’ reads an automated reply on WhatsApp on 2 October 2025,” de Volkskrant reported. “It is the only response de Volkskrant would receive in months. He did not pick up his phone and did not call back. When an acquaintance asked him via LinkedIn to contact the reporter, he blocked access to his LinkedIn page. At an address in Almere where Z.’s personal limited company is registered, no one was present in April. The corner house’s blinds were drawn, and a pile of rubbish bags lay outside next to a container, as if someone had recently left. A neighbour said he knew the man but did not know where he was staying. Z. was later arrested at a residence in Amsterdam.”

2026-05-25 08:08:11 UTC

The Valuable News weekly series is dedicated to provide summary about news, articles and other interesting stuff mostly but not always related to the UNIX/BSD/Linux systems. Whenever I stumble upon something worth mentioning on the Internet I just put it here.

Today the amount information that we get using various information streams is at massive overload. Thus one needs to focus only on what is important without the need to grep(1) the Internet everyday. Hence the idea of providing such information ‘bulk’ as I already do that grep(1).

The Usual Suspects section at the end is permanent and have links to other sites with interesting UNIX/BSD/Linux news.

Past releases are available at the dedicated NEWS page.

UNIX

SonicDE Forked KDE Plasma Login Manager – It Now Runs X11 and Supports systemd-free.
https://x.com/SonicDesktop/status/2056015572849360913

mdo(1) on FreeBSD 15: Base System Privilege Delegation with mac_do(4).
https://blog.hofstede.it/mdo-on-freebsd-15-base-system-privilege-delegation-with-mac_do/

FediMeteo – HAProxy – Art of Not Wasting Snac Threads.
https://it-notes.dragas.net/2026/05/18/fedimeteo-haproxy-and-the-art-of-not-wasting-snac-threads/

FreeBSD Git Weekly: 2026-05-11 to 2026-05-17.
https://freebsd-git-weekly.tarsnap.net/2026-05-11.html

DistroWatch.com Reviews Sylve.
https://distrowatch.com/weekly-mobile.php?issue=20260518#sylve

Thorsten Geppert – FreeBSD Weekly Roundup – 2026/05/11–17.
https://tgeppert.com/2026/05/18/freebsd-weekly-roundup-may-11-17-2026/

OpenBSD 7.9 Released.
https://openbsd.org/79.html

OpenBSD 7.9 Released.
https://undeadly.org/cgi?action=article;sid=20260519132757

OpenBSD 7.9 Released with Support for 255 CPU Cores and WiFi 6.
https://phoronix.com/news/OpenBSD-7.9-Released

Multi Display Hack for OpenBSD.
https://mastodon.social/@izder456@ieji.de/115613408440754414

Qemu Accelerated with bhyve_vmm for First Time on FreeBSD.
https://forums.freebsd.org/threads/qemu-bhyve-vmm.102735/

Blog Ran on Ubuntu 16.04 for 10 years. I Migrated to FreeBSD.
https://crocidb.com/post/this-blog-ran-on-ubuntu-16-04-for-10-years-i-migrated-it-to-freebsd/

Private pkg(8) Repo Behind Mutual TLS.
https://oshogbo.com/blog/88/

FreeBSD 2026/05 Security Batch – Operator Triage Guide.
https://maxiujun.com/blog/freebsd-may-2026-security-batch-triage-guide

FreeBSD FatGid Vulnerability.
https://fatgid.io/

FreeBSD Migration: Best Reasons to Leave Ubuntu Behind.
https://squaredtech.co/migrating-to-freebsd-why-one-dev-ditched-ubuntu-after-10-years

FreeBSD 15.1-RC1 Now Available.
https://lists.freebsd.org/archives/freebsd-stable/2026-May/004103.html

FreeBSD Joins Open Source Security Foundation (OpenSSF).
https://linuxfoundation.org/press/openssf-notes-quarter-of-growth-with-new-members-added-ai-security-resources-and-growing-community

FreeBSD 15.1-RC1 Released: Fixes with Now Seeing More AI Discovered Security Issues.
https://phoronix.com/news/FreeBSD-15.1-RC1

Game of Trees 0.126 Released.
https://undeadly.org/cgi?action=article;sid=20260523115158

Dual Node Home FreeBSD NAS Cluster for $210.
https://laser-coder.net/articles/home-nas/index.html

ElytAmbience Native Ambient Sound Generator for FreeBSD/GhostBSD.
https://github.com/elytraVIII/ElytAmbience

FreeBSD Foundation Executive Director Tries Daily Driving FreeBSD on Laptop.
https://phoronix.com/news/FreeBSD-On-Laptop-Driver

FreeBSD DTrace vs Linux eBPF.
https://vivianvoss.net/blog/dtrace-vs-ebpf

Unlocking Encrypted ZFS Volumes with Passkey.
https://withblue.ink/2026/05/revaulter-encrypted-zfs-passkey

UNIX Has Been Changing but in Places Where I Do Not See It.
https://utcc.utoronto.ca/~cks/space/blog/unix/UnixChangingQuietly

The dhcpd(8) and unbound(8) in FreeBSD Jails.
https://tumfatig.net/2026/dhcpd-and-unbound-in-freebsd-jails/

Desktop BSD.
https://technophobeconfessions.wordpress.com/2026/05/20/desktop-bsd/

Nginx with Automatic HTTPS Using Lets Encrypt and Active24 DNS Challenge.
https://freebsd.uw.cz/2026/05/nginx-with-automatic-https-using-lets.html

Disk Partitioning and Filesystem Management on FreeBSD with gpart(8)/newfs(8)/mount(8) Commands.
https://freebsd.uw.cz/2026/05/disk-partitioning-and-filesystem.html

Printing with CUPS on OpenBSD.
https://kaidenshi.com/posts/printing-with-cups-on-openbsd/

FreeBSD Git Weekly: 2026-05-18 to 2026-05-24.
https://freebsd-git-weekly.tarsnap.net/2026-05-18.html

UNIX/Audio/Video

Random Bits – My Own Teleprompter.
https://youtube.com/watch?v=4k1hYvYZT_4

How to Recover Data from GVINUM RAID on FreeBSD.
https://youtube.com/watch?v=R-BGaH-E8ak

How to Recover Data from ZFS RAIDZ Array with TrueNAS Core.
https://youtube.com/watch?v=ailzc30DIpI

Look at FreeBSD FatGid Vulnerability.
https://youtube.com/watch?v=Xcwp2qFZtiY

GhostBSD DOSBox Staging – Small Howto.
https://youtube.com/watch?v=swVuAlZpf2Q

Chrome Browser Installed AI Behind Your Back – Google Exposed.
https://youtube.com/watch?v=lgzvCnldxgY

2026-05-20 OpenZFS Production User Call.
https://youtube.com/watch?v=Mhu9WllvEes

KDE Plasma Login Manager Fork Working on GhostBSD/XLibre by SonicDE.
https://youtube.com/watch?v=F74Pba9V-Hk

BSD Now 664: No One Misses SPARC.
https://www.bsdnow.tv/664

Hardware

Open Source z386 Brings Intel 80386 Microcode Back to Life.
https://linuxiac.com/open-source-z386-brings-intel-80386-microcode-back-to-life/

AMIGA Bill Documentary Revisits Motorola 68060 with Joe Circello.
https://generationamiga.com/2026/05/24/amiga-bill-documentary-revisits-the-motorola-68060-with-joe-circello/

Inside Motorola 68060 and Chip Design: Interview with Lead Designer Joe Circello.
https://youtube.com/watch?v=1takr2k7Yfo

AMD Announces Production Ramp of Next Generation AMD EPYC Processor Venice on TSMC 2nm Process Technology.
https://www.amd.com/en/newsroom/press-releases/2026-5-20-amd-announces-production-ramp-of-next-generation-a.html

Life

Peter G. Neumann – Who Warned of Computer Security Risks – Dies at 93
https://nytimes.com/2026/05/17/obituaries/peter-g-neumann-dead.html

Why are Men Not Having Friends Anymore?
https://youtube.com/watch?v=ja9yvrR7GmQ

Study Shows Meat Eaters More Likely to Live to 100 – But There is a Catch.
https://sciencealert.com/study-shows-meat-eaters-are-more-likely-to-live-to-100-but-theres-a-catch

Other

Why V10s Represents Peak Emotional Identity of F1.
https://youtube.com/watch?v=fh7WBXGaXFQ

Firefox 153.0 Nightly Rolls Out New Settings UI.
https://phoronix.com/news/Firefox-Nightly-New-Settings

Phrack 40th Anniversary Edition.
https://phrack.org/issues/72/1

Paged Out – Issue #8.
https://pagedout.institute/?page=issues.php

Montagem Alquimia (Slowed) Phonk on Mobile.
https://youtube.com/watch?v=Mk–i0V6wcw

Unreal – 1998 Shooter That Changed Game Development Forever.
https://generationamiga.com/2026/05/23/unreal-the-1998-shooter-that-changed-game-development-forever/

You Can Run Forza Horizon 6 on Unsupported AMD RX 400/500 Series GPU on SteamOS.
https://ounapuu.ee/posts/2026/05/24/forza/

Anna Archive Hit with $19.5M Default Judgment and Global Domain Takedown Order.
https://torrentfreak.com/annas-archive-hit-with-19-5m-default-judgment-and-global-domain-takedown-order/

Planescape: Torment – Part 1 – From Tabletop – Digital Antiquarian.
https://filfre.net/2026/05/planescape-torment-part-1-from-the-tabletop/

Microsoft GitHub Just Got Unexpected Backup.
https://x.com/github/status/2056949168208552080

Usual Suspects

BSD Weekly.
https://bsdweekly.com/

DiscoverBSD.
https://discoverbsd.com/

DragonFly BSD Digest.
https://dragonflydigest.com/

FreeBSD Patch Level Table.
https://bokut.in/freebsd-patch-level-table/

FreeBSD End of Life Date.
https://endoflife.date/freebsd

Phoronix BSD News Archives.
https://phoronix.com/linux/BSD

OpenBSD Journal.
https://undeadly.org/

Call for Testing.
https://callfortesting.org/

Call for Testing – Production Users Call.
https://youtube.com/@callfortesting/videos

BSD Now Weekly Podcast.
https://www.bsdnow.tv/

Nixers Newsletter.
https://newsletter.nixers.net/entries.php

BSD Cafe Journal.
https://journal.bsd.cafe/

DragonFly BSD Digest – Lazy Reading – In Other BSDs.
https://dragonflydigest.com

FreeBSD Git Weekly.
https://freebsd-git-weekly.tarsnap.net/

FreeBSD Meetings.
https://youtube.com/@freebsdmeetings

Sheridan Computers.
https://youtube.com/@sheridans/videos

Quote(s) of the Week

“The only way to deal with an unfree world is to become so absolutely free that your very existence is an act of rebellion.”

– Albert Camus

EOF

2026-05-10 00:23:18 UTC

The PKGBASE way of things on FreeBSD is still not fully mature (and officially marked as experimental). I tried to cover all PKGBASE things in the Brave New PKGBASE World article but I need to add one another thing.

One of the things freebsd-update(8) did was upgrades between minor releases – like from 15.0 to 15.1 … but it seems that this part was not covered by PKGBASE team as Colin just notified me.

I wrote in the past about upgrading FreeBSD within ZFS Boot Environments here:

… and it will be more or less the same this time.

I was able to upgrade FreeBSD 15.0-RELEASE to FreeBSD 15.1-BETA2 with ZFS Boot Environments like that:

host # uname -prism
FreeBSD 15.0-RELEASE amd64 amd64 GENERIC

Create new ZFS BE and chroot(8) into it.

host # beadm create NEW

host # beadm mount NEW /tmp/NEW

host # chroot /tmp/NEW

BE # mount -t devfs devfs /dev

Create /usr/local/etc/pkg/repos/FreeBSD.conf file with following contents.

BE # cat /usr/local/etc/pkg/repos/FreeBSD.conf
FreeBSD-base: {
  url: "pkg+https://pkg.FreeBSD.org/${ABI}/base_release_1",
  mirror_type: "srv",
  signature_type: "fingerprints",
  fingerprints: "/usr/share/keys/pkgbase-${VERSION_MAJOR}",
  enabled: yes
}

Update pkg(8) databases.

BE # pkg update -f

Next upgrade pkg(8) tool.

BE # pkg upgrade -r FreeBSD-ports pkg

Then upgrade FreeBSD PKGBASE Base System with pkg(8) command and reboot(8).

BE # pkg upgrade -r FreeBSD-base

BE # exit

host # umount /tmp/NEW/dev

host # beadm list
BE      Active Mountpoint  Space Created
default NR     /          630.2M 2026-03-13 13:29
NEW     -      /tmp/NEW   854.2M 2026-05-09 23:15

host # reboot

At loader(8) hit 8. Boot Environments and then hit 2. Active to see something like this there:

  2. Active: zfs:zroot/ROOT/NEW (2 of 2)

This is how it looks graphically.

Then hit [ENTER] key too boot.

After boot process you will see that FreeBSD 15.0-RELEASE got upgraded to FreeBSD 15.1-BETA2 version.

host # uname -prism
FreeBSD 15.1-BETA2 amd64 amd64 GENERIC

If you are satisfied with the result You may make this ZFS Boot Environment as the default – rename it – and upgrade 3rd party pkg(8) packages.

host # beadm activate NEW
Activated successfully

host # beadm rename NEW 15.1
Renamed successfully

host # pkg upgrade -r FreeBSD-ports -r FreeBSD-ports-kmods

One more important thing – sometimes its needed to also upgrade the BIOS/UEFI boot code – details about doing it are in the UPDATE 1 for the Other FreeBSD Version in ZFS Boot Environment article.

Hope that helps.

Let me know please if You have better way of minor PKGBASE FreeBSD upgrade.

UPDATE 1 – Alternative Upgrade Way

Instead editing /usr/local/etc/pkg/repos/FreeBSD.conf file you may use alternative pkg(8) command instead. Also as pkg(8) supports --chroot option we will also use that to not mount and later unmount the devfs(5) filesystem.

host # beadm create NEW
Created successfully

host # beadm mount NEW /tmp/NEW

host # pkg --chroot=/tmp/NEW upgrade -r FreeBSD-ports pkg

host # pkg -o ABI=FreeBSD:15:$(uname -p) \
           -o OSVERSION=1501000 \
           --chroot=/tmp/NEW \
           upgrade

host # shutdown -r now

Here we also upgraded the kernel modules that are outside Base System and later third party packages from FreeBSD Ports tree.

Now same as before at the FreeBSD loader(8) hit 8. Boot Environments and then hit 2. Active to select NEW ZFS BE.

… and You still need to remember about updating BIOS/UEFI boot code as specified in the UPDATE 1 for the Other FreeBSD Version in ZFS Boot Environment article.

UPDATE 2 – Official Upgrade Method

Right now FreeBSD project officially started to add PKGBASE upgarde instructions along older freebsd-update(8) ones to its regular FreeBSD Mailing Lists posts. Below I will copy/paste what is available in the most recent FreeBSD 15.1-RC1 Now Available annoncement.

Upgrading with Base System Packages

If your system was installed with base system packages, you cannot use freebsd-update(8). Instead, use the following procedure to upgrade to 15.1-RC1.

First, update pkg(8) itself to ensure you have the latest version:

# pkg upgrade -yr FreeBSD-ports pkg

Second, upgrade the base system. Create a temporary repository configuration that points exactly to the 15.1-RC1 package repository:

# mkdir /tmp/upgrade-15.1
# echo 'FreeBSD-base: {
    url: "pkg+https://pkg.FreeBSD.org/${ABI}/base_release_1_rc1"
}' > /tmp/upgrade-15.1/upgrade.conf

Then upgrade the base system:

# pkg -o REPOS_DIR=/etc/pkg,/usr/local/etc/pkg/repos,/tmp/upgrade-15.1 \
      -o IGNORE_OSVERSION=yes upgrade -r FreeBSD-base

After the upgrade, review any messages printed by pkg(8). Some base packages may require additional configuration steps (e.g., running ‘service setup‘). Follow those instructions as needed.

Third, update any third-party kernel modules (kmods) that you may have installed from packages (e.g. drm-kmod, acpi_call). Use the same temporary repository configuration:

# pkg -o REPOS_DIR=/etc/pkg,/usr/local/etc/pkg/repos,/tmp/upgrade-15.1 \
      upgrade -r FreeBSD-ports-kmods

Fourth, update the UEFI boot loader. Back up the existing loader file (if any), then copy the new loader ‘/boot/loader.efi‘ to the appropriate location on the EFI System Partition (ESP). Common default destinations:

amd64:   cp /boot/loader.efi /boot/efi/efi/boot/BOOTX64.EFI
aarch64: cp /boot/loader.efi /boot/efi/efi/boot/BOOTAA64.EFI
armv7:   cp /boot/loader.efi /boot/efi/efi/boot/BOOTARM.EFI

If your system uses a non-standard loader path (e.g., ‘/efi/freebsd/loader.efi‘), find the correct destination with ‘efibootmgr -v‘ and look for the ‘File(...)‘ entry of the active boot option.

Fifth, check for configuration file updates that may have been installed as ‘.pkgnew‘ files:

# find /etc /usr/local/etc -name '*.pkgnew' -ls

If such files exist, manually compare them with the originals (e.g. ‘diff /etc/rc.conf /etc/rc.conf.pkgnew‘) and merge any necessary changes.

After verifying the configuration files, remove the temporary repository configuration:

# rm -r /tmp/upgrade-15.1

Finally, reboot to load the new kernel and userland:

# shutdown -r now

Later, when 15.1-RELEASE is out, a plain ‘pkg upgrade‘ will move you from the BETA to the final RELEASE automatically.

How to Determine Your Base System Type

Run the following command:

# pkg which /usr/bin/uname

If the output shows a package name starting with ‘FreeBSD-‘ (for example ‘FreeBSD-runtime-15.0‘), then your base system is managed by pkg (pkgbase). If the output says ‘/usr/bin/uname was not installed by a package‘, then your system uses the traditional layout (freebsd-update(8)
is the appropriate upgrade method).

To check whether you have any third-party kernel modules (kmods) installed from packages, run the following command:

# pkg which $(kldstat -v | awk -F '[()]' '/\.ko/ {print $2}')

Modules located in ‘/boot/kernel/‘ (such as ‘zfs.ko‘) are part of the base system packages, and belong to a ‘FreeBSD-kernel-*‘ package. Modules located in ‘/boot/modules/‘ (such as ‘sysctlinfo.k‘) are third-party kmods installed from the ports/pkg repository. If the command shows any packages with names that do not start with ‘FreeBSD-‘, those are third-party kmods. If no such packages appear, you have no third-party kmods installed.

I assume that when FreeBSD 15.1-RELEASE will be released – even more detailed instructions could be available in the Release Notes document.

EOF

2026-05-23 00:00:00 UTC

The first release candidate build for the FreeBSD 15.1 release cycle is now available. ISO images for the amd64, armv7, aarch64, powerpc64, powerpc64le, and riscv64 architectures are FreeBSD mirror sites.

2026-05-22 16:34:24 UTC

Lawmakers in both houses of Congress are demanding answers from the U.S. Cybersecurity & Infrastructure Security Agency (CISA) after KrebsOnSecurity reported this week that a CISA contractor intentionally published AWS GovCloud keys and a vast trove of other agency secrets on a public GitHub account. The inquiry comes as CISA is still struggling to contain the breach and invalidate the leaked credentials.

On May 18, KrebsOnSecurity reported that a CISA contractor with administrative access to the agency’s code development platform had created a public GitHub profile called “Private-CISA” that included plaintext credentials to dozens of internal CISA systems. Experts who reviewed the exposed secrets said the commit logs for the code repository showed the CISA contractor disabled GitHub’s built-in protection against publishing sensitive credentials in public repos.

CISA acknowledged the leak but has not responded to questions about the duration of the data exposure. However, experts who reviewed the now-defunct Private-CISA archive said it was originally created in November 2025, and that it exhibits a pattern consistent with an individual operator using the repository as a working scratchpad or synchronization mechanism rather than a curated project repository.

In a written statement, CISA said “there is no indication that any sensitive data was compromised as a result of the incident.” But in a May 19 a letter (PDF) to CISA’s Acting Director Nick Andersen, Sen. Maggie Hassan (D-NH) said the credential leak raises serious questions about how such a security lapse could occur at the very agency charged with helping to prevent cyber breaches.

“This reporting raises serious concerns regarding CISA’s internal policies and procedures at a time of significant cybersecurity threats against U.S. critical infrastructure,” Sen. Hassan wrote.

A May 19 letter from Sen. Margaret Hassan (D-NH) to the acting director of CISA demanded answers to a dozen questions about the breach.

Sen. Hassan noted that the incident occurred against the backdrop of major disruptions internally at CISA, which lost more than a third of it workforce and almost all of its senior leaders after the Trump administration forced a series of early retirements, buyouts, and resignations across the agency’s various divisions.

Rep. Bennie Thompson (D-MS), the ranking member on the House Homeland Security Committee, echoed the senator’s concerns.

“We are concerned that this incident reflects a diminished security culture and/or an inability for CISA to adequately manage its contract support,” Thompson wrote in a May 19 letter to the acting CISA chief that was co-signed by Rep. Delia Ramirez (D-Ill), the ranking member of the panel’s Subcommittee on Cybersecurity and Infrastructure Protection. “It’s no secret that our adversaries — like China, Russia, and Iran — seek to gain access to and persistence on federal networks. The files contained in the ‘Private-CISA’ repository provided the information, access, and roadmap to do just that.”

KrebsOnSecurity has learned that more a week after CISA was first notified of the data leak by the security firm GitGuardian, the agency is still working to invalidate and replace many of the exposed keys and secrets.

On May 20, KrebsOnSecurity heard from Dylan Ayrey, the creator of TruffleHog, an open-source tool for discovering private keys and other secrets buried in code hosted at GitHub and other public platforms. Ayrey said CISA still hadn’t invalidated an RSA private key exposed in the Private-CISA repo that granted access to a GitHub app which is owned by the CISA enterprise account and installed on the CISA-IT GitHub organization with full access to all code repositories.

“An attacker with this key can read source code from every repository in the CISA-IT organization, including private repos, register rogue self-hosted runners to hijack CI/CD pipelines and access repository secrets, and modify repository admin settings including branch protection rules, webhooks, and deploy keys,” Ayrey told KrebsOnSecurity. CI/CD stands for Continuous Integration and Continuous Delivery, and it refers to a set of practices used to automate the building, testing and deployment of software.

KrebsOnSecurity notified CISA about Ayrey’s findings on May 20. Ayrey said CISA appears to have invalidated the exposed RSA private key sometime after that notification. But he noted that CISA still hasn’t rotated leaked credentials tied to other critical security technologies that are deployed across the agency’s technology portfolio (KrebsOnSecurity is not naming those technologies publicly for the time being).

CISA responded with a brief written statement in response to questions about Ayrey’s findings, saying “CISA is actively responding and coordinating with the appropriate parties and vendors to ensure any identified leaked credentials are rotated and rendered invalid and will continue to take appropriate steps to protect the security of our systems.”

Ayrey said his company Truffle Security monitors GitHub and a number of other code platforms for exposed keys, and attempts to alert affected accounts to the sensitive data exposure(s). They can do this easily on GitHub because the platform publishes a live feed which includes a record of all commits and changes to public code repositories. But he said cybercriminal actors also monitor these public feeds, and are often quick to pounce on API or SSH keys that get inadvertently published in code commits.

The Private-CISA GitHub repo exposed dozens of plaintext credentials to important CISA GovCloud resources.

In practical terms, it is likely that cybercrime groups or foreign adversaries also noticed the publication of these CISA secrets, the most egregious of which appears to have happened in late April 2026, Ayrey said.

“We monitor that firehose of data for keys, and we have tools to try to figure out whose they are,” he said. “We have evidence attackers monitor that firehose as well. Anyone monitoring GitHub events could be sitting on this information.”

James Wilson, the enterprise technology editor for the Risky Business security podcast, said organizations using GitHub to manage code projects can set top-down policies that prevent employees from disabling GitHub’s protections against publishing secret keys and credentials. But Wilson’s co-host Adam Boileau said it’s not clear that any technology could stop employees from opening their own personal GitHub account and using it to store sensitive and proprietary information.

“Ultimately, this is a thing you can’t solve with a technical control,” Boileau said on this week’s podcast. “This is a human problem where you’ve hired a contractor to do this work and they have decided of their own volition to use GitHub to synchronize content from a work machine to a home machine. I don’t know what technical controls you could put in place given that this is being done presumably outside of anything CISA managed or even had visibility on.”

Update, 3:05 p.m. ET: Added statement from CISA. Corrected a date in the story (Truffle Security said it found the repo gained some of its most sensitive secrets in late April 2026, not 2025).

2026-05-21 21:50:25 UTC

Canadian authorities on Wednesday arrested a 23-year-old Ottawa man on suspicion of building and operating Kimwolf, a fast spreading Internet-of-Things botnet that enslaved millions of devices for use in a series of massive distributed denial-of-service (DDoS) attacks over the past six months. KrebsOnSecurity publicly named the suspect in February 2026 after the accused launched a volley of DDoS, doxing and swatting campaigns against this author and a security researcher. He now faces criminal hacking charges in both Canada and the United States.

A criminal complaint unsealed today in an Alaska district court charges Jacob Butler, a.k.a. “Dort,” of Ottawa, Canada with operating the Kimwolf DDoS botnet. A statement from the Department of Justice says the complaint against Butler was unsealed following the defendant’s arrest in Canada by the Ontario Provincial Police pursuant to a U.S. extradition warrant. Butler is currently in Canadian custody awaiting an initial court hearing scheduled for early next week.

The government said Kimwolf targeted infected devices which were traditionally “firewalled” from the rest of the internet, such as digital photo frames and web cameras. The infected systems were then rented to other cybercriminals, or forced to participate in record-smashing DDoS attacks, as well as assaults that affected Internet address ranges for the Department of Defense. Consequently, the DoD’s Defense Criminal Investigative Service is investigating the case, with assistance from the FBI field office in Anchorage.

“KimWolf was tied to DDoS attacks which were measured at nearly 30 Terabits per second, a record in recorded DDoS attack volume,” the Justice Department statement reads. “These attacks resulted in financial losses which, for some victims, exceeded one million dollars. The KimWolf botnet is alleged to have issued over 25,000 attack commands.”

On March 19, U.S. authorities joined international law enforcement partners in seizing the technical infrastructure for Kimwolf and three other large DDoS botnets — named Aisuru, JackSkid and Mossad — that were all competing for the same pool of vulnerable devices.

On February 28, KrebsOnSecurity identified Butler as the Kimwolf botmaster after digging through his various email addresses, registrations on the cybercrime forums, and posts to public Telegram and Discord servers. However, Dort continued to threaten and harass researchers who helped track down his real-life identity and dramatically slow the spread of his botnet.

Dort claimed responsibility for at least two swatting attacks targeting the founder of Synthient, a security startup that helped to secure a widespread critical security weakness that Kimwolf was using to spread faster and more effectively than any other IoT botnet out there. Synthient was among many technology companies thanked by the Justice Department today, and Synthient’s founder Ben Brundage told KrebsOnSecurity he’s relieved Butler is in custody.

“Hopefully this will end the harassment,” Brundage said.

An excerpt from the criminal complaint against Butler, detailing how he ordered a swatting attack against Ben Brundage, the founder of the security firm Synthient.

The government says investigators connected Butler to the administration of the KimWolf botnet through IP address, online account information, transaction records, and online messaging application records obtained through the issuance of legal process. The criminal complaint against Butler (PDF) shows he did little to separate his real-life and cybercriminal identities (something we demonstrated in our February unmasking of Dort).

In April, the Justice Department joined authorities across Europe in seizing domain names tied to nearly four-dozen DDoS-for-hire services, although because of a bureaucratic mix-up the list of seized domains has remain sealed until today. The DOJ said at least one of those services collaborated with Butler’s Kimwolf botnet.

A statement from the Ontario Provincial Police said a search warrant was executed on March 19 at Butler’s address in Ottawa, where they seized multiple devices. As a result of that investigation, Butler was arrested and charged this week with unauthorized user of computer; possession of device to obtain unauthorized use of computer system or to commit mischief; and mischief in relation to computer data. He is scheduled to remain in custody until a hearing on May 26.

In the United States, Butler is facing one count of aiding and abetting computer intrusion. If extradited, tried and convicted in a U.S. court, Butler could face up to 10 years in prison, although that maximum sentence would likely be heavily tempered by considerations in the U.S. Sentencing Guidelines, which make allowances for mitigating factors such as youth, lack of criminal history and level of cooperation with investigators.

2026-05-21 16:59:08 UTC

I am a big fan of mutual TLS ("mTLS" if you prefer the shorter spelling, "client certificates" if you are describing the half a user actually touches). Strangely, I rarely see it used in the wild. That probably says something worrying about how I choose to spend free time, but they are a neat fit for small private infrastructure. Most people reach for HTTP Basic, an API token, or a VPN, and call it a day. A private pkg repository is one of those quiet little places where mutual TLS fits perfectly: a well established mechanisms, no humans typing passwords, and a server that should only answer questions from boxes I actually have access to.

2026-05-20 18:33:48 UTC

This post is mostly notes for myself. There’s no real useful information here, apart from how to increase the disk space of your vm-bhyve instance.

I’m just back from a short time away. I noticed my Home Assistant instance was running, but not responding.

In this post:

FreeBSD 15.0
vm-bhyve-1.7.3

I stopped and started it:

[17:41 r730-01 dvl ~] % sudo vm list
NAME  DATASTORE  LOADER  CPU  MEMORY  VNC  AUTO     STATE
hass  default    uefi    4    8GB     -    Yes [1]  Running (18349)

[17:41 r730-01 dvl ~] % sudo vm hass stop
Starting hass
  * found guest in /usr/local/vm/hass
  * booting...
[17:43 r730-01 dvl ~] % sudo vm stop hass 
Sending ACPI shutdown to hass

[17:42 r730-01 dvl ~] % sudo vm list
NAME  DATASTORE  LOADER  CPU  MEMORY  VNC  AUTO     STATE
hass  default    uefi    4    8GB     -    Yes [1]  Running (18349)
[17:42 r730-01 dvl ~] % sudo vm list
NAME  DATASTORE  LOADER  CPU  MEMORY  VNC  AUTO     STATE
hass  default    uefi    4    8GB     -    Yes [1]  Running (18349)
[17:42 r730-01 dvl ~] % sudo vm list
NAME  DATASTORE  LOADER  CPU  MEMORY  VNC  AUTO     STATE
hass  default    uefi    4    8GB     -    Yes [1]  Stopped


[17:43 r730-01 dvl ~] % sudo vm start hass
Starting hass
  * found guest in /usr/local/vm/hass
  * booting...

Nope. Still not running.

I tried the console.

[17:44 r730-01 dvl ~] % sudo vm console hass                      
Connected

home-assistant login: root
Welcome to Home Assistant OS.

Use `ha` to access the Home Assistant CLI.
# hs
-sh: hs: not found
# ha

Nothing I tried in there gave any information.

But here’s the log anyway:

# ha supervisor logs
2026-05-20 17:55:26.039 INFO (MainThread) [supervisor.api] Starting API on 172.30.32.2
2026-05-20 17:55:26.069 INFO (MainThread) [supervisor.hardware.monitor] Started Supervisor hardware monitor
2026-05-20 17:55:26.071 INFO (MainThread) [supervisor.dbus.manager] Connected to system D-Bus.
2026-05-20 17:55:26.071 INFO (MainThread) [supervisor.dbus.agent] Load dbus interface io.hass.os
2026-05-20 17:55:26.071 INFO (MainThread) [supervisor.dbus.hostname] Load dbus interface org.freedesktop.hostname1
2026-05-20 17:55:26.072 INFO (MainThread) [supervisor.dbus.logind] Load dbus interface org.freedesktop.login1
2026-05-20 17:55:26.072 INFO (MainThread) [supervisor.dbus.network] Load dbus interface org.freedesktop.NetworkManager
2026-05-20 17:55:26.072 INFO (MainThread) [supervisor.dbus.rauc] Load dbus interface de.pengutronix.rauc
2026-05-20 17:55:26.072 INFO (MainThread) [supervisor.dbus.resolved] Load dbus interface org.freedesktop.resolve1
2026-05-20 17:55:26.072 INFO (MainThread) [supervisor.dbus.systemd] Load dbus interface org.freedesktop.systemd1
2026-05-20 17:55:26.073 INFO (MainThread) [supervisor.dbus.timedate] Load dbus interface org.freedesktop.timedate1
2026-05-20 17:55:26.250 INFO (MainThread) [supervisor.host.services] Updating service information
2026-05-20 17:55:26.255 INFO (MainThread) [supervisor.host.sound] Updating PulseAudio information
2026-05-20 17:55:26.514 INFO (MainThread) [supervisor.host.network] Updating local network information
2026-05-20 17:55:26.651 INFO (MainThread) [supervisor.host.firewall] Gateway firewall rules applied
2026-05-20 17:55:26.652 INFO (MainThread) [supervisor.host.apparmor] Loading AppArmor Profiles: {'hassio-supervisor'}
2026-05-20 17:55:26.678 INFO (MainThread) [supervisor.os.manager] Detect Home Assistant Operating System 17.2 / BootSlot B
2026-05-20 17:55:26.678 INFO (MainThread) [supervisor.docker.monitor] Started docker events monitor
2026-05-20 17:55:26.684 INFO (MainThread) [supervisor.docker.interface] Attaching to ghcr.io/home-assistant/amd64-hassio-cli with version 2026.05.0
2026-05-20 17:55:26.717 INFO (MainThread) [supervisor.docker.interface] Attaching to ghcr.io/home-assistant/amd64-hassio-dns with version 2026.02.0
2026-05-20 17:55:26.742 INFO (MainThread) [supervisor.plugins.dns] Updated /etc/resolv.conf
2026-05-20 17:55:26.749 INFO (MainThread) [supervisor.docker.interface] Attaching to ghcr.io/home-assistant/amd64-hassio-audio with version 2026.02.0
2026-05-20 17:55:26.775 INFO (MainThread) [supervisor.docker.interface] Attaching to ghcr.io/home-assistant/amd64-hassio-observer with version 2026.02.0
2026-05-20 17:55:26.799 INFO (MainThread) [supervisor.docker.interface] Attaching to ghcr.io/home-assistant/amd64-hassio-multicast with version 2026.02.0
2026-05-20 17:55:26.827 INFO (MainThread) [supervisor.homeassistant.secrets] Loaded 1 Home Assistant secrets
2026-05-20 17:55:26.829 INFO (MainThread) [supervisor.docker.interface] Attaching to ghcr.io/home-assistant/qemux86-64-homeassistant with version 2026.4.4
2026-05-20 17:55:26.857 INFO (MainThread) [supervisor.store.git] Loading app /data/addons/git/5c53de3b repository
2026-05-20 17:55:26.857 INFO (MainThread) [supervisor.store.git] Loading app /data/addons/git/a0d7b954 repository
2026-05-20 17:55:26.857 INFO (MainThread) [supervisor.store.git] Loading app /data/addons/core repository
2026-05-20 17:55:26.857 INFO (MainThread) [supervisor.store.git] Loading app /data/addons/git/d5369777 repository
2026-05-20 17:55:27.578 WARNING (SyncWorker_0) [supervisor.addons.validate] App config 'arch' uses deprecated values ['armv7']. Please report this to the maintainer of InfluxDB
2026-05-20 17:55:27.578 WARNING (SyncWorker_0) [supervisor.addons.validate] App 'InfluxDB' uses deprecated 'codenotary' field in config. This field is no longer used and will be ignored. Please report this to the maintainer.
2026-05-20 17:55:27.593 WARNING (SyncWorker_0) [supervisor.addons.validate] App config 'arch' uses deprecated values ['armv7']. Please report this to the maintainer of Overseerr
2026-05-20 17:55:27.593 WARNING (SyncWorker_0) [supervisor.addons.validate] App 'Overseerr' uses deprecated 'codenotary' field in config. This field is no longer used and will be ignored. Please report this to the maintainer.
2026-05-20 17:55:27.594 WARNING (SyncWorker_0) [supervisor.addons.validate] App 'Traccar' uses deprecated 'codenotary' field in config. This field is no longer used and will be ignored. Please report this to the maintainer.
2026-05-20 17:55:27.600 WARNING (SyncWorker_0) [supervisor.addons.validate] App config 'arch' uses deprecated values ['armv7']. Please report this to the maintainer of Log Viewer
2026-05-20 17:55:27.600 WARNING (SyncWorker_0) [supervisor.addons.validate] App 'Log Viewer' uses deprecated 'codenotary' field in config. This field is no longer used and will be ignored. Please report this to the maintainer.
2026-05-20 17:55:27.608 WARNING (SyncWorker_0) [supervisor.addons.validate] App 'SQLite Web' uses deprecated 'advanced' field in config. This field is ignored by the Supervisor. Please report this to the maintainer.
2026-05-20 17:55:27.615 WARNING (SyncWorker_0) [supervisor.addons.validate] App config 'arch' uses deprecated values ['armv7']. Please report this to the maintainer of Nginx Proxy Manager
2026-05-20 17:55:27.615 WARNING (SyncWorker_0) [supervisor.addons.validate] App 'Nginx Proxy Manager' uses deprecated 'codenotary' field in config. This field is no longer used and will be ignored. Please report this to the maintainer.
2026-05-20 17:55:27.623 WARNING (SyncWorker_0) [supervisor.addons.validate] App 'Folding@home' uses deprecated 'codenotary' field in config. This field is no longer used and will be ignored. Please report this to the maintainer.
2026-05-20 17:55:27.625 WARNING (SyncWorker_0) [supervisor.addons.validate] App config 'arch' uses deprecated values ['armv7']. Please report this to the maintainer of MQTT IO
2026-05-20 17:55:27.626 WARNING (SyncWorker_0) [supervisor.addons.validate] App 'MQTT IO' uses deprecated 'codenotary' field in config. This field is no longer used and will be ignored. Please report this to the maintainer.
2026-05-20 17:55:27.686 INFO (MainThread) [supervisor.store] Loading apps from store: 79 all - 79 new - 0 remove
2026-05-20 17:55:27.716 INFO (MainThread) [supervisor.addons.manager] Found 8 installed apps
2026-05-20 17:55:27.749 INFO (MainThread) [supervisor.docker.interface] Attaching to ghcr.io/hassio-addons/influxdb/amd64 with version 5.0.2
2026-05-20 17:55:27.754 INFO (MainThread) [supervisor.docker.interface] Attaching to ghcr.io/hassio-addons/vscode/amd64 with version 6.0.1
2026-05-20 17:55:27.756 INFO (MainThread) [supervisor.docker.interface] Attaching to ghcr.io/hassio-addons/nut with version 0.18.0
2026-05-20 17:55:27.762 INFO (MainThread) [supervisor.docker.interface] Attaching to homeassistant/amd64-addon-ssh with version 10.2.0
2026-05-20 17:55:27.763 INFO (MainThread) [supervisor.docker.interface] Attaching to homeassistant/amd64-addon-letsencrypt with version 6.3.2
2026-05-20 17:55:27.764 INFO (MainThread) [supervisor.docker.interface] Attaching to ghcr.io/hassio-addons/unifi with version 5.1.1
2026-05-20 17:55:27.764 INFO (MainThread) [supervisor.docker.interface] Attaching to ghcr.io/hassio-addons/airsonos with version 5.1.1
2026-05-20 17:55:27.765 INFO (MainThread) [supervisor.docker.interface] Attaching to ghcr.io/hassio-addons/grafana/amd64 with version 12.1.0
2026-05-20 17:55:27.900 INFO (MainThread) [supervisor.backups.manager] Found 35 backup files
2026-05-20 17:55:27.949 INFO (MainThread) [supervisor.discovery] Loaded 0 messages
2026-05-20 17:55:27.949 INFO (MainThread) [supervisor.ingress] Loaded 0 ingress sessions
2026-05-20 17:55:27.949 INFO (MainThread) [supervisor.resolution.check] Starting system checks with state setup
2026-05-20 17:55:27.950 INFO (MainThread) [supervisor.resolution.checks.base] Run check for detached_addon_removed/addon
2026-05-20 17:55:27.950 INFO (MainThread) [supervisor.resolution.checks.base] Run check for deprecated_addon/addon
2026-05-20 17:55:27.950 INFO (MainThread) [supervisor.resolution.checks.base] Run check for disabled_data_disk/system
2026-05-20 17:55:27.950 INFO (MainThread) [supervisor.resolution.checks.base] Run check for multiple_data_disks/system
2026-05-20 17:55:27.950 INFO (MainThread) [supervisor.resolution.checks.base] Run check for deprecated_arch_addon/addon
2026-05-20 17:55:27.950 INFO (MainThread) [supervisor.resolution.checks.base] Run check for duplicate_os_installation/system
2026-05-20 17:55:27.977 INFO (MainThread) [supervisor.resolution.checks.base] Run check for detached_addon_missing/addon
2026-05-20 17:55:27.977 INFO (MainThread) [supervisor.resolution.check] System checks complete
2026-05-20 17:55:27.977 INFO (MainThread) [supervisor.resolution.evaluate] Starting system evaluation with state setup
2026-05-20 17:55:27.978 INFO (MainThread) [supervisor.resolution.evaluate] System evaluation complete
2026-05-20 17:55:27.978 INFO (MainThread) [supervisor.jobs] 'ResolutionFixup.run_autofix' blocked from execution, system is not running - setup
2026-05-20 17:55:28.012 INFO (MainThread) [supervisor.os.manager] Rauc: slot B - activated slot kernel.1, marked slot kernel.1 as good
2026-05-20 17:55:28.025 INFO (MainThread) [supervisor.updater] Fetching update data from https://version.home-assistant.io/stable.json
2026-05-20 17:55:28.098 INFO (MainThread) [supervisor.addons.manager] Phase 'initialize' starting 0 apps
2026-05-20 17:55:28.098 INFO (MainThread) [supervisor.core] Detected Supervisor restart
2026-05-20 17:55:28.098 INFO (MainThread) [supervisor.misc.tasks] All core tasks are scheduled
2026-05-20 17:55:28.100 INFO (MainThread) [supervisor.host.info] Updating local host information
2026-05-20 17:55:28.101 INFO (MainThread) [supervisor.resolution.check] Starting system checks with state running
2026-05-20 17:55:28.101 INFO (MainThread) [supervisor.resolution.checks.base] Run check for ipv4_connection_problem/system
2026-05-20 17:55:28.101 INFO (MainThread) [supervisor.resolution.checks.base] Run check for dns_server_ipv6_error/dns_server
2026-05-20 17:55:28.107 INFO (MainThread) [supervisor.core] Supervisor is up and running
2026-05-20 17:55:28.112 INFO (MainThread) [__main__] Running Supervisor
2026-05-20 17:55:28.113 INFO (MainThread) [supervisor.resolution.checks.base] Run check for disabled_data_disk/system
2026-05-20 17:55:28.113 INFO (MainThread) [supervisor.resolution.checks.base] Run check for docker_config/system
2026-05-20 17:55:28.113 INFO (MainThread) [supervisor.resolution.checks.base] Run check for multiple_data_disks/system
2026-05-20 17:55:28.113 INFO (MainThread) [supervisor.resolution.checks.base] Run check for deprecated_arch_addon/addon
2026-05-20 17:55:28.114 INFO (MainThread) [supervisor.resolution.checks.base] Run check for free_space/system
2026-05-20 17:55:28.120 INFO (MainThread) [supervisor.resolution.checks.base] Run check for dns_server_failed/dns_server
2026-05-20 17:55:28.126 INFO (MainThread) [supervisor.homeassistant.api] Updated Home Assistant API token
2026-05-20 17:55:28.130 INFO (MainThread) [supervisor.homeassistant.api] Connected to Core via TCP http://172.30.32.1:8123
2026-05-20 17:55:28.138 INFO (MainThread) [supervisor.resolution.checks.base] Run check for disk_lifetime/system
2026-05-20 17:55:28.145 INFO (MainThread) [supervisor.resolution.checks.base] Run check for no_current_backup/system
2026-05-20 17:55:28.145 INFO (MainThread) [supervisor.resolution.module] Create new suggestion create_full_backup - system / None
2026-05-20 17:55:28.146 INFO (MainThread) [supervisor.resolution.module] Create new issue no_current_backup - system / None
2026-05-20 17:55:28.146 INFO (MainThread) [supervisor.resolution.checks.base] Run check for pwned/addon
2026-05-20 17:55:28.148 INFO (MainThread) [supervisor.resolution.check] System checks complete
2026-05-20 17:55:28.148 INFO (MainThread) [supervisor.resolution.evaluate] Starting system evaluation with state running
2026-05-20 17:55:28.149 INFO (MainThread) [supervisor.host.services] Updating service information
2026-05-20 17:55:28.158 INFO (MainThread) [supervisor.host.network] Updating local network information
2026-05-20 17:55:28.171 INFO (MainThread) [supervisor.resolution.evaluate] System evaluation complete
2026-05-20 17:55:28.172 INFO (MainThread) [supervisor.resolution.fixup] Starting system autofix at state running
2026-05-20 17:55:28.172 INFO (MainThread) [supervisor.resolution.fixup] System autofix complete
2026-05-20 17:55:28.249 INFO (MainThread) [supervisor.host.manager] Host information reload completed
#

I left that and looked at disk. See there, that line.. Size == Used. I think it’s a full disk.

# 

Welcome to Home Assistant
home-assistant login: root
Welcome to Home Assistant OS.

Use `ha` to access the Home Assistant CLI.

# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root               229.8M    229.8M         0 100% /
devtmpfs                  3.9G         0      3.9G   0% /dev
tmpfs                     3.9G         0      3.9G   0% /dev/shm
tmpfs                     1.6G      1.2M      1.5G   0% /run
tmpfs                     1.6G      1.2M      1.5G   0% /etc/machine-id
tmpfs                     1.0M         0      1.0M   0% /run/credentials/systemd-journald.service
tmpfs                     1.0M         0      1.0M   0% /run/credentials/systemd-network-generator.service
tmpfs                     1.0M         0      1.0M   0% /run/credentials/systemd-udev-load-credentials.service
tmpfs                     1.0M         0      1.0M   0% /run/credentials/systemd-tmpfiles-setup-dev-early.service
tmpfs                     1.0M         0      1.0M   0% /run/credentials/systemd-tmpfiles-setup-dev.service
/dev/vda1                31.9M    742.0K     31.2M   2% /mnt/boot
/dev/vda7                84.5M     53.0K     77.7M   0% /mnt/overlay
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/default
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/dropbear
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/modprobe.d
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/modules-load.d
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/sysctl.d
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/udev/rules.d
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/usb_modeswitch.d
/dev/vda7                84.5M     53.0K     77.7M   0% /root/.docker
/dev/vda7                84.5M     53.0K     77.7M   0% /root/.ssh
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/NetworkManager/system-connections
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/hostname
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/hosts
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/systemd/timesyncd.conf
tmpfs                     1.0M         0      1.0M   0% /run/credentials/systemd-sysctl.service
tmpfs                     1.0M         0      1.0M   0% /run/credentials/systemd-vconsole-setup.service
/dev/vda8                30.8G     26.0G      3.5G  88% /mnt/data
tmpfs                     3.9G    288.0K      3.9G   0% /var
/dev/zram2               15.0M     72.0K     13.8M   1% /tmp
/dev/vda7                84.5M     53.0K     77.7M   0% /var/lib/bluetooth
/dev/vda8                30.8G     26.0G      3.5G  88% /var/lib/docker
/dev/vda7                84.5M     53.0K     77.7M   0% /var/lib/NetworkManager
/dev/vda7                84.5M     53.0K     77.7M   0% /var/lib/systemd
/dev/vda8                30.8G     26.0G      3.5G  88% /var/log/journal
tmpfs                     1.0M         0      1.0M   0% /run/credentials/systemd-tmpfiles-setup.service
tmpfs                     1.0M         0      1.0M   0% /run/credentials/systemd-resolved.service
overlay                  30.8G     26.0G      3.5G  88% /mnt/data/docker/overlay2/619b93d49b90fa1a1ca1c2b0ed29bbb233501745f1365249369ec570a294771b/merged
overlay                  30.8G     26.0G      3.5G  88% /var/lib/docker/overlay2/619b93d49b90fa1a1ca1c2b0ed29bbb233501745f1365249369ec570a294771b/merged
overlay                  30.8G     26.0G      3.5G  88% /mnt/data/docker/overlay2/ec93c5e02543272efa6151716c404c4de2ab9f4760e4d51d651ce05164098f21/merged
overlay                  30.8G     26.0G      3.5G  88% /var/lib/docker/overlay2/ec93c5e02543272efa6151716c404c4de2ab9f4760e4d51d651ce05164098f21/merged
overlay                  30.8G     26.0G      3.5G  88% /mnt/data/docker/overlay2/ae9f698dc6358b61fa5c38d988dd9f0d3cad0a5a65ce0027b6c6480995e5d76b/merged
overlay                  30.8G     26.0G      3.5G  88% /var/lib/docker/overlay2/ae9f698dc6358b61fa5c38d988dd9f0d3cad0a5a65ce0027b6c6480995e5d76b/merged
overlay                  30.8G     26.0G      3.5G  88% /mnt/data/docker/overlay2/828c6e5ebb8c176a6a6abb7c657824da7c0fd8811e8ee000c9b7f5f132fdba57/merged
overlay                  30.8G     26.0G      3.5G  88% /var/lib/docker/overlay2/828c6e5ebb8c176a6a6abb7c657824da7c0fd8811e8ee000c9b7f5f132fdba57/merged
overlay                  30.8G     26.0G      3.5G  88% /mnt/data/docker/overlay2/9209b668c2a1b9e6c8f4b687cc4007911165ef9595e229a765748628243cded1/merged
overlay                  30.8G     26.0G      3.5G  88% /var/lib/docker/overlay2/9209b668c2a1b9e6c8f4b687cc4007911165ef9595e229a765748628243cded1/merged
overlay                  30.8G     26.0G      3.5G  88% /mnt/data/docker/overlay2/c71742e59797347d95353016f74fcfeb6fb77c63ee9fae2194303a1a02df571d/merged
overlay                  30.8G     26.0G      3.5G  88% /var/lib/docker/overlay2/c71742e59797347d95353016f74fcfeb6fb77c63ee9fae2194303a1a02df571d/merged
overlay                  30.8G     26.0G      3.5G  88% /mnt/data/docker/overlay2/41ac092f15d8ba40eacee2f649ec6902c53e959d977975a84ad6c5f58ff37676/merged
overlay                  30.8G     26.0G      3.5G  88% /var/lib/docker/overlay2/41ac092f15d8ba40eacee2f649ec6902c53e959d977975a84ad6c5f58ff37676/merged
overlay                  30.8G     26.0G      3.5G  88% /mnt/data/docker/overlay2/4c1ca9d2f78db22b66e3aacae995575af4b5a5f4ab0c789ea6843fb79518b19f/merged
overlay                  30.8G     26.0G      3.5G  88% /var/lib/docker/overlay2/4c1ca9d2f78db22b66e3aacae995575af4b5a5f4ab0c789ea6843fb79518b19f/merged
overlay                  30.8G     26.0G      3.5G  88% /mnt/data/docker/overlay2/594d97141741baf82d813346ddd1f2cd044838dfa4bac3e4700b161bfbafeac1/merged
overlay                  30.8G     26.0G      3.5G  88% /var/lib/docker/overlay2/594d97141741baf82d813346ddd1f2cd044838dfa4bac3e4700b161bfbafeac1/merged
overlay                  30.8G     26.0G      3.5G  88% /mnt/data/docker/overlay2/9063ed862b7a78f62311d1ef1a6af17acfe18f60820b25768ff1a0c45ee8c127/merged
overlay                  30.8G     26.0G      3.5G  88% /var/lib/docker/overlay2/9063ed862b7a78f62311d1ef1a6af17acfe18f60820b25768ff1a0c45ee8c127/merged
overlay                  30.8G     26.0G      3.5G  88% /mnt/data/docker/overlay2/6e2c9286772ed20dfc3f27a2e5e2188c0435d73c375811f5cf27affbed72889d/merged
overlay                  30.8G     26.0G      3.5G  88% /var/lib/docker/overlay2/6e2c9286772ed20dfc3f27a2e5e2188c0435d73c375811f5cf27affbed72889d/merged
overlay                  30.8G     26.0G      3.5G  88% /mnt/data/docker/overlay2/fb144aca5fb7770c8efe0ae9923adc492a0683d2f7f4e341a62f4ddd5a0962ef/merged
overlay                  30.8G     26.0G      3.5G  88% /var/lib/docker/overlay2/fb144aca5fb7770c8efe0ae9923adc492a0683d2f7f4e341a62f4ddd5a0962ef/merged
overlay                  30.8G     26.0G      3.5G  88% /mnt/data/docker/overlay2/ce6d1521b5b13941fa1c11c35f0759ace577f65d04efd555a1eed34f9ecd0499/merged
overlay                  30.8G     26.0G      3.5G  88% /var/lib/docker/overlay2/ce6d1521b5b13941fa1c11c35f0759ace577f65d04efd555a1eed34f9ecd0499/merged
tmpfs                     1.0M         0      1.0M   0% /run/credentials/serial-getty@ttyS0.service

I stopped the VM:

[17:43 r730-01 dvl ~] % sudo vm stop hass 
Sending ACPI shutdown to hass

[18:03 r730-01 dvl ~] % sudo vm list
NAME  DATASTORE  LOADER  CPU  MEMORY  VNC  AUTO     STATE
hass  default    uefi    4    8GB     -    Yes [1]  Stopped

I did some searching and found I needed truncate.

The disk was named in /usr/local/vm/hass/hass.conf:

[18:16 r730-01 dvl /usr/local/vm/hass] % grep name hass.conf
disk0_name="disk0.img"

Next, I did this:

[18:03 r730-01 dvl /usr/local/vm/hass] % ls -lh disk0.img 
-rw-------  1 root wheel   32G 2026.05.20 18:02 disk0.img

[18:04 r730-01 dvl /usr/local/vm/hass] % sudo truncate -s 64G disk0.img 

[18:05 r730-01 dvl /usr/local/vm/hass] % ls -lh disk0.img              
-rw-------  1 root wheel   64G 2026.05.20 18:05 disk0.img

[18:05 r730-01 dvl /usr/local/vm/hass] % sudo vm start hass
Starting hass
  * found guest in /usr/local/vm/hass
  * booting...

Getting back into the console and into ha, no, that wasn’t the problem:

Use `ha` to access the Home Assistant CLI.
# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root               229.8M    229.8M         0 100% /
devtmpfs                  3.9G         0      3.9G   0% /dev
tmpfs                     3.9G         0      3.9G   0% /dev/shm
tmpfs                     1.6G      1.2M      1.5G   0% /run
tmpfs                     1.6G      1.2M      1.5G   0% /etc/machine-id
tmpfs                     1.0M         0      1.0M   0% /run/credentials/systemd-udev-load-credentials.service
tmpfs                     1.0M         0      1.0M   0% /run/credentials/systemd-network-generator.service
tmpfs                     1.0M         0      1.0M   0% /run/credentials/systemd-journald.service
tmpfs                     1.0M         0      1.0M   0% /run/credentials/systemd-tmpfiles-setup-dev-early.service
tmpfs                     1.0M         0      1.0M   0% /run/credentials/systemd-tmpfiles-setup-dev.service
/dev/vda1                31.9M    742.0K     31.2M   2% /mnt/boot
/dev/vda7                84.5M     53.0K     77.7M   0% /mnt/overlay
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/NetworkManager/system-connections
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/dropbear
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/default
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/hostname
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/hosts
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/modprobe.d
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/modules-load.d
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/systemd/timesyncd.conf
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/sysctl.d
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/udev/rules.d
/dev/vda7                84.5M     53.0K     77.7M   0% /etc/usb_modeswitch.d
/dev/vda8                62.3G     26.0G     33.7G  44% /mnt/data
/dev/vda7                84.5M     53.0K     77.7M   0% /root/.docker
/dev/vda7                84.5M     53.0K     77.7M   0% /root/.ssh
tmpfs                     1.0M         0      1.0M   0% /run/credentials/systemd-sysctl.service
/dev/zram2               15.0M     80.0K     13.8M   1% /tmp
tmpfs                     3.9G    276.0K      3.9G   0% /var
tmpfs                     1.0M         0      1.0M   0% /run/credentials/systemd-vconsole-setup.service
/dev/vda7                84.5M     53.0K     77.7M   0% /var/lib/NetworkManager
/dev/vda7                84.5M     53.0K     77.7M   0% /var/lib/systemd
/dev/vda8                62.3G     26.0G     33.7G  44% /var/lib/docker
/dev/vda7                84.5M     53.0K     77.7M   0% /var/lib/bluetooth
/dev/vda8                62.3G     26.0G     33.7G  44% /var/log/journal
tmpfs                     1.0M         0      1.0M   0% /run/credentials/systemd-tmpfiles-setup.service
tmpfs                     1.0M         0      1.0M   0% /run/credentials/systemd-resolved.service
overlay                  62.3G     26.0G     33.7G  44% /mnt/data/docker/overlay2/619b93d49b90fa1a1ca1c2b0ed29bbb233501745f1365249369ec570a294771b/merged
overlay                  62.3G     26.0G     33.7G  44% /var/lib/docker/overlay2/619b93d49b90fa1a1ca1c2b0ed29bbb233501745f1365249369ec570a294771b/merged
overlay                  62.3G     26.0G     33.7G  44% /mnt/data/docker/overlay2/ec93c5e02543272efa6151716c404c4de2ab9f4760e4d51d651ce05164098f21/merged
overlay                  62.3G     26.0G     33.7G  44% /var/lib/docker/overlay2/ec93c5e02543272efa6151716c404c4de2ab9f4760e4d51d651ce05164098f21/merged
overlay                  62.3G     26.0G     33.7G  44% /mnt/data/docker/overlay2/bc481db24ccec9c792c3e0966b134e5df48da87ee0cfb97b99b72251a371000a/merged
overlay                  62.3G     26.0G     33.7G  44% /var/lib/docker/overlay2/bc481db24ccec9c792c3e0966b134e5df48da87ee0cfb97b99b72251a371000a/merged
overlay                  62.3G     26.0G     33.7G  44% /mnt/data/docker/overlay2/825ccba10d65a2a4aa9d318818c0d6e9274302397ed69d3e0c8df035192706bd/merged
overlay                  62.3G     26.0G     33.7G  44% /var/lib/docker/overlay2/825ccba10d65a2a4aa9d318818c0d6e9274302397ed69d3e0c8df035192706bd/merged
overlay                  62.3G     26.0G     33.7G  44% /mnt/data/docker/overlay2/7ef4f7a524e6730a512dff7ff444f9e8782473916974e8783db2da330fb41db5/merged
overlay                  62.3G     26.0G     33.7G  44% /var/lib/docker/overlay2/7ef4f7a524e6730a512dff7ff444f9e8782473916974e8783db2da330fb41db5/merged
overlay                  62.3G     26.0G     33.7G  44% /mnt/data/docker/overlay2/1b91b4ea1fe92090ef72c0e304ea6f738caf864ddfd23b70c8e04eb27fe62c58/merged
overlay                  62.3G     26.0G     33.7G  44% /var/lib/docker/overlay2/1b91b4ea1fe92090ef72c0e304ea6f738caf864ddfd23b70c8e04eb27fe62c58/merged
overlay                  62.3G     26.0G     33.7G  44% /mnt/data/docker/overlay2/f9a3a0956a44933652dd4d274c05c1444088b1c58d9f621c32ed9c9f6c3a8e4b/merged
overlay                  62.3G     26.0G     33.7G  44% /var/lib/docker/overlay2/f9a3a0956a44933652dd4d274c05c1444088b1c58d9f621c32ed9c9f6c3a8e4b/merged
overlay                  62.3G     26.0G     33.7G  44% /mnt/data/docker/overlay2/887d24bdf071a5c4ce9b07e6ed7da27d835622e5afcf4e8fbe1ccdc477b77b58/merged
overlay                  62.3G     26.0G     33.7G  44% /var/lib/docker/overlay2/887d24bdf071a5c4ce9b07e6ed7da27d835622e5afcf4e8fbe1ccdc477b77b58/merged
overlay                  62.3G     26.0G     33.7G  44% /mnt/data/docker/overlay2/bd8760efdf4414b51305514324aadae0672becd918d04c3a022b915805b16a9d/merged
overlay                  62.3G     26.0G     33.7G  44% /var/lib/docker/overlay2/bd8760efdf4414b51305514324aadae0672becd918d04c3a022b915805b16a9d/merged
overlay                  62.3G     26.0G     33.7G  44% /mnt/data/docker/overlay2/cc03ec06242ca490d2d2f8aaa0ae2dec4612c7f0689a05a00112c27a936c123b/merged
overlay                  62.3G     26.0G     33.7G  44% /var/lib/docker/overlay2/cc03ec06242ca490d2d2f8aaa0ae2dec4612c7f0689a05a00112c27a936c123b/merged
overlay                  62.3G     26.0G     33.7G  44% /mnt/data/docker/overlay2/8a67e52bc10879c9b6189e97e56c99a3f340e09b49550f5879f44da4e91d6ad6/merged
overlay                  62.3G     26.0G     33.7G  44% /var/lib/docker/overlay2/8a67e52bc10879c9b6189e97e56c99a3f340e09b49550f5879f44da4e91d6ad6/merged
overlay                  62.3G     26.0G     33.7G  44% /mnt/data/docker/overlay2/d59c62b2b24b6c27711734a2b4dcd67c82340c9ca4465d7570a2aefa1e786516/merged
overlay                  62.3G     26.0G     33.7G  44% /var/lib/docker/overlay2/d59c62b2b24b6c27711734a2b4dcd67c82340c9ca4465d7570a2aefa1e786516/merged
overlay                  62.3G     26.0G     33.7G  44% /mnt/data/docker/overlay2/ce6d1521b5b13941fa1c11c35f0759ace577f65d04efd555a1eed34f9ecd0499/merged
overlay                  62.3G     26.0G     33.7G  44% /var/lib/docker/overlay2/ce6d1521b5b13941fa1c11c35f0759ace577f65d04efd555a1eed34f9ecd0499/merged
tmpfs                     1.0M         0      1.0M   0% /run/credentials/serial-getty@ttyS0.service
#

I checked my console connection and saw this within the boot process:

[    0.478363] virtio_blk virtio0: 1/0/0 default/read/poll queues
[    0.480195] virtio_blk virtio0: [vda] 134217728 512-byte logical blocks (68.7 GB/64.0 GiB)
[    0.482886] GPT:Primary header thinks Alt. header is not at the end of the disk.
[    0.484139] GPT:67108863 != 134217727
[    0.484750] GPT:Alternate GPT header not at the end of the disk.
[    0.485755] GPT:67108863 != 134217727
[    0.486366] GPT: Use GNU Parted to correct GPT errors.
...
[    1.940865] EXT4-fs (vda7): mounted filesystem 6233dab6-4ddf-44cb-9ccc-e8256722f9a3 r/w with ordered data mode. Quota mode: none.
[    2.546386] EXT4-fs (vda8): mounted filesystem 7dfbe2ce-edc1-4d42-921c-7cebd6ee6be1 r/w with ordered data mode. Quota mode: none.
[    2.582051] EXT4-fs (vda8): resizing filesystem from 8210171 to 16598779 blocks

and it’s still not responding…

2026-05-22 16:11:00 UTC

When I last wrote about AIs (well, technically, LLMs), I have noted that I’ll never use LLMs to write articles for this blog. I am not breaking said promise! Much as I’ve been tempted to let an LLM write a “Privacy Policy” page (since it would all be boilerplate anyway, I’m not tracking anything, and the only third party cookie is from WordPress/Automattic themselves), I don’t plan on ever letting an LLM try to pass for me. Heck, I refuse to even use tools like Grammarly, because I don’t trust their privacy policies, to the dismay of a few readers.

Where I have actually used an LLM is to get myself a tool to write this blog more easily. I have let agents, and multiple models, under my active supervision, build an Android app: a WordPress client, optimized to be used with eInk displays such as the Max Lumi which I already used up until recently to write later at night.

You may or may not know that – when I bought the Max Lumi and started using it – I have struggled badly with the various ways I had to write on it. The native Android app (“Jetpack”) is terrible on eInk, with most of its UI being shades of gray or colour. What worked the best, for a while at least, was using Edge for Android to access the Web UI. Not my favourite option to be honest, but it was workable, as long as I didn’t care about writing offline.

I had, at first, thought of writing a “Free Ideas” blog post, but even when I tried offering to pay someone to implement something I needed, I got no responses. So instead, given I’ve been playing with LLMs already to keep my skills relevant to the industry I find myself in, I decided it was a good time to try “vibing” something I had no experience with before at all: an Android app.

In my previous experiments with Claude, in particular, I had been using it either for obvious boilerplate (Ansible) or a service for which I had at least a decent understanding of (my pdfrenamer and Paperless integration.) This is the first time I decided to throw an LLM to a problem I had no idea how to solve myself, instead of solving something that I could have fixed myself, but would require me more time than I had available.

The end result is something quite workable, as you can see from this post, which I’m insisting on keeping edited only exclusively from the app itself, to make sure the whole flow works out correctly. Workable doesn’t mean maintainable, and definitely not perfect. I used Forgejo to “pair” with the LLM in terms of testing and requesting changes, and it took well over a week before I had something I could actually type onto, with over 50 issues reported, and a handful of them re-opened until they could actually be cleared. And I have obviously no idea how to maintain this if I lost access to every LLM on the planet.

Does this make me a doomerist, suggesting that software engineering as a profession is dead? Not really. Does it make me a cultist, suggesting that software engineering is obsolete? No. Does it make me a dismisser that thinks “AI” will never replace me professionally? Not that either. I think I’m still skeptical of all of these statements. But like with many other topics, I believe that the only way to form a valid opinion is at least approaching the reality with a healthy dose and skepticism and an open mind at the same time. Hey I even did that for cryptocurrencies – and yet I call them carboncurrencies still to this day! Approaching something doesn’t mean necessarily accepting it as a dogma!

What I can say is that, as tools to start a MVP (Minimum Viable Product, because we have too many overlapping acronyms), LLMs work like a charm. If I was going to try to productionize this app to share it with the world, and put it on various Android stores, I would probably need to spend more time understanding what the LLMs generated, because I wouldn’t trust it to keep it up to date for me. And of course, even though this all started with me describing what I was looking for, it doesn’t mean that I magically got everything I wanted the first time around. Software engineering was never exclusively about coding, in my opinion – which is likely formed through translating the eponymous Ian Sommerville’s book. Which is why I’m not expecting it to be a dead end. It is going, though, to change drastically: architectural decisions, UI layouts, and user acceptance testing are going to become increasingly more important than they have been over the past 50 years.

And yes, I am considering making this app available, even though it’s really just a scratch-my-itch kind of app. While I’m optimizing it for eInk displays and my own workflow (including an in-app Compose key support, since I couldn’t find a reasonable way to get this done with Android IMEs while also keeping the hardware keyboard support working), there’s nothing that is particularly tied to my own setup: it’s a WordPress client using application-specific password, with a minimalistic block editor and full offline drafting. It’s my ideal editor which I’ve been looking for for over 12 years!

Unfortunately, blogging is now an increasingly lost art. Newsletters and “Substacks” appear to be the mainstream alternative, but even those are becoming rarer and rarer, and I have found myself unsubscribing from a few that turned out to become a source of AI slop. Which is why I found myself needing to build my own tool in here. It’s definitely not something I expect most people to want to do in the first place, but it is something that is now within reach of most people with enough cash flow.

Post Scriptum

I have provided preambles a number of times regarding my views on LLMs (“AI”) and their usage, and their relationship to my employment. Even these ended up getting complaints because they were too long and verbose, so this time you’re all getting a post-scriptum instead.

The opinions I share on this blog are my own and do not reflect my employer’s. And that should be obvious, since my current employer has invested a lot on “AI”, and I don’t even like using the term. I’m not being paid by anyone to hype up anything in this post — heck, I have not even shared which LLMs I used to do this, intentionally!

Personally, as I said above, I don’t believe software engineering as a profession is done for. I think it is definitely going to change, significantly, in the next few years. I think that there will be a lot more value in the non-coding components of the job. If I was interested in the sociological aspect of this, I would probably be looking in the evolution of machining and mechanical design with the advent of CAD/CAM and CNC.

There are definitely a number of things that, as LLMs become more capable, will sound as obsolete as turning metal pots on a lathe — and yet there are plenty of people turning objects on a lathe to this day! Artisanship has not completely been replaced by industrial-scale manufacturing. In many fields, LLMs are bringing a similar “revolution”, as tasks that used to consume people’s time can be given to an LLM to complete, trading time for money, in a similar way as Cloud Computing does to infra.

What I don’t think LLMs will actually do is replacing the creative industries, no matter how both the doomerist and the hyperists insist they might. LLMs can generate generic images and placeholders, and they might be currently eating into some of the customer base of illustrators and cover artists — but it’s not going to stay like this once the novelty fades, just as Microsoft Wordart hasn’t replaced graphic designers before. Nobody who cares would want their covers, signs, or even business cards look generic like everyone else — the people who are now using “AI art” for their own commercial venues were not going to pay an artist to do the illustrations in the first place.

2026-05-18 20:48:21 UTC

Until this past weekend, a contractor for the Cybersecurity & Infrastructure Security Agency (CISA) maintained a public GitHub repository that exposed credentials to several highly privileged AWS GovCloud accounts and a large number of internal CISA systems. Security experts said the public archive included files detailing how CISA builds, tests and deploys software internally, and that it represents one of the most egregious government data leaks in recent history.

On May 15, KrebsOnSecurity heard from Guillaume Valadon, a researcher with the security firm GitGuardian. Valadon’s company constantly scans public code repositories at GitHub and elsewhere for exposed secrets, automatically alerting the offending accounts of any apparent sensitive data exposures. Valadon said he reached out because the owner in this case wasn’t responding and the information exposed was highly sensitive.

A redacted screenshot of the now-defunct “Private CISA” repository maintained by a CISA contractor.

The GitHub repository that Valadon flagged was named “Private-CISA,” and it harbored a vast number of internal CISA/DHS credentials and files, including cloud keys, tokens, plaintext passwords, logs and other sensitive CISA assets.

Valadon said the exposed CISA credentials represent a textbook example of poor security hygiene, noting that the commit logs in the offending GitHub account show that the CISA administrator disabled the default setting in GitHub that blocks users from publishing SSH keys or other secrets in public code repositories.

“Passwords stored in plain text in a csv, backups in git, explicit commands to disable GitHub secrets detection feature,” Valadon wrote in an email. “I honestly believed that it was all fake before analyzing the content deeper. This is indeed the worst leak that I’ve witnessed in my career. It is obviously an individual’s mistake, but I believe that it might reveal internal practices.”

One of the exposed files, titled “importantAWStokens,” included the administrative credentials to three Amazon AWS GovCloud servers. Another file exposed in their public GitHub repository — “AWS-Workspace-Firefox-Passwords.csv” — listed plaintext usernames and passwords for dozens of internal CISA systems. According to Caturegli, those systems included one called “LZ-DSO,” which appears short for “Landing Zone DevSecOps,” the agency’s secure code development environment.

Philippe Caturegli, founder of the security consultancy Seralys, said he tested the AWS keys only to see whether they were still valid and to determine which internal systems the exposed accounts could access. Caturegli said the GitHub account that exposed the CISA secrets exhibits a pattern consistent with an individual operator using the repository as a working scratchpad or synchronization mechanism rather than a curated project repository.

“The use of both a CISA-associated email address and a personal email address suggests the repository may have been used across differently configured environments,” Caturegli observed. “The available Git metadata alone does not prove which endpoint or device was used.”

The Private CISA GitHub repo exposed dozens of plaintext credentials for important CISA GovCloud resources.

Caturegli said he validated that the exposed credentials could authenticate to three AWS GovCloud accounts at a high privilege level. He said the archive also includes plain text credentials to CISA’s internal “artifactory” — essentially a repository of all the code packages they are using to build software — and that this would represent a juicy target for malicious attackers looking for ways to maintain a persistent foothold in CISA systems.

“That would be a prime place to move laterally,” he said. “Backdoor in some software packages, and every time they build something new they deploy your backdoor left and right.”

In response to questions, a spokesperson for CISA said the agency is aware of the reported exposure and is continuing to investigate the situation.

“Currently, there is no indication that any sensitive data was compromised as a result of this incident,” the CISA spokesperson wrote. “While we hold our team members to the highest standards of integrity and operational awareness, we are working to ensure additional safeguards are implemented to prevent future occurrences.”

A review of the GitHub account and its exposed passwords show the “Private CISA” repository was maintained by an employee of Nightwing, a government contractor based in Dulles, Va. Nightwing declined to comment, directing inquiries to CISA.

CISA has not responded to questions about the potential duration of the data exposure, but Caturegli said the Private CISA repository was created on November 13, 2025. The contractor’s GitHub account was created back in September 2018.

The GitHub account that included the Private CISA repo was taken offline shortly after both KrebsOnSecurity and Seralys notified CISA about the exposure. But Caturegli said the exposed AWS keys inexplicably continued to remain valid for another 48 hours.

CISA is currently operating with only a fraction of its normal budget and staffing levels. The agency has lost nearly a third of its workforce since the beginning of the second Trump administration, which forced a series of early retirements, buyouts, and resignations across the agency’s various divisions.

The now-defunct Private CISA repo showed the contractor also used easily-guessed passwords for a number of internal resources; for example, many of the credentials used a password consisting of each platform’s name followed by the current year. Caturegli said such practices would constitute a serious security threat for any organization even if those credentials were never exposed externally, noting that threat actors often use key credentials exposed on the internal network to expand their reach after establishing initial access to a targeted system.

“What I suspect happened is [the CISA contractor] was using this GitHub to synchronize files between a work laptop and a home computer, because he has regularly committed to this repo since November 2025,” Caturegli said. “This would be an embarrassing leak for any company, but it’s even more so in this case because it’s CISA.”

2026-05-18 17:10:00 UTC

Smokin' Guns auf Debian/Ubuntu installieren

Smokin' Guns ist ein Free-Software-Western-Shooter auf Basis der Quake-3-Engine.
Das offizielle `.deb`-Paket (v1.1) lässt sich auf aktuellen 64-Bit-Systemen nicht direkt
installieren, weil `libjpeg8:i386` nicht mehr im Repo liegt. Der folgende Weg löst das.

Voraussetzungen

- 64-Bit-System (amd64), Debian 13 oder Ubuntu/Tuxedo OS
- `smokinguns_1.1-1_i386.deb` – Download von [smokin-guns.org](https://www.smokin-guns.org)

geht nicht, ich habe es bei [web.archive.org](https://web.archive.org/web/20190629023139/http://download.smokin-guns.org/smokinguns_1.1-1_i386.deb)

Hinweis:
Ich bin kein sudo Freund, ich nutze das nur ala sudo bash

---

Installation

1. i386-Architektur aktivieren

dpkg --add-architecture i386
apt update

2. Fehlende Abhängigkeit lösen

`libjpeg8:i386` existiert in aktuellen Repos nicht mehr. Workaround:

Dummy-Paket bauen (einmalig):

mkdir -p /tmp/libjpeg8-dummy/DEBIAN
cat > /tmp/libjpeg8-dummy/DEBIAN/control << 'EOF'
Package: libjpeg8
Version: 8d-2
Architecture: i386
Maintainer: Local Dummy
Depends: libjpeg62-turbo:i386
Description: Dummy-Paket fuer libjpeg8 i386 Kompatibilitaet
EOF
dpkg-deb --build /tmp/libjpeg8-dummy /tmp/libjpeg8_8d-2_i386.deb
sudo dpkg -i /tmp/libjpeg8_8d-2_i386.deb

**Symlink anlegen**, damit die Library auch gefunden wird:

ln -sf /usr/lib/i386-linux-gnu/libjpeg.so.62 \
            /usr/lib/i386-linux-gnu/libjpeg.so.8

> Auf Ubuntu-basierten Systemen (Tuxedo OS) ist `libjpeg8:i386` oft direkt verfügbar –
> dann reicht `sudo apt install libjpeg8:i386` und die beiden Schritte oben entfallen.

3. Spiel installieren

apt install ./smokinguns_1.1-1_i386.deb

apt zieht alle weiteren Abhängigkeiten automatisch nach.

4. Starten

/usr/games/smokinguns/smokinguns.i386

---

Auflösung einstellen

Im Spiel selbst lässt sich die Auflösung nicht dauerhaft ändern – die Einstellungen
werden beim nächsten Start überschrieben. Workaround über die Config-Datei:

Config bearbeiten

nano ~/.smokinguns/smokinguns/q3config.cfg

Folgende Zeilen eintragen oder anpassen:

seta r_mode "-1"
seta r_customwidth "1920"
seta r_customheight "1080"

Alternativ: `r_mode "-2"` übernimmt automatisch die Desktop-Auflösung.

> **Hinweis:** Smokin' Guns unterstützt kein echtes Widescreen-Seitenverhältnis.
> Bei 16:9 wird das Bild gestreckt. 4:3-Auflösungen wie 1280x960 oder 1600x1200
> sehen besser aus.

Config schreibschützen

Damit das Spiel die Werte nicht beim Start überschreibt:

chmod 400 ~/.smokinguns/smokinguns/q3config.cfg

---

## Automatisches Installations-Script

Wer die Schritte nicht einzeln ausführen will: Das Script `install-smokinguns.sh`
erledigt alles automatisch und erkennt selbst, ob Debian- oder Ubuntu-Workaround
nötig ist.

bash install-smokinguns.sh /pfad/zu/smokinguns_1.1-1_i386.deb

"Smokin' Guns auf Debian/Ubuntu installieren" vollständig lesen

2026-05-18 10:29:08 UTC

The Valuable News weekly series is dedicated to provide summary about news, articles and other interesting stuff mostly but not always related to the UNIX/BSD/Linux systems. Whenever I stumble upon something worth mentioning on the Internet I just put it here.

Today the amount information that we get using various information streams is at massive overload. Thus one needs to focus only on what is important without the need to grep(1) the Internet everyday. Hence the idea of providing such information ‘bulk’ as I already do that grep(1).

The Usual Suspects section at the end is permanent and have links to other sites with interesting UNIX/BSD/Linux news.

Past releases are available at the dedicated NEWS page.

UNIX

Teaching ZFS About Time.
https://oshogbo.com/blog/86/

FreeBSD Git Weekly: 2026-05-04 to 2026-05-10.
https://freebsd-git-weekly.tarsnap.net/2026-05-04.html

Unlocking Encrypted ZFS Volumes with Passkey.
https://withblue.ink/2026/05/09/revaulter-encrypted-zfs-passkey.html

Nintendo Wii as NetBSD Web Server.
https://hackster.io/news/alex-haydock-saves-a-nintendo-wii-from-the-scrapheap-and-turns-it-into-a-netbsd-web-server-aebbf2c6492e

OpenBSD and Slopcode: Raindrop to Torrent?
https://osnews.com/story/144935/openbsd-and-slopcode-raindrop-to-a-torrent/

FreeBSD 2026/05/04-11 Weekly Review. [German]
https://tgeppert.de/2026/05/11/freebsd-wochenrueckblick-4-11-mai-2026/

Game of Trees 0.125 Released.
https://undeadly.org/cgi?action=article;sid=20260512052610

Automatic Expiry at Timeout for pf(4) Overload Tables on OpenBSD.
https://undeadly.org/cgi?action=article;sid=20260513064948

FreeBSD 15.2 Will Aim for Nice KDE Desktop Installation Experience.
https://phoronix.com/news/FreeBSD-15.2-KDE-Desktop

FreeBSD 15.1-BETA2 Released with ZSTD 1.5.7 and Kernel Bug Fixes.
https://pbxscience.com/freebsd-15-1-beta-2-released-with-zstd-1-5-7-and-kernel-bug-fixes/

Tailscale SSH Server Access on FreeBSD.
https://conradresearch.com/articles/tailscale-ssh-server-access-on-freebsd

Manage ZFS Boot Environments in Webmin with zfsmanager on FreeBSD.
https://github.com/JRGTH/zfsmanager

NetBSD 11.0 RC4 Available.
https://blog.netbsd.org/tnf/entry/netbsd_11_0_rc4_available

Real Time Network Diagnostics in Terminal with netwatch(8) Command.
https://github.com/matthart1983/netwatch

Bun Now Has Official FreeBSD Builds.
https://github.com/oven-sh/bun/releases/tag/bun-v1.3.14

BaroPAM Installation Guide on FreeBSD.
https://mc529.tistory.com/1567

FreeBSD NTSync Kernel Driver for Use with Windows Compatibility Layers.
https://github.com/XaeroVincent/FreeBSD-NTSync

Wlasny Serwer FreeBSD – Czesc 6 – Serwer SMTP. [Polish]
https://linuxiarze.pl/wlasny-serwer-freebsd-cz-6-serwer-poczty-smtp/

AI Generated Code Merged into OpenBSD Base.
https://exquisite.social/@kaidenshi/116550773312366690

Farewell Aruba – Hello OVH – Migration Story.
https://oshogbo.com/blog/87/

BSD Part Deux.
https://ministryofmayhem.space/posts/bsdptdeux/

Wine 11.9 Released with Initial Support for System Threads.
https://phoronix.com/news/Wine-11.9-Released

FreeBSD 15.1-BETA3 is Now Live.
https://officialaptivi.wordpress.com/2026/05/16/freebsd-15-1-beta-3-is-now-live/

FreeBSD 15.1 – Running Plasma Wayland without SDDM.
https://blog.cabroneria.com/post/0009_freebsd15.1_wayland_no_sddm/

FreeBSD 15.1-BETA3 Updates OpenZFS and Ensures Cloud Updated Images on First Boot.
https://phoronix.com/news/FreeBSD-15.1-Beta-3

FreeBSD 15.1-BETA3 DRM/i915 Upgrade Runbook.
https://blog.cabroneria.com/bits/0014_freebsd-15.1-drm-i915-runbook/

Going from ZFS Object ID to Its Path Easier Way.
https://utcc.utoronto.ca/~cks/space/blog/solaris/ZFSObjectIdToPath

The battery-sleep.sh Script for Auto Suspend on Low Battery for FreeBSD.
https://blog.cabroneria.com/bits/0013_kde_wayland_sleep/

UNIX/Audio/Video

Installing and Using Sylve on FreeBSD.
https://youtube.com/watch?v=oQaGtMiEMy4

FreeBSD 15.0 pf(4) Deep Dive.
https://youtube.com/watch?v=gu_R-eO3_T8

2026-05-13 OpenZFS Production User Call.
https://youtube.com/watch?v=7i1lOG1K8y0

2026-05-14 Bhyve Production User Call.
https://youtube.com/watch?v=St14DAYnYWs

386BSD Installation on Real Hardware.
https://youtube.com/watch?v=kDanM667khI

BSD Now 663: Proxhyve.
https://www.bsdnow.tv/663

Hardware

Lego AMIGA 4000 Build: Commodore Classic Reimagined as Amiga CD3200.
https://generationamiga.com/2026/05/17/lego-amiga-4000-build-commodore-classic-reimagined-as-the-amiga-cd3200/

AMD Finally Fixing HDMI 2.1 on Linux.
https://youtube.com/watch?v=g-dvzJ2GIYA

ChargeCap Helps Your Batteries Last Longer by Limiting Charge Level.
https://hackaday.com/2026/05/14/chargecap-helps-your-batteries-last-longer-by-limiting-charge-level/

Bambu Lab 3D Printers: Never Again.
https://youtube.com/watch?v=eb48MdtNaDQ

Bambu Lab is Abusing Open Source Social Contract.
https://jeffgeerling.com/blog/2026/bambu-lab-abusing-open-source-social-contract/

The Go Computer Now! is Story of Tiny USA/Utah Company That Built 1st Desktop PC in 1975.
https://gocomputernow.com/

Other

Replace Ads with They Live (1988) Style Slogans.
https://github.com/davmlaw/they_live_adblocker

Security Researcher Says Microsoft Built Backdoor in BitLocker and Releases Exploit to Prove It.
https://techspot.com/news/112410-security-researcher-microsoft-secretly-built-backdoor-bitlocker-releases.html

YellowKey 0-Day Vulnerability Enables Access to BitLocker Encrypted Drives.
https://cybersecuritynews.com/windows-bitlocker-0-day-vulnerability/

Real Racing 3 – Keroxea Edition – Project Resurrection.
https://realracing3keroxeaedition.blogspot.com/2026/03/blog-post.html

Usual Suspects

BSD Weekly.
https://bsdweekly.com/

DiscoverBSD.
https://discoverbsd.com/

DragonFly BSD Digest.
https://dragonflydigest.com/

FreeBSD Patch Level Table.
https://bokut.in/freebsd-patch-level-table/

FreeBSD End of Life Date.
https://endoflife.date/freebsd

Phoronix BSD News Archives.
https://phoronix.com/linux/BSD

OpenBSD Journal.
https://undeadly.org/

Call for Testing.
https://callfortesting.org/

Call for Testing – Production Users Call.
https://youtube.com/@callfortesting/videos

BSD Now Weekly Podcast.
https://www.bsdnow.tv/

Nixers Newsletter.
https://newsletter.nixers.net/entries.php

BSD Cafe Journal.
https://journal.bsd.cafe/

DragonFly BSD Digest – Lazy Reading – In Other BSDs.
https://dragonflydigest.com

FreeBSD Git Weekly.
https://freebsd-git-weekly.tarsnap.net/

FreeBSD Meetings.
https://youtube.com/@freebsdmeetings

Sheridan Computers.
https://youtube.com/@sheridans/videos

EOF

2026-05-16 00:00:00 UTC

The third BETA build for the FreeBSD 15.1 release cycle is now available. ISO images for the amd64, armv7, aarch64, powerpc64, powerpc64le, and riscv64 architectures are FreeBSD mirror sites.

2026-05-15 17:22:38 UTC

Aruba Cloud decided to retire VMware and push everyone onto their OpenStack offering. Fine, that is their call to make. VWhat I am less excited about is the thirty-day deadline, and the part where their OpenStack does not provide a FreeBSD image.

2026-05-12 21:46:45 UTC

Artificial intelligence platforms may be just as susceptible to social engineering as human beings, but they are proving remarkably good at finding security vulnerabilities in human-made computer code. That reality is on full display this month with some of the more widely-used software makers — including Apple, Google, Microsoft, Mozilla and Oracle — fixing near record volumes of security bugs, and/or quickening the tempo of their patch releases.

As it does on the second Tuesday of every month, Microsoft today released software updates to address at least 118 security vulnerabilities in its various Windows operating systems and other products. Remarkably, this is the first Patch Tuesday in nearly two years that Microsoft is not shipping any fixes to deal with emergency zero-day flaws that are already being exploited. Nor have any of the flaws fixed today been previously disclosed (potentially giving attackers a heads up in how to exploit the weakness).

Sixteen of the vulnerabilities earned Microsoft’s most-dire “critical” label, meaning malware or miscreants could abuse these bugs to seize remote control over a vulnerable Windows device with little or no help from the user. Rapid7 has done much of the heavy lifting in identifying some of the more concerning critical weaknesses this month, including:

CVE-2026-41089: A critical stack-based buffer overflow in Windows Netlogon that offers an attacker SYSTEM privileges on the domain controller. No privileges or user interaction are required, and attack complexity is low. Patches are available for all versions of Windows Server from 2012 onwards.
CVE-2026-41096: A critical RCE in the Windows DNS client implementation worthy of attention despite Microsoft assessing exploitation as less likely.
CVE-2026-41103: A critical elevation of privilege vulnerability that allows an unauthorized attacker to impersonate an existing user by presenting forged credentials, thus bypassing Entra ID. Microsoft expects that exploitation is more likely.

May’s Patch Tuesday is a welcome respite from April, which saw Microsoft fix a near-record 167 security flaws. Microsoft was among a few dozen tech giants given access to a “Project Glasswing,” a much-hyped AI capability developed by Anthropic that appears quite effective at unearthing security vulnerabilities in code.

Apple, another early participant in Project Glasswing, typically fixes an average of 20 vulnerabilities each time it ships a security update for iOS devices, said Chris Goettl, vice president of product management at Ivanti. On May 11, Apple shipped updates to address at least 52 vulnerabilities and backported the changes all the way to iPhone 6s and iOS 15.

Last month, Mozilla released Firefox 150, which resolved a whopping 271 vulnerabilities that were reportedly discovered during the Glasswing evaluation.

“Since Firefox 150.0.0 released, they have been on a more aggressive weekly cadence for security updates including the release of Firefox 150.0.3 on May Patch Tuesday resolving between three to five CVEs in each release,” Goettl said.

The software giant Oracle likewise recently increased its patch pace in response to their work with Glasswing. In its most recent quarterly patch update, Oracle addressed at least 450 flaws, including more than 300 fixes for remotely exploitable, unauthenticated flaws. But at the end of April, Oracle announced it was switching to a monthly update cycle for critical security issues.

On May 8, Google started rolling out updates to its Chrome browser that fixed an astonishing 127 security flaws (up from just 30 the previous month). Chrome automagically downloads available security updates, but installing them requires fully restarting the browser.

If you encounter any weirdness applying the updates from Microsoft or any other vendor mentioned here, feel free to sound off in the comments below. Meantime, if you haven’t backed up your data and/or drive lately, doing that before updating is generally sound advice. For a more granular look at the Microsoft updates released today, checkout this inventory by the SANS Internet Storm Center.

2026-05-08 02:58:46 UTC

An ongoing data extortion attack targeting the widely-used education technology platform Canvas disrupted classes and coursework at school districts and universities across the United States today, after a cybercrime group defaced the service’s login page with a ransom demand that threatened to leak data from 275 million students and faculty across nearly 9,000 educational institutions.

A screenshot shared by a reader showing the extortion message that was shown on the Canvas login page today.

Canvas parent firm Instructure responded to today’s defacement attacks by disabling the platform, which is used by thousands of schools, universities and businesses to manage coursework and assignments, and to communicate with students.

Instructure acknowledged a data breach earlier this week, after the cybercrime group ShinyHunters claimed responsibility and said they would leak data on tens of millions of students and faculty unless paid a ransom. The stated deadline for payment was initially set at May 6, but it was later pushed back to May 12.

In a statement on May 6, Instructure said the investigation so far shows the stolen information includes “certain identifying information of users at affected institutions, such as names, email addresses, and student ID numbers, as well as as messages among users.” The company said it found no evidence the breached data included more sensitive information, such as passwords, dates of birth, government identifiers or financial information.

The May 6 update stated that Canvas was fully operational, and that Instructure was not seeing any ongoing unauthorized activity on their platform. “At this stage, we believe the incident has been contained,” Instructure wrote.

However, by mid-day on Thursday, May 7, students and faculty at dozens of schools and universities were flooding social media sites with comments saying that a ransom demand from ShinyHunters had replaced the usual Canvas login page. Instructure responded by pulling Canvas offline and replacing the portal with the message, “Canvas is currently undergoing scheduled maintenance. Check back soon.”

“We anticipate being up soon, and will provide updates as soon as possible,” reads the current message on Instructure’s status page.

While the data stolen by ShinyHunters may or may not contain particularly sensitive information (ShinyHunters claims it includes several billion private messages among students and teachers, as well as names, phone numbers and email addresses), this attack could hardly have come at a worse time for Instructure: Many of the affected schools and universities are in the middle of final exams, and a prolonged outage could be highly damaging for the company.

The extortion message that greeted countless Canvas users today advised the affected schools to negotiate their own ransom payments to prevent the publication of their data — regardless of whether Instructure decides to pay.

“ShinyHunters has breached Instructure (again),” the extortion message read. “Instead of contacting us to resolve it they ignored us and did some ‘security patches.'”

A source close to the investigation who was not authorized to speak to the press told KrebsOnSecurity that a number of universities have already approached the cybercrime group about paying. The same source also pointed out that the ShinyHunters data leak blog no longer lists Instructure among its current extortion victims, and that the samples of data stolen from Canvas customers were removed as well. Data extortion groups like ShinyHunters will typically only remove victims from their leak sites after receiving an extortion payment or after a victim agrees to negotiate.

Dipan Mann, founder and CEO of the security firm Cloudskope, slammed Instructure for referring to today’s outage as a “scheduled maintenance” event on its status page. Mann said Shiny Hunters first demonstrated they’d breached Instructure on May 1, prompting Instructure’s Chief Information Security Officer Steve Proud to declare the following day that the incident had been contained. But Mann said today’s attack is at least the third time in the past eight months that Instructure has been breached by ShinyHunters.

In a blog post today, Mann noted that in September 2025, ShinyHunters released thousands of internal University of Pennsylvania files — donor records, internal memos, and other confidential materials — through what the Daily Pennsylvanian and other outlets later determined was, in part, a Canvas/Instructure-mediated access path.

“Penn was the named victim,” Mann wrote. “Instructure was the mechanism. The incident was treated as a Penn-specific story by most of the national press and quietly handled by Instructure as a customer-specific matter. That framing was wrong then. It is dramatically more wrong in light of the May 2026 events, which now look like the planned escalation of an attack pattern that ShinyHunters had been working against Instructure’s environment for at least eight months prior. The September 2025 Penn breach was the proof of concept. The May 1, 2026 incident was the production run. The May 7, 2026 recompromise was ShinyHunters demonstrating publicly that the May 2 ‘containment’ did not happen.”

In February, a ShinyHunters spokesperson told The Daily Pennsylvanian that Penn failed to pay a $1 million ransom demand. On March 5, ShinyHunters published 461 megabytes worth of data stolen from Penn, including thousands of files such as donor records and internal memos.

ShinyHunters is a prolific and fluid cybercriminal group that specializes in data theft and extortion. They typically gain access to companies through voice phishing and social engineering attacks that often involve impersonating IT personnel or other trusted members of a targeted organization.

Last month, ShinyHunters relieved the home security giant ADT of personal information on 5.5 million customers. The extortion group told BleepingComputer they breached the company by compromising an employee’s Okta single sign-on account in a voice phishing attack that enabled access to ADT’s Salesforce instance. BleepingComputer says ShinyHunters recently has taken credit for a number of extortion attacks against high-profile organizations, including Medtronic, Rockstar Games, McGraw Hill, 7-Eleven and the cruise line operator Carnival.

The attack on Canvas customers is just one of several major cybercrime campaigns being launched by ShinyHunters at the moment, said Charles Carmakal, chief technology officer at the Google-owned Mandiant Consulting. Carmakal declined to comment specifically on the Canvas breach, but said “there are multiple concurrent and discrete ShinyHunters intrusion and extortion campaigns happening right now.”

Cloudskope’s Mann said what happens next depends largely on whether Instructure’s customers — the universities, K-12 districts, and education ministries paying for Canvas — choose to apply pressure or absorb the breach quietly.

“The history of education-vendor incidents suggests the path of least resistance is the second one,” he concluded.

Update, May 8, 11:05 a.m. ET: Instructure has published an incident update page that includes more information about the breach. Instructure said its Canvas portal is functioning normally again, and that the hackers exploited an issue related to Free-for-Teacher accounts.

“This is the same issue that led to the unauthorized access the prior week,” Instructure wrote. “As a result, we have made the difficult decision to temporarily shut down Free-for-Teacher accounts. These accounts have been a core part of our platform, and we’re committed to resolving the issues with these accounts.”

Instructure said affected organizations were notified on May 6.

“If your organization is affected, Instructure will contact your organization’s primary contacts directly,” the update states. “Please don’t rely on third-party lists or social media posts naming potentially affected organizations as those lists aren’t verified. Instructure will confirm validated information through direct outreach to all affected organizations.”

Update, May 11, 10:16 p.m. ET: Instructure posted an update saying they paid their extortionists in exchange for a promise to destroy the stolen data. “The data was returned to us,” the update reads. “We received digital confirmation of data destruction (shred logs). We have been informed that no Instructure customers will be extorted as a result of this incident, publicly or otherwise.”

2026-05-11 17:12:00 UTC

For readers new to Expat:

libexpat is a fast streaming XML parser. Alongside libxml2, Expat is one of the most widely used software libre XML parsers written in C, specifically C99. It is cross-platform and licensed under the MIT license.

Expat 2.8.1 was released yesterday. The key motivation for cutting a release and doing so now was:

Fixing vulnerability CVE-2026-45186 that allows easy denial of service.

The vulnerability was reported to me responsibly about eight months ago by Nick Wellnhofer, the long-time and past maintainer of libxml2.

The attack relies on Expat <2.8.1 using an O(n²) runtime algorithm — a for loop — to check for collisions among attribute names. It takes nothing more than dialing up XML document…

<!DOCTYPE d [
  <!ATTLIST e a0 CDATA "" a1 CDATA "" a2 CDATA "">
]>
<d/>

…from 3 attributes to a number big enough for the specific target of the attack.

It should be noted that a layer of compression around XML can significantly reduce the minimum attack payload size.

There is an attack payload generator available for download: please use it responsibly!

Berkay Eren Ürün and I teamed up for a fix. It uses a hash table instead of a linear loop to detect collisions, which turns overall runtime from O(n*n) into O(n).

For some numbers (from older ThinkPad X220 hardware):

Count	Runtime unfixed	Runtime fixed	Payload size
	(seconds)	(seconds)	(uncompressed, bytes)
10,000	0.17	0.03	135,615
100,000	13.22	0.24	1,395,615
200,000	59.71	0.49	2,795,615
400,000	253.18	1.04	5,708,119

And a quick graph:

It is worth noting that after I filed a CVE request with Mitre, someone turned my classification as remote (i.e. parsing from the wire) to mistaken local (i.e. local account access needed) and also to "Attack complexity: High" when it is a simple as shown above and with an attack payload generator being public. That results is an unrealistically low current CVSS score "2.9 of 10" on GitHub…

…and also in NVD. A more realastic score than 2.9 would be 5.3 to 7.5.

I have requested a fix from Mitre in the meantime, but that's not fixing the core issue. This could serve as both a concrete example and a reminder that:

CVSS scores are unreliable: they are often over- or (worse) underestimating risk.
CVSS scores (and CVE reports) are edited by individuals that may or may not know better than the reporting individuals and/or the maintainers upstream.
CVSS score is not a metric to base decisions about vulnerabilities on.

Thanks to everyone who contributed to this release of Expat!

For more details about this release, please check out the change log.

If you maintain Expat packaging, a bundled copy of Expat, or a pinned version of Expat, please update to version 2.8.1. Thank you!

Sebastian Pipping

2026-05-11 11:49:25 UTC

ZFS is a robust file system, in large part thanks to its copy-on-write design. Problems can still show up: flaky cables, dying drives, or the occasional cosmic ray flipping a bit. For exactly those situations ZFS has a feature called scrub. Scrub walks every used block starting from the uberblock and compares the stored checksum against the data on disk.

2026-05-11 09:29:22 UTC

The Valuable News weekly series is dedicated to provide summary about news, articles and other interesting stuff mostly but not always related to the UNIX/BSD/Linux systems. Whenever I stumble upon something worth mentioning on the Internet I just put it here.

Today the amount information that we get using various information streams is at massive overload. Thus one needs to focus only on what is important without the need to grep(1) the Internet everyday. Hence the idea of providing such information ‘bulk’ as I already do that grep(1).

The Usual Suspects section at the end is permanent and have links to other sites with interesting UNIX/BSD/Linux news.

Past releases are available at the dedicated NEWS page.

UNIX

FreeBSD 15.1-BETA2 Now Available.
https://lists.freebsd.org/archives/freebsd-stable/2026-May/004070.html

FreeBSD 15.1-BETA2 Brings Updated ZSTD and Bug Fixes.
https://phoronix.com/news/FreeBSD-15.1-Beta-2-Released

FreeBSD 15.1-BETA1 Released for Early Testing.
https://phoronix.com/news/FreeBSD-15.1-Beta-1

FreeBSD 15.1-BETA1 is Now Live.
https://officialaptivi.wordpress.com/2026/05/04/freebsd-15-1-beta-1-is-now-live/

OmniOS Community Edition r151058.
https://omnios.org/article/r58.html

Help Needed for Testing GhostBSD 26.2.
https://forums.ghostbsd.org/d/881-help-needed-for-testing-ghostbsd-262

NetBSD Based smolBSD on FreeBSD Bhyve.
https://mastodon.bsd.cafe/@imil/116521405582028887

FreeBSD Git Weekly: 2026-04-27 to 2026-05-03.
https://freebsd-git-weekly.tarsnap.net/2026-04-27.html

CVE-2026-31431: Copy Fail vs. Rootless Containers.
https://dragonsreach.it/2026/05/04/cve-2026-31431-copy-fail-rootless-containers/

Only Nx GPU Backend That Tuns on FreeBSD – Vulkan Compute for Linux NVIDIA and FreeBSD mesa-radv.
https://github.com/borodark/nx_vulkan

Why FreeBSD – Isolation as Security Primitive – Fudo CEO Pawel Dawidek.
https://linkedin.com/feed/update/urn:li:activity:7458165739682947072/

Monitor Your Devices with LibreNMS on FreeBSD.
https://it-notes.dragas.net/2026/05/07/monitor-your-services-with-librenms-on-freebsd/

Going Back to BSD.
https://peteftw.com/~pete/2026/05/using-freebsd.html

FreeBSD PKGBASE Minor Upgrades.
https://vermaden.wordpress.com/2026/05/10/freebsd-pkgbase-minor-upgrades/

Upgrading FreeBSD 15.0-STABLE to 15.1-BETA2 (PKGBASE System).
https://officialaptivi.wordpress.com/2026/05/10/upgrading-freebsd-15-0-stable-to-15-1-beta2-pkgbase-system/

Unison in Anger.
https://blog.feld.me/posts/2026/05/unison-in-anger/

Telling newsyslog(8) to Not Compress for Anything.
https://dan.langille.org/2026/05/10/newsyslog-telling-it-not-to-compress-for-anything/

VPP with Maglev Loadbalancing – Part 2.
https://ipng.ch/s/articles/2026/05/08/vpp-with-maglev-loadbalancing-part-2/

NetBSD Welcomes Google Summer of Code 2026 Contributors.
https://blog.netbsd.org/tnf/entry/gsoc2026_welcome_contributors

Backlight Idle Daemon for FreeBSD/KDE/Plasma/Wayland.
https://blog.cabroneria.com/bits/0012_blight_wayland_screen_dimming_freebsd/

Mudlet for FreeBSD Ports Tree.
https://daemondesktop.blogspot.com/2026/05/mudlet-for-freebsd-ports-tree.html

Autolycus is World First AI Agent for FreeBSD.
https://github.com/waym0reom3ga/autolycus-agent

UNIX/Audio/Video

2026-05-05 Jail/Zones Production User Call.
https://youtube.com/watch?v=hZG0G77WkT8

Saving Your Storage: How OpenZFS Architecture Rescues Enterprise Data with Allan Jude.
https://youtube.com/watch?v=d2AxBT-cyQA

Look at GhostBSD 26.1 Mate Edition.
https://youtube.com/watch?v=08Wvb0LQJcw

FreeBSD Updating Ports.
https://youtube.com/watch?v=g11a-1im6Q4

BSD Now 662: I Need Hero.
https://www.bsdnow.tv/662

Hardware

AMD Intros Instinct MI350P Accelerator: CDNA 4 Comes to PCIe Cards.
https://servethehome.com/amd-intros-instinct-mi350p-accelerator-cdna-4-comes-to-pcie-cards/

x86 ACE Instructions: AMD Zen 7 Core AI Acceleration Detailed.
https://hwcooling.net/en/x86-ace-instructions-amd-zen-7-cores-ai-acceleration-detailed/

Micron Ships Gigantic 245TB SSD.
https://nerds.xyz/2026/05/micron-245tb-ssd/

Life

Why Governments are Suddenly Banning WiFi Routers.
https://youtube.com/watch?v=7MvOAGo4FSA

Other

Open Source Does Not Imply Open Community.
https://blog.feld.me/posts/2026/04/open-source-does-not-imply-open-community/

Google Chrome Silently Installs 4 GB AI Model on Your Device without Consent.
https://thatprivacyguy.com/blog/chrome-silent-nano-install/

Internet Just Changed (and Nobody Noticed).
https://youtube.com/watch?v=lWBKO6n5kaY

Mozilla Used Claude Mythos to Find 271 Security Problems in Firefox – All of Them Fixed in 150.0.
https://x.com/Pirat_Nation/status/2052795666057838669

John Carmack: C Simplicity Makes It Easier to Work with Especially in Projects Like OpenBSD.
https://x.com/tetsuoai/status/2053045359245725735

Usual Suspects

BSD Weekly.
https://bsdweekly.com/

DiscoverBSD.
https://discoverbsd.com/

DragonFly BSD Digest.
https://dragonflydigest.com/

FreeBSD Patch Level Table.
https://bokut.in/freebsd-patch-level-table/

FreeBSD End of Life Date.
https://endoflife.date/freebsd

Phoronix BSD News Archives.
https://phoronix.com/linux/BSD

OpenBSD Journal.
https://undeadly.org/

Call for Testing.
https://callfortesting.org/

Call for Testing – Production Users Call.
https://youtube.com/@callfortesting/videos

BSD Now Weekly Podcast.
https://www.bsdnow.tv/

Nixers Newsletter.
https://newsletter.nixers.net/entries.php

BSD Cafe Journal.
https://journal.bsd.cafe/

DragonFly BSD Digest – Lazy Reading – In Other BSDs.
https://dragonflydigest.com

FreeBSD Git Weekly.
https://freebsd-git-weekly.tarsnap.net/

FreeBSD Meetings.
https://youtube.com/@freebsdmeetings

Sheridan Computers.
https://youtube.com/@sheridans/videos

EOF

2026-05-10 13:40:16 UTC

In this post, I’m going to show you how I told FreeBSD’s newsyslog to ignore any compression directives and just rotate the file. I will also speculate about some historical items which may be widely incorrect. If you wish to correct any inaccuracies, I will update them here.

In this post:

FreeBSD 15
wild speculation as to how logging, newsyslog, and compression evovled
many paragraphs which aren’t related, but you may find interesting, so skip to the end if in a hurry

Way back when…

Logging is good. Log files fill up. Disk space was expensive. Let’s rotate them away. And newsyslog was born.

I know how we can save more disk space! Compress the rotated files. Nobody writes to them. We can save space!

Let’s add this new algorithm for compression, it’ll be faster and save even more space!

I enjoy how new features come in to meet preferences and optimizations. This post talks about one such change.

Then ZFS came along

One of the fantastic ZFS features is filesystem compression. With modern CPUs and drives, it is faster to read and decompress the data from disk than it is to just read uncompressed data from disk. The throughput is faster.

FYI, I recently decided to use zstd compression over the default lz4 compression.

newsyslog compression

This is a typical log rotation scenario:

[12:19 nagios04 dvl ~] % ls -l /var/log/messages*
-rw-r--r--  1 root wheel 414580 2026.05.10 11:35 /var/log/messages
-rw-r--r--  1 root wheel  38164 2026.04.28 14:00 /var/log/messages.0.bz2
-rw-r--r--  1 root wheel  48391 2026.03.18 17:00 /var/log/messages.1.bz2
[12:19 nagios04 dvl ~] %

That rotation and compression is controlled here:

[12:19 nagios04 dvl ~] % grep messages /etc/newsyslog.conf
# contents of maillog, messages, and lpd-errs to be confidential.  In the
/var/log/messages			644  5	   1000	@0101T JC

See man 8 newsyslog.conf for detail.

The J directives says the file is compressible, which is why you see the bz2 suffix.

The duplication of effort

In the above situation, ZFS is compressing the data on-the-fly. Then newsylog comes along and decompresses it at the file-contents level. ZFS then can’t do much about compressing the already-compressed data.

A goal: don’t do that. Just let ZFS compress the data. It will be much better at it.

Reviewing logs

From time to time, I review logs, looking for something that happened.

Here’s an example, taken from command history, from FreshPorts. In this output, I’m counting the number of web requests per day over the last two weeks (plus today). The logs are rotated daily. First, I sort those logs by date, then do the line count

[12:26 aws-1 dvl ~] % sudo wc -l $(ls -t /jails/nginx01/var/log/nginx/freshports.org-access.log*)
  186365 /jails/nginx01/var/log/nginx/freshports.org-access.log
  530253 /jails/nginx01/var/log/nginx/freshports.org-access.log.0
  681046 /jails/nginx01/var/log/nginx/freshports.org-access.log.1
  992448 /jails/nginx01/var/log/nginx/freshports.org-access.log.2
 1131488 /jails/nginx01/var/log/nginx/freshports.org-access.log.3
  451385 /jails/nginx01/var/log/nginx/freshports.org-access.log.4
  418666 /jails/nginx01/var/log/nginx/freshports.org-access.log.5
 1622017 /jails/nginx01/var/log/nginx/freshports.org-access.log.6
 1830966 /jails/nginx01/var/log/nginx/freshports.org-access.log.7
 3387571 /jails/nginx01/var/log/nginx/freshports.org-access.log.8
  761097 /jails/nginx01/var/log/nginx/freshports.org-access.log.9
  712777 /jails/nginx01/var/log/nginx/freshports.org-access.log.10
 1054190 /jails/nginx01/var/log/nginx/freshports.org-access.log.11
  778871 /jails/nginx01/var/log/nginx/freshports.org-access.log.12
  435143 /jails/nginx01/var/log/nginx/freshports.org-access.log.13
 14974283 total
[12:27 aws-1 dvl ~] % date
Sun May 10 12:27:20 UTC 2026

If these files are .bz2 files, this little command will be more complicated.

I don’t even want to show that one.

What to do about it

As you can see, the logs above are not compressed. It is controlled by a configuration file I created:

[12:32 aws-1 dvl ~] % grep /var/log/nginx/freshports.org-access.log  /jails/nginx01/usr/local/etc/newsyslog.conf.d/freshports-www.conf
/var/log/nginx/freshports.org-access.log       www:logcheck            640 14  *   $D0  B

What about system log files?

I modified /etc/newsyslog.conf – see, no compression flags:

[12:31 aws-1 dvl ~] % grep J /etc/newsyslog.conf
[12:31 aws-1 dvl ~] %

Which gives logs like this:

[12:32 aws-1 dvl ~] % ls -l /var/log/messages*
-rw-r--r--  1 root wheel  786212 2026.05.10 12:20 /var/log/messages
-rw-r--r--  1 root wheel 1056498 2026.05.01 03:00 /var/log/messages.0
-rw-r--r--  1 root wheel 1023425 2026.04.20 15:00 /var/log/messages.1
-rw-r--r--  1 root wheel 1023835 2026.03.14 14:00 /var/log/messages.2
-rw-r--r--  1 root wheel 1023533 2026.02.09 20:00 /var/log/messages.3
-rw-r--r--  1 root wheel  644428 2026.01.01 00:00 /var/log/messages.4

A great solution. It works. It works well. Until.

Oh, what about upgrades

Modifying system-provided configuration files such as /etc/newsyslog.conf adds a complication to upgrades – merging in changes from the new release.

For one line, no big deal, however there are 15 lines with compression settings in a standard /etc/newsyslog.conf – I know I’m going to miss something. I’d rather avoid that extra work.

Tell the system not to compress rotated log files

This section provides a historical overview of how this new feature came about.

Most of these links are to reviews.freebsd.org.

On Dec 7 2023, Do not compress log files was created:

With ZFS now widely used and the default install doing compression, we no
longer have to compress log files to save space.

This is a quality-of-life fix, mainly. to make it easier to search all logs
with the same command. e.g. you don’t have to use bzgrep.

It included a newsyslog.conf file without the J option. This proposal was rightly rejected because, amongst other things, it ignored all the non-ZFS users and those ZFS users not using compression (long may their reads last).

That review was abandoned in favor of newsyslog(8): Add option to globally override compression method. That idea was preferred (at least by me) because it was one switch, and did not modify the configuration file. In short, it was a -c option added to newsyslog.

Later, newsyslog(8): Add support of specifying compression method in configuration file was proposed. This is what was eventually adopted and included into FreeBSD on Dec 23 2023 and the -c option was removed.

My thanks to Xin LI (delphij) for the work on this feature. I’m only just now coming to use it.

How I’m using it

Yesterday I started looking at my existing newsyslog.conf files and reconciling all my local changes. On one host (with 34 jails), I found 8 different versions of that file. I’m sure most of these are very subtle changes.

I started by going back to the original file (https://cgit.freebsd.org/src/plain/usr.sbin/newsyslog/newsyslog.conf?h=releng/15.0) and comparing. On some hosts, lines had disappeared, presumably unintentionally omitted during the manual merge process during an upgrade. After some work on spaces vs tabs, a different value in the size column, and some owner:group issues, I had what I called my standard newsyslog.conf file. Then I added <compression> none to the top of the file.

I copied that file to several hosts and waited for rotation to proceed naturally.

Here’s an example, from dev.freshports.org:

[13:19 dev-nginx01 dvl ~] % ls -l /etc/newsyslog.conf    
-rw-r-----  1 root wheel 1744 2026.05.09 13:34 /etc/newsyslog.conf
[13:19 dev-nginx01 dvl ~] % ls -l /var/log/auth.log*
-rw-r-----  1 root logcheck     91939 2026.05.10 13:18 /var/log/auth.log
-rw-r-----  1 root logcheck    103518 2026.05.10 08:00 /var/log/auth.log.0
-rw-r-----  1 root logcheck    103476 2026.05.10 02:00 /var/log/auth.log.1
-rw-r-----  1 root logcheck    103521 2026.05.09 20:00 /var/log/auth.log.2
-rw-r-----  1 root logcheck 238717891 2026.05.09 14:00 /var/log/auth.log.3
-rw-r-----  1 root logcheck      4437 2024.06.28 19:00 /var/log/auth.log.4.bz2
-rw-r-----  1 root logcheck      4505 2024.06.28 10:00 /var/log/auth.log.5.bz2
-rw-r-----  1 root logcheck      4711 2024.06.28 01:00 /var/log/auth.log.6.bz2

That’s a huge .3 log file.. oh I see now, I wasn’t rotating that file for nearly two years. I’m sure that was a missing entry from the configuration file, and recently fixed.

The points being:

the log files are not compressed
the new directive is working as expected

The file I’m using

This is the file I’m using on that host:

[13:20 dev-nginx01 dvl ~] % cat /etc/newsyslog.conf
<compress> none

# configuration file for newsyslog
#
# Entries which do not specify the '/pid_file' field will cause the
# syslogd process to be signalled when that log file is rotated.  This
# action is only appropriate for log files which are written to by the
# syslogd process (ie, files listed in /etc/syslog.conf).  If there
# is no process which needs to be signalled when a given log file is
# rotated, then the entry for that file should include the 'N' flag.
#
# Note: some sites will want to select more restrictive protections than the
# defaults.  In particular, it may be desirable to switch many of the 644
# entries to 640 or 600.  For example, some sites will consider the
# contents of maillog, messages, and lpd-errs to be confidential.  In the
# future, these defaults may change to more conservative ones.
#
# logfilename          [owner:group]    mode count size when  flags [/pid_file] [sig_num]
/var/log/all.log			600  7	   *	@T00  J
/var/log/auth.log	root:logcheck	640  7     100  @0101T JC
/var/log/console.log			600  5	   1000	*     J
/var/log/cron				600  3	   1000	*     JC
/var/log/daemon.log			644  5	   1000	@0101T JC
/var/log/daily.log			640  7	   *	@T00  JN
/var/log/debug.log			600  7	   1000 *     JC
/var/log/devd.log			644  3	   1000	*     JC
/var/log/init.log			644  3	   1000	*     J
/var/log/kerberos.log			600  7	   1000	*     J
/var/log/maillog	root:logcheck	640  7     *    @T00   JC
/var/log/messages			644  5	   1000	@0101T JC
/var/log/monthly.log			640  12	   *	$M1D0 JN
/var/log/security			600  10	   1000	*     JC
/var/log/utx.log			644  3	   *	@01T05 B
/var/log/weekly.log			640  5	   *	$W6D0 JN

<include> /etc/newsyslog.conf.d/[!.]*.conf
<include> /usr/local/etc/newsyslog.conf.d/[!.]*.conf

For comparison, this is a diff against the original file from FreeBSD 15.0.

The changes are:

added the compression directive
The auth.log owner:group specifications are different and size (size will probably be updated to match 15.0)
the maillog owner:group specifications are different

In short, I’ve added compress and some chown stuff.

[13:23 dev-nginx01 dvl ~] % diff -ruN ~/newsyslog.conf.from.15.0 /etc/newsyslog.conf 
--- /usr/home/dvl/newsyslog.conf.from.15.0	2026-05-10 13:24:38.106872000 +0000
+++ /etc/newsyslog.conf	2026-05-09 13:34:35.022623000 +0000
@@ -1,3 +1,5 @@
+ none
+
 # configuration file for newsyslog
 #
 # Entries which do not specify the '/pid_file' field will cause the
@@ -15,7 +17,7 @@
 #
 # logfilename          [owner:group]    mode count size when  flags [/pid_file] [sig_num]
 /var/log/all.log			600  7	   *	@T00  J
-/var/log/auth.log			600  7	   1000 @0101T JC
+/var/log/auth.log	root:logcheck	640  7     100  @0101T JC
 /var/log/console.log			600  5	   1000	*     J
 /var/log/cron				600  3	   1000	*     JC
 /var/log/daemon.log			644  5	   1000	@0101T JC
@@ -24,7 +26,7 @@
 /var/log/devd.log			644  3	   1000	*     JC
 /var/log/init.log			644  3	   1000	*     J
 /var/log/kerberos.log			600  7	   1000	*     J
-/var/log/maillog			640  7	   *	@T00  JC
+/var/log/maillog	root:logcheck	640  7     *    @T00   JC
 /var/log/messages			644  5	   1000	@0101T JC
 /var/log/monthly.log			640  12	   *	$M1D0 JN
 /var/log/security			600  10	   1000	*     JC

What’s left for me to do

I will roll this out to all my hosts/jails soon. It is implemented on many of them now.

2026-05-08 21:30:00 UTC

On 1 April 2025 we stopped heating the house with natural gas. The installation was described while it was still fresh in Going fully electric : two Panasonic multi-split air-air heat pump systems, seven indoor units, and a heat-pump boiler for warm water.

One year later the interesting question is no longer whether the house can be heated. It can. The interesting question is where the energy moved to, and how visible that move is in the numbers.

The yearly view

For the first full year we consumed 10.5 MWh of electricity. That includes everything: household electricity, cooking, warm water, space heating and charging the car. The original projection was 10-12 MWh/year, so the result is right inside the expected range.

Bar chart titled “Electricity usage” comparing two yearly periods of household electricity consumption. Darker colored bars represent April 2025 through March 2026. Lighter translucent bars behind them represent the previous year, April 2024 through March 2025. The vertical axis ranges from about -1,000 to 2,000 kWh.

Each month contains stacked sections above and below zero. Blue sections above zero represent the largest share of electricity usage. Orange sections above zero are smaller supporting values. Purple sections extend below zero and represent exported or offset energy.

From spring through summer, both years show similar electricity use, with positive usage around 500 to 650 kWh and negative values around -600 to -750 kWh. Starting in autumn, the darker 2025-2026 bars rise sharply above the lighter previous-year bars. Usage peaks in winter, reaching about 1,500 kWh in January 2026, compared with roughly 500 kWh in the previous winter. The largest increases occur from November through February.

The comparison reflects a major heating-system change. During 2024-2025, the home used gas heating, which is not included in the electricity figures. During 2025-2026, gas heating was removed and replaced with an air-to-air heat pump, causing winter electricity consumption to rise substantially. A badge in the upper right shows a cumulative annual electricity usage of “+10,526.18 kWh.”

The important shape in this diagram is the winter step. Spring and summer still look like the previous year. From autumn onward the gas boiler is gone from the energy accounting, and the heating load appears as electricity.

January 2026 is the peak month with about 1.5 MWh. That sounds large when compared to old household electricity usage, but it is now also carrying the heat load that previously appeared on the gas meter.

Solar still helps, but at the wrong time

The solar roof produced 7.8 MWh over the same period. With net metering still active, that can be put against the 10.5 MWh consumption, leaving a net yearly electricity consumption of about 2.7 MWh. At current pricing that is around 700 EUR for living, cooking, heating and driving.

Bar chart titled “Solar production” comparing monthly solar energy generation between two yearly periods. Darker orange bars represent April 2025 through April 2026. Lighter translucent orange bars represent the previous year, with available historical data beginning in September 2024. The vertical axis ranges from 0 to about 1,200 kWh.

Solar production in the 2025-2026 period starts high in spring and summer, reaching just above 1,000 kWh in May and June, then gradually declines through autumn. Production falls to around 600 kWh in September, about 250 kWh in October, and reaches its lowest levels during winter, with roughly 100 to 150 kWh per month between November and January. Output rises again toward spring, reaching about 630 kWh in March and around 930 kWh in April.

The lighter comparison bars show that earlier-year data is only available from September 2024 onward. Compared with the previous year, the newer period produced somewhat more solar energy in September through January, while March production was lower. April production was nearly identical between both years, at just under 950 kWh. A badge in the upper right shows a cumulative solar production total of “7,833.36 kWh.”

The problem is not the yearly total. The problem is timing.

Solar production is strongest in May and June. Heating demand is strongest in December and January. The annual balance is good because the Dutch net-metering scheme still hides this mismatch. That is also why the result changes when net metering ends. At that point the house needs more local buffering, and the next obvious component is a battery.

Dashboard titled “Energy distribution” showing how electricity moves between solar generation, the electrical grid, and home consumption. A central flow diagram connects three circular nodes labeled Solar, Grid, and Home. The Solar node at the top shows 7.83 MWh generated. The Home node on the right shows 10.5 MWh consumed. The Grid node on the left shows two values: about 7.67 MWh imported from the grid and 4.98 MWh exported back to the grid. Colored lines between the nodes indicate energy flow directions and amounts.

Below the diagram are three gauge-style indicators. The first gauge shows “Net imported from the grid” with a value of 2,692.82 kWh. The second gauge shows “Self-consumed solar energy” at 36%, meaning just over one-third of solar production was used directly in the home. The third gauge shows “Self-sufficiency” at 27%, indicating about one-quarter of the home’s electricity demand was covered by solar generation rather than grid imports.

The energy distribution diagram is the clearest argument for the battery. The house imported 7.67 MWh and exported 4.98 MWh. The net import is only 2.69 MWh, but the gross traffic is large. Only 36% of solar production was self-consumed directly, and self-sufficiency was 27%.

That is not a failure of the heat pumps. It is a storage problem. Without a buffer, the house exports midday solar and imports evening, night and winter electricity.

Where the electricity went

The device view shows the heating system directly. The car existed in the previous year as well. The new loads are the two air-air heat pump systems and the heat-pump boiler.

Stacked bar chart titled “Individual devices detail usage” comparing monthly electricity consumption by device across two yearly periods. Darker colored stacked bars represent April 2025 through April 2026. Lighter translucent bars behind them represent the previous year, April 2024 through March 2025. The vertical axis ranges from about 0 to 1,800 kWh.

Many household devices are listed in the legend, but the dominant contributors are the Airco Südseite, Airco Nordseite, Boiler, and Charge Point categories. During spring and summer, total monthly electricity usage remains moderate, generally between 500 and 650 kWh in both years. Beginning in autumn 2025, consumption rises sharply in the darker bars. Usage peaks during winter, reaching roughly 1,500 kWh in January 2026.

Most of the winter increase comes from the Airco Südseite and Airco Nordseite systems, which represent air-to-air heat pumps used for heating, along with the Boiler, a heat-pump water heater. The Charge Point category also contributes noticeably, especially during higher-consumption months.

Compared with the previous year, winter electricity demand is dramatically higher because the earlier 2024-2025 period relied on gas heating, which is not included in the electricity data.

The lighter bars therefore remain much lower during winter months.

Over the year the heating-related electrical consumption was approximately:

Airco Südseite: 3,446 kWh
Airco Nordseite: about 500 kWh
Boiler: about 920 kWh

The charge point used about 1,950 kWh. That is visible and relevant, but it is not part of the heating conversion.

Double-ring circular chart showing household electricity consumption by device category for April 2025 through April 2026. The outer ring represents the 2025-2026 period. The lighter inner ring represents the previous year for comparison. The center of the chart displays a total electricity usage of 10,526.18 kWh.

The largest segment in the outer ring is Airco Südseite, representing one of the air-to-air heat pumps used for heating. The second largest segment is the Charge Point for electric vehicle charging. Together, these two categories account for roughly half of all electricity consumption.

Additional large segments include Airco Nordseite, the second heating heat pump, the Boiler, which is a heat-pump water heater, and Untracked consumption. Together, these categories contribute roughly another quarter of total usage. A Server category is also large enough to stand out as a named segment.

Many smaller categories form narrow slices around the remainder of the chart, representing ordinary household devices and appliances. Compared with the lighter inner ring from the previous year, the outer ring shows substantially greater heating-related electricity consumption because the household switched from gas heating to electric heat pumps during the 2025-2026 period.

Space heating and warm water therefore used:

3,446 + 500 + 920 = 4,866 kWh/year

Before the change, the house used about 1,100 m³ of gas per year. Using the usual rough conversion of 10 kWh/m³, that is about 11 MWh/year of thermal input from gas.

11,000 kWh/year / 156 m² = 70.5 kWh/(m² year)

For the house, that was already a decent number. It is around the German class B boundary range, and in the broad Dutch label bands it lands in the good part of the scale.

The important result is the replacement:

11,000 kWh gas input / 4,866 kWh electricity = 2.26

As a whole-system seasonal performance factor, 2.26 is not spectacular for the theoretical heat pump, but it is the actually measured system including behavior, winter conditions, warm water, defrosting, distribution losses and auxiliary heating. It is also enough to eliminate gas consumption while keeping yearly costs under control.

The weakest part is the warm-water heat pump. It is less efficient than I want, especially in cold weather when it falls back to the heating element. The air-air heat pumps are doing the heavy lifting.

Cost in the winter peak

The useful cost comparison is January, because January is where the conversion is most visible.

Dashboard comparing household energy costs between June 2025 through May 2026 and the previous yearly period. A grouped bar chart on the left shows monthly cost differences in euros. Dark blue bars represent the earlier year, while lighter blue bars represent the current year. Positive values indicate higher winter energy costs, while several summer months show small negative values.

Costs rise sharply during winter in both years, peaking around January. The current year shows noticeably lower winter peaks than the previous year, despite much higher electricity consumption caused by switching from gas heating to electric heat pumps.

A highlighted comparison panel on the right focuses on January. January 2025 total energy costs were EUR 493.73, consisting of EUR 86.56 for electricity usage of 386 kWh and EUR 407.17 for gas usage of 280 cubic meters. January 2026 total costs were lower at EUR 347.09, consisting of EUR 316.31 for electricity usage of 1,412 kWh and EUR 30.78 for gas usage of 0 cubic meters.

The overall monthly cost difference is shown as -EUR 146.64, indicating the newer heating setup reduced total winter energy expenses despite substantially higher electricity demand.

The chart period label at the bottom reads “jun 2025 - mei 2026,” covering June 2025 through May 2026.

January 2025 was the gas-heated reference month: 386 kWh electricity, 280 m³ gas, total cost EUR 493.73.

January 2026 was the electric-heated month: 1,412 kWh electricity, no gas use, total cost EUR 347.09.

So the electricity bill became large, as expected, but the gas bill disappeared. The winter peak month was EUR 146.64 cheaper.

The gas meter is the point

The gas chart is boring in the best possible way.

Bar chart comparing annual household gas consumption across multiple yearly periods. The vertical axis is measured in cubic meters, ranging from 0 to slightly above 2,000 m³. Three yearly periods are shown along the horizontal axis.

The first period, June 2023 through June 2024, shows gas usage slightly above 1,100 m³. The second period, June 2024 through June 2025, is highlighted and shows gas consumption of 1,044 m³. A detail panel on the right confirms this value and notes that the latest meter reading was taken on 07 May 2026.

The third period, June 2025 through May 2026, shows effectively zero gas consumption, with no visible bar. This reflects the household transition away from gas heating during the 2025-2026 period after replacing the gas heating system with electric air-to-air heat pumps and a heat-pump water heater.

The overall comparison demonstrates a complete reduction in annual gas usage after the heating-system conversion.

The previous years were around 1,100 m³/year. The first complete post-conversion period is effectively zero.

The electricity grid chart shows the other side of the same change.

Bar chart comparing annual household electricity usage and grid feed-in across three yearly periods from June 2023 through May 2026. The vertical axis is measured in kilowatt-hours and ranges from about -6,000 to 8,000 kWh. Blue bars above zero represent electricity imported from the grid and consumed in the home. Yellow bars below zero represent electricity exported back to the grid from solar production.

The first two yearly periods, June 2023 through June 2024 and June 2024 through June 2025, show similar patterns. Electricity consumption is around 4,000 to 4,500 kWh per year, while grid feed-in is slightly larger in magnitude, around 4,200 to 4,600 kWh exported.

The highlighted third period, June 2025 through May 2026, shows a major increase in electricity consumption. The right-side detail panel lists 7,153 kWh imported from the grid and 3,488 kWh exported back to the grid, resulting in a net annual electricity usage of 3,665 kWh. The latest meter reading was taken on 07 May 2026.

Compared with earlier years, electricity imports increased substantially because the household replaced gas heating with electric air-to-air heat pumps and a heat-pump water heater. At the same time, solar production continued to offset part of the increased demand through grid feed-in.

Imported electricity increased substantially. That is not surprising; it is the intended substitution. The household moved energy demand from the gas network to the electricity network.

From a consumption-shift point of view, the result is clean:

Gas went from about 1,100 m³/year to zero.
Heating and warm water moved to about 4.9 MWh/year of electricity.
Total electricity consumption landed at 10.5 MWh/year including the car.
Solar produced 7.8 MWh/year.
Net electricity import was only 2.7 MWh/year under net metering.
Gross import and export remain too high, so local storage is the next optimization.

Conclusion

The conversion worked. The house is gas-free, winter comfort is fine, and the yearly electricity consumption matches the original projection.

The main lesson is that electrification does not make the energy demand disappear. It moves it. That makes the demand measurable in a different place, and it makes timing more important. The heat pumps solved the gas problem. The next problem is matching more of the solar roof to the house load before the electricity reaches the grid.

Sources: first Mastodon post , second Mastodon post , and Going fully electric .

2026-05-08 00:00:00 UTC

The second BETA build for the FreeBSD 15.1 release cycle is now available. ISO images for the amd64, armv7, aarch64, powerpc64, powerpc64le, and riscv64 architectures are FreeBSD mirror sites.

2026-05-04 09:46:50 UTC

The Valuable News weekly series is dedicated to provide summary about news, articles and other interesting stuff mostly but not always related to the UNIX/BSD/Linux systems. Whenever I stumble upon something worth mentioning on the Internet I just put it here.

Today the amount information that we get using various information streams is at massive overload. Thus one needs to focus only on what is important without the need to grep(1) the Internet everyday. Hence the idea of providing such information ‘bulk’ as I already do that grep(1).

The Usual Suspects section at the end is permanent and have links to other sites with interesting UNIX/BSD/Linux news.

Past releases are available at the dedicated NEWS page.

UNIX

Ansible Native Quadlets: Deploying Mastodon Greeter Bot with containers.podman.
https://blog.hofstede.it/ansible-native-quadlets-deploying-a-mastodon-greeter-bot-with-containerspodman/

Joining DN42: MikroTik Border – Three WireGuard Peerings – FreeBSD Jail in Hobbyist Internet.
https://blog.hofstede.it/joining-dn42-a-mikrotik-border-three-wireguard-peerings-and-a-freebsd-jail-in-the-hobbyist-internet/

FreeBSD Git Weekly: 2026-04-20 to 2026-04-26.
https://freebsd-git-weekly.tarsnap.net/2026-04-20.html

Sudo and Heartbleed and Lessons We Still Have Not Learned.
https://fossforce.com/2026/02/sudo-heartbleed-and-the-lessons-we-still-havent-learned/

OpenSSH Flaw Allowing Full Root Shell Access Lurked for 15 Years.
https://securityweek.com/openssh-flaw-allowing-full-root-shell-access-lurked-for-15-years/

Future of FreeBSD Kernel LLDB Plugin.
https://minsoo.io/future-of-the-freebsd-kernel-lldb-plugin/

Problems with FreeBSD ULE Scheduler.
https://minsoo.io/problems-with-the-ule-scheduler/

First Unix Port – Richard Miller.
http://bitsavers.informatik.uni-stuttgart.de/bits/Interdata/32bit/unix/univWollongong_v6/miller.pdf

When Resizing gmirror(8) Gives You a Hard Time.
https://oshogbo.com/blog/85

Apple Wants to Kill Your Time Capsule but They Run NetBSD So They Can Not.
https://osnews.com/story/144845/apple-wants-to-kill-your-time-capsule-but-they-run-netbsd-so-they-cant/

TimeCapsuleSMB Hacking Apple Time Capsule to Run Modern Samba.
https://github.com/jamesyc/TimeCapsuleSMB

Servo Browser Engine Seeing Progress on FreeBSD Support.
https://phoronix.com/news/Servo-On-FreeBSD

New XLibre X11 XServer 25.0.0.23 and 25.1.5 Versions.
https://bsky.app/profile/xlibredev.bsky.social/post/3mkqirdkmk22r

GhostBSD Now Supports GELI Encryption in Installer.
https://github.com/ghostbsd/issues/issues/68#issuecomment-4357392352

2026/04 Survey: FreeBSD in Enterprise.
https://docs.google.com/forms/d/e/1FAIpQLSeLd8SP6qjwxkukeBVLKA-V0eBNo92SCoGH_p0idCtCD-GGog/viewform

NetBSD Based smolBSD Now Boots in Proxmox.
https://bsky.app/profile/imil.bsd.cafe.ap.brid.gy/post/3mkrkxwre6nf2

XLibre Matrix Space and Discord Server Changes.
https://bsky.app/profile/xlibredev.bsky.social/post/3mkrb6qhovs2s

FreeBSD 15.1-BETA1 Now Available.
https://lists.freebsd.org/archives/freebsd-stable/2026-May/004035.html

FreeBSD on 2026 Google Summer of Code.
https://summerofcode.withgoogle.com/programs/2026/organizations/the-freebsd-project

Copy Fail is Straight Line Logic Flaw that Roots Every Linux Distribution Shipped Since 2017.
https://copy.fail/

Upgrade PHP 8.x on FreeBSD.
https://gaelanlloyd.com/blog/how-to-upgrade-php-80-to-82-on-freebsd/

How to Rebuild ZFS Pool.
https://gaelanlloyd.com/blog/how-to-rebuild-a-zfs-pool/

Fix Weird Lag Issues with Intel Graphics on FreeBSD 14.3 with i915 Driver.
https://gaelanlloyd.com/blog/fix-freebsd-lag-issues-intel-i915/

Upgrade MariaDB from 10.6 LTS to 11.8 LTS on FreeBSD.
https://gaelanlloyd.com/blog/upgrade-mariadb-106-to-118/

Create IoT VLAN with OPNsense and TP-Link Omada and IPv6 Prefix Delegation.
https://gaelanlloyd.com/blog/iot-vlan-opnsense-omada-ipv6/

Meet Good Boy Zero Dependency FreeBSD Bootstrapper.
https://gaelanlloyd.com/blog/good-boy-zero-dependency-freebsd-bootstrapper/

Update FreeBSD ZFS EFI and Legacy Boot Code on GPT Devices with zfs-update-boot.sh Tool.
https://github.com/morganwdavis/zfs-update-boot

Getting Started on OpenBSD.
https://github.com/outpaddling/desktop-installer/blob/master/OpenBSD/getting-started.md

OpenBSD Stories – SPARC Frame Buffers.
http://miod.online.fr/software/openbsd/stories/sparcfb.html

Fast Dedup Economics when Dedup Beats Buying New Disks.
https://klarasystems.com/articles/fast-dedup-economics-when-deduplication-beats-buying-new-disks/

Google Summer of Code 2025 Reports: Using bubblewrap to Add Sandboxing to NetBSD.
https://blog.netbsd.org/tnf/entry/gsoc2025_bubblewrap_sandboxing

Google Summer of Code 2025: Mentor Summit in Munich/Germany Travel Notes.
https://blog.netbsd.org/tnf/entry/gsoc2025_mentor_summit

Welcome to Google Summer of Code 2026 Contributors of NetBSD.
https://blog.netbsd.org/tnf/entry/gsoc2026_welcome_contributors

UNIX/Audio/Video

FreeBSD Privilege Escalation Out of the Box with mdo(1) Tool.
https://youtube.com/watch?v=dA-TNsVG9IY

GTK2 Brought Back from the Dead.
https://x.com/LundukeJournal/status/2049512442594480436

Open Source Did Not Die – It Got Absorbed.
https://youtube.com/watch?v=8E6zawa9QhQ

Internet Has New Predator and It is Not Human.
https://youtube.com/watch?v=-rh55lKBXAQ

Nestopia on OpenIndiana (Bare Metal and NVIDIA GPU).
https://youtube.com/watch?v=o6maN9-mQ1Y

BSD Now 661: Break Up Big Tech.
https://www.bsdnow.tv/661

Hardware

Rise and Fall of SPARC: Why No One Misses It.
https://minsoo.io/the-rise-and-fall-of-sparc-why-no-one-misses-it/

Decade of AMD Ryzen: 10 Years of CPUs Tested.
https://techspot.com/article/3117-10-years-amd-flagship-cpus/

AMD Readies Full Open Source HDMI 2.1 Support for Linux.
https://techpowerup.com/348723/amd-readies-full-open-source-hdmi-2-1-support-for-linux

I Recreated Apple Lisa Computer Inside FPGA – LisaFPGA Project.
https://youtube.com/watch?v=8jNQDcpHc68

Life

Men are Not Afraid of Marriage – They are Afraid of Divorce.
https://youtube.com/watch?v=L84GzQe6-SA

Other

Chrome is Surveillance Platform. Here is Evidence.
https://substack.com/home/post/p-194499648

Kubernetes Reimplemented in Rust.
https://github.com/calfonso/rusternetes

Story of Fallout with Chris Avellone.
https://geeksguideshow.com/2026/04/29/ggg618-the-story-of-fallout/

Video Games in Books and Movies.
https://geeksguideshow.com/2015/08/14/ggg163-video-games-in-books-and-movies/

Firefox Free VPN Adds Server Location Choice – Coming to Android.
https://omgubuntu.co.uk/2026/04/firefox-free-vpn-select-server

Zeewolf AMIGA Retrospective: Desert Strike Meets Polygon Chaos.
https://generationamiga.com/2026/05/03/zeewolf-amiga-retrospective-desert-strike-meets-polygon-chaos/

Usual Suspects

BSD Weekly.
https://bsdweekly.com/

DiscoverBSD.
https://discoverbsd.com/

DragonFly BSD Digest.
https://dragonflydigest.com/

FreeBSD Patch Level Table.
https://bokut.in/freebsd-patch-level-table/

FreeBSD End of Life Date.
https://endoflife.date/freebsd

Phoronix BSD News Archives.
https://phoronix.com/linux/BSD

OpenBSD Journal.
https://undeadly.org/

Call for Testing.
https://callfortesting.org/

Call for Testing – Production Users Call.
https://youtube.com/@callfortesting/videos

BSD Now Weekly Podcast.
https://www.bsdnow.tv/

Nixers Newsletter.
https://newsletter.nixers.net/entries.php

BSD Cafe Journal.
https://journal.bsd.cafe/

DragonFly BSD Digest – Lazy Reading – In Other BSDs.
https://dragonflydigest.com

FreeBSD Git Weekly.
https://freebsd-git-weekly.tarsnap.net/

FreeBSD Meetings.
https://youtube.com/@freebsdmeetings

Sheridan Computers.
https://youtube.com/@sheridans/videos