Schlagwort: Debian

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.


Kernel aus Backports installieren

21. Juli 2022 · Betriebssysteme · andreas · Kein Kommentar

Je nach verwendeter Hardware fehlt mit ein bißchen Pech im Kernel der Debian-Stable-Version altersbedingt die Unterstützung für einige Hardware-Komponenten.

Das aktuelle Debian Bullseye verwendet standardmäßig den Kernel 5.10

$ uname -a
Linux *** 5.10.0-16-amd64 #1 SMP Debian 5.10.127-1 (2022-06-30) x86_64 GNU/Linux

Glücklicherweise gibt es als einfache und Distributions-konforme Lösung für solche Fälle das Backports-Repository:

Backports are packages taken from the next Debian release (called “testing”), adjusted and recompiled for usage on Debian stable. Because the package is also present in the next Debian release, you can easily upgrade your stable+backports system once the next Debian release comes out. [Quelle]

Die Backports bieten die Möglichkeit, mit Hilfe der gewohnten Paketverwaltung - sofern bereitgestellt - auf eine neuere Version eines Pakets zu aktualisieren, ohne dabei ein Franken-Debian zu erschaffen.

Als erstes müssen, sofern dies nicht bei der Installation des Systems bereits angewählt wurde, die Backports in der Datei “/etc/apt/sources.list” ergänzt werden:

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

Dann kann man sich nach einem “apt update” auf die Suche nach einem passenden Kernel machen:

$ sudo apt search linux-image
Sortierung… Fertig
Volltextsuche… Fertig
...
linux-image-5.10.0-11-amd64/stable-security 5.10.92-2 amd64
Linux 5.10 for 64-bit PCs (signed)
...
linux-image-5.18.0-0.bpo.1-amd64/bullseye-backports 5.18.2-1~bpo11+1 amd64
Linux 5.18 for 64-bit PCs (signed)
...

In der Liste werden alle Kernel-Versionen angezeigt, die installiert werden können, i.d.R. ist die Version mit möglichst wenigen Zusätzen im Namen die richtige:

$ sudo apt install linux-image-5.18.0-0.bpo.1-amd64/bullseye-backports
...
Version »5.18.2-1~bpo11+1« (Debian Backports:bullseye-backports [amd64]) für »linux-image-5.18.0-0.bpo.1-amd64« gewählt.
...
Die folgenden NEUEN Pakete werden installiert:
  linux-image-5.18.0-0.bpo.1-amd64
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

Nach erfolgreicher Installation reicht ein Neustart, um mit dem aktualisierten Kernel zu starten.

$ uname -a
Linux *** 5.18.0-0.bpo.1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 5.18.2-1~bpo11+1 (2022-06-14) x86_64 GNU/Linux

Im GRUB-Menü kann jederzeit wieder der bisher verwendete Kernel gestartet werden und falls der neue Kernel wieder entfernt werden soll, reicht ein einfaches “sudo apt purge …”, um die Installation rückgängig zu machen.


Debian 11, GNOME und RDP: Oh no! Something has gone wrong

27. Mai 2022 · Betriebssysteme · andreas · Kein Kommentar

Während eine RDP-Verbindung zum GNOME-Desktop mit Debian 10 problemlos funktionierte, wurde nach einem Upgrade auf Debian 11 jeder Verbindungsversuch mit “Leider ist ein Problem aufgetreten.” beendet:

Die Problematik ist sowohl auf Github unter “On Debian 11 upgraded install I get “Oh no! Something has gone wrong.” when connecting.” als auch in dem Debian Bug Report “xRDP connection results in Oh No ! something has gone wrong..Logout when Gnome Desktop used” dokumentiert, die Ursache liegt wohl in einem Fehler in der von Debian 11 ausgelieferten “xorgxrdp-0.2.12”-Version.

Da es aktuell kein fehlerbereinigtes Paket in den Standard-Paketquellen gibt, kann behelfsweise ein Paket von https://snapshot.debian.org/ verwendet werden. Die im oben genannten Github-Thread vorgeschlagenen Paketversionen “xorgxrdp_0.2.15-1_amd64.deb” sowie “xrdp_0.9.15-1_amd64.deb” laufen nach manueller Installation ohne weitere Abhängigkeiten in der Debian 11-Umgebung und ermöglichen wieder einen Zugriff auf den GNOME-Desktop mit RDP:

$ wget https://snapshot.debian.org/archive/debian/20210302T032219Z/pool/main/x/xorgxrdp/xorgxrdp_0.2.15-1_amd64.deb
...

$ wget https://snapshot.debian.org/archive/debian/20210302T032219Z/pool/main/x/xrdp/xrdp_0.9.15-1_amd64.deb
...

$ sudo apt install ./xorgxrdp_0.2.15-1_amd64.deb 
...
Die folgenden Pakete werden aktualisiert (Upgrade):
  xorgxrdp
1 aktualisiert, 0 neu installiert, 0 zu entfernen und 5 nicht aktualisiert.
...

$ sudo apt install ./xrdp_0.9.15-1_amd64.deb 
...
Die folgenden Pakete werden aktualisiert (Upgrade):
  xrdp
1 aktualisiert, 0 neu installiert, 0 zu entfernen und 5 nicht aktualisiert.
...

Spende an das Debian-Projekt

4. Januar 2022 · IMHO · andreas · 2 Kommentare

Der Beitrag “Spendenempfänger 2021” bei blog.jakobs.systems hat mir den letzendlichen Schubs gegeben, selbst auch eine Spende in Richtung des Debian-Projekts loszuschicken.

Gemäß dem dort zitierten Motto “Tue Gutes und erzähl’ davon” hilft vielleicht die Erwähung hier, den Gedanken noch etwas weiter zu verbreiten. Lediglich der von Debian empfohlene Weg

Die einfachste Möglichkeit, Geld an Debian zu spenden, ist über Paypal an Software in the Public Interest, eine gemeinnützige Organisation, die treuhändisch Vermögen für Debian verwaltet. [Quelle]

die Spende an “Software in the Public Interest” ausgerechnet über PayPal abzuwickeln, fühlt sich irgendwie seltsam an.


Debian Stable und Firefox ESR

13. Dezember 2021 · Anwendungen · andreas · 1 Kommentar

Ausgangssituation

Die Debian-Veröffentlichungen gliedern sich in drei Varianten, von denen “stable” für die Verwendung durch den Ottonormalbenutzer empfohlen wird:

The release of Debian called “stable” is always the official released version of Debian. Ordinary users should use this version. [Quelle]

Stabil bedeutet hierbei

once released, the operating system remains relatively unchanging over time. [Quelle]

Im Rahmen eines sog. Freeze werden zu einem bestimmten Zeitpunkt Programme in den zu diesem Zeitpunkt aktuellen Versionen eingefroren, welche dann Teil der nächsten “stable”-Veröffentlichung werden. So war zum Beispiel bei der Veröffentlichung von Debian 10 Libreoffice 6 aktuell und ist auch zum jetzigen Zeitpunkt in Debian 10 noch enthalten, der Wechsel zu Version 7 wurde erst mit Debian 11 durchgeführt.

Dies garantiert eine weitestgehend stabile Arbeitsplattform, auf der nicht durch Updates bestehende und funktionierende Prozesse gefährdet werden, da i.d.R. nur sicherheitsrelevante Änderungen in einmal veröffentlichte Programmpakete integriert werden.

Es gibt nur wenige Ausnahmen von diesem Schema, eine davon ist Firefox, welcher von Debian in der ESR (Extended Support Release)-Version ausgeliefert wird.

Leider reicht aber der verlängerte Support-Zeitraum der ESR-Versionen nicht aus, um die komplette Lebensspanne einer Debian-“stable”-Veröffentlichung zu begleiten, so daß innerhalb einer Stable-Version das Firefox ESR-Paket aktualisiert werden muss. Aktuell steht der Wechsel von Version 78 zu Version 91 an, der sich leider auf Grund einiger Randbedingungen spürbar verzögert.

Die Betreuer des Pakets laden nicht nur das fertige Binärpaket von der Mozilla-Website und verteilen es neu, es wird stattdessen eine eigene Version von Firefox aus dem öffentlich zugänglichen Quelltext gebaut und verteilt, wozu aber erst zahlreiche hierfür verwendete Werkzeugpakete angepasst werden müssen, was Zeit benötigt.

Lösungsmöglichkeiten

Da der Einsatz des nicht mehr aktuellen Browsers auf Grund mehrerer Sicherheitslücken nicht mehr empfehlenswert ist, gibt es verschiedene Möglichkeiten, zumindest temporär auf eine aktuellere Version auszuweichen, bis eine aktualisierte Browserversion bereitgestellt wird.

Flathub / snap

Vorteil (oder Nachteil) der Lösung ist, daß nicht nur die Anwendung heruntergeladen wird, sondern auch alle Bibliotheken, welche die Anwendung zur Laufzeit benötigt und die Anwendung mit “ihren” statt den im System installierten Bibliotheken ausgeführt wird. Somit müssen nicht wie bei einem “normalen” System die passenden Bibliotheken systemweit installiert werden, sondern die Anwendung kann gekapselt mit den für sie zuständigen Bibliotheken laufen, während der Rest des Systems andere Versionen verwenden kann.

Nachteil ist, daß irgendwelche Bibilotheken im Zweifelsfall mehrfach auf dem System vorhanden sind und falls der Ersteller des Pakets z.B. eine Bibliothek, die Sicherheitsprobleme hat, nicht aktualisiert, ist und bleibt das eben so. Mit ein bißchen Pech wird somit durch die Hintertür die Systemsicherheit ausgehebelt. Ob es dann reicht, daß die unsichere Bibliothek in der jeweiligen Umgebung läuft, bleibt im Ernstfall spannend …

Da es sich um eine temporäre Zwischenlösung handeln soll, ist dieser Ansatz nur dann interessant, wenn aus anderen Gründen sowieso bereits eine der beiden Umgebungen in Betrieb ist.

Direkter Download von Mozilla

Hier wird lediglich die aktuelle Binärversion des Browsers heruntergeladen, entpackt und in das System eingebunden. Für den geplanten Einsatzzweck also perfekt geeignet.

Umsetzung

Als erstes wird die aktuelle ESR-Version von der Mozilla-Website heruntergeladen:

$ wget 'https://download.mozilla.org/?product=firefox-esr-latest-ssl&os=linux64&lang=de' -O "$HOME/Downloads/firefox-esr.tar.bz2"

und dann nach “/opt” entpackt:

$ cd /opt
$ sudo tar xfvj "$HOME/Downloads/firefox-esr.tar.bz2"

Theoretisch gäbe es auch die Möglichkeit, die Dateien innerhalb des “$HOME”-Verzeichnisses zu entpacken und zu verwenden, aus Sicherheitsaspekten ist davon aber abzuraten: der Browser hat standardmäßig Schreibrechte im kompletten “$HOME”-Verzeichnis und könnte somit im Schadensfall auch die eigenen Programmdateien modifizieren.

Als letzter Schritt muß noch die “.desktop”-Datei angepasst werden. Unter GNOME kann dies wie folgt erledigt werden:

$ cp /usr/share/applications/firefox-esr.desktop ~/.local/share/applications/

Anschließend die soeben kopierte Datei bearbeiten

$ vi ~/.local/share/applications/

und den Pfad in der Zeile

Exec=/usr/lib/firefox-esr/firefox-esr %u

in

Exec=/opt/firefox/firefox %u

ändern. Nach einmal ab- und wieder anmelden wird von der kompletten Oberfläche die neu installierte Version verwendet. Da sich Firefox 78 und 91 auch optisch deutlich unterscheiden, ist die Ausführung des neueren Browsers jederzeit klar erkennbar und man braucht nicht panisch nach jedem Browserstart die Version zu kontrollieren.

Der so installierte Browser läuft hier seit einiger Zeit problemlos, lediglich beim ersten Start musste das richtige Profil gewählt werden.

Sobald Firefox 91 ESR in Debian integriert ist, reicht es, den Ordner “/opt/firefox” sowie die Datei “~/.local/share/applications/firefox-esr.desktop” zu löschen.