Die genauen Umstände des auf den 17. Dezember 2002 datierenden Screenshots lassen sich leider nicht mehr rekonstruieren.
Offensichtlich kam es beim Ausführen der Funktion “Ändern/Entfernen” von Microsoft Office 97 zu einem Systemfehler. Die Wahlmöglichkeit zwischen “Abbrechen” und “Abbrechen” ist allerdings nicht wirklich hilfreich.
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.
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.
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.bullseyethose 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) ...
...
Nach einem Fehler wärend der Cron-Ausführung liefen die Hintergrundjobs der Nextcloud-Instanz unauffällig, die Feeds der App “News” wurden allerdings nicht mehr aktualisiert. Der Strack-Trace des abgebrochenen Cron-Jobs meldete als letzten Eintrag
#6 /***/cron.php(158): OC\BackgroundJob\JobList->setLastJob(Object(OCA\News\Cron\UpdaterJob))
#7 {main}
In der Protokollierung der Nextcloud-Instanz waren keine auf die News-App bezogenen Fehlermeldungen enthalten. Ein manueller Cron-Aufruf lief ebenfalls ohne sichtbare Fehlermeldungen durch und Nextcloud meldete in den Grundeinstellungen
Die letzte Aufgabe lief vor einer Minute.
während sich die News-App über eine letzte Aufgaben-Ausführung vor 11 Stunden beschwerte.
Die Lösung war ein Reset des News-Jobs auf der Kommandozeile
$ php occ news:updater:job --reset
Nach dem Reset wurden die Feeds bei der nächsten Cron-Ausführung wieder ordnungsgemäß aktualisiert.