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

[s20e6a14]

hi zusammen,
welche tests/prüfungen führt ihr denn so aus, nachdem ihr auf 6.1.0-15-amd64 / 6.1.66-1 aktualisiert habt?
auf mehreren meiner systeme war die betroffene version 6.1.64-1 im einsatz, glücklicherweise verhalten sich alle auf den ersten blick noch "normal".
aber irgendwie ist mir noch nicht ganz wohl...

[isabena]

empfehlenswert ist auch das

Code: Alles auswählen

 autoclean

um das lokale Repo von abgerufenen Paketdateien zu löschen - hier linux-libc-dev 6.1.64-1

[slu]

hi zusammen,
welche tests/prüfungen führt ihr denn so aus, nachdem ihr auf 6.1.0-15-amd64 / 6.1.66-1 aktualisiert habt?
auf mehreren meiner systeme war die betroffene version 6.1.64-1 im einsatz, glücklicherweise verhalten sich alle auf den ersten blick noch "normal".
aber irgendwie ist mir noch nicht ganz wohl...

Genau diese Frage stelle ich mir auch, ich verstehe noch nicht was genau wann passieren kann/konnte.
Der Commit war ja auch ein Fix für ein anderes ext4 Problem..

[Livingston]

Soweit ich den Bug-Report verstanden habe, mussten schon ein paar dumme Zufälle zusammenkommen, damit es rummst. Aber wenn, dann mit der Auswirkung: "It eats data". Ist also schon ernstzunehmen aber nicht sehr wahrscheinlich.
Und zum Glück hat man ja immer Backups parat.

[slu]

Soweit ich den Bug-Report verstanden habe, mussten schon ein paar dumme Zufälle zusammenkommen, damit es rummst. Aber wenn, dann mit der Auswirkung: "It eats data". Ist also schon ernstzunehmen aber nicht sehr wahrscheinlich.

Das würde mich erleichtern und es könnte mir zugute kommen das nicht viel Last auf den Systemen war, da Wochenende.

Und zum Glück hat man ja immer Backups parat.

Da ich davon ausgehen muss das meine Backups gestern Abend mit dem defekten Kernel schon defekt sind müsste ich die VMs von letzter Woche nehmen und die Nutzdaten von Freitag Abend einspielen,
dafür ist es jetzt schon zu spät um das bis morgen früh zu schaffen.

Daher bleibt mir jetzt nichts anderes übrig als den Bug besser zu verstehen (Wahrscheinlichkeit) und die Systeme stichprobenartig zu testen.

[Livingston]

Zum Glück waren in meinem Fall nur ein Hand voll firmeninterner Server betroffen, auf die am Wochenende nicht zugegriffen wurde. Backups von der Nacht von Fr auf Sa waren da zum Glück kein Problem.
Bei 24h-Betrieb wüsste ich nicht, wie man da evtl. Fehler abschätzen kann. Wahrscheinlich ist es besser, in den sauren Apfel zu beißen, als dauerhaft mit eventuell kompromitierten Daten zu arbeiten. Sorry, aber mehr fällt mir dazu grad auch nicht ein.

[Livingston]

Was da in 6.1.64 kaputt gegangen ist, erfährt man auf der Kernel-Mailingliste https://lore.kernel.org/stable/20231205 ... c3@quack3/
Insbesondere hier:

So I've got back to this and the failure is a subtle interaction between
iomap code and ext4 code. In particular that fact that commit 936e114a245b6
("iomap: update ki_pos a little later in iomap_dio_complete") is not in
stable causes that file position is not updated after direct IO write and
thus we direct IO writes are ending in wrong locations effectively
corrupting data. The subtle detail is that before this commit if ->end_io
handler returns non-zero value (which the new ext4 ->end_io handler does),
file pos doesn't get updated, after this commit it doesn't get updated only
if the return value is < 0.

Also ein amoklaufender Zeiger, der auf die aktuelle Schreibposition verweist und der Daten an die falsche Stelle schreiben könnte, falls bestimmte Randbedingungen zutreffen. Weiß nicht, ob das bedeutet, dass nur innerhalb einer Datei Mist gebaut würde, oder auch sonstwo innerhalb des ext4-Filesystems.

[slu]

Ich habe das wohl gelesen, aber nicht richtig verstanden wann welcher Fall eintreten kann.
Meine ersten fsck waren unauffällig, die Frage ist halt ob man das überhaupt merken kann.

Blöde Situation.

[Livingston]

Geht mir auch so. Wann das Ding zuschlägt, kann ich dem auch nicht entnehmen. Hab leider überhaupt keinen Plan von der Programmierung der ext4-Eingeweide
Ich würd mal sagen, man kann sich nur für die Zukunft absichern, wenn man konsequent hashes erstellt (sha256sum/md5sum), sichert und im Verdachtsfall mit frischen Werten abgleicht.

[slu]

Ich lerne hier gerade das es mit Direct I/O zu tun hat:
https://forums.debian.net/viewtopic.php ... 01#p788901

Habe ich bis heute noch nicht gehört:
https://access.redhat.com/documentation ... -direct-io

Ich wüsste gar nicht ob meine Systeme das verwenden und wenn ja wie man das heraus findet...

Edit:
https://www.thomas-krenn.com/de/wiki/Di ... nter_Linux
https://www.thomas-krenn.com/de/wiki/Li ... sts_mit_dd

[Livingston]

Direct I/O is used only by applications (such as databases) that manage their own caches.

Datenbanken, und vielleicht auch ein paar andere Programme... nicht so ungewöhnlich.

[Cordess]

Erwähnenswert wäre noch, wer sich den kaputten Kernel bereits eingefangen hat, sollte das System mit dem alten Kernel, also nicht dem kaputten Kernel booten um danach dann erst die Updates auf den nun gefixten Kernel einzuspielen.

Grund:
Es macht Sinn Schreibzugriffe mit dem kaputten Kernel zu vermeiden.

[dasebastian]

Da ich da überhaupt keinen Durchblick habe und es bei mir eine Angelegenheit von einer guten halben Stunde ist, habe ich gerade vorher die Atombombe gezündet und neu installiert.

Backup hatte ich noch von vorgestern, besser mit dem weiterarbeiten als "weiterzuzittern" ob da mal irgendwann irgendwo (vielleicht schon mit korrumpiertem Backup) was kommt.

Jetzt werden grad die Daten zurückgespielt, das Terminal freut sich und ich fühle mich nicht mehr verunsichert.

[kalle123]

Da ich da überhaupt keinen Durchblick habe und es bei mir eine Angelegenheit von einer guten halben Stunde ist, habe ich gerade vorher die Atombombe gezündet und neu installiert.

Backup hatte ich noch von vorgestern, besser mit dem weiterarbeiten als "weiterzuzittern" ob da mal irgendwann irgendwo (vielleicht schon mit korrumpiertem Backup) was kommt.

'Backup' bezieht sich auf deine Persönlichen Daten, nicht auf das System?!

Dann denke vielleicht mal drüber nach, so was wie timeshift zu nutzen. Hab auch ein blödes Gesicht gemacht, gestern gerade 12.3 eingespielt und dann gelesen, was da passiert ist. Umgehend das System auf einen früheren Sicherungspunkt (bei mir hier war das die weekly Sicherung vom 5.12.) und ich war wieder zurück auf 12.2.

Gruß KH

[dasebastian]

In meinem Backup sind schon auch ein paar systemrelevante Konfigurationen und Skripte dabei.

Ich bin eigentlich mittlerweile ganz zufrieden mit meinem Backupsystem.

[MSfree]

Da ich da überhaupt keinen Durchblick habe und es bei mir eine Angelegenheit von einer guten halben Stunde ist, habe ich gerade vorher die Atombombe gezündet und neu installiert. :lol

Völlig überflüssige Aktion. Du hättest doch nur den 6.1.0.14er purgen brauchen und dann den letzten Kernel booten können. So habe ich es jedenfalls mit meinem Bookworm gemacht, nachdem ich diesen Thread gelesen hatte.

Inzwischen habe ich mit

Code: Alles auswählen

apt-get install linux-image-amd64

den 6.1.0.15er eingespielt bekommen und alles ist wieder im Lot.

[dasebastian]

Völlig überflüssige Aktion. Du hättest doch nur ...

Das ist jetzt wieder so eine Antwort, wo ich mir

I c h fühle mich besser damit. Ob du das überflüssig findest oder nicht.

[cosinus]

I c h fühle mich besser damit. Ob du das überflüssig findest oder nicht.

Statt einem dist-upgrade auf ein neues Release machst du ja auch lieber eine Neuinstallation

[dasebastian]

Ach cosy, ich wusste, dass du kommst, wenn ich dir so ein schönes Leckerli hinwerfe, gelt?!

[cosinus]

Ach cosy, ich wusste, dass du kommst, wenn ich dir so ein schönes Leckerli hinwerfe, gelt?!

Wenn dir Neuinstallationen eine Freude bereiten ist doch alles gut

[TuxPeter]

Ist bei einem normalen Update soeben bei mir komplett und ohne Meldungeni durchgelaufen.

[cosinus]

Ist bei einem normalen Update soeben bei mir komplett und ohne Meldungeni durchgelaufen.

Wie jetzt? Du hast eben grad 6.1.0-14 installiert?

[dasebastian]

Eher gleich auf 12.4.

[MSfree]

Wie jetzt? Du hast eben grad 6.1.0-14 installiert?

6.1.0-14 wurde aus dem Debian Repository entfernt, der läßt sich nicht mehr installieren, auch nicht versehentlich.

[TuxPeter]

Code: Alles auswählen

$ uname -r
6.1.0-15-amd64