Linux Mint und Opera – wenn Videos im Web nicht abgespielt werden können

Es war mal wieder ein neues Notebook fällig, und da hab ich natürlich das ressourcenschonende Linux Mint in der aktuellen Version 22 draufgespielt. Dazu Opera (seit beinahe Jahrzehnten mein Lieblingsbrowser) als .deb-Paket von der Original-Opera-Website heruntergeladen und nachinstalliert. Nachdem ich alles so eingestellt, konfiguriert und ausgestattet hatte, war ja erst mal alles schön soweit – bis auf die kleine Endlos-Geschichte, dass sich die Linux-Version von Opera nicht ihre Größeneinstellung auf dem Desktop merkt und ich nach dem Aufruf den Browser jedesmal erst mal größerziehen muss – ob die Opera-Foundation das jemals hinkriegt?

Was ich hier aber ansprechen will: Wenn man wie oben beschrieben vorgeht, wird man irgendwann feststellen, dass man Videos (z. B. auf X, facebook oder von mir aus auch auf einschlägigen XXX-Sites 😉 ) nicht abspielen kann. Entweder es passiert gar nichts oder es kommen so ominöse Fehlermeldungen wie „Source not available“ oder ähnlich. Das Problem liegt in der im .deb-Paket von Opera mitgelieferten Bibliothek namens libffmpeg.so, die für das Abspielen von MPEG-Filmchen im Browser sorgen soll. Die von Opera im .deb-Paket mitgelieferte libffmpeg.so passt nicht zu der Version, wie sie das aktuelle Linux Mint bzw. die zugrundeliegende Ubuntu-Version benötigt. Die Datei, wie sie von Opera verwendet wird, findet man unter ./usr/lib/x86_64-linux-gnu/opera/libffmpeg.so . Was also tun? Ich habe ausgehend vom Root-Ordner ‚/‘ mit sudo find -name libffmpeg.so das Laufwerk durchsucht, ob es vielleicht noch an anderen Orten eine passende libffmpeg.so gibt (von anderen Browsern, Multimedia-Programmen oder gar der eigenen Distribution), die man testweise ersetzen kann. War in meinem frisch installierten Linux Mint aber nicht der Fall.

Ich habe mir wie folgt beholfen: Ich habe einfach das Chromium-Paket aus dem Repository installiert, darin müsste doch auch eine passende und funktionierende libffmpeg.so vorhanden sein. Und das war auch der Fall. Die habe ich dann einfach ins Opera-Verzeichnis kopiert – und Bingo! Videos spielen jetzt, wie sie sollen. Hier im Einzelnen meine Vorgehensweise im Terminal auf der Linux-Shell:

Chromium installieren: sudo apt install chromium

Nachsehen, wo die „neue“ libffmpeg.so liegt: sudo find -name libffmpeg.so – vorher natürlich ‚cd /‘ eingeben. sudo sorgt als root-User dafür, dass man beim Suchlauf nicht tausende von Directories um die Ohren gehauen kriegt, für die man keine Berechtigung hat.

Nun fanden sich zwei der gesuchten Dateien: /usr/lib/chromium/libffmpeg.so – die brauchen wir! – und /usr/lib/x86_64-linux-gnu/opera/libffmpeg.so – die soll ersetzt werden. Nun wird letztere einfach mit der ersteren überschrieben:

sudo cp /usr/lib/chromium/libffmpeg.so /usr/lib/x86_64-linux-gnu/opera/libffmpeg.so

Ängstliche Zeigenossen sichern vorher die Opera-eigene libffmpeg.so, damit man diese wieder an ihren ursprünglichen Ort zurückspielen kann, falls was schiefgeht. „sudo“ ist hier beim Umkopieren erforderlich, weil man als gemeiner User keine Schreibrechte auf die lib-Datei hat, und die soll ja überschrieben werden.

Und das war’s auch schon. Falls Opera noch offen ist, einmal schließen und wieder aufrufen – und wie man sieht, kommt nun auch bei xHamster & Co. Bewegung ins Bild \o/

Ach ja, wenn man den Chromium nicht weiter braucht, kann man das Paket danach getrost wieder deinstallieren (spart ungefähr 340 MB auf der Platte), denn die lib-Datei, die wir brauchten, ist ja nun dort, wo sie hingehört. Chromium-Paket entfernen geht wie folgt:

sudo apt purge chromium

Nun fragt man sich jetzt abschließend nur noch, was passiert, wenn ein Opera-Update kommt und man danach wieder das gleiche Problem hat. Dann muss man kurzerhand die libffmpeg.so von Chromium einfach wieder überbügeln. Aber das hab ich in den letzten Jahren noch nie gebraucht.

Defektes NTFS-Laufwerk retten und kopieren – so geht’s mit gddrescue

Mein Artikel „Linux rennt beim Booten in initramfs – was tun?“ hat, wie man den Kommentaren entnehmen kann, vielen Menschen geholfen, ihr Linux-System wieder zum Starten bewegen zu können. Ich wurde gelegentlich auch nach den Ursachen gefragt, wie es dazu kommen kann. Meistens liegen die Gründe in fehlerhaften Laufwerken oder Problemen im Dateisystem. Letztere kann man aber in der Regel mit fsck beheben (wenn z. B. während eines Schreibzugriffs auf die Platte ein Absturz erfolgte und dadurch das Dateisystem inkontinent wurde 😀 ). Auch bei mir kam es in der letzten Zeit auf einem Dual-Boot-Notebook mit LinuxMint 19 und Windows 10 vermehrt zum initramfs – und auch unter Windows kam es immer häufiger zu den berüchtigten Bluescreens mit anschließendem Neustart. Hier lag es nun daran, dass die Festplatte nach acht Jahren intensivem Einsatzes erste Schwächen aufzeigte. Arbeiten damit ging noch irgendwie, aber nachdem nun auch unter Linux nach Schreibzugriffen auf das Laufwerk (insbesondere bei Updates) das Dateisystem auf read-only gesetzt wurde und außer Alarmmeldungen, dass ich den Systemadministrator benachrichtigen soll, nun gar nichts mehr ging, war es doch mal an der Zeit, nach Abhilfe zu schauen.

Also habe ich mir eine neue 2,5″-HDD für das Notebook bestellt. Der Plan war, mit Tools wie CloneZilla oder mit dem Linux-eigenen dd das komplette Laufwerk sektorenweise 1 : 1 auf die neue Platte zu kopieren. Ich habe einen PC hergenommen, die beiden Platten an die SATA-Anschlüsse gehängt und die Maschine mit einem bootfähigen USB-Stick mit Ubuntu 20.4 gestartet. Quell- und Ziellaufwerk (bzw. die kaputte und die neue HDD) waren schnell ausgemacht, CloneZilla hat mich gut geführt und der Kopiervorgang konnte starten. Beim Lesen auf der Windows-10-NTFS-Partition wurden dann aber vermehrt Lesefehler auf dem Quell-Laufwerk festgestellt, einzelne Sektoren waren schlichtweg nicht mehr lesbar, was – je nach Einstellungen unter CloneZilla – entweder zum Komplettabbruch des Kopiervorgangs oder zu endlos wiederholten Leseversuchen auf den schadhaften Blöcken führte. Nachdem Stunden verstrichen waren und der Fortschritt immer langsamer wurde, habe ich einfach hart abgebrochen und ich dachte mir: „Das Ding ist wohl ZU intelligent – probierstes mal mit dem schlichten, einfachen dd.“ Ich wollte ja einfach nur eine 1-zu-1-Kopie der Platte erstellen – mit allen enthaltenen Fehlern, die man später auf der neuen Platte dann immer noch in aller Ruhe reparieren kann. Mit dd habe ich noch jeden Datenträger im Originalzustand (insbesondere SD-Karten, siehe hier) kopiert bekommen. Aber selbst in diesem Fall führte dd beim Erreichen der NTFS-Partition zu Lesefehlern und Abbrüchen. Scheint also ein echtes Hardware-Problem zu sein.

Nach eingehenden Recherchen bin ich dann auf das Linux-Tool GNU ddrescue gestoßen (kann in den Paketquellen der aktuellen Debian-Distros mit

sudo apt-get install gddrescue

installiert werden). Bei gddrescue handelt es sich um eine Art erweitertes dd mit zusätzlichen Funktionen zur Rettung und Wiederherstellung von defekten Bereichen auf Festplatten. Man geht dabei in zwei Etappen vor. Angenommen, die alte Festplatte, die ich retten und kopieren möchte, sei /dev/sda, und die neue Platte sei /dev/sdb (welche nun welche ist, kann man schnell z. B. mit lsblk oder gparted ermitteln, CloneZilla hat zuvor auch bereits darüber Auskunft gegeben). Dann erfolgt ein erster Kopiervorgang mit folgendem Terminalbefehl:

sudo ddrescue -n --force /dev/sda /dev/sdb ddrescue.log

Nun wird das Quelllaufwerk – ohne Abbrüche durch schadhafte Sektoren – blockweise auf die neue Platte übertragen, inklusive aller Partitionstabellen, Boot-Sektoren, MBR usw. Der Parameter „-n“ sorgt dafür, das nicht lesbare Bereiche auf der Festplatte zunächst übersprungen werden, damit der Kopiervorgang alle Teile, die „noch gut“ sind, auf die neue Platte übernommen werden können. Der Clou bei diesem Vorgang ist nun die Datei „ddrescue.log“. Hier werden alle Adressen der nicht mehr lesbaren Sektoren gespeichert, was im zweiten Schritt nutzbar gemacht werden kann. Uff – primäres Ziel ist aber erst mal erreicht: 99,99 Prozent des Quell-Laufwerks waren noch lesbar. Der erste Kopier- und Analysevorgang hat bei einer 500-GB-Platte etwa drei Stunden gedauert.

Im zweiten Schritt nimmt sich gddrescue nun die geschriebene Log-Datei vor und kratzt in einem sogenannten Scraping-Verfahren intensiv genau an den Stellen auf der Platte herum (natürlich nur lesenderweise), die zuvor in der ddrescue.log als fehlerhaft markiert wurden. Hier wird nun versucht, aus den schadhaften Sektoren vielleicht doch noch das eine oder andere wiederherstellen zu können. Der dazugehörende Terminalbefehl ist fast identisch mit dem obigen, nur ohne den Parameter „-n“:

sudo ddrescue --force /dev/sda /dev/sdb ddrescue.log
gddrescue
Im oberen Schritt erkennt man den ersten Kopierlauf. Im unteren Teil sieht man, wie gddrescue versucht, das Letzte aus den schadhaften Sektoren herauszuholen.

Der zweite Durchgang hat dann in meinem Fall nochmal etwa eineinhalb Stunden gedauert. Um es abzuschließen: Nachdem der zweite Durchgang beendet war und ich die Kiste sauber runtergefahren habe (man weiß ja nie, was vielleicht doch noch im Cache nicht auf die Platte geschrieben wurde), habe ich die neue Platte im Ursprungs-Notebook eingebaut und zunächst Windows gebootet. Hier hat er erstmal einen großmächtigen chkdsk durchgeführt, der nochmal eine Stunde gedauert hatte, und dann lief alles reibungslos. Neustart mit Grub und Start von LinuxMint – hier lief dann alles auf Anhieb wieder problemlos, auch Updates ließen sich problemlos schreiben. Gerettet…

Zu beachten ist auf jeden Fall, dass keins der beteiligten Laufwerke während der Arbeit mit ddrescue gemountet sein darf. Daher ist die Lösung mit einem bootfähigen Live-Linux per USB-Stick (geht natürlich auch mit einer Boot-DVD) die sauberste.

Es versteht sich von selbst, dass man die defekte Platte noch komplett löscht und überschreibt, bevor man sie der Elektroschrott-Entsorgung zuführt.

Nur den Stunden-Aufwand darf man nicht in Lohn umrechnen 🙂 Nicht auszudenken, was ein bezahlter Fachmann für diese Nummer genommen hätte. Aber das sehr spezielle Notebook komplett neu aufzusetzen wäre dann doch weitaus zeitintensiver gewesen.

USB-WLAN-Stick wird von Ubuntu-Linux beim Booten nicht erkannt

Hier hab ich mal etwas, was mich zuletzt auf einem Raspberry 2 vor sechs Jahren ständig genervt hatte: Beim Booten einer neu aufgesetzten Linux-Maschine (Ubuntu 20.04) wird ein WLAN-Dongle, welcher der Kiste per USB die Verbindung zur Außenwelt herstellen soll, nicht erkannt – oder zumindest nicht immer. Einmal rausziehen und wieder einstöpseln – und es geht. Muss man erst mal drauf kommen – aber eine Dauerlösung kann dieser unnötige zusätzliche Handgriff natürlich nicht sein. Also was tun?

Wie es bei diesen Realtek-WLAN-Sticks immer wieder mal vorkommt, gibt es während des Bootvorganges ein Timing-Problem mit dem notwendigen Kernel-Modul. Wenn man nun die Produkt-ID des Dongles und die Bezeichnung des zuständigen Kernel-Moduls herausbekommt, kann man mit ein paar wenigen Terminal-Befehlen diesem kleinen Problem Abhilfe schaffen. Wenn der WLAN-Stick also in Betrieb ist (wie gesagt: nach dem Start ggf. einmal ziehen und wieder stecken), sieht man mit dem Terminal-Befehl lsusb | egrep ‚Realtek‘ u. a. die benötigten Hardware-IDs, die wir später noch brauchen werden. Dort erscheint dann z. B. Folgendes:

Bus 003 Device 005: ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter

Nun geht es noch darum, den Namen des zuständigen Kernelmoduls herauszubekommen. Dazu gibt man den Befehl lsusb -t ein. Hier erscheinen in einer Art Baumstruktur alle vorhandenen USB-Ports und die angeschlossenen Geräte mit ihren jeweiligen Modulen. Aus dem o. g. Beispiel wissen wir, dass unser WiFi-Stick an Bus 003 als Device 005 hängt. Und genau danach halten wir in der Ausgabe von lsusb -t Ausschau. Dort sollte eine Zeile wie die Folgende erscheinen:

Port 7: Dev 5, If 0, Class=Vendor Specific Class, Driver=r8188eu, 480M

Nun wissen wir also auch, dass das gesuchte Modul in diesem Falle r8188eu heißt. Probieren wir also aus, ob wir das Modul entladen können:

sudo modprobe -rfv r8188eu

Wenn Sie bis hierher alles richtig gemacht haben, muss die LED am WLAN-Stick ausgehen. Nach dem erneuten Laden mit

sudo modprobe -v r8188eu

geht die LED wieder an und Sie sind sofort wieder drahtlos online. So weit, so schön – nun müssen wir nur noch dafür sorgen, dass dieses Modul nicht sofort während des Bootens (also zu früh) geladen wird, sondern der Stick passend ins USB-Subsystem eingebunden wird. Und das funktioniert mit folgenden zwei Befehlszeilen:

echo „blacklist r8188eu“ | sudo tee /etc/modprobe.d/blacklist_r8188eu.conf

echo ‚SUBSYSTEM==“usb“, ATTR{idVendor}==“0bda„, ATTR{idProduct}==“8179„, RUN+=“/sbin/modprobe r8188eu„‚ | sudo tee /etc/udev/rules.d/10_realtek_wlan_stick.rules

Bei dem Modulnamen (hier „r8188eu“) setzen Sie natürlich Ihren Modulbezeichner ein, den Sie zuvor ermittelt haben (bei manchen WLAN-Sticks heißt er z. B. 8192eu oder ähnlich). Bei den ATTR-IDs (hier 0bda bzw. 8179) setzen Sie die IDs ein, die Sie oben mit lsusb herausbekommen haben.

Das sollte es dann auch schon gewesen sein. Einmal die Kiste neu starten – und Sie sind auf Anhieb online.

Windows-Uhr geht auf einer Linux-Dual-Boot-Maschine zwei Stunden nach – hier die Abhilfe

Heute mal wieder etwas, das mir alle Jubeljahre immer wieder passiert, wenn ich einen Dual-Boot-PC aufsetze, auf dem Windows und eine Linux-Distribution laufen sollen. Nachdem man die beiden Betriebssysteme eingerichtet hat, stellt man fest, dass unter Windows 7/8/10 die Uhrzeit eine Stunde bzw. während der Sommerzeit zwei Stunden nachgeht. In früheren Zeiten musste man, um dies zu beheben, mühsam in den ntp-Einstellungen unter Linux herumfuhrwerken oder aber unter Windows die Uhrzeit ständig manuell synchronisieren. Heute geht das viel einfacher – hier erfahren Sie, wie!

Das eigentliche Problem ist, dass sowohl Linux als auch Windows ihre aktuelle Uhrzeit innerhalb des Betriebssystems speichern, jedoch nicht die Hardware-RTC-Uhr des Rechners aktualisieren. Um dies zu beheben, müssen beide Betriebssysteme dazu gebracht werden, die Uhrzeit in der PC-Uhr zu speichern. Unter aktuellen Linux-Distros, die mit systemd laufen – Ubuntu, Fedora, LinuxMint usw. – gibt man zunächst folgenden Befehl in ein Terminal ein:

timedatectl set-local-rtc 1 --adjust-system-clock

Hierdurch wird das System veranlasst, die Uhrzeit künftig in der RTC-Uhr des BIOS zu aktualisieren. Mit

timedatectl

können Sie dann nachprüfen, ob die Einstellung richtig angenommen wurde. Hier sollte nun u. a. „RTC in local TZ: yes“ zu lesen sein. Die anschließende Warnung, dass es nicht gut sei, die RTC statt der Software-Uhr zu aktualisieren, können wir geflissentlich übersehen.

Unter Umständen könnte es nach einem Reboot aber sein, dass Windows immer noch die falsche Zeit anzeigt. Dies kann man in der Registry fixen. Hierzu also regedit aufrufen und den Pfad HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation suchen. An dieser Stelle trägt man nun ein neues DWORD mit der Bezeichnung RealTimeIsUniversal ein und setzt darin den Wert 1. Dies sorgt dafür, dass die Hardware-Uhrzeit, die ja in UTC (internationale Weltzeit, früher GMT) gespeichert ist, gemäß Ihrer Zeitzone (etwa ME[S]Z, Berlin) und der aktuell gültigen Sommer- oder Normalzeit unter Windows richtig angezeigt wird.

Nach einem erneuten Reboot und Windows-Start erscheint nun dauerhaft die korrekte, lokal gültige Uhrzeit.

Dass Sie mit der Windows-Registry vorsichtig umgehen sollten, versteht sich von selbst – ich gehe davon aus, dass Sie wissen, was Sie tun. Eine Haftung für zerschossene Windows-Maschinen kann ich natürlich nicht übernehmen.

Linux rennt beim Booten in initramfs – was tun?

Es ist mir – in größeren Abständen – schon zweimal passiert: Nach einem Kernel-Update von LinuxMint 18.3 bzw. 19 rennt das System nach dem Reboot in einen initramfs-Prompt. Erst mal ist der Schreck groß: System platt? Platte hinüber? Oder viel Reparaturarbeit? Zunächst glaubte ich, dass GRUB versucht, von einer falschen Partition zu starten – dieses Problem hatte ich ja schon mal nach dem Upgrade auf Windows 10 auf einem Dual-Boot-System hier beschrieben, als Win10 die GRUB-Konfiguration zerstört hatte. Aber hier lag das Problem doch etwas anders.

Der initramfs-Prompt erscheint immer dann, wenn ein Linux-System bootet und etwas mit dem Dateisystem nicht in Ordnung ist. Der Prompt „(initramfs)“ erscheint bei LinuxMint im Rahmen einer BusyBox. Um das System dazu bringen, wieder wie gewohnt zum Login-Bildschirm zu booten, muss das Dateisystem repariert werden. Dazu sind nur drei Schritte erforderlich:

  1. Zunächst gibt man „exit“ <Enter> ein, um aus dem initramfs-Prompt rauszukommen. Hier werden nun einige Fehlermeldungen angezeigt, die darauf hinweisen, dass fsck (linux-eigenes Tool zum Reparieren von Dateisystemfehlern) manuell ausgeführt werden muss. Wichtig ist hier die Zeile „The root filesystem on /dev/xxx requires a manual fsck“. Diese Zeile zeigt das Laufwerk bzw. das Root-Verzeichnis an, auf dem repariert werden muss. Bei mir war dies /dev/sda9.
  2. Nun startet man mit fsck </dev/Boot-Dateiverzeichnis> -y und <Enter> den Reparaturvorgang. In meinem Fall also „fsck /dev/sda9 -y“. Je nach Festplattengröße und Anzahl der Fehler kann die Reparatur einige Minuten dauern.
  3. Nun startet man mit „reboot“ das System neu. Wenn alles gutgegangen ist, landet man jetzt wieder im Login-Menü von LinuxMint.

Linux Mint KDE 18.3 (Sylvia) auf 19 updaten – und es geht DOCH mit KDE!

Linux Mint 18.3 war bekanntlich die Version, mit der letztmalig auch eine KDE-Desktopumgebung ausgeliefert wurde. Deren Support läuft im April 2021 aus; seit Linux Mint 19, die bereits im Juni 2018 veröffentlicht wurde, gibt es für die KDE-Editionen früherer Linux-Mint-Versionen keine Upgrade-Möglichkeiten mehr. Mit ein bisschen Know-how kann man jedoch Mint-19.x-Neuinstallationen mit KDE-Plasma 5 manuell ausstatten; Anleitungen dazu gibt es genug im Netz. In meinem Fall stand ich jedoch vor der Situation, dass ich auf einem Notebook, das ich in produktivem Einsatz habe, eine langjährige, sehr speziell eingerichtete und konfigurierte Linux-Mint-18.3-KDE-Installation betreibe (mit Eigenentwicklungen, speziellen Compiler-Umgebungen, Autoren-System und Peripherie-Schnittstellen), die ich nur sehr ungern plattmachen und mit der 19er-Version neu bespielen wollte. Was also tun?

Nach eingehenden Recherchen bin ich zunächst zu folgendem Ergebnis gekommen: Ich hätte die 18.3er KDE-Installation auf MATE oder Cinnamon umrüsten können, aber das wäre nach wie vor nicht upgradefähig gewesen, weil der „Unterbau“ weiterhin auf KDE beruht, den sich die Linux-Mint-Macher für ihre Zwecke seinerzeit „passendgemacht“ haben (diesen Aufwand will man ab Linux Mint 19 nicht mehr betreiben, deshalb gibt es kein Linux Mint mit KDE mehr). Es gibt also keinen regulären Weg des Updates (es sei denn, mit viel händischem Einsatz, der den Aufwand aber nicht rechtfertigt).

Ich arbeite seit den 90er Jahren mit KDE-Anwendungen und möchte gerne dieser Desktopumgebung treu bleiben. Irgendwann bin ich dann auf dieses Posting in einem KDE-Forum gestoßen, in dem beschrieben wird, wie man Linux Mint KDE 18.3 (Sylvia) eben doch auf Version 19 (Tara) upgraden, dabei bei KDE bleiben und die bisherige Installation beibehalten kann. Risikofreudig, wie ich nun mal bin, habe ich den Versuch gewagt, und es funktioniert – bis auf ein paar wenige kleine Maleschen, die man aber leicht beheben kann! Wie also geht man vor?

1. Man öffnet ein Terminal/eine Konsole und öffnet nacheinander die Repositories-Dateien mit dem Lieblings-Editor (nano, vi – was auch immer), als da wären:

/etc/apt/sources.list.de/official-package-repositories.list

/etc/apt/sources.list.de/ubuntu-defaults.list

In beiden Dateien ersetzt man überall dort, wo „xenial“ steht, dieses durch „bionic“. Das sorgt dafür, dass der Ubuntu-Unterbau von Linux Mint von 16.4 auf 18.4 upgedatet wird. Gleichzeitig wird mit dieser Einstellung während des Upgrades der KDE-Desktop mit Plasma 5 von den Kubuntu-Backport-Repositories nachinstalliert.

Halt, die beiden Dateien noch nicht speichern und beenden! Es fehlt noch etwas: Überall dort, wo „sylvia“ erscheint, dieses löschen und durch „tara“ (für Linux Mint 19) ersetzen. Dies sorgt für das eigentliche Upgrade von Linux Mint 18.3 auf 19. Nun speichern und den Editor schließen.

2. Nun beginnt es spannend zu werden. Mit den gespeicherten Einstellungen wird die Installation mit sudo apt-get update auf den neuesten Stand gebracht. Es müssen aber noch einige Voraussetzungen geschaffen werden, damit das Upgrade auch gestartet werden kann. Dazu müssen apt, mintupdate und die libgtk-Bibliotheken vorab auf den Stand von Ubuntu 18.4 gebracht werden:

sudo apt-get install apt

sudo apt-get install mintupdate libgtk-3-0 libgtk-3-bin

3. Jetzt wird es noch spannender. Nun muss man sich einmal aus- und wieder einloggen. Und hier könnte es ein erstes Problem geben. Bei mir war es so, dass sich die grafische Oberfläche nach dem Login nicht mehr aufbauen wollte, was durch das libgtk-Update ja auch nachvollziehbar ist. Aber das ist nicht wirklich ein Problem, denn wir brauchen nur ein textbasiertes Terminal, und das bekommt man ja z. B. mit Strg-Alt-F2. Hier kann man sich dann einloggen und stößt nun das ersehnte Upgrade an mit

sudo apt-get dist-upgrade

Je nach Geschwindigkeit der Internetverbindung und der Leistungsfähigkeit des Rechners kann man nun getrost etwa zwei Stunden Kaffee trinken oder sonstwas Unanständiges tun. In meinem Fall zog er sich etwas über 3 GB an Updates rein mit anschließenden Anpassungen, Compilierungen usw. usf. Kleiner Tipp am Rande: Bevor Sie diesen Durchgang starten, kontrollieren Sie, ob Sie möglicherweise noch alte Linux-Kernel, -Module und -Header installiert haben. Genau das hatte ich nämlich vorab nicht überprüft – mit dem Ergebnis, dass er sich äußerst zeitaufwändig so an die 30 alte Kernel, Modules und Header reingepfiffen, konfiguriert und in GRUB eingepflegt hat – völlig überflüssigerweise. Im Laufe der letzten Jahre hat er bei jedem Kernel-Update die alten Kernel ja nicht automatisch gelöscht – und ich auch nicht 😉 Ein gelegentlicher Blick aufs Display kann nicht schaden, denn gelegentlich erwartet er eine Eingabe, wenn es darum geht, eine conf-Datei zu aktualisieren. In den allermeisten Fällen sollte man die bereits bestehende Datei beibehalten (wird auch fast immer als Default vorgegeben).

Wenn nun alles gut durchgelaufen ist, kann man mit sudo reboot das Schätzchen neustarten. Nach erfolgtem Login begrüßt einen dann die neue KDE-Plasma-5-Oberfläche. Und das Schönste: Alle bisherigen Icons bleiben erhalten, alle Anwendungen sind weiterhin vorhanden. Nur der Desktop-Hintergrund ist ein neuer.

4. Wenn nun aber der dist-upgrade-Lauf mit Fehlermeldungen abbricht, dann konnte apt irgendwelche Package-Abhängigkeiten nicht auflösen. Hier kann man dann versuchen, mit sudo dpkg –configure -a diesen Mangel zu beheben. Bei mir war meine spezielle, nicht-standardgemäße Python-Installation Schuld an einigen unlösbaren Abhängigkeiten („Paket xyz setzt Paket abc voraus, dieses kann aber nicht installiert werden“ usw.). Möglicherweise löst o.g. dpkg-Befehl durch seine Reparatur einen erneuten Komplett-Download des Updates aus. Falls auch – wie bei mir – der dpkg-configure-Befehl zu weiteren Fehlern führt, behebt man diese mit sudo apt install –fix-broken (der dpkg-Befehl gibt an dieser Stelle den falschen Hinweis aus, es mit „apt –fix-broken install“ zu versuchen, was durch die falsche Options-Reihenfolge natürlich zu nichts führt).

5. Nachdem man nun sämtliche Fehler beseitigt hat, geht man nochmals den gesamten Upgrade-Lauf durch, also sudo apt-get update, sudo apt-get upgrade und sudo apt-get dist-upgrade. Abschließend sollte man vor einem Neustart mit sudo apt-get install -f noch einmal checken, ob es noch irgendwelche Probleme gibt, die es zu beheben gilt (eigentlich unnötig, wenn der dist-upgrade-Lauf komplett durchgelaufen ist, aber sicher ist sicher). So, und nun aber endlich sudo reboot und sich an der neuen Oberfläche erfreuen.

Ob man auf diese Weise von Linux Mint KDE 18.3 auch direkt auf die neueren Versionen 19.1 (Tessa), 19.2 (Tina) oder 19.3 (Tricia) upgraden kann, kann ich nicht sagen. Ich denke aber: eher nicht. Ich empfehle, erst mal auf die 19 (Tara) upzugraden, um dann später bei Bedarf auf eine aktuellere Version umzusteigen. Man weiß ja nie, ob die 19.1 oder spätere etwas von der 19 voraussetzen. Für alle drei Versionen läuft der Support bis April 2023.

Update 12.07.: Wie ich soeben erfahre, ist vor einigen Tagen die Linux-Mint-Version 20 erschienen. Diese setzt als Upgrade eine Version 19.3 voraus. Aber ich freue mich, dass wir erst einmal erfolgreich in der Linux-Mint-19er-Welt angekommen sind!

Leistungs-Index unter Windows 7: Zugriff auf primäres Laufwerk nicht möglich. Falscher Parameter.

Ich habe auf einem Arbeitsrechner, mit dem ich mein Geld verdiene, immer noch Windows 7 im Einsatz. Nun habe ich kürzlich dem PC eine neue SSD spendiert und das Gesamtsystem unter Linux mit „dd“ von der alten HDD rüberkopiert. Hat alles bestens funktioniert und der SSD-Performancegewinn macht Spaß.

Nun habe ich heute aber mal nach langer Zeit das Leistungs-Index-Tool unter Windows 7 gestartet. Das hat auch alles brav gecheckt – bis zu dem Punkt, wo es darum geht, den Datendurchsatz der Festplatte zu messen. Da brach das Tool mit der Fehlermeldung „Zugriff auf primäres Laufwerk nicht möglich. Falscher Parameter.“ ab. Mein erster Gedanke war natürlich: „Da hab ich wohl irgendwas noch mit der neuen SDD nicht richtig eingestellt.“ Auf der Kommandozeile „winsat disk“ eingegeben – das ergab die selbe Fehlermeldung. Na ja, das Leistungs-Index-Tool ist ja nicht so wichtig, ansonsten läuft ja alles – aber das wollte ich dann doch genauer wissen.

Es hat einige Zeit gedauert, bis ich den Übeltäter entdeckt habe: die Antiviren-Software AVAST! Diese gräbt sich sehr tief in die Windows-Registry ein und hebelt dort einiges aus – mit der Folge, dass die Festplatte nicht mehr richtig parametrisiert wird. AVAST verhindert direkte HDD-/SDD-Zugriffe und leitet diese für den Echtzeitschutz über eigene Dienste um. So ohne Weiteres lässt sich AVAST jedoch auch nicht restlos deinstallieren, und genau aus diesem Grund bietet das Unternehmen auch ein separates Deinstallationstool namens AvastClear.exe an (Download). Die exe-Datei einfach auf den Desktop ablegen und das System im abgesicherten Modus (während des Bootvorganges F8 drücken) starten. Nun die AvastClear.exe per Doppelklick starten. Wärend des Ablaufs der Deinstallationsroutine sieht man sehr deutlich, welche Dateien, Kernel und Registry-Einträge eliminiert werden.

Anschließend Windows 7 wieder „normal“ starten. Erster Test mit „winsat disk“ auf der Kommandozeile: Juhuuu, dort tut er nun was. Dann nochmal das Leistungs-Index-Tool gestartet und durchlaufen lassen: Yippieh, die SSD hat eine Top-Performance!

Doch jetzt steht das Ding völlig ohne Virenschutz da! Nun hätte ich AVAST neu installieren können, aber nach diesem Reinfall habe ich mich für einen anderen Weg entschieden, nämlich für den Windows Defender! Das MS-eigene Antivirenprogramm hat in der Systemsteuerung einen eigenen Eintrag und ist schnell aktiviert und aktualisiert. Während in früheren Zeiten der Defender eigentlich nur für einen grundlegenden Schutz gut war, so hat er in den letzten Wochen und Monaten in vielen Tests durch die üblichen Verdächtigen (Heise & Co.) in seiner aktuellen Version durch seine sehr hohe Infektions-Erkennungsrate überrascht. Im Übrigen geht der Defender auch und gerade im Echtzeitschutz sehr schonend und sparsam mit den Ressourcen um. Ich gebe dem Windows Defender also mal eine Chance und werde beobachten.

Raspberry Pi: So verkleinert man SD-Card-Images

Wer Backups macht, ist nur zu faul zum Neu-Aufsetzen eines Systems. Und so erstelle auch ich immer wieder mal in loser Folge Images von meinen SD-Cards, die ich auf meinen Raspberries zu verschiedenen Produktiv-Zwecken im Einsatz habe. Nun ist es mir jedoch schon mehrfach vorgekommen, dass z. B. ein Image einer 8-GB-Karte nicht auf eine andere (neue) 8-GB-Karte passt, weil auf dieser einige wenige Byte an Speicherplatz fehlen (insbesondere SDHC-Karten von Intenso und CnMemory sind häufig von wenigen kB bis mehreren MB kleiner als ihre Kollegen von z. B. SanDisk oder Transcend). Nachdem ich kürzlich eine neue Karte nicht mit dem Image eines dringend benötigten Backups beschreiben konnte, stand ich erst mal blöd da. Speicherkarten sind bei mir nicht gerade Kartonware 😉

Nun habe ich aber einen Weg gefunden, wie man unter Linux mit dem eigentlich genialen Partitionierungstool GParted ein SD-Card-Image, das ich z. B. mit dd (Linux) oder Win32DiskImager erzeugt habe, verkleinern kann. Eine Datenpartition ist ja in den seltensten Fällen bis zum letzten Bit mit Nutzerdaten aufgefüllt, so dass sich diese problemlos verkleinern lässt, damit sie auf eine neue SD-Karte passt. Nun ist es jedoch so, dass GParted nur auf physische Geräte (Festplatten, Memory-Cards usw.) schreiben kann, nicht jedoch auf Image-Dateien. Wie reduziert man also Image-Dateien bzw. die darin enthaltenen Partitionen?

Um Image-Dateien und die darin enthaltenen Partitionen zu verkleinern, braucht man nur drei Tools, die in den meisten Linux-Distrtibutionen bereits enthalten sind: 1. GParted, 2. fdisk und 3. truncate. Wie gesagt – GParted kann nur auf physischen Geräten (Devices) arbeiten, nicht jedoch auf Images. Deshalb müssen wir als Erstes ein Device für das Image erstellen. Dafür nutzen wir die Loopback-Funktion unter Linux. Falls diese noch nicht aktiviert sein sollte, tun wir dies mit

sudo modprobe loop

Nun kann man mit

sudo losetup -f

das Device /dev/loop0 bereitstellen. Nun erstellen wir aus der Imagedatei.img das Device /dev/loop0:

sudo losetup /dev/loop0 Imagedatei.img

Soooo – das Device /dev/loop0 ist somit schon mal vorhanden, es enthält den Gesamtinhalt von Imagedatei.img. Wir wollen jedoch die einzelnen Partitionen bearbeiten, die darin enthalten sind. Also geben wir diese dem Kernel wie folgt bekannt:

sudo partprobe /dev/loop0

Dieser Befehl gibt uns/dev/loop0p2 zurück – die zweite verfügbare Partition in der Imagedatei.img. Dies ist das Device (= Partition), mit dem GParted arbeiten kann (die /dev/loop0p1 ist die kleine FAT16-Partition, die der Raspberry Pi zum Booten benötigt – die belassen wir so, wie sie ist).

Nun geht es endlich daran, die Partition zu verkleinern. Dazu starten wir GParted wie folgt:

sudo gparted /dev/loop0

Hier klicken wir oben auf die Partition /dev/loop0p2 (Aktivieren) und anschließend auf den Button „Verändern/Verschieben“ (die Schaltfläche, die so ähnlich aussieht wie ein Play-Button). In dem Fenster, das nun erscheint, sehen wir einen Balken, der die Größe der Partition sowie den tatsächlich genutzen Speicherplatz anzeigt. Den rechten Rand des Balkens kann man jetzt mit der Maus nach links ziehen – bis zur gewünschten reduzierten Partitionsgröße. Anschließend klickt man auf „Ändern/Verschieben“. Nun sind wir wieder im Hauptfenster (s. o.) und siehe da: Die Partition ist jetzt kleiner und es wird der neu gewonnene freie Speicherplatz angezeigt – so sieht es zumindest aus. Jetzt noch oben in der Button-Leiste auf den Haken klicken – und los geht’s. Wenn alles gut geht (d. h. wenn die Imagedatei keine Fehler enthält), wird jetzt ca. 2 – 3 Minuten lang aufgeräumt und umsortiert. Sobald diese Prozedur abgeschlossen ist, können wir GParted schließen. Das Loopback-Device /dev/loop0 brauchen wir nicht mehr, also geben wir das Device wieder frei mit

sudo losetup -d /dev/loop0

Nun ist bereits viel erreicht, aber wenn wir uns die Imagedatei.img mit ls -l ansehen, so sehen wir, das sie immer noch genauso groß ist wie zuvor. Wir müssen noch den durch die Partitionsverkleinerung freigewordenen Speicherplatz freigeben, damit das Image auf eine neue, kleinere SD-Karte passt. Dazu müssen wir wissen, auf welchen Speicherblöcken die Partition beginnt und endet. Hierfür benutzen wir fdisk:

fdisk -l Imagedatei.img

Hier sehen wir in etwa Folgendes:

Hier achten wir auf das Gerät mit der Bezeichnung Imagedatei.img2 in der untersten Zeile. Im Bild endet es im Sektor 9404415 (abhängig jeweils davon, um wieviel die Partition in GParted verkleinert wurde). Oben sehen wir, dass jeder Sektor 512 Byte groß ist. Das Beispiel im Bild zeigt, dass unsere (verkleinerte) Partition an Byte 9404415 x 512 endet. Alles, was dahinter kommt, ist unser freier und ungenutzter Speicherplatz, um den wir die Imagedatei.img verkleinern wollen.

Dazu nutzen wir abschließend das Tool truncate. Als Parameter benötigen wir wiederum den End-Block der Partition 2, in diesem Beispiel also 9404415 und die Blockgröße 512 Byte. In der Praxis sieht der Befehl so aus:

truncate –size=$[(9404415+1)*512] Imagedatei.img

Nun ist das Ziel erreicht: Die Imagedatei hat jetzt die reduzierte Größe und wir können das Image auf eine neue SD-Card schreiben. Das mache ich mit

sudo dd if=./Imagedatei.img of=/dev/mmcblk0 bs=1M

Überzeugen Sie sich zuvor mit „df“, ob /dev/mmcblk0 wirklich Ihr SD-Card-Device ist!

Raspberry 2 (Wheezy): GCC und G++ auf 4.8 updaten – so geht’s

Ich habe auf einem älteren Raspberry Pi 2B noch ein Raspbian/Wheezy laufen, auf dem einige spezielle Anwendungen ihren Dienst tun, deren Entwickler von Zeit zur Zeit ihre Updates als C++-Sourcen via Github veröffentlichen. Nun ist passiert, was irgendwann ja mal passieren musste: Der Compiler gab nach einem Update einige Fehler aus, weil einige benötigte Funktionen nicht verfügbar waren. Mit anderen Worten: GCC musste von der etwas betagten Version 4.6.3 auf (mindestens) 4.7 upgedated werden. Diese ist jedoch so ohne Weiteres nicht auf dem alten Raspian Wheezy per apt verfügbar. Und einfach mit „sudo apt-get install gcc-4.7“ eine neue Version drüberbügeln – damit allein ist es nicht getan. Was also tun?

Nach einigen Recherchen bin ich auf diese Anleitung gestoßen. Die habe ich Schritt für Schritt abgearbeitet. Und seitdem kann ich wieder neue Releases problemlos compilieren.

Zunächst öffnet man mit dem Editor seines Vertrauens (z. B. nano) die Datei /etc/apt/sources.list .

sudo nano /etc/apt/sources.list

Normalerweise steht dort seit Wheezy-Zeiten nur eine Zeile drin, nämlich „deb http://mirrordirector.raspbian.org/raspbian/ wheezy main contrib non-free rpi“. Um Software aus neueren Jessie-Repositories installieren zu können, muss man die sources.list um folgenden Inhalt erweitern:

deb http://mirrordirector.raspbian.org/raspbian/ wheezy main contrib non-free rpi
deb http://archive.raspbian.org/raspbian wheezy main contrib non-free rpi
# Quelltext-Repository aus Raspian Jessie hinzufügen
deb-src http://archive.raspbian.org/raspbian wheezy main contrib non-free rpi
deb http://mirrordirector.raspbian.org/raspbian/ jessie main contrib non-free rpi
deb http://archive.raspbian.org/raspbian jessie main contrib non-free rpi
deb-src http://archive.raspbian.org/raspbian jessie main contrib non-free rpi

Nun die sources.list speichern und schließen. Jetzt fügt man im Verzeichnis /etc/apt/ eine Datei namens „preferences“ hinzu (sudo nano preferences) und schreibt dort Folgendes hinein:

Package: *
Pin: release n=wheezy
Pin-Priority: 900
Package: *
Pin: release n=jessie
Pin-Priority: 300
Package: *
Pin: release o=Raspbian
Pin-Priority: -10

Auch diese Datei speichern und schließen. Nun fährt man auf den eigenen Software-Stand ein Update mit „sudo apt-get update“. Nachdem das durchgelaufen ist, ist man in der Lage, GCC und G++ 4.8 aus den Jessie-Repositories zu installieren. Das geht mit

sudo apt-get install -t jessie gcc-4.8 g++-4.8

Das dauert nun etwas. Zwischendurch wird man gefragt, ob sämtliche noch laufende Dienste neu gestartet werden dürfen (u. a. Apache). Diese Abfrage bestätigt man mit „Yes“. Falls noch andere GCC-/G++Versionen auf dem Raspi vorhanden sein sollten, entfernt man diese mit

sudo update-alternatives --remove-all gcc 
sudo update-alternatives --remove-all g++

Wenn man will (oder muss, weil aus irgendwelchen Gründen noch ältere Versionen benötigt werden), kann man diese auch wieder hinzufügen:

sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.6 20
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.8 50
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.6 20
sudo update-alternatives --install /usr/bin/g++ g++ /usr/bin/g++-4.8 50

Soooooo – ab sofort ist GCC 4.8 der Standard-Compiler auf der Himbeere (Testen mit „gcc -v“). Falls man evtl. andere GCC-Versionen aktivieren möchte, so geht das mit

sudo update-alternatives --config gcc
sudo update-alternatives --config g++

Raspberry Pi verliert WLAN-Verbindung: die ultimative Abhilfe

Wer einen Raspberry Pi mit USB-WLAN-Stick (z. B. Edimax) im 24/7-Betrieb laufen hat, der kennt das Problem: Sobald der WLAN-Hotspot auch nur kurzzeitig weg ist – sei es durch übermäßigen Traffic durch andere Teilnehmer oder durch Nachtabschaltung -, schaltet das WLAN-Plugin des RasPi ab. Man hat dann keine Chance mehr, administrativ per SSH auf den Raspberry zuzugreifen und es hilft nur ein harter Reset oder „Stecker raus – Stecker rein“, um das Ding neu zu starten und online zu bringen. Mehr als einmal ist es mir schon passiert, dass ich auf die Art die SD-Card zerschossen habe.

Nun habe ich mir endlich mal die Zeit dafür genommen, nach Abhilfe für dieses Problem zu suchen. Auf einem alten Raspberry Pi 2B hab ich seit Ewigkeiten einen kleinen Webserver laufen, dessen Inhalte auch brav bei Bing & Co. indexiert werden. Es ist schon passiert, dass die Webseiten in den Suchmaschinen nicht mehr gelistet wurden, weil der RasPi von mir unbemerkt mehrmals einige Tage nicht mehr am Netz hing – ich schaue ja nicht ständig nach dem zart-bläulichen Blinken der WLAN-LED. Die Suchmaschinen-Bots schauen gelegentlich mal nach, was es bei mir so Neues gibt, erreichen den Server nicht und folgerichtig fliegen die Seiten aus dem Index. Und per Cronjob das Ding in loser Folge neustarten zu lassen, („falls mal was sein sollte“) erschien mir auch recht unprofessionell.

Ich hab mir wie folgt beholfen: Im Verzeichnis /etc/ifplugd/action.d gibt es eine Shellskript-Datei namens ifupdown. Die hab ich umbenannt nach ifupdown.bak (da steht zwar nicht viel drin, aber könnte man ja nochmal brauchen). Danach habe ich im Verzeichnis /etc/wpa_supplicant/ nach der Datei ifupdown.sh Ausschau gehalten. Diese hab ich nach /etc/ifplugd/action.d kopiert und nach ifupdown umbenannt. Die bisherige ifupdown wird dadurch durch eine neue Version ersetzt. Diese versetzt den Raspberry  in die Lage, sich in das vorhandene WLAN-Netzwerk wieder „einzubuchen“, wenn es denn mal weg war. Nun wird der RasPi abschließend mit sudo reboot neu gestartet. Wenn man alles richtig gemacht hat, ist zunächst alles unverändert: WLAN startet, die entsprechende LED blinkt. Nun kann man testen, ob der gewünschte Reconnect funktioniert: Einfach das WLAN abschalten oder den Stecker am Router ziehen, wie auch immer. Jetzt sieht man, dass die LED des WLAN-Moduls in loser Folge kurz aufblinkt und nach „seinem“ Funknetz sucht (bisher ging die LED aus und der RasPi war offline). Sobald der WLAN-Hotspot wieder da ist, verbindet sich der Raspberry Pi wieder binnen wenigen Sekunden. Bei meinen Tests hatte ich vor dem Ausschalten des WLANs eine SSH-Session offen. Nachdem das Netz wenige Minuten weg und dann wieder da war, war die SSH-Verbindung immer noch bzw. wieder unverändert vorhanden – ls -l flog über den Bildschirm, als wenn nichts gewesen wäre.

Einen Haken hat die ganze Sache jedoch: Sobald man den Raspberry auf diese Art umkonfiguriert hat, funktioniert die LAN-Buchse nicht mehr. Also WLAN off und dann Netzwerk-Stecker in die Ethernetbuchse geht nicht. Aber hierfür haben wir ja die ifupdown.bak gesichert. Wenn man also wieder mal ein Netz per Leitung braucht: Einfach die Datei nach ifupdown umkopieren, und schon ist wieder alles beim Alten.