USB-Sticks auf Fehler prüfen

Im ersten Schritt müsst ihr die Geräte-ID des USB-Sticks oder der Speicherkarte herausfinden. Steckt den Datenträger daher an den Rechner an oder legt die SD-Karte in das entsprechende Lesegerät und gebt im Terminal lsblk ein. Das Kommando listet euch sämtliche am Rechner angeschlossene Datenträger auf. Anhand der Größe des Datenträgers lässt sich in der Regel die Geräte-ID erkennen. In meinem Beispiel bindet das System meinen 8 GByte großen USB-Stick unter sdc (also /dev/sdc in der vollständigen Syntax) ein. Seid ihr euch nicht sicher, dann zieht den zu kontrollierenden Datenträger ab und wiederholt lsblk. Fehlt sdc in der ausgegebenen Liste, dann habt ihr die richtige Kennung. Alternativ lässt sich die Kennung auch mit grafischen Tools wie der Laufwerksverwaltung von Gnome ermitteln.

$ lsblk
[...]
sdc           8:32   1   7,5G  0 disk 
├─sdc1        8:33   1   2,9G  0 part /run/media/toff/Ubuntu 21.10 amd64
├─sdc2        8:34   1   4,1M  0 part 
└─sdc3        8:35   1   300K  0 part 
[...]

Für die eigentliche Fehlersuche kommt nun das Kommando badblocks aus dem Paket e2fsprogs zum Einsatz, das zur Grundausstattung der üblichen Distributionen gehört. Es kann vorkommen, dass sich Badblocks erst einmal weigert, die Überprüfung zu starten, da das Laufwerk bereits vom System benutzt sei. In der Regel kommt das davon, dass das Betriebssystem den Datenträger automatisch einbindet, sobald ihr den USB-Stick ansteckt. Auf meinem System genügt das Antippen des Icons zum Aushängen des Laufwerks im Dateimanager nicht, ich muss die Geräte-ID des Laufwerks und der dazugehörigen Partitionen gezielt mit umount aushängen.

Achtung: An dieser Stelle muss ich eine Warnung schreiben: Beim Prüfen auf Fehler überschreibt Badblocks sämtliche Daten und Partitionen auf dem angegebenen Datenträger. Stellt daher auf jeden Fall sicher, dass ihr die richtige Geräte-ID an das Kommando übergibt und sichert vor der Aktion wichtige Daten vom betroffenen USB-Stick oder der SD-Speicherkarte. Im Fall der Fälle könnt die Daten nach der Fehlerüberprüfung nicht wiederherstellen.

$ sudo badblocks -wsv /dev/sdc
/dev/sdc wird offensichtlich vom System genutzt; es ist zu unsicher, Badblocks zu starten!
$ sudo umount /dev/sdc*
umount: /dev/sdc: nicht eingehängt.
umount: /dev/sdc2: nicht eingehängt.
umount: /dev/sdc3: nicht eingehängt.

Beim Aufruf von Badblocks übergebt ihr dem Kommando die Parameter -wsv sowie die Geräte-ID. Die Parameter weisen das Programm an, einen destruktiven Schreibtest auszuführen (-w), den Fortschritt anzuzeigen (-s) und generell mehr Informationen auszugeben (-v). Der ausführliche Test beschreibt jeden Block des Datenträgers viermal hintereinander mit unterschiedlichen Mustern (0xaa, 0x55, 0xff und 0x00). Je nach Geschwindigkeit und Kapazität müsst ihr dafür eine längere Zeit einplanen. Die Prüfung des von mir im Beispiel benutzten USB-Sticks nach dem USB-2.0-Standard und 8 GByte Kapazität benötigte über eine Stunde.

$ sudo badblocks -wsv /dev/sdc
Es wird getestet Mit Muster 0xaa:   0.00% erledigt, 0:00 verstrichen. (0/0/0 Fehler) erledigt                                             
Lesen und Vergleichen:erledigt
Es wird getestet Mit Muster 0x55:   0.00% erledigt, 23:47 verstrichen. (0/0/0 Fehler) erledigt                                             
Lesen und Vergleichen:erledigt
Es wird getestet Mit Muster 0xff:   0.00% erledigt, 47:33 verstrichen. (0/0/0 Fehler) erledigt                                             
Lesen und Vergleichen:erledigt
Es wird getestet Mit Muster 0x00:   0.00% erledigt, 1:11:26 verstrichen. (0/0/0 Fehler) erledigt                                             
Lesen und Vergleichen:erledigt

Neben der destruktiven Prüfmethode unterstützt Badblocks einen zerstörungsfreien Lesen+Schreiben-Modus. Diesen aktiviert ihr mit dem Parameter -n anstatt von -w. In dieser Variante sichert Badblocks die Daten des geprüften Speicherblocks zuerst in den Arbeitsspeicher, überschreibt dann den Datenblock mit Zufallsdaten und prüft, ob die Daten korrekt geschrieben werden konnten. Abschließend schreibt Badblocks die Sicherung wieder auf den Datenträger zurück. Auf den ersten Blick erscheint die Prüfroutine schneller, da es nur einen Prüfdurchlauf gibt, in der Praxis brauch das Sichern und Zurückschreiben der bestehenden Daten allerdings wesentlich mehr Zeit. In meinem Beispiel anstatt nur etwas mehr als einer Stunde über 2,5 Stunden.

$ sudo badblocks -nsv /dev/sdc
Es wird nach defekten Blöcken im zerstörungsfreien Lesen+Schreiben-Modus gesucht
Von Block 0 bis 7812607
Es wird nach defekten Blöcken gesucht (zerstörungsfreier Lesen+Schreiben-Modus)
Es wird mit zufälligen Mustern getestet:  94.36% erledigt, 2:35:18 verstrichen. (0/0/0 Fehler)

Gefälschte USB-Sticks ermitteln

Einen Schritt weiter geht das Tool F3 oder etwas länger Fight Flash Fraud. Das Open-Source-Programm prüft ausführlich, ob ein Datenträger wirklich die Kapazität besitzt, die er vorgibt zu haben. Ein Thema, das leider immer noch aktuell ist, besonders wenn man super günstige Angebote aus dem Internet kauft. Um gefälschte USB-Sticks oder SD-Speicherkarten aufzudecken, müsst ihr das Programm aus dem Paketquellen installieren. Debian, Ubuntu, Fedora und Co. führen das Konsolenwerkzeug in den offiziellen Repositories, das Paket nennt sich in der Regel f3. Arch Linux führt das Programm nur im AUR, zur Installation braucht ihr daher einen AUR-Helper.

### Installation unter Arch Linux oder Manjaro:
$ yay -S f3
### Installation unter Debian, Ubuntu oder Raspberry Pi OS:
$ sudo apt install f3

Die Kommandos zum Prüfen von USB-Datenträgern lauten nun f3write, f3read und f3probe. Die ersten zwei Befehle müsst ihr in Kombination nutzen. Als Option übergebt ihr den Kommandos jeweils den Mountpunkt des Datenträgers. f3write schreibt nun so lange ein Gigabyte große Dateien auf den eingebundenen Datenträger, bis der Platz ausgeht. Anschließend prüft ihr mit f3read, ob die geschriebenen Daten auch wirklich wieder gelesen werden können. Falls es sich um einen gefälschten USB-Stick oder eine manipulierte SD-Speicherkarte handeln sollte, dann würde f3read korrupte Sektoren ausgeben. Bei dieser Prüfung bleiben alle Daten auf dem Datenträger erhalten, ihr müsst am Ende nur wieder die h2w-Dateien löschen, sonst habt ihr keinen Platz mehr auf dem Stick.

$ f3write /run/media/toff/291E-6F9C
[...]
Free space: 3.72 GB
Creating file 1.h2w ... OK!
Creating file 2.h2w ... OK!
Creating file 3.h2w ... OK!
Creating file 4.h2w ... OK!
Free space: 0.00 Byte
Average writing speed: 3.91 MB/s
$ f3read /run/media/toff/291E-6F9C
[...]
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
Validating file 2.h2w ... 2097152/        0/      0/      0
Validating file 3.h2w ... 2097152/        0/      0/      0
Validating file 4.h2w ... 1518736/        0/      0/      0

  Data OK: 3.72 GB (7810192 sectors)
Data LOST: 0.00 Byte (0 sectors)
	       Corrupted: 0.00 Byte (0 sectors)
	Slightly changed: 0.00 Byte (0 sectors)
	     Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 14.73 MB/s
$ ls -al /run/media/toff/291E-6F9C
insgesamt 3907596
drwxr-xr-x  3 toff toff       4096  1. Jan 1970   .
drwxr-x---+ 4 root root         80  7. Dez 16:27  ..
-rw-r--r--  1 toff toff 1073741824  7. Dez 18:35  1.h2w
-rw-r--r--  1 toff toff 1073741824  7. Dez 18:40  2.h2w
-rw-r--r--  1 toff toff 1073741824  7. Dez 18:44  3.h2w
-rw-r--r--  1 toff toff  777592832  7. Dez 18:47  4.h2w
[...]

Ein wenig schneller arbeitet f3probe --destructive. Die Option --destructive ist optional, die beschleunigt die Aktion jedoch ganz wesentlich. Bei diesem Test beschreibt F3 nur die nötigsten Sektoren und kümmert sich auch nicht um eine Datensicherung. Da die Probe direkt auf die Hardware zugreif, gebt ihr als Parameter nicht den Mountpunkt sondern die Geräte-ID (hier /dev/sdg) an. Der Test mit meinem 4 GByte großen USB-2.0-Stick dauert so nur ein wenig mehr als sieben Minuten. Habt aber bei dieser Prüfung wieder im Hinterkopf, dass die Routine sämtliche Datenblöcke auf dem Datenträger überschreibt.

$ f3probe --destructive --time-ops /dev/sdg
[...]
Good news: The device `/dev/sdg' is the real thing

Device geometry:
	         *Usable* size: 3.73 GB (7831552 blocks)
	        Announced size: 3.73 GB (7831552 blocks)
	                Module: 4.00 GB (2^32 Bytes)
	Approximate cache size: 0.00 Byte (0 blocks), need-reset=no
	   Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 7'17"
 Operation: total time / count = avg time
      Read: 2.73s / 4812 = 568us
     Write: 7'13" / 3637313 = 119us
     Reset: 1us / 1 = 1us

Sowohl Badblocks als auch F3 helfen beim Analysieren von Fehlern auf Datenträgern. Bei der Prüfung müsst ihr allerdings immer ein wenig Zeit mitbringen. Die ausführliche Analyse eines 8 GByte großen USB-Sticks kann schonmal zwei Stunden dauern, besonders wenn bei der Prüfung die Daten erhalten bleiben sollen und der USB-Stick nur mit dem langsamen USB-2.0-Protokoll arbeitet. Danach könnt ihr aber davon ausgehen, dass der USB-Stick oder die SD-Speicherkarte auch wirklich funktionieren und die Kapazität besitzen, die auf dem Aufdruck steht.

Nutzer bekommen das Upgrade nun nicht automatisch auf den RasPi gespielt. Das Upgrade muss man von Hand einleiten. Dabei spielt das System nicht nur einen neuen Linux Kernel auf die Speicherkarte, sondern alle bis dahin aufgelaufenen Neuerungen aus dem Open-Source-Universum rund um GNU/Linux. Für Nutzer des Raspberry Pi 4 oder des Compute Module 4 mit dem aktuellen Chipsatz (zu erkennen an der auf dem Chipsatz aufgedruckten Endung C0T) bedeutet das sogar ein wenig mehr Geschwindigkeit, da das System damit ganz offiziell mit 1,8 GHz laufen darf. Wie bei Distributions-Upgrade allerdings üblich sollte man vor der Aktion ein Backup starten.

System- und Firmware-Upgrade

In meinem kleinen Heimnetz läuft ein Raspberry Pi 3 als kleine eierlegende Wollmilchsau. Der Mini-Rechner filtert mittels PiHole Anzeigen aus dem Datenstrom. Er tunnelt via WireGuard einen sicheren Zugang via VPN durch das Internet ins eigene LAN. Zudem macht mein Raspberry Pi einen steinalten Canon-Scanner netzwerkfähig. Von daher sind bei diesem System einige Dienste eingerichtet und das System an mehr als einer Stelle individuell konfiguriert. Ich war daher skeptisch, ob das Upgrade ohne Komplikationen durchläuft und habe erst einmal ein paar Wochen abgewartet, bis etwaige Schwierigkeiten im Upgrade-Prozess ausgebügelt werden konnten.

### Bestehende Installation auf aktuellen Stand bringen:
$ sudo apt update
$ sudo apt full-upgrade
$ sudo rpi-update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Performing self-update
[...]
 *** Backing up modules 5.10.63-v7+
#############################################################
WARNING: This update bumps to rpi-5.10.y linux tree
See: https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=288234
'rpi-update' should only be used if there is a specific
reason to do so - for example, a request by a Raspberry Pi
engineer or if you want to help the testing effort
and are comfortable with restoring if there are regressions.

DO NOT use 'rpi-update' as part of a regular update process.

##############################################################
Would you like to proceed? (y/N)

Im oben aufgeführten ersten Schritt solltet ihr die bestehende Installation des Raspberry Pi OS auf einen aktuellen Stand bringen. Ich selbst arbeite auf meinen RasPi ohne grafische Oberfläche, logge mich daher via SSH auf dem System ein. Alternativ könnt ihr das Upgrade natürlich aber auch unter der grafischen Oberfläche des Systems ausführen. Der letzte Schritt sudo rpi-update ist optional: Er bringt die direkt auf dem Raspberry Pi installierte Firmware auf den neusten Stand. Wie immer bei solchen Firmware-Updates ist hier Vorsicht angebracht. Theoretisch könnt ihr damit das System in das Nirvana schicken, auf der anderen Seite bügelt solch ein Update aber auch Schwächen aus oder schaltet neue Funktionen frei.

Upgrade auf Buster auf Bullseye

Zur Sicherheit startet ihr das System nach diesem Upgrade einmal durch und kontrolliert, ob der Raspberry Pi auch sicher mit Strom versorgt wird. Das komplette Upgrade hat bei mir in etwa zwei Stunden gedauert, während dieser Zeit sollte der Strom auf keinen Fall ausfallen. Loggt euch nun wieder in das System ein und erstellt zunächst eine Sicherheitskopie der für die Paketverwaltung zuständigen Konfigurationsdatei /etc/apt/sources.list. Das nächste Kommando im folgenden Listing tauscht dann jede Erwähnung von buster gegen bullseyeinnerhalb der Datei. Alternativ könnt ihr diesen Schritt natürlich auch mit einem Texteditor erledigen.

### Upgrade auf Raspberry Pi OS Bullseye einspielen:
$ sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak
$ sudo sed -i 's/buster/bullseye/g' /etc/apt/sources.list
$ sudo apt update
[...]
Reading state information... Done
429 packages can be upgraded. Run 'apt list --upgradable' to see them.
$ sudo apt full-upgrade

Danach lasst ihr mit sudo apt update die Paketquellen neu einlesen und startet abschließend mit dem sudo apt full-upgrade den eigentlichen Upgrade-Prozess, der auf meinem System über 300 MByte an neuen Paketen in das System spült. Das Upgrade läuft mehr oder minder automatisch durch, allerdings informiert die Paketverwaltung zwischendurch über eine Reihe von Neuerungen, die ihr mit [Q] quittieren müsst. Sind wie bei mir Dienste installiert, fragt das Upgrade zudem im weiteren Verlauf ab, ob ihr die Dienste während des Upgrade-Prozesses ohne Nachfrage neu starten möchtet — in der Regel könnt ihr das erlauben.

Kritisch wird es bei Nachfragen wie hier im nachfolgenden Bild. In diesem Fall registriert die Paketverwaltung eine Änderung an der Konfigurationsdatei /etc/default/useradd. Ihr habt nun die Wahl: Mit [Y] das unveränderte Original des Entwicklers zu übernehmen und somit eure eigenen Änderungen zurückzusetzen oder mit [N] eure Version der Konfiguration zu behalten und somit eventuell Neuerungen des Dienstes zu verpassen. Am besten schaut ihr euch mit [D] den Unterschied zwischen beiden Versionen an und entscheidet dann von Fall zu Fall, was zu tun ist. Ganz ohne Wissen über die betroffenen Dienste kann es hier allerdings zu ein paar kniffligen Situationen kommen. Ich für meinen Teil übernehme gerne die Version der Paketentwickler und passe meine Konfiguration danach wieder von Hand an.

Auf meinen Raspberry Pi 3 mit einer Reihe von Diensten hat das System in etwa zwei Stunden an dem Upgrade gearbeitet — allerdings war ich zwischendurch immer wieder mal nicht am Platz, das Upgrade hat dadurch immer mal wieder auf meine Eingaben gewartet. Nach der erfolgreichen Installation von Raspberry Pi OS Bullseye meldet das System am Ende den Wunsch nach einem Neustart an. Startet daher den Raspberry mit dem Kommando sudo reboot einmal neu und meldet euch wieder am System an. Als letzten Schritt kontrolliert ihr, ob das System nun wirklich mit Bullseye läuft und entfernt nicht mehr benötigte Pakete aus dem System. Danach ist euer Raspberry Pi auf dem neusten Stand und wieder bereit für seine Aufgaben im Netz.

$ cat /etc/os-release 
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
[...]
$ sudo apt autoremove
[...]
0 upgraded, 0 newly installed, 40 to remove and 0 not upgraded.
After this operation, 173 MB disk space will be freed.

Kleiner Tipp am Ende: Wie eingangs angesprochen dürfen die aktuell gefertigten Raspberry Pi 4 und Compute Model 4-Platinen (mit der Kennung C0T am Ende der aufgedruckten CPU-Kennzeichnung) nun ganz offiziellem mit einer Taktrate von 1,8 GHz arbeiten. Damit die CPU jedoch überhaupt so hoch taktet, müsst ihr in der Datei /boot/config.txt die Zeile arm_freq=1800 eintragen. Ansonsten habt ihr bis zur nächsten großen Änderung am System wieder ein wenig Zeit. Das nächste große Update steht analog zum Release-Zyklus von Debian in etwa zwei Jahren an, die Basis bildet dann Debian 12 „Bookworm“.

$ mount
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
dev on /dev type devtmpfs (rw,nosuid,relatime,size=3991400k,nr_inodes=997850,mode=755)
[...]
/dev/sdb1 on /home type ext4 (rw,relatime,data=ordered)
[...]
/etc/autofs/auto.misc on /misc type autofs (rw,relatime,fd=6,pgrp=1207,timeout=300,minproto=5,maxproto=5,indirect)
-hosts on /net type autofs (rw,relatime,fd=12,pgrp=1207,timeout=300,minproto=5,maxproto=5,indirect)
/etc/autofs/auto.nas on /mnt/nas type autofs (rw,relatime,fd=18,pgrp=1207,timeout=60,minproto=5,maxproto=5,indirect)
//192.168.178.79/daten on /mnt/nas/daten type cifs (rw,relatime,vers=1.0,cache=strict,username=me,domain=NAS,uid=1000,forceuid,gid=0,noforcegid,addr=192.168.178.79,unix,posixpaths,serverino,mapposix,acl,rsize=1048576,wsize=1048576,echo_interval=60,actimeo=1)
[...]

Zur Ausgabe von Laufwerksinformationen bietet sich jedoch als Alternative zu mount das Kommando findmnt an. Es steckt schon seit geraumer Zeit im Paket mount und findet sich in der Regel von Haus aus auf dem System. Allerdings nutzt kaum jemand das kleine Programm, im Forum von ubuntuusers.de wird es beispielsweise nur in ein Dutzend Threads erwähnt. Ohne weitere Optionen gibt findmnt einen Verzeichnisbaum mit der Geräte-ID, dem Dateisystemtyp und dem Mount-Optionen aus. Bei Bedarf kann man die Ausgabe nach Mount-Punkten filtern oder beispielsweise nach Dateisystemarten filtern.

$ findmnt
TARGET                           SOURCE      FSTYPE          OPTIONS
/                                /dev/sda1   ext4            rw,relatime,data=ordered
├─/proc                          proc        proc            rw,nosuid,nodev,noexec,relatime
│ └─/proc/sys/fs/binfmt_misc     systemd-1   autofs          
[...]
├─/tmp                           tmpfs       tmpfs           rw,nosuid,nodev
├─/home                          /dev/sdb1   ext4            rw,relatime,data=ordered
├─/misc                          /etc/autofs/auto.misc
│ autofs          rw,relatime,fd=6,pgrp=1207,timeout=300,minproto=5,maxproto=5,indirect
├─/net                           -hosts      autofs          rw,relatime,fd=12,pgrp=1207,timeout=300,minproto=5,maxproto=5,indirect
└─/mnt/nas               /etc/autofs/auto.nas
  autofs          rw,relatime,fd=18,pgrp=1207,timeout=60,minproto=5,maxproto=5,indirect
  ├─/mnt/nas/daten       //192.168.178.79/daten
  │ cifs            
[...]

$ findmnt /home
TARGET SOURCE    FSTYPE OPTIONS
/home  /dev/sdb1 ext4   rw,relatime,data=ordered
$ findmnt -t cifs
TARGET SOURCE FSTYPE OPTIONS
/mnt/nas/daten //192.168.178.79/daten cifs rw,relatime,vers=1.0,cache=strict,[...],addr=192.168.178.79,un
/mnt/nas/homes //192.168.178.79/homes cifs rw,relatime,vers=1.0,cache=strict,[...],addr=192.168.178.79,un
[...]

Den Unterschied zwischen den Ausgaben beider Kommandos wird am besten über einen Screenshot verdeutlicht. Während man mit mount am besten gleich nach einem bestimmten Eintrag per mount | grep foo filtert, erhält man mit findmnt einen übersichtlich formatierten Verzeichnisbaum, den man ohne umständliche Pipes sofort im Blick hat. Zusätzlich könnte man mit etwa findmnt --poll --mountpoint /foo/bar gezielt einen Mountpunkt überwachen lassen und in einem Skript Aktionen auslösen.

Mit Pacman 5.0 wurde dem Paketmanager von Arch die Fähigkeit beigebracht Aktionen per Hooks auszuführen. Das bedeutet für Arch, dass beispielsweise bei der Installation von mehreren Fonts nicht x mal der Font-Cache generiert wird, sondern nur einmal am Ende der Installation. Ein anderer Anwendungsfall wäre etwa das Bauen von Kernelmodulen, das dann eben auch nur einmal angestoßen werden muss. Dies beschleunigt die Arbeit mit Pacman zum Teil erheblich. Diese Änderung bedingt nun aber, dass ihr euer Arch-System bis zum 23.04.2016 auf einen aktuellen Stand gebracht haben müsst.

The release of pacman-5.0 brought support for transactional hooks. These will allow us to (e.g.) run font cache updates a single time during an update rather than after each font package installation. This will both speed up the update process, but also reduce packaging burden for the Developers and Trusted Users. In order for the use of hooks to be started, we require all users to have updated to at least pacman-5.0.1 before 2016-04-23. Pacman-5.0.1 was released on 2016-02-23, so this will have given everyone two months to update their system.

Somit hat jeder Arch-User über zwei Monate Zeit gehabt seine Systeme zu aktualisieren. Wer nach diesem Tag noch Pacman mit einer Versionsnummer kleiner als 5.0.1 auf seinem Rechner hat, kann eventuell keine Pakete mehr installieren und demzufolge auch sein System nicht mehr aktualisieren. Solltet ihr Fragen zu dem Thema haben, könnt ihr euch beispielsweise an das deutschsprachige Arch-Forum wenden, dort gibt es einen entsprechenden Thread. Die Thematik gilt ebenso für Arch-Derivate wie Antergos, die direkt auf den Paketquellen von Arch Linux aufsetzen. Das beliebte Manjaro hingegen nutzt seine eigenen Quellen, allerdings wird das Pacman-Update vermutlich auch dort irgendwann zur Pflicht.

### Welche Pacman-Version ist auf dem Rechner installiert?
$ pacman -Qi pacman
Name : pacman
Version : 5.0.1-2
Beschreibung : A library-based package manager with dependency
support
Architektur : x86_64
$ pacman --version

 .--.                  Pacman v5.0.1 - libalpm v10.0.1
/ _.-' .-.  .-.  .-.   Copyright (C) 2006-2016 Pacman Development Team
\  '-. '-'  '-'  '-'   Copyright (C) 2002-2006 Judd Vinet
 '--'
                       Dieses Programm darf unter Bedingungen der GNU
                       General Public License frei weiterverbreitet werden
[...]

Die meisten Arch-User werden auf einem regelmäßig genutzten System die anlaufenden Updates sowieso mehr oder weniger regelmäßig einspielen und so nicht in die Verlegenheit kommen das Zeitfenster für das Pacman-Update zu verpassen. Es gibt allerdings auch viele User, die Arch auf einem kleiner Server oder etwa einem Raspberry Pi einsetzen, der irgendwo gut versteckt seine Arbeit still und heimlich verrichtet. Vergesst nicht diese Systeme mit dem Update zu versorgen.

Bei all der Freude über ein fortwährend aktuelles System gibt es ab und an kleine Unstimmigkeiten bei der Installation von Software-Updates. Es kann schon mal passieren, dass eine neue Versionen einen Bug mitbringt. Da Arch aber eng am Upstream sitzt, ist dieser meist auch schnell wieder behoben. Die größten Pannen entstehen jedoch nicht durch die Systemupdates: Der größte anzunehmende Fehler sitzt in der Regel vor dem Bildschirm. So fiel bei mir während schon einmal während eines Pacman-Updates der Strom aus oder ich habe die Konfiguration des Bootmanagers verbastelt.

HINWEIS: Das hier geschilderte Vorgehen funktioniert selbstverständlich auch bei anderen Linux-Distributionen wie auch mit anderen Live-Linuxen. Im Endeffekt geht es immer darum das eigentlich installierte System in einem Live-Linux per Chroot einzubinden, um in diesem mit dem eigentlich installierten arbeiten zu können, ohne es booten zu müssen.

Das Ergebnis ist am Ende meist das selbe: Wenn man sehr sehr viel Pech hat, dann lässt sich Arch nicht mehr booten. Aus diesem Grunde habe ich bei mir auch immer einen USB-Stick mit einem Ubuntu-System liegen. Von diesem Notfall-System aus lässt sich Arch in der Regel wiederbeleben — egal was zuvor passiert ist. Hat man nur eine Konfigurationsdatei wie die /etc/fstab oder die /boot/syslinux/syslinux.cfg verbastelt, dann kann man diese ja leicht von der Live-CD aus bearbeiten. Hängt allerdings das System, weil zum Beispiel Pacman jäh unterbrochen wurde, dann braucht es ein anderes Kaliber: Ein Chroot in die nicht mehr bootende Arch-Installation.

Arch-Chroot aus Ubuntu

Damit das klappt, müsst ihr euren Rechner von einer Linux-Live-DVD oder einem USB-Stick mit Linux booten. Für meine Zwecke reicht ein USB-Stick mit Ubuntu 14.04 und persistenter Partition aus, so muss ich nicht immer wieder die Spracheinstellungen korrigieren oder den WLAN-Zugang neu einrichten. Ist das Live-System geladen, öffnet ihr als erstes ein Terminal und schaut euch an, welche Device-IDs die in eurem System verbauten Festplatten und Partitionen bekommen haben. Am einfachsten klappt dies in meinem Augen immer mit dem Befehl lsblk.

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 232,9G 0 disk
├─sda1 8:1 0 26G 0 part
├─sda2 8:2 0 202,9G 0 part
└─sda3 8:3 0 4G 0 part [SWAP]
sde 8:64 1 1000M 0 disk
├─sde1 8:65 1 964M 0 part
└─sde2 8:66 1 2,3M 0 part
loop0 7:0 0 922M 1 loop /rofs

In meinem Fall sitzt das ganze System auf einer 256 GByte großen SSD, also ist /dev/sda das richtige Gerät. Nun weiß ich, dass bei meinem Rechner auf /dev/sda1 das System, auf /dev/sda3 die Homeverzeichnisse und auf /dev/sda4 das Boot-Verzeichnis liegt; kennt ihr euch auf eurem System nicht so gut aus und lässt sich auch aus der Partitionsgröße nicht auf die Zugehörigkeit schließend, dann könnt ihr aus dem Dateimanager heraus die Partitionen kurz einbinden und so direkt nachsehen, welche Daten wo liegen.

Ist die Frage geklärt, holt ihr euch mit sudo -s Root-Rechte und erzeugt einen Mount-Punkt für euer Arch-System im aktuellen Live-Linux; für mein Beispiel nutze ich einfach /arch. In dieses mountet ihr zuerst die Systempartition, dann die Homepartition nach /arch/home und schließlich — natürlich nur wenn /boot auch auf einer eigenen Partition liegt — die Bootpartition eures Arch-Systems.

$ sudo -s
$ mkdir /arch
$ mount /dev/sda1 /arch
$ mount /dev/sda2 /arch/home
### Falls ihr weitere Partitionen nutzt...
$ mount /dev/sda4 /arch/boot

Damit das Chroot später komplett funktioniert, müsst ihr nun noch Symlinks zu dynamischen Verzeichnissen des Live-Systems wie /proc oder /dev in den zukünftigen Chroot-Bereich legen. Alleine mit diesen Symlinks würde allerdings der Netzwerkzugang inklusive Namensauflösung noch nicht korrekt funktioniern, holt euch daher noch die resolv.conf des Live-Linux in das Chroot rüber. Ist das alles geschehen, öffnet ihr schließlich mit dem Chroot-Befehl euer Arch-Linux — ohne es vorher Booten zu müssen.

$ mount -t proc none /arch/proc
$ mount -t sysfs none /arch/sys
$ mount -o bind /dev /arch/dev
$ mount -o bind /dev/pts /arch/dev/pts # Wichtig für Pacman
$ cp -L /etc/resolv.conf /arch/etc # Für Netzwerkzugriff
$ chroot /arch bash

Im Chroot arbeitet ihr nun mit sämtlichen Daten eures Arch-System, die Wurzel des Verzeichnisbaums beginnt wie gewohnt bei / und nicht mehr mit dem zuvor erstellten Mountpunkt. Zum Bearbeiten der fstab wechselt ihr also einfach nur nach /etc und öffnet dort die Fstab-Datei mit einem Editor wie zum Beispiel Nano: nano /etc/fstab. Ihr braucht sogar auf Programme mit einer graphischen Oberfläche nicht verzichten, dazu müsst ihr lediglich den Xserver des Ubuntu-Systems mit xhost + für Zugriffe von außen öffnen.

Befehle wie pacman -Syu zum Einspielen von Updates oder etwa syslinux-install_update -i -a -m für die Neu-Installation des Syslinux-Bootloaders lassen sich direkt aus dem Chroot ausführen, als ob ihr aus eurem Arch-System heraus arbeiten würdet. Mit ein bisschen Ellbogenschmalz und Geschick beim Googeln nach Fehlermeldungen bekommt man sein Arch danach in der Regel wieder recht schnell flott, sodass man wieder ganz normal von der Festplatte oder der SSD booten kann.

17  *   * * *   root      run-parts --report /etc/cron.hourly
59 23   * * *   username  /pfad/zu/skript.sh
*/5 *   * * *   username  ping -c 1 www.google.de > /dev/null 2>&1

Die Syntax für einfache Aufgaben zu lernen ist nicht sonderlich schwer, meist reicht ein Blick ins Wiki. Doch was muss man denn jetzt als Cronjob angeben, wenn jede ungerade Minute, zu jeder geraden Stunde, zweimal im Monat, aber bitte nur an ungerade Monaten, aber dann auch nur an Wochentagen das Kommando foobar ausgeführt werden soll? Dafür müssen wohl auch erfahrene Sysadmins ein paar Minuten grübeln.

1-59/2 */2 */15 1-11/2 0,6 foobar >/dev/null 2>&1

Ganz so einfach lässt sich die Logik nicht zusammenstellen, aber per Mausklick ist das schnell gemacht, man muss nur wissen wo! Mit dem Crontab-Generator lassen sich Cronjobs Schritt für Schritt mit der Maus zusammenbauen, so dass man am Ende nur noch die Cronjob-Zeile in die Crontab des betroffenen Systems übernehmen muss. Der Generator beachtet dabei auch die Ausgaben, man kann sie verwerfen, in eine Datei schreiben oder per Mail verschicken. Damit dürften die meisten Anwendungsfälle wohl abgedeckt sein.

# Dropbox
deb http://linux.getdropbox.com/ubuntu karmic main   
deb-src http://linux.getdropbox.com/ubuntu karmic main   

…neu zu installieren, dann erhält man eine Fehlermeldung…

$ sudo apt-get install --reinstall nautilus-dropbox 
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut       
Lese Status-Informationen ein... Fertig
Erneute Installation von nautilus-dropbox ist nicht möglich,
es kann nicht heruntergeladen werden.
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.

Schaut also in eure /etc/apt/sources.list und passt die URL an. Anstatt getdropbox.com müsst ihr dropbox.com eintragen…

# Dropbox
deb http://linux.dropbox.com/ubuntu karmic main   
deb-src http://linux.dropbox.com/ubuntu karmic main   

…nur so kommt ihr an Updates wenn Dropbox nautilus-dropbox aktualisiert. Bitte vergesst nicht die Zeilen an die von Euch genutzte Ubuntu-Version anzupassen.

Über Synaptic kann man sich die alten Kernel in einer graphischen Umgebung raussuchen und sie dann deinstallieren. Doch dazu müsste man sich nach und nach allen alten Ballast raussuchen und von Hand zur Deinstallation vormerken. Das ist umständlich und dauert durchaus ein kleines Weilchen, erst recht wenn sich im Ubuntu-System nach einer ganzen Weile eine Menge Kernel angesammelt haben. Mit ein bisschen Shell-Magie deinstalliert man jedoch mit nur einem Kommando alle alten Linux-Kernel inklusive ihren Headern. Via…

…löscht ihr alle alten Kernel inklusive den jeweils zusätzlich installierten Kernel-Headern von der Festplatte. Der aktuelle Kernel des Systems bleibt dabei komplett unangetastet. Ihr müsst also keine Angst haben, dass ihr nach dem Ausführen des Befehls gleich ganz ohne Kernel dasteht und euren Computer nicht mehr booten könnt. Trotzdem solltet ihr einen kritischen Blick auf die Liste der zu deinstallierenden Pakete werfen, nicht dass aus irgendeinem Grund eine Abhängigkeit quer schießt und das halbe System von der Platte fliegt.

$ dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' | xargs sudo apt-get -y purge

Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Lese Status-Informationen ein... Fertig
Die folgenden Pakete werden ENTFERNT:
linux-headers-2.6.31-13* linux-headers-2.6.31-13-generic*
linux-headers-2.6.31-14* linux-headers-2.6.31-14-generic*
linux-image-2.6.27-14-generic* linux-image-2.6.31-13-generic*
linux-image-2.6.31-14-generic* linux-restricted-modules-2.6.27-14-generic*
0 aktualisiert, 0 neu installiert, 8 zu entfernen und 10 nicht aktualisiert.
Nach dieser Operation werden 441MB Plattenplatz freigegeben.
Möchten Sie fortfahren [J/n]?

Allerdings würde ich generell ältere Kernel erst dann von der Festplatte löschen, wenn ich weiß dass ich mit dem aktuellen Linux-Kernel definitiv keine Probleme habe. Lasst nach einem Kernelupdate den alten Kernel daher also noch ein paar Tage oder gar ein paar Wochen auf eurem Rechner. Die dadurch verbrauchten MByte lassen sich meist verschmerzen. Das Aufräumen könnt ihr ja immer noch nachholen, mehr als einen Befehl braucht es dazu ja nicht.

Über Synaptic kann man via „Paket -> Version erzwingen“ die Rückkehr zu einer älteren Version des Pakets erzwingen, doch der Vorgang ist bei Quellen wie xorg-edgers oder ubuntu-mozilla-daily, die eine ganze Reihe von Paketen bereithalten, recht aufwändig das man jedes Paket einzeln deaktualisieren müsste. Im xorg-edgers PPA gibt es jedoch jetzt ein Mittelchen, das die Aufgabe deutlich vereinfacht…

Wer also nicht zig Pakete von Hand auf eine ältere Version bringen möchte, der installiert sich das Paket ppa-purge aus dem xorg-edgers PPA. Ich würde die Quelle selber nicht in das System einfügen. Das xorg-edgers PPA enthält experimentelle Pakete für Grafiktreiber und X-Server, wenn Euch die graphische Umgebung Eures System lieb ist, dann würde ich von der Quelle die Finger lassen.

Das Paket kann man auch so herunterladen und dann mit einem Doppelklick installieren. Die Funktionsweise erkläre ich anhand der ubuntu-mozilla-daily Paketquellen, die experimentelle Pakete von allen Mozilla-Produkten enthät. Via…

$ sudo add-apt-repository ppa:ubuntu-mozilla-daily/ppa

…füge ich sie zu meinem System hinzu, um dann die Quellen neu einzulesen und ein Upgrade durchzuführen…

$ sudo apt-get update
$ sudo apt-get dist-upgrade
[...]
Die folgenden Pakete werden aktualisiert:
  firefox firefox-3.5 firefox-3.5-branding firefox-3.5-gnome-support firefox-gnome-support prism xulrunner-1.9.1 xulrunner-1.9.1-gnome-support
8 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen noch 0B von 10,1MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 565kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren [J/n]? 
[...]

Es werden also Vorabversionen von Firefox, Prism und Zubehör installiert. Will ich zurück zu den „alten“ Versionen aus den Paketquellen von Canonical, so müsste ich wie oben im Bild gezeigt in Synaptic jedes Paket einzeln von Hand auf die offizielle Version bringen. ppa-purge macht das für mich mit einem Kommando…

$ sudo ppa-purge ppa:ubuntu-mozilla-daily/ppa
PPA to be removed: ubuntu-mozilla-daily ppa
[...]
Disabling ubuntu-mozilla-daily PPA from 
/etc/apt/sources.list.d/ubuntu-mozilla-daily-ppa-karmic.list
Running apt-get update
[...]
Die folgenden Pakete werden DEAKTUALISIERT:
  firefox firefox-3.5 firefox-3.5-branding firefox-3.5-gnome-support firefox-gnome-support prism xulrunner-1.9.1 xulrunner-1.9.1-gnome-support
0 aktualisiert, 0 neu installiert, 8 deaktualisiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen noch 0B von 9.802kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 565kB Plattenplatz freigegeben.
Möchten Sie fortfahren [J/n]? 

ppa-purge wird wohl in der kommenden Version auch offiziell Einzug in Ubuntu halten. Bis dahin könnt Ihr das Programm ja von Hand installieren und aktuell halten.