Fehler bei Kernel-Upgrade auf 6.1.64-1: „broken package“

[slu]

Außerdem hat das Krisenmanagement bei Debian sehr gut gegriffen.

Genau so ist es!

Und ich schätze jetzt einfach mal das kommt bei Proprietäre Software genau so vor, nur kann man da nicht einfach in den Quellcode schauen.
Es ist dort viel einfacher das ganze einfach unter den Teppich zu kehren.

[HumiNi]

Außerdem hat das Krisenmanagement bei Debian sehr gut gegriffen.

Guter Punkt: Das ist wohl war.
Dann allgemein: Dass es ein direct-io-Bug, der sich auf jedem zentralen System, nämlich auf DB-Servern, auswirkt, so weit schafft...
Als ich noch Admin war, wäre bei uns der War Room wegen kleinerer Probleme tagelang besetzt gewesen.

[TRex]

Ich blick bei den Backports zu stable nicht besonders durch - wie lange war der bug denn in sid und testing?

[cosinus]

sodass ich mich nicht gegen Erdbeben und Meteoriten bsichere.

Ein T.Rex/Dino sollte aber gegen Metoriten und Asteroiden besser gewappnet sein

[HumiNi]

Ich blick bei den Backports zu stable nicht besonders durch

Wieso Backports?

Code: Alles auswählen

root@gauner:/var/log# apt-cache policy linux-image-6.1.0-15-amd64
linux-image-6.1.0-15-amd64:
  Installed: (none)
  Candidate: 6.1.66-1
  Version table:
     6.1.66-1 500
        500 http://deb.debian.org/debian bookworm/main amd64 Packages

[cosinus]

Ein tragischer Unfall, wie er alle 20 Jahre einmal vorkommt.
Außerdem hat das Krisenmanagement bei Debian sehr gut gegriffen.

Ja ein Unfall, aber wie ich finde ist erstaunlich wenig passiert bei diesem Horrorbug, weil: Glück im Unglück; eine nur sehr selten bis garnicht benutzte Operation lässt den Bug zuschnappen.
Dass das Problem so schnell erkannt und die betroffenen Archivedateien mit dem kaputten Kernel vom Netz genommen wurden ist wirklich lobenswert.

[MSfree]

Wieso Backports?

Weil:

The issue affects all kernels which have the commit 91562895f803
("ext4: properly sync file size update after O_SYNC direct IO") from
6.7-rc1 (which is present in 6.6.3, 6.5.13 and 6.1.64) but when commit
936e114a245b ("iomap: update ki_pos a little later in
iomap_dio_complete") from 6.5-rc1 is missing (which was backported to
5.15.142 and 6.1.66 additionally).

[cosinus]

Ich blick bei den Backports zu stable nicht besonders durch - wie lange war der bug denn in sid und testing?

Salvatore hat was denke ich dazu geschrieben:

The issue affects all kernels which have the commit 91562895f803
("ext4: properly sync file size update after O_SYNC direct IO") from
6.7-rc1 (which is present in 6.6.3, 6.5.13 and 6.1.64) but when commit
936e114a245b ("iomap: update ki_pos a little later in
iomap_dio_complete") from 6.5-rc1 is missing (which was backported to
5.15.142 and 6.1.66 additionally).

[Livingston]

Das bezieht sich aber nicht auf Debian-Backports sondern auf das Zurückportieren bei kernel.org: Also Neuerungen rückwirkend auf ältere Kernel-Linien exportieren

[HumiNi]

Das bezieht sich aber nicht auf Debian-Backports sondern auf das Zurückportieren bei kernel.org: Also Neuerungen rückwirkend auf ältere Kernel-Linien exportieren

Ok, verstanden.

[cosinus]

Hmm...sind neuere Kernel wie 6.5 oder 6.6 nun betroffen oder nicht?
Finde da etwas widersprüchliche Aussagen.

[JTH]

Via 1057843:

The commit [936e114a245b6] got merged in 6.5-rc1 so all stable kernels that have
91562895f803 ("ext4: properly sync file size update after O_SYNC direct
IO") before 6.5 are corrupting data - I've noticed at least 6.1 is still
carrying the problematic commit. Greg, please take out the commit from all
stable kernels before 6.5 as soon as possible, we'll figure out proper
backport once user data are not being corrupted anymore. Thanks!

6.5 und neuer sind demnach wohl nicht betroffen gewesen. Und für die betroffenen sollte es ja nun passende Fehlerbehebungen gegeben haben.

[Livingston]

Oder noch etwas genauer. Bei kernel.org hat man unter Kernel 6.5 eine Verbesserung eingeführt: commit 936e114a245b ("iomap: update ki_pos a little later in iomap_dio_complete"), anschließend kam in 6.7 commit 91562895f803 ("ext4: properly sync file size update after O_SYNC direct IO") dazu.
Beim Rückportieren auf 6.1.64 hatte man aber den ersten Commit (936e114a245b) vergessen/verbarselt. Zusammen wirkte sich das dann als der O_DIRECT-Bug aus.

[cosinus]

Es ist also in 6.1.64 was aus 6.7 reingekommen, ohne das notwendige, was in 6.5 eingeführt wurde?
Wenn ja, warum schriebt Salvatore dann sowas:

which is present in 6.6.3, 6.5.13 and 6.1.64

[Livingston]

D.h. 6.6.3 und 6.5.3 sind nicht kaputt, weil die Neuerung (commit 936e114a245b) dort schon fester Bestandteil ist.

[cosinus]

Ok, danke. Ich hake das Thema für mich jetzt ab.

[slu]

Ok, danke. Ich hake das Thema für mich jetzt ab.

Mein strace läuft noch eine weile (und schon seit ca. 12 Uhr), ich schreibe später das Ergebnis.

[Cordess]

Mal gut, dass ich nicht wie ein aufgescheuchtes Hühnchen am Sonntag alles geplättet hab.

Diese Aussage ist logischer Unsinn. Du hast russisch Roulette gespielt und Glück gehabt, dass sich im Nachhinein herausgestellt hat, dass der Fehler nur bei ganz bestimmten Dateisystemzugriffen unter wenigen Programmen zum Tragen kommt.
Wäre es anders gewesen, dann hätten sich die Fehler und Folgen potenziert.

[HumiNi]

Bitte, bitte, bitte. Nutzt doch für persönliche Meinungsverschiedenheiten PNen.

[TRex]

Mal gut, dass ich nicht wie ein aufgescheuchtes Hühnchen am Sonntag alles geplättet hab.

Diese Aussage ist logischer Unsinn. Du hast russisch Roulette gespielt und Glück gehabt, dass sich im Nachhinein herausgestellt hat, dass der Fehler nur bei ganz bestimmten Dateisystemzugriffen unter wenigen Programmen zum Tragen kommt.
Wäre es anders gewesen, dann hätten sich die Fehler und Folgen potenziert.

Verzichtet hier auf weitere einseitige, beharrlich persönlich gerichtete Kritik und Sticheleien. Beim nächsten entsprechenden Beitrag gibts für denjenigen mindestens einen Tag* Forenauszeit.

Wir sehen uns in 24h wieder. Wenn du es bis dahin nicht gelernt hast, gerne auch länger.

[slu]

Ok, danke. Ich hake das Thema für mich jetzt ab.

So ich hab jetzt 5 Stunden die MariaDB von Nextcloud mit strace -f geloggt (418 MB), bis zum Upgrade auf 28.0.0 gab es keinen einzigen O_DIRECT.
Weil sich dann das Upgrade von 27.1.4 auf 28.0.0 angeboten hat habe ich das auch noch durchlaufen lassen, danach gab es 11x 11904 fcntl(203, F_SETFL, O_RDONLY|O_DIRECT) = 0,
jedoch keinen einzigen Schreibvorgang.

Mein zweiter Test war ein KVM Guest hier waren es in 5 Stunden 218 MB und kein einziger O_DIRECT.

[Livingston]

Glückwunsch, slu
Dann bist Du wohl aus dem Schneider.

[slu]

Dann bist Du wohl aus dem Schneider.

Hoffentlich nicht nur ich!

Wieder viel gelernt, danke @Livingston für deinen strace Hinweis!

[cosinus]

Mein zweiter Test war ein KVM Guest hier waren es in 5 Stunden 218 MB und kein einziger O_DIRECT.

Danke für deinen Langzeittest.
Ich habe zwar nicht so lange mit strace geloggt, aber bei mir war auch kein einziger schreibender O_DIRECT zu sehen.

[ingo2]

Nach diesem Thread und Berobachtungen macht sich der Fehler durch "O_DIRECT" ja vorwiegend bei Datenbanken als Anwendung bemerkbar, da diese ihr eigenes Caching verwenden und kaum auf einem Standard-Desktop.

Jetzt aber noch eine andere Konstellation (sorry, wenn ich hier ein kerneltechnischer Laie bin und das irrelevant ist), wo meines Erachtens direktes I/O gemacht wird:

Beispiel sei meine Samsung 980 NVMe-SSD mit HMB (host memory buffer). Die SSD selbst besitzt ja kein DRAM und nutzt stattdessen das RAM des Hosts/meines PC's. Ein Teil der "mapping table" oder "translation map" wird doch dabei zwischen SSD und RAM des Hosts synchron gehalten - also eigentlich ein ausgesprochen typischer Fall für "O_DIRECT" - oder liege ich da falsch?

Ich hatte hier auf dem PC jedenfalls für 1 Tag den kaputten Kernel am laufen, habe sogar ein "fstrim" laufen lassen - aber bisher jedenfalls keine Probleme beobachtet.

Kann das vielleicht Jemand hier beurteilen?

Gruß. Ingo