Fehlerhafter Kernel in Debian 12.3

10. Dezember 2023 · Betriebssysteme · andreas · 2 Kommentare

Gestern wurde die Verteilung von Debian 12.3 gestoppt. Grund dafür ist ein Fehler im Kernel 6.1.64-1, der zur Beschädigung von Daten auf ext4-Dateisystemen führen kann.

Debian 12.3 image release delayed

December 9th, 2023

Due to an issue in the ext4 file system with data corruption in kernel 6.1.64-1, we are pausing the planned Debian 12.3 point release images for today while we attend to fixes.

Please do not upgrade any systems at this time, we urge caution for users with UnattendedUpgrades configured.

Genauere Informationen gibt es im Debian Bug-Report “linux: ext4 data corruption in 6.1.64-1

Sofern die Systeme nach der Aktualisierung des Kernels noch nicht neu gestartet wurden, war der fehlerhafte Kernel auch noch nicht aktiv und es wird weiterhin der Vorgänger benutzt:

$ uname -a Linux *** 6.1.0-13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.55-1 (2023-09-29) x86_64 GNU/Linux

Es ist noch der Kernel 6.1.55-1 vom 29. September (Debian Paket 6.1.0-13) aktiv, welcher den Fehler nicht enthält.

$ apt list --installed | grep linux-image WARNING: apt does not have a stable CLI interface. Use with caution in scripts. linux-image-5.10.0-26-amd64/now 5.10.197-1 amd64 [Installiert,lokal] linux-image-6.1.0-13-amd64/stable,now 6.1.55-1 amd64 [Installiert,automatisch] linux-image-6.1.0-14-amd64/stable,now 6.1.64-1 amd64 [Installiert,automatisch] linux-image-amd64/stable,now 6.1.64-1 amd64 [installiert]

Der fehlerhafte Kernel ist installiert und würde beim nächsten Systemstart verwendet werden. Das fehlerhafte Kernel-Paket wird deinstalliert, so daß auf jeden Fall sichergestellt ist, daß bei einem Neustart weiterhin der Kernel 6.1.55-1 verwendet wird.

$ sudo apt remove linux-image-6.1.0-14-amd64 ... Die folgenden Pakete werden ENTFERNT: linux-image-6.1.0-14-amd64 linux-image-amd64 ...

Soweit im Debian Forum zu lesen, schlägt ein Versuch, die Kernel-Installationsdatei “linux-signed-amd64/linux-image-6.1.0-14-amd64_6.1.64-1_amd64.deb” herunterzuladen mit einen “403 Forbidden”-Fehler fehl, so daß der fehlerhafte Kernel auch nicht mehr heruntergeladen werden kann.


Manuell neue Domain zu Firefox Multi-Account Containers hinzufügen

09. Dezember 2023 · Anwendungen · andreas · Kein Kommentar

Die Firefox Multi-Account Containers sind eine offizielle Erweiterung von Mozilla, die hoffentlich bald nativ im Browser eingebaut wird. Aufgabe ist die Trennung des Website-Speichers in Tab-spezifische Container, d.h. Cookies, die in einem Container vorhanden sind, sind in anderen Containern nicht verfügbar.

Im Gegensatz zur Funktionalität ist die Verwaltbarkeit leider alles andere als gelungen - in der aktuell verfügbaren Version können nur im Browser geöffnete Domains einer Umgebung hinzugefügt werden, das manuelle Hinzufügen einer Domain zu einer Umgebung ist nicht vorgesehen. Dies hat den Nachteil, daß bei allen Websites, welche mit Redirections arbeiten, die Multi-Account Containers nur eingeschränkt verwendet werden können.

Glücklicherweise kann hier mittels “about:debugging”, der Entwicklerwerkzeuge und der Javascript-Konsole Anbhilfe geschaffen werden. Das Vorgehen wurde von Philip Snowberger in “Another way to manually add another site to Firefox Multi-Account Containers” auf Github beschrieben:

Nach dem Starten des Debug-Modus wird zuerst das Objekt einer Domain ausgelesen, zu deren Umgebung eine weitere Domain hinzugefügt werden soll.

Im konkreten Beispiel soll die Domain “accounts.ebay.de” der Umgebung hinzugefügt werden, in der “www.ebay.de” bereits vorhanden ist:

obj = Object(await browser.storage.local.get("siteContainerMap@@_www.ebay.de"))

Dann wird eine Kopie der vorhandenen Einstellungen unter dem Zielnamen angelegt

obj["siteContainerMap@@_accounts.ebay.de"] = obj["siteContainerMap@@_www.ebay.de"]

und die ursprüngliche Domain aus dem ausgelesenen Objekt gelöscht:

delete obj['siteContainerMap@@_www.ebay.de']

Als letzter Schritt wird das Objekt zurückgeschrieben

await browser.storage.local.set(obj)

womit die Tab-Umgebung um die neue Domain erweitert wurde.


Saga 2005-12-09 Bildergalerie

05. Dezember 2023 · Konzerte · andreas · Kein Kommentar

Saga am 09. Dezember 2005 im Quasimoto in Pirmasens


Hörenswert #109: Bruce Dickinson - Afterglow Of Ragnarok

02. Dezember 2023 · Hörenswert · andreas · Kein Kommentar

19 Jahre nach dem 2005 erschienenen “Tyranny Of Souls” erscheint mit “The Mandrake Project” 2024 ein neues Soloalbum von Bruce Dickinson. Wie die Vorgängeralben erneut in Zusammenarbeit mit Roy Z entstanden, legt die erste Single “Afterglow Of Ragnarok” die Messlatte für den Rest des Albums recht hoch. Die Spannung steigt …


apt ignoriert Zammad beim Distributionsupgrade

30. November 2023 · Betriebssysteme · andreas · Kein Kommentar

Beim Upgrade von Debian 11 (Bullseye) auf Debian 12 (Bookworm) wurde das komplette System wie vorgesehen aktualisiert, lediglich das Zammad-Paket zeigte in der Weboberfläche die falsche Version:

Dies ist Zammad Version 6.1.0-1700492762.96ac5a60.bullseye

Was auf auch ein Anzeigefehler in Zammad hätte sein können, wurde von dpkg bestätigt

$ dpkg -s zammad ... Version: 6.1.0-1700492762.96ac5a60.bullseye ...

und apt zeigte keinerlei Motivation, das Paket zu aktualisieren.

$ sudo apt update ... Alle Pakete sind aktuell.

Daß die eigentlich richtige Datei zur Installation zur Verfügung stand, bestätigte ein Aufruf von “apt-cache policy”

$ sudo apt-cache policy zammad zammad: Installiert: 6.1.0-1700492762.96ac5a60.bullseye Installationskandidat: 6.1.0-1700492762.96ac5a60.bullseye Versionstabelle: *** 6.1.0-1700492762.96ac5a60.bullseye 100 100 /var/lib/dpkg/status 6.1.0-1700492762.96ac5a60.bookworm 500 500 https://dl.packager.io/srv/deb/zammad/zammad/stable/debian 12/main amd64 Packages ...

Trotz offensichtlich verfügbarer Bookworm-Installationsdatei hielt apt die Bullseye-Version für geeigneter. Die Suche nach der Ursache bzw. deren Lösung führte zum Beitrag “Distupgrade debian buster to bullseye - zammad still shows buster version” im Zammad-Forum, der für das Upgrade von Bullseye auf Bookworm noch genauso gilt. Dort erklärt MrGeneration vom Zammad-Core-Team:

Due to the way our version numbers are generated, you end up in

6.0.0-1692176490.0e2399eb.buster
6.0.0-1692176490.0e2399eb.bullseye

those versions. Versioning is done alphabetical. So buster vs bullseye apart from the rest of the version string being the same is your issue.

Das gleiche Verhalten tritt auch hier auf: beim Vergleich der beiden Versionen “6.1.0-1700492762.96ac5a60.bullseye” und “6.1.0-1700492762.96ac5a60.bookworm” ist apt nach Vergleich der Versionsnummern der Meinung, daß “bullseye” neuer als “bookworm” ist und behält deshalb die Bullseye-Version, statt auf die Bookworm-Version zu aktualisieren. Dies kann man auch mit dpkg evaluieren:

$ dpkg --compare-versions 6.1.0-1700492762.96ac5a60.bookworm lt 6.1.0-1700492762.96ac5a60.bullseye && echo "älter" älter

Die im oben verlinkten Beitrag vorgeschlagene Lösung eines “apt remove zammad” gefolgt vom einem “apt install zammad” ist zumindest im Fall des Upgrades von Bullseye auf Bookworm nicht notwendig, da Zammad auch in der Bullseye-Version problemlos arbeitet.

Mit der nächsten Änderung der tatsächlichen Versionsnummer wurde dann auch auch auf das Bookworm-Paket aktualisiert:

... Preparing to unpack .../zammad_6.1.0-1701163867.5a81e629.bookworm_amd64.deb ... Unpacking zammad (6.1.0-1701163867.5a81e629.bookworm) over (6.1.0-1700492762.96ac5a60.bullseye) ... Setting up zammad (6.1.0-1701163867.5a81e629.bookworm) ... ...