Kernel 6.17.2-2-pve bootet nicht: XFS log recovery write I/O error

[jedie]

Der aktuelle PVE Kernel 6.17.2-2 startet bei mir nicht. Lande im initramfs BusyBox mit der Meldung "XFS log recovery write I/O error"

Also hab ich mal die Boot SSD ausgebaut und manual an meinem Rechner geprüft: SMART Werte und SMART Quick test sind in Ordnung...
Aber xfs_repair hat wirklich gemeckert. Fix war über mounten... Leider hab ich mir das Vorgehen und die Ausgaben nicht notiert.

Platte wieder eingebaut und gebootet und selbe Problem... Dann hab ich einfach statt 6.17 den neusten 6.14, genauer den "6.14.11-4-pve" versucht und siehe da, booten funktionierte...

Hab mal ein fix mit apt install --reinstall "*6.17.2-2-pve-signed" probiert, dabei kam noch eine Meldung das ein XFS Programm fehlen würde, also noch xfsprogs nachinstalliert und nochmal reinstall gemacht.

Hilft aber nix: 6.17 startet nicht, also wieder den älteren 6.14 genommen.

Jemand eine Idee?

 

[jedie]

Ich hab weiterhin Problem mit dem booten und bekomme den "XFS log recovery write I/O error" Fehler...



Ein xfs_repair mount /dev/mapper/pve-root -L und reboot, behebt es nicht...

Es hängt irgendwie mit der CPU zusammen!

Mein System ist ein alter "HP ProLiant ML10 v2" (aus 2026, mit Intel Haswell Sockel 1150, DDR3 mit ECC...)

Eigentlich hab ich da drin den Intel Xeon E3-1241 v3 und genau mit dem kommt es beim booten zu dem "XFS log recovery write I/O error" Fehler.

Ich hab noch einen zweiten "HP ProLiant ML10 v2" mit der kleinen Intel Pentium G3240 CPU und damit bekomme ich keinen XFS fehler.
Ich kann auch die Boot platte in einen ganz anderen Rechner einbauen und bekomme keinen Fehler.

Memtest ist grün, bei beiden CPUs:






Hab dennoch mal RAM hin unter her getauscht: Spielt keine Rolle.
Da ich zwei "HP ProLiant ML10 v2" habe, kann ich Mainboard auch ausschließen.

Booten vom USB Stick, ein "gpartedlive" funktioniert. Platte sieht normal aus:



Am Ende bleibt nur die CPU! Und nun kommt es: Ich hab auf eBay zwei weitere "Intel Xeon E3-1241 v3" gekauft (Eine ist defekt, bei der anderen bekomme ich den selben Fehler.

Also zwei unterschiedliche "Xeon E3-1241 v3" -> "XFS log recovery write I/O error"
Selbe Hardware aber "Pentium G3240" -> geht


Wie ist das zu erklären? Was könnte ich noch machen?

 

[Falk R.]

Ich hab weiterhin Problem mit dem booten und bekomme den "XFS log recovery write I/O error" Fehler...

View attachment 98793

Ein xfs_repair mount /dev/mapper/pve-root -L und reboot, behebt es nicht...

Es hängt irgendwie mit der CPU zusammen!

Mein System ist ein alter "HP ProLiant ML10 v2" (aus 2026, mit Intel Haswell Sockel 1150, DDR3 mit ECC...)

Eigentlich hab ich da drin den Intel Xeon E3-1241 v3 und genau mit dem kommt es beim booten zu dem "XFS log recovery write I/O error" Fehler.

Ich hab noch einen zweiten "HP ProLiant ML10 v2" mit der kleinen Intel Pentium G3240 CPU und damit bekomme ich keinen XFS fehler.
Ich kann auch die Boot platte in einen ganz anderen Rechner einbauen und bekomme keinen Fehler.

Memtest ist grün, bei beiden CPUs:

View attachment 98794

View attachment 98795


Hab dennoch mal RAM hin unter her getauscht: Spielt keine Rolle.
Da ich zwei "HP ProLiant ML10 v2" habe, kann ich Mainboard auch ausschließen.

Booten vom USB Stick, ein "gpartedlive" funktioniert. Platte sieht normal aus:

View attachment 98796

Am Ende bleibt nur die CPU! Und nun kommt es: Ich hab auf eBay zwei weitere "Intel Xeon E3-1241 v3" gekauft (Eine ist defekt, bei der anderen bekomme ich den selben Fehler.

Also zwei unterschiedliche "Xeon E3-1241 v3" -> "XFS log recovery write I/O error"
Selbe Hardware aber "Pentium G3240" -> geht


Wie ist das zu erklären? Was könnte ich noch machen?

Schon mal Firmwareupdates / BIOS Update gemacht?

 

[jedie]

Ja, sind die letzten Updates drauf. Sind allerdings auch von 2019. Was neueres gibt es nicht mehr:





Ich überlege, ob ich nicht als Boot Platte ext4 statt XFS nehmen kann oder grub2 mit was anderes ersetzten? Wobei, ich glaube UEFI kann die Kiste nicht.
Sonstige Ideen?

 

[ThoSo]

bei Google ("ubuntu kernel 6.17 Xeon E3-1241 v3 xfs") finden sich so einige Bootprobleme mit dem 6.17er Kernel.
Eine Idee von Gemini wäre : UEFI VT-d (Intel Virtualization Technology for Directed I/O) deaktivieren

Evtl. mal mit dem 7er Kernel testen oder beim 6.14er bleiben.

 

[jedie]

Danke, werde ich mal testen...

Aber auf 6.x bleiben ist keine langfristig gute Idee, denke ich.
"VT-d" deaktivieren ist allerdings eine option, denn ich mach eh kein PCIe/GPU Passthrough und das dürfte vermutlich der haupt Unterschied sein, was?

EDIT: Hab mal https://lumo.proton.me gefragt, er spuckt noch Ideen aus:

• C-State Optionen im BIOS deaktivieren
• GRUB Parameter (iommu=pt)
• Auf ext4 wechseln

und die "Zusammenfassung":

Es ist wahrscheinlich ein Timing-/Initialisierungsproblem während des Early Boots, das durch die unterschiedliche CPU-Implementierung von Power Management und Speichercontroller ausgelöst wird. Die Pentium-CPU ist langsamer und weniger komplex, daher toleranter gegen kleine Timing-Probleme beim XFS Log Recovery.

 

[jedie]

So, nochmal ein paar tests gemacht. Mit der "Xeon E3-1241 v3" CPU.
Die selben Probleme gibt es auch mit dem Proxmox Backup Server. Aber ist nicht verwunderlich, weil auch XFS als Boot mit den selben Kernel.
Hab noch Kernel 6.17.4-2-pve und 6.14.11-5-pve drauf.

Hab auf der Kiste folgende CPU Optionen im BIOS unter "System Options" / "Processor Options":

1. No-Execute Memory Protection
2. Virtualization Technology
3. Hyperthreading
4. Turbo Boot
5. VT-d

Hab die alle mal deaktiviert und kann dann Kernel 6.17 und 6.14 booten.
Dann alle aktiviert, bis auf "VT-d": "6.14.11-5-pve" und "6.17.4-2-pve" sind bootbar.
Dann auch "VT-d" aktiviert: "6.14.11-5-pve" geht, aber mit "6.17.4-2-pve" kommt es zu dem XFS Fehlern.

Damit ist bestätigt, das ein deaktivieren von VT-d ein möglicher work-a-round darstellt.

 

[jedie]

Hab nochmal Lumo gefragt und das wichtigste wäre:

Dieses Problem bei Haswell-CPUs (E3-1241 v3) wird oft durch BIOS-DMAR-Tabellen-Fehler verursacht. Der Kernel 6.17 hat ein neues DMAR-Handling eingeführt, das diese BIOS-Bugs aufdeckt. ... Ein späterer Kernel (6.18+) hat diese Regression bereits gepatcht

und nochmal weiter gebort:

Der Fix in Kernel 6.17.8+ (Stable Backport)​

Ein post-release Hotfix wurde schnell bereitgestellt:


Commit 8d7c0a7a9c3b - "intel‑iommu: fix boot when Intel IOMMU initialization fails under TXT"


Dieser Patch:

• Verbesserte die Fehlerbehandlung bei fehlgeschlagener IOMMU-Initialisierung
• Verhinderte, dass der Boot-Prozess komplett abgebrochen wird
• Ermöglichte den Boot-Vorgang selbst bei teilweisen IOMMU-Problemen

In pbs gibt es auch schon Kernel 7.0, den werde ich auch mal probieren. Vielleicht ist das damit dann schon komplett gelöst.

 

[jedie]

Ne: Mit dem neusten "7.0.14-4-pve" hab ich dennoch das selbe Problem
Bleibt noch der Test: Im BIOS "VT-d" aktiviert lassen, aber Kernel-Parameter: "intel_iommu=on,igfx_off iommu=pt" setzten. Vielleicht ist das der beste weg (oder halt was anderes als XFS für das Boot Dateisystem zu nehmen.)

 

[ThoSo]

Die Option "VT-d" brauchst doch nur wenn du Hardware an eine VM / LXC durchreichst.
Wenn ich nichts durchreichen und das auch nicht vorhabe, mach es aus und gut ist - außer du willst es unbedingt wissen.

Dann würde ich aber eher mal den Test mit ext4 machen auf einer frischen Platte und nur mit einer Auswahl an VMs zum spielen.

 

[Bu66as]

Das ist ein eingegrenztes Problem, jedie hat die eigentliche Arbeit schon gemacht. Ich häng mich mit einem fachlichen Punkt dran (VT-d/IOMMU ist die Ursache, der XFS-Fehler ist nur Symptom).

Der XFS-Fehler ist hier gar nicht das eigentliche Problem, das ist nur das Symptom. Schau dir die Meldung genau an: log recovery write I/O error ... error -5. Error -5 ist EIO, also der Schreibzugriff auf die Platte selbst schlägt fehl. Sprich: der SATA-Controller bekommt über die DMA-Remapping-Einheit (VT-d) keine sauberen Writes mehr durch. Deshalb hilft ein Wechsel auf ext4 vermutlich auch nix, du kriegst dann halt denselben I/O-Fehler unter ext4 statt XFS.

Zu deinem Kernel-Parameter-Test: iommu=pt würde ich mir sparen, pt initialisiert das IOMMU trotzdem (nur im Passthrough-Modus), du rennst wahrscheinlich in denselben DMAR-Bug. Wenn du kein PCIe/GPU-Passthrough machst, ist intel_iommu=off auf der Kernel-Cmdline das Äquivalent zu deinem BIOS-Schalter, nur eben pro Kernel und ohne BIOS-Gefummel. Das ist der zuverlässige Workaround.

Und das Ding ist ja eine echte Kernel-Regression (Haswell + die spezifische DMAR-Tabelle von dem alten HP-BIOS, das seit 2019 nicht mehr gepflegt wird). Wäre gut wenn du das mal mit dem dmesg vom kaputten Boot im Proxmox-Bugtracker meldest, sonst wird das nie gefixt und du sitzt ewig auf dem Workaround. Die Commit-Hashes die dir Lumo/Gemini ausgespuckt haben würd ich übrigens nicht für bare Münze nehmen, die KI-Teile erfinden sowas gern mal.