Debian

Torchlight 2 startet nicht mehr nach Debian-Update

9. Juni 2024 · Spiele · andreas · Kein Kommentar

Nach einem Betriebssystem-Update von Debian 11 auf Debian 12 wollte Torchlight 2, das vor dem Update problemlos lief, nicht mehr starten: nach dem Klick auf das Icon erschien nur noch kurz der Spash-Screen … und das war’s - vom eigentlich erwarteten Startschirm fehlte jede Spur.

Torchlight 2

Als erste Möglichkeit zur Fehlersuche bietet sich meist ein Start des Programms über die Kommandozeile an, in der Hoffnung, dadurch vielleicht in paar Statusmeldungen zu sehen. Dies funktioniert auch beim Start von Torchlight 2, welches eine ganze Menge an Meldungen ausgab, bevor es letztendlich mit einem “Speicherzugriffsfehler” abbrach.

$ ./Torchlight2.bin.x86_64

Creating resource group General
Creating resource group Internal
Creating resource group Autodetect
...
Loading library RenderSystem_GL
Path for saving is ...
...
Compressing memory size is: 246
Compressing memory size is: 4559
Speicherzugriffsfehler

Leider führte die Kombination von “Torchlight 2” und “Speicherzugriffsfehler” bei der Suche nach Lösungsmöglichkeiten nicht zu hilfreichen Ergebnissen. Auch Tips, die in Richtung von Bibliothekskonflikten gingen halfen nicht, das Programm wieder zum Starten zu bewegen.

Zum Ziel führte letztendlich ein Blick in die Datei “ogre.log”, die auf den ersten Blick identisch mit den Ausgaben beim Programmstart aussieht, allerdings noch ein paar zusätzliche Ausgaben enthält:

$ cat ~/.local/share/Runic\ Games/Torchlight\ 2/ogre.log

11:57:15: Creating resource group General
11:57:15: Creating resource group Internal
11:57:15: Creating resource group Autodetect
...
11:57:15: Loading library RenderSystem_GL
11:57:15: OGRE EXCEPTION(7:InternalErrorException): Could not load dynamic library RenderSystem_GL.  System Error: libGLU.so.1: cannot open shared object file: No such file or directory in DynLib::load at /builddir/Torchlight2/ogre170/OgreMain/src/OgreDynLib.cpp (line 94)
11:57:15: Path for saving is ...
...
11:57:16: Compressing memory size is: 246
11:57:16: Compressing memory size is: 4559

So war der entscheidende Hinweis zwischen den Zeilen “Loading library RenderSystem_GL” und “Path for saving is” versteckt, im konkreten Fall ein

System Error: libGLU.so.1: cannot open shared object file: No such file or directory

der sich durch Installation des Pakets libglu1-mesa letzendlich leicht beheben ließ.


Diskussionen um Debian-Paket KeepassXC

24. Mai 2024 · Anwendungen · andreas · Kein Kommentar

In den letzten Tagen sorgte eine Änderung am “KeepassXC"-Paket in Debian für hitzige Diskussionen.

Der grundlegende Gedanke, ein Paket mit minimalem und ein Paket mit vollständigem Funktionsumfang anzubieten ist hierbei nicht ungewöhnlich: eine solche Aufspaltung gibt es bis hin zu den Desktop-Umgebungen, wo z.B. bei der Installation zwischen einem “gnome” und einem “gnome-core"-Paket gewählt werden kann, welches nur den minimal notwendigen Umfang zu Betrieb der Desktopumgebung enthält.

Was allerdings nicht nur mir unangenehm aufstößt ist die Vorgehensweise des Paketbetreuers, der statt der Erstellung eines zusätzlichen “keepassxc-core”-Pakets das ursprüngliche “keepassxc”-Paket um bestehende Funktionalität erleichtert und somit bestehende Installationen mit der nächsten Aktualisierung beschneidet.

Dies ist offensichtlich ohne vorherigen Dialog mit den KeepassXC-Entwicklern geschehen und führt dazu, daß nun vermehrt Anwender bei KeepassXC (nicht vorhandene) Fehler melden, denn

This will be painful for a year as users annoyingly do not read the NEWS files they should be reading but there’s little that can be done about that. [Quelle]

Dieser Satz und vor allem eine Aussage wie

Users who need this crap can install the crappy version but obviously this increases the risk of drive-by contributor attacks. [Quelle]

lässt aber nicht unbedingt (nur) auf sachliche Hintergründe schließen, sondern zeigt deutlich, wo das eigentliche Problem liegt - und erinnert mich von der Grundeinstellung an den Münchner OB Dieter Reiter.

Aktualisierungen:
2024-06-01: Inzwischen scheint die Diskussion beigelegt und der Maintainer hat sich davon überzeugen lassen, daß sein Vorgehen subobtimal war. Wie in Bug 1071847 zu lesen, wird es nun doch ein “keepassxc-minimal”-Paket geben.

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.


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.