Betriebssysteme

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.


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) ...
...

Standard-Ordner in GNOME loswerden

31. Oktober 2023 · Betriebssysteme · andreas · Kein Kommentar

Gut gemeint ist nicht immer gut gemacht, so auch im Falle von GNOME und dessen Dateimanager Files: egal, ob die Ordner verwendet werden oder nicht, den freedesktop.org-Spezifikationen folgend werden bei jedem Login die XDG-Standard-Ordner wie z.B. “Musik” und “Videos” angelegt und auch in der Seitenleiste von Files angezeigt. Eine Möglichkeit, dies innerhalb der Oberfläche zu konfigurieren ist nicht vorgesehen.

This program reads a configuration file, and a set of default directories. It then creates localized versions of these directories in the users home directory and sets up a config file in $(XDG_CONFIG_HOME)/user-dirs.dirs (XDG_CONFIG_HOME defaults to ~/.config) that applications can read to find these directories. [Quelle]

Das Verhalten kann aber mit Hilfe von Konfigurationsdateien angepasst werden.

Ändern der Verzeichnisse

Wer den grundlegenden Mechanismus aktiviert lassen möchte, kann in der Datei “~/.config/user-dirs.dirs” die nicht benötigten Verzeichniseinträge auf sein “home”-Verzeichnis umbiegen.

Dies wird auch so vorgeschlagen:

To disable a directory, point it to the homedir. [Quelle]

Alternativ ist auch ein Auskommentieren der nicht benötigten Zeilen möglich, dies würde aber ggf. dazu führen, daß eine Applikation einen benötigten Ablageort nicht (mehr) findet.

# This file is written by xdg-user-dirs-update
# If you want to change or add directories, just edit the line you're
# interested in. All local changes will be retained on the next run.
# Format is XDG_xxx_DIR="$HOME/yyy", where yyy is a shell-escaped
# homedir-relative path, or XDG_xxx_DIR="/yyy", where /yyy is an
# absolute path. No other format is supported.
#
XDG_DESKTOP_DIR="$HOME/Schreibtisch"
XDG_DOWNLOAD_DIR="$HOME/Downloads"
XDG_TEMPLATES_DIR="$HOME/Vorlagen"
XDG_PUBLICSHARE_DIR="$HOME"
XDG_DOCUMENTS_DIR="$HOME/Dokumente"
XDG_MUSIC_DIR="$HOME"
XDG_PICTURES_DIR="$HOME/Bilder"
XDG_VIDEOS_DIR="$HOME"

Da “home” bereits exisitiert, werden Ordner, welche auf “$HOME” verweisen, nicht nochmal angelegt und auch nicht zusätzlich zum “Persönlichen Ordner” angezeigt. Das Verbiegen einer Variable mit dem Namen “XDG_PUBLICSHARE_DIR” auf “$HOME” hinterlässt aber auf Systemen, auf denen mehr als ein Benutzer aktiv ist, ein ungutes Gefühl.

Abschalten des Mechanismus

Alternativ (oder zusätzlich) kann der Mechanismus auch komplett stillgelegt werden.

At the moment there are only two settings, you can disable the whole thing, and you can specify the charset encoding used for filenames. [Quelle]

Dies kann entweder systemweit über die Datei “/etc/xdg/user-dirs.conf” gesteuert oder benutzerbezogen eingestellt werden.

Hierzu ist die Systemdatei zuerst ins Benutzerverzeichnis zu kopieren

$ cp /etc/xdg/user-dirs.conf ~/.config/

dann kann die Einstellung “enabled” von “True” auf “False” geändert werden:

# This controls the behaviour of xdg-user-dirs-update which is run on user login
# You can also have per-user config in ~/.config/user-dirs.conf, or specify
# the XDG_CONFIG_HOME and/or XDG_CONFIG_DIRS to override this
#

enabled=False

# This sets the filename encoding to use. You can specify an explicit
# encoding, or "locale" which means the encoding of the users locale
# will be used
filename_encoding=UTF-8

Bei der nächsten Anmeldung werden die Ordner nicht mehr neu angelegt und die Einträge in der Seitenleiste von “Files” sind verschwunden.

Dies ist eine Erweiterung zu den Beiträgen “Wahl der Desktopumgebung” und “Eigene Dateien umziehen”, in denen die xdg-user-dirs bereits angesprochen wurden.

Debian 12 "Bookworm" sources.list

7. Juli 2023 · Betriebssysteme · andreas · Kein Kommentar

Als Copy & Paste-Vorlage …

#deb cdrom:[Debian GNU/Linux 12.0.0 _Bookworm_ - Official amd64 NETINST with firmware 20230610-10:21]/ bookworm main non-free-firmware

deb http://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware
deb-src http://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware

deb http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware
deb-src http://security.debian.org/debian-security bookworm-security main contrib non-free non-free-firmware

# bookworm-updates, to get updates before a point release is made;
# see https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports
deb http://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware
deb-src http://deb.debian.org/debian/ bookworm-updates main contrib non-free non-free-firmware

# bookworm-backports, previously on backports.debian.org
deb http://deb.debian.org/debian/ bookworm-backports main contrib non-free non-free-firmware
deb-src http://deb.debian.org/debian/ bookworm-backports main contrib non-free non-free-firmware

# This system was installed using small removable media
# (e.g. netinst, live or single CD). The matching "deb cdrom"
# entries were disabled at the end of the installation process.
# For information about how to configure apt package sources,
# see the sources.list(5) manual.

Debian 12 “sources.list” mit non-free, non-free-firmware sowie backports aktiviert.


GRUB stellt Hintergrundbild nicht dar

23. Februar 2023 · Betriebssysteme · andreas · Kein Kommentar

Während auf anderen Geräten das GRUB-Menü in dem von Debian vorgesehenen Standard-Theme erstrahlte, wurde auf einem frisch installierten Laptop nur die Fallback-Darstellung in Cyan auf blauem Hintergrund gewählt:

GRUB Menu

Funktional ist dies zwar keine Einschränkung, aber die Neugier war geweckt und das “Warum?” wollte gelöst werden. Die Ausgabe von “update-grub” sah vollkommen normal aus, die Einbindung des Hintergrundbildes wurde auch explizit angezeigt:

$ sudo update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
...
done

Nachdem die in GRUB eingebauten Videotests alle erfolgreich waren und auch der Plymouth-Bootsplash wie erwartet angezeigt wurde, musste das Problem an einer anderen Stelle liegen - und so war es auch.

Den entscheidenden Hinweis lieferte der Debiag Bug Report #945404 “grub2-common: ‘/boot/grub/.background_cache.png’ is not created on LUKS encrypted system”: die Datenpartition des Laptops ist verschlüsselt und bei der Überprüfung des Hintergrundbildes erkennt das zuständige Skript nicht, daß beim Booten auf das Bild nicht mehr zugegriffen werden kann. Als möglicher Verursacher wurde Zeile 100 der Datei “/etc/grub.d/05_debian_theme” benannt:

It looks like the command ‘if is_path_readable_by_grub “${1}”; then’ in line 100 in ‘/etc/grub.d/05_debian_theme’ always returns “true”, and therefore ‘/boot/grub/.background_cache.png’ is never created. [Quelle]

“is_path_readable_by_grub” scheint entweder gar nicht zu funktionieren oder im konkreten Fall ein falsches Ergebnis zurückzuliefern.

	# Step #5: Check if GRUB can read the background image directly.
	# If so, we can remove the cache file (if any). Otherwise the background
	# image needs to be cached under /boot/grub/.
	if is_path_readable_by_grub "${1}"; then
		rm --force "${BACKGROUND_CACHE}.jpeg" \
			"${BACKGROUND_CACHE}.png" "${BACKGROUND_CACHE}.tga"
	elif cp "${1}" "${BACKGROUND_CACHE}.${reader}"; then
		set -- "${BACKGROUND_CACHE}.${reader}" "${2}" "${3}"
	else
		return 5
	fi

Als einfacher Test bzw. Workround wurde das Ergebnis der Abfrage durch “false” ersetzt

	if false; then

und die Konfigurationsdatei neu erzeugt:

$ sudo update-grub
Generating grub configuration file ...
Found background image: .background_cache.png
...
done

Nun wurde - wie erzwungen - davon ausgegangen, daß das Hintergrundbild zum Zeitpunkt des Bootens nicht lesbar sein würde und deshalb eine Kopie in einem für GRUB zugreifbaren Bereich erstellt.

Beim nächsten Bootvorgang wurde das GRUB-Menü dann auch mit Theme dargestellt. Ein vielleicht schönerer Workaround als die direkte Änderung der Datei “/etc/grub.d/05_debian_theme” ist im oben genannte Bug Report ebenfalls dargestellt.