FreeBSD in den letzten sieben Tagen: Zwischen 14.4-Realität, ZFS-Sorgen und kleinen pkg-Ideen

Wer bei FreeBSD auf den großen Trommelwirbel wartet, wartet oft lange. Das ist einer der Punkte, die ich an dem System gleichzeitig schätze und gelegentlich unerquicklich finde. Schätze, weil man nicht jeden zweiten Tag mit irgendeinem Marketingfeuerwerk belästigt wird. Unerquicklich, weil man sich die wirklich interessanten Entwicklungen oft aus Mailinglisten, Release Notes und Nebensätzen zusammensuchen muss.

Wenn man auf die letzten sieben Tage blickt, dann ergibt sich im Kern ein recht typisches Bild für FreeBSD: Nach außen ist es vergleichsweise ruhig, unter der Oberfläche wird aber an genau den Stellen diskutiert, an denen Betriebssysteme im Alltag entweder angenehm oder unerquicklich werden. Performance beim Bauen von Software, Stabilität und Speicherverhalten von ZFS sowie die Frage, wie sich pkg im PKGBASE-Umfeld sinnvoller bedienen lässt.

FreeBSD 14.4 ist weiterhin das beherrschende Thema

Die wichtigste offizielle Nachricht im betrachteten Zeitraum bleibt letztlich die Veröffentlichung von FreeBSD 14.4-RELEASE am 10. März. Das fällt zwar knapp aus dem Sieben-Tage-Fenster heraus, prägt aber die Diskussionen dieser Woche deutlich. Und das ist auch kein Wunder.

Zu den wichtigen Punkten von 14.4 gehören unter anderem:

  • OpenSSH 10.0p2
  • standardmäßig der hybride Post-Quantum-Algorithmus mlkem768x25519-sha256
  • OpenZFS 2.2.9
  • bessere cloud-init-/nuageinit-Kompatibilität
  • ein neues p9fs(4) für Dateisystem-Sharing zwischen Host und bhyve-Gästen
  • Verbesserungen bei den Manpages und deren Werkzeugen

Das ist insgesamt ein ordentliches Release. Keine Revolution, aber genau diese Sorte Version, die für FreeBSD eigentlich typisch ist: evolutionär, pragmatisch, mit Fokus auf sinnvolle Pflege statt auf Show.

Erwähnenswert ist auch die Widmung der Version an Ken Smith, der Ende letzten Jahres verstorben ist und als Release-Engineering-Leiter über viele Jahre hinweg eine wichtige Rolle bei FreeBSD gespielt hat. Solche Hinweise gehen in technischen Veröffentlichungen gerne unter, sind aber durchaus bedeutend, weil sie zeigen, dass hinter der ganzen Sache eben doch Menschen stehen und nicht nur Code.

Erste Rückmeldungen nach 14.4: Build-Zeiten sorgen für Unmut

Interessanter als die reine Release-Ankündigung waren in dieser Woche die Rückmeldungen aus der Praxis. Auf der Mailingliste wurde ein Fall beschrieben, bei dem sich nach dem Upgrade von 14.3 auf 14.4 die Build-Zeiten mit poudriere teils drastisch erhöht haben. Konkret war von teils doppelt so langen Zeiten die Rede.

Das ist kein kleines Detail. Für Leute, die Ports bauen, Pakete pflegen oder generell viel lokal kompilieren, ist das kein Schönheitsfehler, sondern schlicht Alltagsschmerz. Wenn ein Full Build plötzlich nicht mehr einen Tag, sondern zwei braucht, dann ist das keine Randnotiz mehr.

In der Diskussion wurde darauf verwiesen, dass hier vermutlich ein bereits bekanntes Performance-Problem hineinspielt und dass es dafür inzwischen einen Schalter gibt, um das frühere Verhalten wiederherzustellen. Das ist zunächst einmal die gute Nachricht. Die weniger gute Nachricht ist aber, dass solche Dinge überhaupt erst einmal wieder in der Praxis auffallen müssen und man sich die Informationen aus Threads und Commit-Hinweisen zusammensuchen darf.

Das ist bei FreeBSD leider nicht ganz unüblich: Die Technik ist oft solide, die Kommunikation darüber mitunter weniger komfortabel, als sie sein könnte.

ZFS bleibt hervorragend – und manchmal unerquicklich

Wirklich interessant wurde es bei einer Diskussion zu ZFS-Deadlocks und Memory-Accounting-Problemen auf NFS-Servern. Beschrieben wurde dort ein Verhalten, bei dem Maschinen trotz sehr viel freiem RAM unter Speicherdruck geraten, anfangen zu swapen und im schlimmsten Fall sogar im OOM-Kontext landen. Das ist schon deshalb unerquicklich, weil gerade große Speicher- und Storage-Systeme unter FreeBSD häufig genau mit dem Versprechen betrieben werden, dass ZFS dort besonders gut aufgehoben sei.

Der geschilderte Fall betraf Systeme mit sehr viel RAM, bei denen ARC-Speicher zwar als evictable erschien, das System aber dennoch in einen problematischen Zustand lief. Dazu kamen Hinweise auf blockierte Prozesse und Wartezustände rund um ARC- und dbuf-Mechanismen. Das ist natürlich erst einmal ein Einzelfall aus einer Mailingliste und keine allgemeingültige Aussage über alle 14.x-Installationen. Aber es ist genau die Sorte Signal, bei der Administratoren hellhörig werden sollten.

Denn solche Probleme sind im Alltag nicht deswegen unangenehm, weil sie spektakulär sind, sondern weil sie sich oft lange als „komisches Verhalten“ tarnen. Ein bisschen Swap hier, etwas Last dort, ein paar hängende Prozesse, und plötzlich steht ein System, das laut oberflächlicher Kennzahlen eigentlich gar nicht in Schwierigkeiten sein dürfte.

FreeBSD hat im Storage-Bereich nach wie vor sehr gute Argumente. Aber wenn solche Berichte auftauchen, dann sollte man sie ernst nehmen. Nicht hysterisch, aber ernsthaft.

Kleine pkg-Diskussion, aber durchaus mit praktischer Relevanz

Weniger dramatisch, aber praktisch nicht uninteressant war eine Diskussion um pkg und den Umgang mit PKGBASE. Konkret ging es um den Wunsch, Upgrades für Drittanbieter-Pakete und Base-System sauberer voneinander zu trennen.

Vorgeschlagen wurden zusätzliche Aliase wie:

  • pkg upgrade-packages
  • pkg upgrade-base

Die Idee dahinter ist simpel und vernünftig: Man möchte im Alltag nicht immer alles in einen Topf werfen, sondern bewusst entscheiden können, ob gerade nur Ports-Pakete oder nur das Base-System angefasst werden sollen.

Das ist nun keine Nachricht, bei der irgendjemand in Begeisterung ausbrechen müsste. Aber es ist ein gutes Beispiel dafür, wie sich FreeBSD verändert: oft in kleinen, unaufgeregten, aber alltagstauglichen Schritten. Gerade solche Verbesserungen machen am Ende häufig mehr Unterschied als irgendein groß angekündigtes Großprojekt.

Zugleich zeigt die Diskussion aber auch ein typisches Problem: Benennung und Verständlichkeit sind eben nicht nebensächlich. Wenn man „packages“ sagt, obwohl technisch betrachtet am Ende alles Pakete sind, dann ist die Verwirrung fast schon eingebaut. Das ist kein Drama, aber auch kein Detail, das man völlig ignorieren sollte.

Was bleibt also von dieser Woche?

Wenn man die letzten sieben Tage rund um FreeBSD zusammenfasst, dann ergibt sich aus meiner Sicht vor allem dieses Bild:

FreeBSD wirkt nach außen oft ruhig, fast schon zu ruhig. Unter dieser ruhigen Oberfläche zeigen sich aber genau die Themen, die für Anwender und Administratoren wirklich relevant sind:

  • Wie gut läuft ein frisches Release im Alltag?
  • Gibt es Performance-Regressions?
  • Ist ZFS unter realer Last so stabil, wie man es erwartet?
  • Werden Werkzeuge wie pkg im täglichen Betrieb besser bedienbar?

Das ist am Ende vielleicht auch das eigentlich Sympathische an FreeBSD. Die interessanten Nachrichten sind dort selten bloß „Neu! Größer! Schneller!“. Oft sind es eher Hinweise darauf, wo die Praxis gegen die Theorie arbeitet. Und genau dort entscheidet sich, ob ein System auf Dauer Vertrauen verdient.

14.4-RELEASE ist ohne Frage die wichtigste jüngere Entwicklung. Die anschließenden Diskussionen zu Build-Performance und ZFS zeigen aber auch, dass ein Release eben nicht mit der Veröffentlichung fertig ist. Es beginnt dann erst die Phase, in der sich herausstellt, wie gut die Dinge außerhalb von Release Notes und Ankündigungen wirklich funktionieren.

Und genau diese Phase war in den letzten sieben Tagen die eigentlich interessante.

Quellen

  • FreeBSD News Flash: https://www.freebsd.org/news/newsflash/
  • FreeBSD News RSS Feed: https://www.freebsd.org/news/feed.xml
  • FreeBSD 14.4-RELEASE Announcement: https://lists.freebsd.org/archives/freebsd-announce/2026-March/000228.html
  • FreeBSD-announce Archiv März 2026: https://lists.freebsd.org/archives/freebsd-announce/2026-March/date.html
  • Thread: „Huge build times increase after updating from 14.3 to 14.4“: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003900.html
  • Antwort von Olivier Certner zum bekannten Performance-Problem: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003901.html
  • Nachfrage von Philip Paeps zu den Package-Buildern: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003907.html
  • Thread: „ZFS deadlocks/memory accounting issues“: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003910.html
  • Antwort von Alan Somers im ZFS-Thread: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003911.html
  • Thread/Proposal zu pkg-Aliases: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003942.html
  • Rückfrage zur Benennung der pkg-Aliases: https://lists.freebsd.org/archives/freebsd-stable/2026-March/003944.html
  • FreeBSD-stable Archiv März 2026: https://lists.freebsd.org/archives/freebsd-stable/2026-March/date.html

CENMATE Festplattengehäuse als Erweiterung für meinen Server

Mein Hauptserver, den ich mit FreeBSD (15) betreibe, hat acht Bays. Die sind bereits voller SAS- bzw. Nearline-SAS-Festplatten. Ich hatte aber noch drei 4TB große SSDs, die ich gerne für Virtualisierung nutzen wollte, da mir die NL-Platten zu langsam sind.

Nach langem Überlegen und Herumprobieren habe ich dann die externen Gehäuse von CENMATE entdeckt. Ich wollte mir zuerst das mit 10 Bays kaufen, doch das gab es im ganzen Internet nicht. Dann las ich, dass viele andere Menschen Probleme mit den Geräten an Desktop-Systemen haben, da Festplatten immer wieder „verschwinden“ würden. Also dachte ich mir, bevor ich so viel Geld ausgebe, hole ich mir das Gerät mit drei Bays für gut 100 Euro und probiere einmal herum. Ich hatte mir bereits vorher extra eine zusätzliche USB-3-PCIe-Karte gekauft und eingebaut, die gut funktioniert.

CENMATE Festplattengehäuse mit drei Bays.
CENMATE Festplattengehäuse mit drei Bays.

Ich habe das Gerät jetzt seit zwei Wochen und bisher funktioniert es super. Ich habe meine drei SSDs mit 2,5″-auf-3,5″-Adaptern eingesteckt und fahre ein verschlüsseltes RAIDz darauf (ZFS + RAID-5). Die Performance ist in Ordnung, könnte aber besser sein. Richtige Messwerte habe ich nicht, ich kann aber gleichzeitig etliche VMs (getestet mit zehn, davon zwei mit Windows) drauf laufen lassen und es lässt sich gut damit arbeiten. Einen einfachen Schreibtest habe ich mit dd gemacht, da kam ich auf gut 220MB/s. Wäre ausbaubar, denn die Platten schaffen mehr, aber vielleicht schaue ich mir das Problem irgendwann noch genauer an. Bisher bin ich auch so erst einmal zufrieden, da alles stabil läuft.

Warum ich FreeBSD statt Linux auf Servern einsetze

Wenn es um Server-Betriebssysteme geht, denken viele zuerst an Linux. Das ist nachvollziehbar: Linux ist weit verbreitet, hat eine große Community und wird von vielen Unternehmen eingesetzt.

Trotzdem arbeite ich seit vielen Jahren bevorzugt mit FreeBSD. Angefangen habe ich damit ungefähr zur Zeit von FreeBSD 4 – und seitdem ist es für viele meiner Server die erste Wahl geblieben.

Warum eigentlich?

Die kurze Antwort: FreeBSD wirkt für mich wie ein durchdachtes Gesamtsystem, während sich viele Linux-Installationen eher wie eine Sammlung einzelner Komponenten anfühlen.

Die längere Antwort folgt hier.

Ein Betriebssystem statt vieler Einzelteile

Ein grundlegender Unterschied zwischen Linux und FreeBSD ist die Struktur des Systems.

Bei Linux besteht eine Distribution meist aus vielen Komponenten verschiedener Projekte:

  • Kernel
  • GNU-Tools
  • Init-System
  • Paketmanager
  • zusätzliche Werkzeuge

Das funktioniert gut, führt aber manchmal zu Inkonsistenzen.

FreeBSD verfolgt einen anderen Ansatz: Das Basissystem wird als einheitliches Betriebssystem entwickelt und gepflegt.

Kernel, Systemwerkzeuge und viele zentrale Komponenten gehören zusammen. Dadurch wirkt das System sehr konsistent – sowohl in der Konfiguration als auch in der Dokumentation.

Gerade bei langfristig betriebenen Servern ist das ein großer Vorteil.

Vorhersagbarkeit im Betrieb

Ein wichtiger Punkt für mich ist Vorhersagbarkeit.

Server sollen möglichst langweilig sein: Sie sollen stabil laufen, sich nachvollziehbar konfigurieren lassen und keine Überraschungen produzieren. Ähnlich wie ein Flugzeug.

Viele meiner FreeBSD-Systeme laufen über lange Zeiträume sehr unauffällig. Updates sind in der Regel gut planbar, und das Verhalten des Systems bleibt konsistent.

Das ist besonders dann wertvoll, wenn ein System über Jahre betrieben wird.

ZFS als integraler Bestandteil

Ein weiterer großer Vorteil ist die enge Integration von ZFS.

ZFS bietet Funktionen, die im Alltag enorm hilfreich sind:

  • Snapshots
  • einfache Backups
  • Datenintegrität
  • flexible Storage-Strukturen

Gerade bei Servern mit vielen Daten oder virtuellen Systemen macht das einen großen Unterschied.

Viele meiner Systeme nutzen ZFS als Grundlage für Storage und Backups. Das ermöglicht sehr robuste und wartbare Setups.

Jails: leichtgewichtige Isolation

FreeBSD bietet mit Jails eine sehr elegante Möglichkeit, Dienste voneinander zu isolieren.

Im Gegensatz zu vollständigen virtuellen Maschinen sind Jails sehr leichtgewichtig. Dienste lassen sich getrennt betreiben, ohne dass jede Anwendung ein eigenes Betriebssystem benötigt.

Das hat mehrere Vorteile:

  • geringerer Ressourcenverbrauch
  • klare Trennung von Diensten
  • einfache Verwaltung

Für viele Server-Szenarien ist das ein sehr praktischer Ansatz.

Gute Werkzeuge und klare Struktur

Ein weiterer Punkt, den ich an FreeBSD schätze, ist die klare Struktur des Systems.

Dazu gehören beispielsweise:

  • das klassische rc-System zur Dienstverwaltung
  • ein konsistentes Konfigurationsmodell
  • das Paketmanagement mit pkg
  • sehr gute Manpages und Dokumentation

Gerade wenn man Systeme länger betreibt oder später wieder nachvollziehen muss, was einmal eingerichtet wurde, zahlt sich diese Klarheit aus.

Praxis statt Theorie

Ich nutze FreeBSD nicht nur gelegentlich, sondern betreibe damit seit vielen Jahren verschiedene Systeme.

Darunter Server mit:

  • Webdiensten
  • Datenbanken
  • DNS, DHCP und NTP
  • NFS, Samba, Apple-Talk (netatalk), iSCSI
  • verschiedenen Anwendungen in Jails
  • Bhyve als Virtualisierer, um auch Linux-Instanzen laufen zu lassen

Teilweise auch mit komplexeren Storage-Konfigurationen und mehreren virtuellen Systemen.

Diese Erfahrungen aus dem Alltag sind der Hauptgrund, warum ich FreeBSD weiterhin gerne einsetze.

Fazit

Linux ist ein sehr gutes Betriebssystem und für viele Szenarien eine sinnvolle Wahl.

Für meine eigenen Server greife ich trotzdem häufig zu FreeBSD.

Die Gründe dafür sind vor allem:

  • ein konsistentes Gesamtsystem
  • stabile und vorhersehbare Server
  • integrierte Technologien wie ZFS
  • elegante Isolation mit Jails
  • klare Struktur und gute Dokumentation

Gerade für langfristig betriebene Infrastruktur hat sich FreeBSD für mich immer wieder als sehr zuverlässige Plattform erwiesen.

FreeBSD auf einem Lenovo T480

Ich, der derzeit fast ausschließlich seit sechs Jahren MacBooks nutzt und relativ glücklich mit seinem M5-Gerät ist, wollte schon immer mal FreeBSD auf einem Notebook ausprobieren. Ein gut kompatibles Gerät hatte ich bisher nie finden können, doch tauchte dann irgendwann ein Artikel auf, der meinte, dass das Lenovo T480 gut mit FreeBSD funktioniert. Also habe ich mir eins bei eBay für 170 Euro geklickt. 14″, i5, 256GB SSD, 16GB RAM. Nichts tolles, aber zum herumspielen reicht es, dachte ich.

Ich habe eine kurze Weile OpenBSD auf einem Eee-PC vor vielen Jahren genutzt und das Ding sogar mal für eine Weile mit ins Krankenhaus genommen. Es funktionierte echt gut, sogar Suspend und Resume. Leider ging es dann kaputt.

Bild vom Lenovo T480 mit FreeBSD und KDE

Das Gerät kam an, Windows 11 war installiert. Ich habe es direkt platt gemacht und FreeBSD 15 amd64 von einem USB-Stick installiert. Letztlich eine Standardinstallation. Was funktioniert alles?

  • Grafikkarte funktioniert, Monitor wird mit voller Auflösung (naja, ist nur Full-HD) unterstützt
  • Tastatur geht
  • Trackpad geht, auch mit Scrolling
  • Trackpoint geht auch
  • Der SD-Card-Reader funktioniert
  • WLAN- und Ethernet funktionieren
  • Beide Akkus (interner und externer) werden erkannt
  • Tonausgabe geht
  • USB-Anschlüsse funktionieren
  • Suspend und Resume funktionieren
  • Bluetooth

Was ich noch nicht ausprobiert habe, sind:

  • Smart-Card-Reader
  • HDMI-Anschluss

Installiert habe ich Xorg, KDE und ein wenig Software. Das Gerät funktioniert recht gut und für jemanden, der unbedingt FreeBSD auf einem Notebook haben möchte, ist es nicht schlecht, wenn man denn mit den ganzen Nachteilen leben kann (langsamer Prozessor, schlechte Grafikkarte, schlechter Bildschirm, mittelmäßiges Trackpad, billiges Plastikgehäuse).

Bhyve: can’t find ‚/boot/entropy‘ und can’t find ‚/etc/hostid‘ beim Virtualisieren von FreeBSD

Ich hatte jetzt auf älteren MicroServern von HP das Problem, dass FreeBSD nach dem Bootloader in Bhyve stoppte:

  _____              ____ ____  ____     ___           _        _ _
 |  ___| __ ___  ___| __ ) ___||  _ \   |_ _|_ __  ___| |_ __ _| | | ___ _ __
 | |_ | '__/ _ \/ _ \  _ \___ \| | | |   | || '_ \/ __| __/ _` | | |/ _ \ '__|
 |  _|| | |  __/  __/ |_) |__) | |_| |   | || | | \__ \ || (_| | | |  __/ |
 |_|  |_|  \___|\___|____/____/|____/   |___|_| |_|___/\__\__,_|_|_|\___|_|



 +-------- Welcome to FreeBSD ----------+     ```                        `
 |                                      |    s` `.....---.......--.```   -/
 |  1. Boot Installer [Enter]           |    +o   .--`         /y:`      +.
 |  2. Boot Single user                 |     yo`:.            :o      `+-
 |  3. Escape to loader prompt          |      y/               -/`   -o/
 |  4. Reboot                           |     .-                  ::/sy+:.
 |  5. Cons: Serial                     |     /                     `--  /
 |                                      |    `:                          :`
 |  Kernel:                             |    `:                          :`
 |  6. kernel (1 of 1)                  |     /                          /
 |                                      |     .-                        -.
 |  Options:                            |      --                      -.
 |  7. Boot Options                     |       `:`                  `:`
 |                                      |         .--             `--.
 +--------------------------------------+            .---.....----.-
   Autoboot in 2 seconds. [Space] to pause
Loading kernel...
/boot/kernel/kernel text=0x1865e8 text=0xdbf5d4 text=0x4474db data=0x180+0xe80 data=0x1972e0+0x468d20 0x8+0x1949a0+0x8+0x1b90eb\
Loading configured modules...
can't find '/boot/entropy'
can't find '/etc/hostid'

Der Prozessor ist ein „Intel(R) Celeron(R) CPU G1610T @ 2.30GHz“. FreeBSD ist 15.0p2 und 15.0p3. Gelöst werden konnte das Problem mit folgender Zeile in der /boot/loader.conf:

vm.pmap.la57=“0″

Nach einem Neustart funktioniert dann die Virtualisierung.

Quelle: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=291768https://www.freebsd.org/security/advisories/FreeBSD-EN-22:07.la57.asc

Nachtrag vom 13.03.2026

Wie ich festgestellt habe, kam bei mir der Fehler auch, wenn ich bei der Installation auf mehr als eine CPU konfigurierte. Wenn ich die Installation durchführen wollte, habe ich in der Konfiguration jetzt einfach auf eine zugewiesene CPU gestellt und danach wieder erhöht.

Der neue Server mit FreeBSD (15.0-RELEASE)

Über die letzten 15 Jahre habe ich HP MicroServer als Home-Server eingesetzt. Ich hatte immer zwei mit FreeBSD (einen Main- und einen Backup-Server) sowie meist noch einen mit Windows, um dort Windows-Software auszuführen, der aber auch nicht permanent lief, sondern nur, wenn er gebraucht wurde.

In meinem letzten Hauptserver liefen vier vier Terrabyte große SATA-Festplatten im RAIDz1, also letztlich eine Art RAID-5 in Software. Das Ganze lief stabil und gut, aber meine heutigen Ansprüche waren viel zu langsam. Neben etlichen Jails mit etlichen Diensten (Web, Datenbanken, DHCP, NTP, DNS, Samba, NFS, uvm.) liefen auch zwei Minecraft-Server darauf und, gelinde gesagt, machte es einfach keinen Spaß mehr.

Etwas Neues musste her. Diesmal wollte ich keinen HP MicroServer mehr, da ich verschiedene Festplattenkombinationen wollte, um mehr Speed zu bekommen. Er sollte vernünftig virtualisieren können. Er sollte auch eine Möglichkeit haben, SAS-Festplatten mit Near-Line-SAS-Festplatten und SATA-Festplatten und -SSDs mischen zu können.

Dell PowerEdge T330

Aufgrund dessen, dass der Server für einen Privathaushalt ist, aber dennoch wichtig, speichert er immerhin wichtige Dokumente, ist für Entertainment da und auch zum Entwickeln von Software, entschied ich mich für eine gebrauchte Maschine, allerdings von einem Händler. Bei ServerShop24 entschied ich mich für einen Dell PowerEdge T330.

Meine Vorteile:

  • Die Maschine ist einfach zu öffnen und zu erweitern
  • Man kann, out of the box, 8 3,5″ HDDs reinstöpseln
  • SAS und SATA sind problemfrei mischbar (bei meiner Konfiguration).
  • FreeBSD läuft problemfrei drauf.

Meine Nachteile:

  • Dell (bäh).
  • FreeBSD bietet keine integrierte Lüftersteuerung, die muss man selbst bauen, was aber nicht so schwer ist – ansonsten drehen die Lüfter auf Vollgas und das macht keinen Spaß.
  • Sehr groß (eigentlich ist es mir egal).

Das ganze Ding hat 64GB RAM. Genug, für die ganzen Dienste, Jails, Virtualisierung von Windows 11. Ich habe zwei 300GB SAS HDDs für das Betriebssystem und Software drin (ZFS Mirror, gmirror für SWAP), 4 3TB NL-SAS HDDs (raidz-1) für das Datengrab und zwei SATA-SSDs für Virtualisierung und Minecraft (ZFS Mirror). Das System ist verschlüsselt.

Zusätzlich habe ich für ein paar Euros einen SD-Card-RAID-Controller gekauft, der zwei SD-Cards aufnimmt und die miteinander synchron hält. Darauf sichere ich immer wieder Systemdateien als Backup. Das ist aber eher eine Spielerei.

Weiterhin habe ich eine Netzwerkkarte mit vier Ports verbaut, mit der ich den Server mehrfach via LACP ans Netzwerk anbinden kann. So hat bspw. die Windows-VM ein eigenes Netzwerkinterface. Auch habe ich noch ein zweites (Redundanz) Netzteil eingebaut.

Hier liegen dann noch Ersatzplatten herum. Alles zusammen schätze ich, dass der Server „nur“ um die 1.200 Euro gekostet hat.

Das Gerät läuft jetzt hier seit mindestens einem halben Jahr durchgängig mit FreeBSD und völlig problemfrei. Nächtliche Backups gehen auf einen weiteren Home-Server sowie auf meinen Online-Server.

Bisher kann ich das System empfehlen, warten wir aber mal ab, wie es in zwei Jahren aussieht.

xrdp läuft zur Zeit recht stabil auf FreeBSD

Nur eine kleine Empfehlung. Immer wieder habe ich mir xrdp auf FreeBSD angesehen. Bisher empfand ich es als unbrauchbar, da es alles andere als stabil funktionierte und teils auch nicht startete.

Seit einer Weile funktioniert xrdp hervorragend.

FreeBSD-Desktop Xfce auf xrdp unter FreeBSD 14.2

xrdp stellt eine RDP-Session her. Damit kann man einen entfernten Computer via a nutzen, ähnlich zu RDP unter Windows. Auf dem oberen Bild kann man das sehen. Hier läuft auf einem Host ein FreeBSD 14.2, worunter ein Jail mit FreeBSD 14.2 läuft, auf dem xrdp installiert ist. Darin wird dann ein Xfce ausgeführt. Seit gut drei oder vier Monaten läuft es problemfrei.

Auf macOS nutze ich Jump Desktop, um auf den xrdp-Desktop zuzugreifen. Ich hatte auch Windows App ausprobiert, hier ist aber das Problem, dass ich es nie geschafft habe, ein deutsches Tastaturlayout zu übertragen. Mit Jump Desktop, welches leider kostenpflichtig ist, ist dies problemlos möglich.

Jump Desktop Hauptfenster

Ich kann das bisher sehr empfehlen, wenn man kein FreeBSD auf seinem Computer installieren will, sondern eine zentrale Installation nutzen möchte, auf der sich auch verschiedene Nutzer gleichzeit einloggen möchten.

PostgreSQL-Installation oder -Update auf FreeBSD läuft auf Fehler: >>could not load locale „sr_YU.ISO8859-5″<<

Nachdem ich PostgreSQL 16 auf Version 17 aktualisieren wollte, trat beim initdb folgender Fehler auf:

root@marge:~ # service postgresql oneinitdb
initdb postgresql
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.

The database cluster will be initialized with this locale configuration:
  locale provider:   libc
  LC_COLLATE:  C
  LC_CTYPE:    C.UTF-8
  LC_MESSAGES: C.UTF-8
  LC_MONETARY: C.UTF-8
  LC_NUMERIC:  C.UTF-8
  LC_TIME:     C.UTF-8
The default text search configuration will be set to "english".

Data page checksums are disabled.

fixing permissions on existing directory /server/database/postgres ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default "max_connections" ... 100
selecting default "shared_buffers" ... 128MB
selecting default time zone ... UTC
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... 2025-08-25 11:53:19.740 UTC [71247] FATAL:  could not load locale "sr_YU.ISO8859-5.bak"
2025-08-25 11:53:19.740 UTC [71247] STATEMENT:  SELECT pg_import_system_collations('pg_catalog');

child process exited with exit code 1
initdb: removing contents of data directory "/server/database/postgres"

Die einzige Möglichkeit, wie ich das Problem umgehen konnte, war, dass ich die Datei „/usr/share/locale/sr_YU.ISO8859-5“ in ein anderes Verzeichnis verschoben habe und dann initdb erneut ausführte. Danach habe ich die Datei zurückverschoben.

FreeBSD-Upgrade: vom Desaster doch noch zum Erfolg? Es war schrecklich

Ich gebe es zu: Ich habe meinen Server, der online steht und, unter anderem, dieses Blog betreibt, ziemlich und auch lange vernachlässigt. Installiert war ein FreeBSD 13.3 amd64. Die aktuelle Version aus der 13er-Reihe war 13.4. So weit zurück war ich nicht, was aber das größere Problem war, waren die installierten Packages, allen voran PostgreSQL, MySQL und PHP.

Rauchender Server

Ich dachte mir, ich ziehe mein FreeBSD 13.3 direkt auf 14.2, damit zumindest das Grundsystem mal aktuell ist und Dienste wie SSH und ähnliche mit Sicherheitsupdates versorgt werden. Die Packages wollte ich dann irgendwann später nachziehen.

Also begann ich, das Upgrade durchzuführen. Das lief auch gut, bis zum ersten Reboot. Der Server kam nicht mehr hoch. Zumindest dachte ich das. Von Hetzner ließ ich mir eine KVM anschließen und war doch erstaunt: Der Server ist hochgefahren und der erste Schritt des Upgrades war erfolgreich. Jedoch hatte der Server kein Netzwerk mehr. Warum, weiß ich nicht, ich konnte es aber schnell lösen, indem ich von meiner statischen Netzwerkonfiguration auf DHCP umgestellt habe. Also weiter mit dem Upgrade.

Der zweite Reboot ging dann leider in die Hose. Ich habe mir wieder eine KVM von Hetzner anschließen lassen (die erste hatte ich nur für eine Stunde geliehen) und sah, dass ich beim Mergen der Konfigurationen irgendwo zwei Zeilen „wegoptmiert“ hatte und so ein Script, welches zum Booten benötigt wird, fehlschlug. Reboot. Die Maschine kam hoch, schmiss aber ein paar Fehlermeldungen. Problematisch war, dass ich mich mit keinem meiner Accounts anmelden konnte. Irgendwelche anderen Scripte waren auch kaputt.

Anscheinend habe ich es entweder geschafft, ein paar Dinge kaputt zu machen (was mir zuvor noch nie passiert war), oder es gab irgendwelche anderen Probleme. Durch den Boot in den Single-User-Mode konnte ich mich umsehen und habe versucht, die Probleme zu fixen. Vergeblich. Dann hatte ich aber auch keine Lust mehr und die KVM war ja auch nur für drei Stunden geliehen, es musste eine Lösung her. Fakt war, dass im etc-Verzeichnis einiges kaputt war.

Also kopierte ich das etc-Verzeichnis von einer funktionsfähigen Installation von FreeBSD 14.2, schob meine Konfigurationen hinein und kopierte alles per „scp“ auf meinen Server. Zumindest das Grundsystem funktionierte dann wieder und ich brauchte die KVM nicht mehr.

Doch kaum ein Dienst funktionierte. Wir (meine Familie und ich) sind allerdings auf ein paar Dienste angewiesen: Mail, Card– und CalDav, mein Blog, NextCloud, meine Projekte, Git, usw.

Es blieb mir nichts übrig, als alles hochzuziehen. Wieder einmal dachte ich mir, wie sinnvoll es wäre, verschiedene Dienste in verschiedenen Jails zu organisieren und regelmäßiger Updates und Upgrades durchzuführen. Es war gut ein Tag Arbeit, alles wieder ans Rennen zu bekommen, zumal auch Packages wegfielen (wxWidgets 2.8, welches ich für compow.de benötige).