[gelöst] spontaner Reboot

    Ich meine das hier:

    Zitat von andreas.

    Hintergrund & Bekannte Issues

    Dies ist ein bekannter Bug in FreeBSD 14.x im softdep-Subsystem des UFS-Journalings. Er wurde in der FreeBSD-Community und im Bugzilla mehrmals gemeldet.
    Er tritt oft unter Last, bei vielen kleinen Schreiboperationen oder bei spezifischen Storage-Backends auf (KVM kann hier durch Latenz oder Queue-Management den Auslöser liefern, ist aber selten die direkte Ursache).
    FreeBSD 14.4-RELEASE-p2 enthält möglicherweise noch keine vollständige Korrektur. Neueere Patch-Level oder 15.x haben das Problem oft behoben.

    Ist ein Update keine Option?

    Natürlich kannst du den Support fragen. Ich bezweifle halt nur, dass netcup was am Host ändern wird, wenn das Problem nicht nachweislich vom Host verursacht wird. Zumal wenn das Problem mit FreeBSD 14.4 öfter auftritt und neuere Versionen das Problem nicht mehr zu haben scheinen. Aber ich kann mich auch irren, passiert oft genug.

    Edit: Eine Speicheroptimierung mag eventuell dafür sorgen, dass die Latenz des Speichers (oder was auch immer den Bug in FreeBSD 14.4 triggert) verbessert wird. Das würde ich allerdings für mich nicht als Lösung betrachten, eher als zeitweiligen Workaround. Es würde dann wohl mit großer Wahrscheinlichkeit nach einiger Zeit erneut passieren.

    Einmal editiert, zuletzt von tab (25. April 2026 um 22:19)

    Zitat von tab

    Ist ein Update keine Option?

    doch, aber das mache ich ungern ohne Not auf Verdacht in's Blaue. Wäre mein erster 15er, .0 vermeide ich normalerweise und IPv6-only ist auch etwas speziell, aber irgendeiner ist ja der Erste.

    P.S.: im Nachhinein ärgerlich, erst kürzlich ging ich 14.3 -> 14.4.

    P.P.S.: ic frge auch mal https://forums.freebsd.org/threads/crash-…ease-p2.102499/

    😈 FreeBSD auf einem x250 Thinkpad. Täglich. Schön.

    Einmal editiert, zuletzt von mro (26. April 2026 um 10:25) aus folgendem Grund: FreeBSD Forum verlinkt

    Zitat von mro

    doch, aber das mache ich ungern ohne Not auf Verdacht in's Blaue. Wäre mein erster 15er, .0 vermeide ich normalerweise und IPv6-only ist auch etwas speziell, aber irgendeiner ist ja der Erste.

    P.S.: im Nachhinein ärgerlich, erst kürzlich ging ich 14.3 -> 14.4.

    Also eine Version, die mit .0 endet, würde ich auch erst einmal vermeiden zu installieren und eher den derzeitigen Kernel auf eine neuere Version, die nicht auch mit .0 endet, hochziehen.

    Dennoch habe ich noch mal meine lokale KI befragt, deren Sprachmodell vor ca. 9 Stunden das letzte Mal aktualisiert / trainiert wurde. Und deren Hinweis auf die Ursache sieht heute wie folgt aus:

    Spoiler anzeigen

    Das ist ein klassischer UFS/Softdep-Korruptionscrash unter FreeBSD. Der Backtrace zeigt:

    Code
    #3  softdep_disk_io_initiation+0x12ae
#4  ffs_geom_strategy+0x13b
...
#9  ffs_fsync+0x22

    FreeBSD versucht, UFS-Metadaten auf die Platte zu schreiben (via ffs_fsync → softdep), und trifft dabei auf einen ungültigen Eintrag mit dem Typ jnewblk, der im Softdep-Log nicht erwartet wird.

    Mögliche Ursachen

    UrsacheBeschreibung
    Disk-Fehler / Bad BlocksDefekte Sektoren korrumppieren Metadaten oder den Softdep-Journal
    Zu wenig RAMSoftdep benötigt viel Arbeitsspeicher — bei zu wenig wird der Cache korruptiert
    Host-Storage-ProblemeBei VMs: falsch konfigurierte VirtIO/SCSI, unzuverlässiger Host-Speicher
    Bug in FreeBSD 14.4p2Möglicher Softdep-Bug in dieser Release

    Vorgehensweise

    1. Sofort: Metadumps holen, bevor sie verloren gehen:

    Code
    # Wenn das System wieder hochfährt und die Partition lesbar ist:
disklabel ad0s1 > /var/tmp/disklabel.txt 2>/dev/null || true
dumpfs -u /dev/ad0s1a > /var/tmp/dumpfs_a.txt 2>/dev/null || true
dumpfs -u /dev/ad0s1b > /var/tmp/dumpfs_b.txt 2>/dev/null || true
# ... für alle Partitionen

    2. RAM-Tests: Memtest86+ laufen lassen — Softdep-Crash sind häufig ein Symptom von Speicherfehlern.

    3. VM-Storage prüfen:

    • VirtIO-Disks unter QEMU/KVM können Probleme machen, wenn iothread=on nicht gesetzt ist oder die Host-Platte langsam
    • SCSI statt VirtIO probieren als Workaround

    4. Dateisystem prüfen:

    Code
    # Einmalig und mit -y für automatische Reparatur:
fsck_ufs /dev/ad0s1a

    5. Falls es sich wiederholt: Auf FreeBSD 14.3 zurückgehen oder ein Upgrade auf 15.x in Betracht ziehen (Softdep wurde dort teilweise überarbeitet).

    Kurzantwort

    Am wahrscheinlichsten ist entweder ein defekter Speicherlaufwerk im Host/VM, RAM-Defekt oder Storage-Latenz der VM-Disks. Starte mit Memtest und fsck.

    Die Frage "Würde ein Upgrade von der derzeitigen Version auf 15.0 das Problem lösen?" wurde wie folgt beantwortet:

    Spoiler anzeigen

    Ja, ein Upgrade auf FreeBSD 15.0 hat gute Chancen, das Problem zu lösen — aber mit wichtigen Einschränkungen.

    Warum es helfen könnte

    In FreeBSD 14.x wurde der Softdep-Mechanismus mehrfach mit Bugs gelandet. In 15.0 gab es folgende relevante Änderungen:

    • FFS2/Softdep-Fixes: Mehrere Patches für Metadaten-Korruption und Race Conditions in softdep
    • Disk I/O Path Refactoring: Der gesamte Writeback-Pfad wurde überarbeitet (verwandte Commit-Reihen)
    • Zahlreiche jnewblk-bezogene Bugs gefixed, die genau diesen Crash verursachen

    Aber: Es ist kein Garant

    Der Softdep-Crash mit jnewblk hat sehr oft eine unterliegende Hardwareursache:

    TypLösung durch 15.0?
    Defekte Platte / Host-Storage❌ Nein — Problem bleibt
    RAM-Bugs im System/Host❌ Nein
    VirtIO-Gast-Treiber Bug⚠️ Möglicherweise (neuer Treiber)
    Softdep-Race Condition✅ Wahrscheinlich gelöst

    Empfohlener Weg

    1. Speicher & Hardware prüfen — falls ein physisches Problem vorliegt, bringt das Upgrade nichts:
      • Memtest86+ auf dem Host oder Gast
      • SMART-Checks der virtuellen Disks (Host-Seite)

    2. Upgrade auf 15.0, aber mit Vorsicht:

      Code
      freebsd-update upgrade -r 15.0-RELEASE
# ... nach Installation
freebsd-update install
# ... Neustart und nochmal
freebsd-update install
    3. Optional: Falls die VM noch nicht kritisch ist, eine saubere Neuinstallation mit 15.0 versuchen (falls das Problem nicht wiederkehrt → war Softdep-Bug, sonst Hardware).

    Fazit

    Ein Upgrade auf 15.0 löst es in ~60-80% der Fälle, wenn die Ursache ein reiner Softwarebug war. Bei Storage-/RAM-Problemen bleibt der Crash gleich — nur unter Umständen mit einer anderen Fehlermeldung. Prüfe also zuerst die Hardware, dann upgrade.

    Zitat von tab

    Natürlich kannst du den Support fragen. Ich bezweifle halt nur, dass netcup was am Host ändern wird, wenn das Problem nicht nachweislich vom Host verursacht wird.

    Ich gehe davon aus, dass der Support erstmal einen Nachweis des Fehlers unter Nutzung des netcup Rettungssystems fordert. :/

    Selbst wenn das FreeBSD Image von netcup bereitgestellt wurde, gibt es dafür keinen Support für unmanaged VPS/RS.

    Das Ergebnis vom Support ist da:

    Zitat

    vielen Dank für die Geduld.

    Im Single-User-Modus hat das Anlegen problemlos funktioniert.

    Bitte beachten Sie, dass für vServer kein weiterführender Support angeboten wird.

    Mit freundlichen Grüßen,
    netcup Team

    ja und ausgeschaltet tritt auch kein Problem auf. Toll.

    Ich denke ich werde in bälde ein 15er Image ausprobieren. Spricht dabei was gegen ZFS?

    😈 FreeBSD auf einem x250 Thinkpad. Täglich. Schön.

    Einmal editiert, zuletzt von mro (12. Mai 2026 um 16:06)

    repariert in

    Code
    $ freebsd-version -kru ; uname -a
14.4-RELEASE-p3
14.4-RELEASE-p3
14.4-RELEASE-p4
FreeBSD n0.mro.name 14.4-RELEASE-p3 FreeBSD 14.4-RELEASE-p3 GENERIC amd64
$ dd if=/dev/zero of=test.blob bs=100M count=20
$ ls -l test.blob 
-rw-r--r--  1 me me  2.0G May 12 21:29 test.blob

    😈 FreeBSD auf einem x250 Thinkpad. Täglich. Schön.

  • mro 12. Mai 2026 um 21:36

    Hat den Titel des Themas von „spontaner Reboot“ zu „[gelöst] spontaner Reboot“ geändert.
    • Neu

    Zunaechst mal wuerde ich dir empfehlen, die aktuellen Kernel patches einzuspielen. Du hast Stand p2 , wenn ich das richtig sehe, aktuell ist p9.

    Da waren mehrere wichtige Kernel-Patches dabei.

    Ich geh mal davon aus, dass du keine From-Source-Installation hast, also binary Updates machst. In dem Fall:

    # freebsd-update fetch

    # freebsd-update install

    # shutdown -r now (oder wann auch immer)

    Alternativ kannst du natuerlich auch gleich auf 14.5 oder 15.1 gehen. Das geht dann so , statt obigen fetch:

    # freebsd-update -r 14.5-RELEASE upgrade

    und entsprechend install 2 mal (vor reboot und nach reboot)


    Ich hab gerade ein aehnliches Problem mit allen netcup VMs, die panic-en aber anders:

    Fatal trap 12: page fault while in kernel mode
    cpuid = 1; apic id = 01
    fault virtual address = 0x1d
    fault code = supervisor read data, page not present
    Egal, welcher Standort, daher vermute ich da ein Problem mit den settings im SCP.

    Weiss jemand was das dortige setting "Betriebssystem-Optimierung" wirklich bewirkt? Ich habs natuerlich auf BSD eingestellt,

    aber evtl. ist das nicht sinnvoll.

    Allerdings begann das erst vor ca. 2 Wochen. Davor liefen sie monatelang stabil.