[gelöst] spontaner Reboot

Thanks for sharing the full logs, m. This gives us much clearer context. Let's dissect this systematically.

Key Observations from Your Logs

1. Filesystem Context: The stack trace shows ffs_* and ufs_* functions, confirming this is a FreeBSD UFS filesystem issue (not Linux/ext4 as I initially suspected). The "jnewblk" reference is specific to FreeBSD's soft updates mechanism.
2. Critical Timing: The panic occurred after only 23 minutes 30 seconds uptime, suggesting either:
   • Boot-time filesystem corruption
   • Early-stage service triggering disk writes
   • Hardware failure manifesting under initial load
3. FreeBSD Version: You're running 14.4-RELEASE-p2 (April 2023 kernel). There have been several softdep-related fixes in later patches.

Root Cause Analysis

The softdep_disk_io_initiation panic with jnewblk indicates:

• Soft Updates Corruption: FreeBSD's soft dependency tracking got inconsistent metadata
• Likely Triggers:
  • Unclean shutdown before this panic
  • Disk controller timeout during write operations
  • Possible kernel bug in 14.4-p2's softdep implementation

Action Plan

Immediate Recovery

# Boot into single-user mode (interrupt boot with spacebar) # Then run: fsck -fy /dev/ada0s1a  # Adjust partition name to match your setup

Note: UFS requires fsck, not fsck.ext4

Diagnostic Steps

1. Check Disk Health:

   Code

• Code

  smartctl -a /dev/ada0  # Replace with your actual disk device

  Look for reallocated sectors or pending sector counts

• Verify Kernel Patch Level:

  Code

• Code

  uname -r
  pkg info | grep freebsd-kernel

  Consider upgrading to 14.4-p3+ if available

• Review Pre-Panic Logs:

  Code

  1. Code

     grep -i "error\|fail" /var/log/messages | tail -50

Long-Term Mitigation

• Enable Soft Updates Monitoring: Add to /etc/sysctl.conf:

  Code

  vfs.ufs.softdep_async=1

• Consider ZFS Migration: If stability is critical, ZFS handles corruption better than UFS
• Check Power Management: Disable aggressive ACPI sleep states that can interrupt disk I/O

Critical Question

Was this system recently updated or migrated? The 23-minute uptime suggests either:

1. Fresh install with corrupted base filesystem
2. Hardware change (disk/controller) triggering incompatibility
3. Power event causing unflushed softdeps

Die Fehlermeldung zeigt einen Kernel-Panic in FreeBSD 14.4 im Bereich des UFS-Dateisystems mit aktiviertem Journaling. Hier ist eine Einordnung, was der Fehler bedeutet und wie du damit umgehen kannst:

🔍 Was sagt die Fehlermeldung?

• panic: handle_disk_io_initiation: Unexpected type jnewblk
  Der FreeBSD-Kernel stieß während einer Festplatten-I/O-Operation auf einen unerwarteten Blocktyp jnewblk (Journal-New-Block). Dieser gehört zum UFS-Journaling (softdep), ist an dieser Stelle im Code aber nicht korrekt behandelt worden → führt zum sofortigen Kernel-Panic.
• Der Backtrace zeigt, dass der Fehler während eines periodischen Sync-Vorgangs (sched_sync → ffs_fsync → bufwrite → softdep_disk_io_initiation) ausgelöst wurde. Das passt zur Uptime von ~23 Minuten (typischer Sync-Intervall).

🐛 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.

✅ Empfohlene Maßnahmen

1. Sofortiger Workaround: UFS-Journaling deaktivieren

# Runtime (bis zum nächsten Neustart):
sysctl vfs.ffsjournal=0

# Persistente Deaktivierung:
echo 'vfs.ffsjournal="0"' | sudo tee -a /etc/rc.conf

⚠️ Hinweis: Du verlierst damit den Schutz vor inkonsistenten Dateisystemen bei einem unerwarteten Powerloss. Für VMs mit zuverlässigem Storage oft akzeptabel.

2. FreeBSD auf den neuesten Patch-Level bringen

freebsd-update fetch
freebsd-update install

Prüfe die FreeBSD Errata nach Einträgen zu softdep oder ffs journaling für 14.4-RELEASE.

3. Storage & KVM-Backend prüfen

• Prüfe /var/log/messages oder dmesg auf vorangehende umass, ahci, virtio-blk oder timeout-Warnungen.
• Stelle sicher, dass der KVM-Storage-Backend (qcow2, raw, LVM, Ceph etc.) keine Latenzspikes oder Queue-Overflows meldet.
• Falls möglich: Storage-Polling-Intervalle oder virtio-blk-Queue-Größe anpassen (-drive ...,iothread=1 oder cache=none,io=native).

4. Langfristige Alternative

Falls Journaling nicht zwingend erforderlich ist, wechsle auf ZFS (zfs create -o compression=on -o mountpoint=/... rpool/...). ZFS ist auf FreeBSD standardmäßig integriert, stabiler im KVM-Context und umgeht das softdep-Problem komplett.

📌 Zusammenfassung

Es handelt sich um einen Software-Bug im FreeBSD-Kernel (UFS-Journaling), nicht zwingend um Hardware oder KVM-Fehler. Deaktiviere vorübergehend das Journaling, aktualisiere das System und prüfe Storage-Latenzen. Bei wiederholten Panics nach Update-Einspielung lege einen Bugreport an FreeBSD Bugzilla mit dmesg, sysctl vfs.ffs* und der KVM-Storage-Konfiguration.