Auf GitHub bin ich neulich über das Skript PiShrink gestolpert, das genau diese Aufgabe übernimmt. Das kleine Programm schnappt sich ein RasPi-Image, reduziert die Partitionsgröße auf das notwendige Minimum und integriert zudem ein Skript ins archivierte System, das beim nächsten Start auf echter Hardware die Partition automatisch auf den maximal verfügbaren Speicherplatz ausdehnt. So lässt sich das Image eines Raspbian-Systems von mehreren Gigabyte schnell auf ein paar Hundert Megabyte verkleinern – ganz ohne großen Aufwand. Auch beim Zurückspielen spart man Zeit, da sich das Dateisystem beim ersten Start des Raspberry Pi automatisch wieder auf die volle Größe erweitert.

$ mkdir ~/bin
$ wget https://raw.githubusercontent.com/Drewsif/PiShrink/master/pishrink.sh -P ~/bin
$ chmod +x ~/bin/pishrink.sh

Da es sich bei PiShrink um ein einfaches Bash-Skript handelt, ist die Installation des Programms nicht sonderlich kompliziert: Man muss das Skript lediglich aus dem Netz herunterladen und die Ausführungsrechte entsprechend setzen. Ich persönlich lege solche Skripte im Verzeichnis ~/bin im Home-Verzeichnis ab. Das System sollte diesen Ordner automatisch in den $PATH eures Benutzers aufnehmen, sodass man das Kommando ohne Pfadangabe von überall im System ausführen kann. Sollte das bei euch nicht der Fall sein, finden sich im Netz zahlreiche Anleitungen zum Erweitern der Umgebungsvariablen (der verlinkte Artikel bezieht sich auf Ubuntu, das Vorgehen ist bei anderen Distributionen jedoch sehr ähnlich).

PiShrink komprimiert Raspberry-Pi-Images

Nun solltet ihr das PiShrink-Skript mit einem beherzten pishrink.sh direkt im Terminal aufrufen können. Ohne die Angabe eines Images zeigt das Skript lediglich seine Syntax an. Im Endeffekt beschränkt sich der Aufruf auf die Angabe einer Image-Datei und optional eines zweiten Dateinamens, falls PiShrink das Original-Image des Raspberry Pi unangetastet lassen soll. Gibt man nur einen Dateinamen an, bearbeitet PiShrink das genannte Image direkt.

Der einzige Schalter -s ist dann wichtig, wenn man das Image eines RasPi-Systems verkleinern möchte, das nicht auf Raspbian basiert – also beispielsweise die Kodi-Distributionen LibreELEC oder OpenELEC. Genauer gesagt weist der Schalter PiShrink an, das automatische Ausdehnen des Systems beim nächsten Start zu unterlassen. Dazu trägt PiShrink normalerweise ein Kommando in die Datei /etc/rc.local ein, die unter Raspbian beim Booten automatisch ausgeführt wird. Diese Datei existiert jedoch bei LibreELEC (und einigen anderen Distributionen) nicht.

### Hilfe zu PiShrink aufrufen:
$ pishrink.sh
Usage: /home/toff/bin/pishrink.sh [-s] imagefile.img [newimagefile.img]
### Vorhandenes RasPi-Image verkleinern:
$ sudo pishrink.sh raspberry-pi.img
### Image verkleinern und Original behalten:
$ sudo pishrink.sh raspberry-pi.img raspberry-pi_pishrink.img
### Automatisches Vergrößern der Partition deaktivieren:
$ sudo pishrink.sh -s raspberry-pi.img raspberry-pi_klein.img

Wie kommt das nun alles zusammen? Als Beispiel verwende ich hier eine aktuelle Installation von Raspbian Lite auf einer 16 GByte großen SD-Karte. Diese legt man in den Kartenleser ein, ermittelt mit lsblk die Geräte-ID und sichert anschließend mit dd das Image auf die Festplatte. Die Image-Datei liegt danach unter dem Namen raspberry-pi.img rund 16 GByte groß auf der Festplatte – obwohl das Image eigentlich größtenteils leer ist. Außer dem Raspbian-System und ein paar Konfigurationen befinden sich keine weiteren Daten auf dem System.

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
[...]
sdd      8:48   1  14,9G  0 disk 
├─sdd1   8:49   1    63M  0 part /run/media/[...]/boot
└─sdd2   8:50   1  14,8G  0 part /run/media/[...]/0aed834e-8c8f-412d-a276-a26
$ sudo dd if=/dev/sdd of=~/raspberry-pi.img
15894831104 Bytes (16 GB, 15 GiB) kopiert, 210 s, 75,7 MB/s     
31116288+0 Datensätze ein
31116288+0 Datensätze aus
15931539456 Bytes (16 GB, 15 GiB) kopiert, 210,459 s, 75,7 MB/s
$ ls -alh ~/raspberry-pi.img 
-rw-r--r-- 1 root root 15G 24. Feb 21:48 raspberry-pi.img

Anschließend ruft man PiShrink entsprechend auf – da es sich um ein Raspbian-System handelt, lasse ich die Option -s weg. PiShrink kopiert zunächst das Image (achtet daher darauf, dass ausreichend freier Speicherplatz vorhanden ist), mountet die Kopie in ein temporäres Verzeichnis unter /tmp und reduziert anschließend die Größe des Images: von ursprünglich knapp 16 GByte auf nur noch etwa 1,6 GByte. Der erzielte Effekt hängt natürlich davon ab, wie viele echte Daten auf der SD-Karte des Raspberry Pi gespeichert waren.

$ sudo pishrink.sh raspberry-pi.img raspberry-pi_pishrink.img
Copying raspberry-pi.img to raspberry-pi_pishrink.img...
Creating new /etc/rc.local
e2fsck 1.43.4 (31-Jan-2017)
Durchgang 1: Inodes, Blöcke und Größen werden geprüft
Durchgang 2: Verzeichnisstruktur wird geprüft
Durchgang 3: Verzeichnisverknüpfungen werden geprüft
Durchgang 4: Referenzzähler werden überprüft
Durchgang 5: Zusammengefasste Gruppeninformation wird geprüft
/dev/loop2: 35832/959616 Dateien (0.2% nicht zusammenhängend), 321790/3872384 Blöcke
resize2fs 1.43.4 (31-Jan-2017)
resize2fs 1.43.4 (31-Jan-2017)
Die Größe des Dateisystems auf /dev/loop2 wird auf 382429 (4k) Blöcke geändert.
Start von Durchgang 2 (max = 40814)
Blöcke werden verschoben     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Start von Durchgang 3 (max = 119)
Die Inode-Tabelle wird gelesenXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Start von Durchgang 4 (max = 3178)
Die Inode-Referenzen werden aktualisierXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-
Das Dateisystem auf /dev/loop2 ist nun 382429 (4k) Blöcke lang.

Shrunk raspberry-pi_pishrink.img from 15G to 1,6G
$ ls -alh raspberry-pi*
-rw-r--r-- 1 root root  15G 27. Feb 11:08 raspberry-pi.img
-rw-r--r-- 1 root root 1,6G 27. Feb 11:30 raspberry-pi_pishrink.img

Geschrumpftes RasPi-Image wiederherstellen

Zum Test soll das ursprünglich auf einer 16-GByte-SD-Karte installierte Raspbian-System auf eine MicroSD-Karte mit nur 8 GByte umziehen. Dazu schreibe ich das mit PiShrink verkleinerte Image wieder mit dd auf die neue Karte, setze sie in den Raspberry Pi ein und starte das geschrumpfte System. Um den verfügbaren Speicherplatz vollständig zu nutzen, führt das System beim ersten Bootvorgang automatisch einen Neustart durch. Anschließend landet man im gewohnten Raspbian-System – ein df -h zeigt, dass das System jetzt die gesamte SD-Karte verwendet.

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
[...]
sdd      8:48   1   7,4G  0 disk 
├─sdd1   8:49   1    63M  0 part /run/media/[...]/boot
└─sdd2   8:50   1   7,3G  0 part /run/media/[...]/0aed834e-8c8f-412d-a276-a26
$ sudo dd if=raspberry-pi_pishrink.img of=/dev/sdd bs=1M; sync
1560+1 Datensätze ein
1560+1 Datensätze aus
1636684288 Bytes (1,6 GB, 1,5 GiB) kopiert, 116,203 s, 14,1 MB/s

pi@raspberrypi:~ $ df -h
Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf
/dev/root       7,2G    990M  6,0G   14% /
devtmpfs        459M       0  459M    0% /dev
tmpfs           463M       0  463M    0% /dev/shm
tmpfs           463M    6,2M  457M    2% /run
tmpfs           5,0M    4,0K  5,0M    1% /run/lock
tmpfs           463M       0  463M    0% /sys/fs/cgroup
/dev/mmcblk0p1   63M     21M   42M   33% /boot

Sichert man ein Raspberry-Pi-System, das nicht auf Raspbian basiert und keine /etc/rc.local enthält – wie etwa die bereits erwähnten Kodi-Distributionen LibreELEC oder OpenELEC – erscheinen beim Schrumpfen mit PiShrink Fehlermeldungen. Der Grund: PiShrink versucht standardmäßig, ein Kommando zur späteren automatischen Vergrößerung der Partition in diese Datei einzutragen. Um das zu vermeiden, muss beim Aufruf die Option -s verwendet werden. Damit lässt sich das Image auch ohne rc.local erfolgreich verkleinern.

### Fehlermeldungen beim Schrumpfen eines LibreELEC-Images:
$ sudo pishrink.sh libreelec.img
[...]
md5sum: /tmp/tmp.4ornQ3Va4y/etc/rc.local: Datei oder Verzeichnis nicht gefunden
/home/[...]/bin/pishrink.sh: Zeile 63: [: !=: Einstelliger (unärer) Operator erwartet.
[...]
### LibreELEC, OpenELEC und Co. schrumpft man besser so:
$ sudo pishrink.sh -s libreelec.img
Skipping autoexpanding process...
e2fsck 1.43.4 (31-Jan-2017)
/dev/loop2: Journal wird wiederhergestellt
Durchgang 1: Inodes, Blöcke und Größen werden geprüft
Durchgang 2: Verzeichnisstruktur wird geprüft
Durchgang 3: Verzeichnisverknüpfungen werden geprüft
Durchgang 4: Referenzzähler werden überprüft
Durchgang 5: Zusammengefasste Gruppeninformation wird geprüft
/dev/loop2: 861/1810432 Dateien (1.0% nicht zusammenhängend), 252448/7235584 Blöcke
resize2fs 1.43.4 (31-Jan-2017)
resize2fs 1.43.4 (31-Jan-2017)
Die Größe des Dateisystems auf /dev/loop2 wird auf 49976 (1k) Blöcke geändert.
Start von Durchgang 2 (max = 15759)
Blöcke werden verschoben     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Start von Durchgang 3 (max = 884)
Die Inode-Tabelle wird gelesenXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Start von Durchgang 4 (max = 143)
Die Inode-Referenzen werden aktualisiertXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX-
Das Dateisystem auf /dev/loop2 ist nun 49976 (1k) Blöcke lang.

Shrunk libreelec.img from 7,5G to 563M

Das zurückgeschriebene System vergrößert sich anschließend jedoch nicht automatisch, da LibreELEC (und nach aktuellem Kenntnisstand auch OpenELEC) in seinen Menüs keine Option bietet, die Datenpartition manuell auf die volle Kartengröße auszudehnen. Die interne Routine zur Größenanpassung greift nur bei einer frisch kopierten Erstinstallation, wie im Skript ersichtlich. Um die Partition dennoch vollständig zu nutzen, hilft nur manuelles Nacharbeiten mit einem Partitionswerkzeug wie GParted. Unter Linux ist GParted direkt verfügbar, Windows-Nutzer können das Tool über eine Live-CD oder einen Live-USB-Stick verwenden.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Für Datenrettungen von alten Rechnern und bei Systemumzügen habe ich mir vor einigen Jahren mal eine SATA auf USB2.0-Dockingstation gekauft. Sie erledigte ihre Aufgaben bisher eigentlich recht zuverlässig… bis ich neulich erstmals Daten von einer 3 TByte großen Festplatte sichern wollte. Sämtliche Versuche, die Festplatte (deren Vorhandensein das System durchaus erkannte) in mein Linux-System einzubinden, scheiterten jedoch. Kommandos wie lsblk melden lediglich eine Kapazität von 746,5 Gigabyte, ebenso liefern grafische Tools wie die Laufwerksverwaltung von Gnome Größen von 802 Gibibyte (wer es selbst umrechnen möchte). Irgendwas stimmt also nicht: Wer sich bisher nicht informiert hat und nicht die passenden Seiten im Netz findet, meint, die Festplatte sei defekt.

Das Problem liegt nun darin, dass die in solchen USB-Festplattenadaptern und -Gehäusen integrierte Firmware und Treiber mit 32-Bit langen Sektornummern rechnen, wodurch sie maximal 232 Sektoren mit 512 Byte adressieren können. Langer Rede, kurzer Sinn: Ab einer Festplattenkapazität von über 2 TByte durchbrechen Festplatten eine Grenze, die vielen älteren Geräten Probleme bereitet — nicht umsonst braucht es ja mit der GPT (aka GUID Partition Table) eine neuartige Partitionstabelle bei solchen Festplattengrößen. Von dem Problem sind übrigens nicht nur USB-Adapter und Rechner mit älteren BIOS-Bausteinen betroffen, das Einbinden einer großen Festplatte wird beispielsweise auch an älteren Fernsehern mit USB-Anschluss zum Problem. Wer sich das alles einmal im Detail ansehen möchte, der wird zum Beispiel in der Heise-FAQ fündig, auch zum Thema Festplatten am TV-Gerät.

Eine Software-Lösung für das Problem gibt es nun leider nicht. Die einzige Möglichkeit, solche Festplatten ans System zu bekommen, ist die Investition in einen neuen USB-Adapter. Die Chancen, dass dieser mit großen Festplatten zurechtkommt, sind bei neu gekauften Artikeln eigentlich recht hoch. Ich für meinen Teil habe einfach einen simplen SATA auf USB3.0-Adapter ohne extra Netzteil gewählt, da ich aufgrund der alten Dockingstation schon eine passende Stromquelle besaß. Wer lieber einen gebrauchten USB-Adapter ersteigern möchte, der sollte unbedingt auf eine USB3.0-Schnittstelle achten. Diese Geräte sollten dann eigentlich neu genug sein, um auch mit großen Festplatten zurechtzukommen. Schließt man mit diesem dann alles korrekt an, erkennt das System brav die Festplatte und man kann mit dem Backup der Daten beginnen.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Was bei OpenELEC funktioniert, klappt selbstverständlich auch mit anderen RasPi-Distributionen wie Raspbian oder Arch. Im Endeffekt geht es darum, die config.txt des Systems zu ändern und die entsprechende Option dort einzutragen. Für Einsteiger konzentriere ich mich in diesem Beitrag auf OpenELEC, da viele RasPi-Beginner den Raspberry Pi als Mediacenter einsetzen und dort eben ihre Mediensammlung über eine externe Festplatte am Raspberry Pi einbinden möchten. Wer mit Raspbian und Co. arbeitet, der überspringt am besten einfach den ersten Part und geht direkt zum Bearbeiten der Konfig-Datei über.

SSH in OpenELEC aktivieren

Damit ihr die Konfiguration des Raspberry Pi bearbeiten könnt, ohne den RasPi zu zerlegen und die Speicherkarte auszubauen, aktiviert ihr den in das System integrierten SSH-Server. Dazu öffnet ihr in OpenELEC Optionen | OpenELEC | Services und setzt bei SSH aktivieren euren Haken. Zum Einloggen lest ihr nun unter Optionen | Systeminfo | Netzwerk die IP-Adresse aus und ladet euch auf Windows-Systemen zum Beispiel PuTTY als SSH-Client herunter. Wer mit Linux oder MacOS X unterwegs ist, der muss sich keine weitere Software installieren.

Danach könnt ihr loslegen und config.txt bearbeiten. Startet dazu ein Terminal oder PuTTY und loggt euch über die IP-Adresse oder den Namen eures OpenELEC-Systems ein — falls die Namensauflösung funktioniert. Die Logindaten lauten root als Benutzername und openelec als Passwort. Bei PuTTY müsst ihr die Adresse des Ziels unter Session als Host Name (or IP adress) eintragen und dann mit Open die Verbindung starten. Die Verbindungsdaten könnt ihr bei Bedarf mit Save für später speichern, sodass ihr sie nicht immer wieder neu eingeben müsst.

$ ssh root@ip-adresse # Einloggen über IP-Adresse
$ ssh root@openelec # Falls Namensauflösung funktioniert

Steht die Verbindung, landet ihr in einem rein auf Text basierten Terminal. In diesem müsst ihr erstmal dafür sorgen, dass ihr auf der Systempartition unter /flash schreiben dürft. Bindet dazu die Partition mit dem ersten Befehl neu ein, die Option rw am Ende des Kommandos sorgt dafür. Anschließend öffnet ihr die Konfigurationsdatei /flash/config.txt mit dem zweiten Befehl im Nano-Texteditor, einem Editor, der sich auch von Einsteigern recht leicht bedienen lässt.

$ mount /flash -o remount,rw
$ nano /flash/config.txt

USB-Output des RasPi auf 1.2 A erhöhen

Nun geht es ans Eingemachte: Scrollt im Editor mit den Pfeiltasten jetzt ein gutes Stückchen nach unten, bis ihr zum Abschnitt „various settings“ kommt. Dort fügt ihr nun die Zeile max_usb_current=1 neu ein, die restlichen Optionen übernehmt ihr unverändert — zur besseren Übersicht könnt ihr der Zeile noch einen mit einer Raute „#“ abgetrennten Kommentar voranstellen. Mit der Tastenkombination [Strg]+[O] und Eingabe speichert ihr eure Änderungen ab und mit [Strg]+[X] beendet ihr Nano wieder.

#############################################################
# various settings see also: http://elinux.org/RPi_config.txt
#############################################################
[...]
# USB-Output erhoehen
max_usb_current=1

Danach sorgt ihr mit sync dafür, dass eure Änderungen auch wirklich auf die Speicherkarte geschrieben werden, bindet die Flash-Partition wieder nur mit Leserechten ein und startet das OpenELEC-System einmal neu durch — das Ganze funktioniert wie gesagt auch auf anderen Raspberry-Pi-Distributionen. Arbeitet ihr direkt auf diesen, dann könnt ihr euch das Einbinden der Flash-Partition eventuell sparen und die config.txt gleich mit Root-Rechten bearbeiten und so externe Festplatten am Raspberry Pi zum Laufen bringen.

$ sync
$ mount /flash -o remount,ro
$ reboot

Klappt nur mit ordentlichem Netzteil

Ingesamt bewirkt max_usb_current=1 in der config.txt, dass der Raspberry Pi jetzt nicht nur mehr 600 mA an den USB-Ports anlegt, sondern bis zu 1200 mA Strom liefert, sodass dann auch Scanner oder eben externe Festplatten im 2,5-Zoll-Format ohne ein eigenes Netzteil am Raspberry Pi funktionieren. Dies unterstützt allerdings nur der Raspberry Pi B+ aus der ersten RasPi-Generation und der neue Raspberry Pi 2 — bei den Modellen A und B (ohne Plus) und vermutlich auch den zukünftigen A-Modellen der zweiten RasPi-Generation bewirkt der Schalter in der config.txt noch nichts.

Beachtet bitte auch, dass die hochgedrehte Stromversorgung der USB-Ports auch nur mit einem ordentlichen Netzteil funktioniert. Das eingesetzte Netzteil sollte mindestens 2000 mA, wenn nicht gar 2100 mA wie diese hier liefern. Zeigt euer Raspberry Pi mit max_usb_current=1 und angeschlossener USB-Festplatte ein buntes Viereck in der rechten oberen Ecke des Display an, dann ist es ein sicheres Zeichen, dass euer RasPi nicht ausreichend Strom vom Netzteil bekommt. Bei mir reichte beispielsweise ein USB-Netzteil eines alten Smartphones nicht mehr für den Betrieb der Festplatte aus, auch bei entsprechender Konfiguration des Systems.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Je nach verwendeter Desktopumgebung kommen unterschiedliche Tools infrage. Unter Gnome würde ich zu Baobab alias Festplattenbelegung greifen – das Programm ist integraler Bestandteil von Gnome und bei vielen Linux-Distributionen bereits vorinstalliert. KDE-Nutzer können zu Filelight greifen, einer optisch ansprechenden Anwendung. Und auf einem Server ohne grafische Oberfläche leistet Ncdu im Terminal hervorragende Dienste beim digitalen Frühjahrsputz.

Ncdu fürs Terminal

Auf einem Server oder einem kleinen Serverchen wie einem Raspberry Pi mit Raspbian läuft in der Regel keine grafische Oberfläche – und das ist auch gut so. Diese Geräte verrichten still und leise im Hintergrund ihren Dienst, ohne dass man ihnen ständig zusehen müsste. Verbindet ihr euch per SSH über das Netzwerk, dann hilft Ncdu – der NCurses Disk Usage Analyzer – beim Aufspüren großer Dateien direkt im Terminal.

Ncdu installieren

### Ncdu unter Arch Linux installieren
$ sudo pacman -S ncdu

### Ncdu unter Debian, Ubuntu, Mint installieren
$ sudo apt-get install ncdu

Ausgehend vom aktuellen Verzeichnis liest Ncdu die Speicherbelegung aus und zeigt die Ergebnisse mit einem einfachen Balkendiagramm an. Mit [Pfeil-hoch] und [Pfeil-runter] navigiert ihr durch die Verzeichnisse, mit Return wechselt ihr ins jeweilige Unterverzeichnis. Dateien oder ganze Ordner lassen sich direkt aus Ncdu mit Entf löschen. Eine vollständige Übersicht über alle Tastenkürzel bekommt ihr mit Umschalt+# über die Hilfe.

Baobab für Gnome-Anwender

Wer mit Gnome unterwegs ist, muss nicht lange nach dem passenden Werkzeug suchen. Baobab, auch bekannt als Festplattenbelegung, ist Teil des Gnome-Desktops und sollte bei den meisten Distributionen bereits vorinstalliert sein. Falls nicht, könnt ihr das Tool ganz einfach über die Paketverwaltung eurer Distribution nachinstallieren. Anschließend findet ihr es unter dem sprechenden Namen „Festplattenbelegung“ im Menü.

Baobab installieren

### Baobab unter Arch Linux installieren
$ sudo pacman -S baobab

### Baobab unter Debian, Ubuntu, Mint installieren
$ sudo apt-get install baobab

Nach dem Start scannt Baobab wahlweise das komplette Dateisystem oder nur das Homeverzeichnis. In der Fußleiste könnt ihr die Anzeigeart wählen – entweder ein Kreisdiagramm oder eine Kachelansicht. Je größer das Segment oder das Kästchen, desto größer ist der belegte Speicher im jeweiligen Verzeichnis. Speicherfresser lassen sich bequem per Rechtsklick direkt in den Mülleimer befördern.

Filelight für KDE-Anwender

KDE bringt mit Filelight ebenfalls ein praktisches Tool zur Analyse der Speicherplatznutzung mit. Bei vielen KDE-Distributionen wie Kubuntu ist es nicht standardmäßig installiert, lässt sich aber wie gewohnt über die Paketquellen nachrüsten. Auch unter Arch-basierten Systemen wie Netrunner steht Filelight zur Verfügung. Nach der Installation findet ihr es im Anwendungsmenü – und mit etwas Glück auch direkt im Kontextmenü des Dolphin-Dateimanagers.

Filelight installieren

### Filelight unter Arch Linux installieren
$ sudo pacman -S kdeutils-filelight

### Filelight unter Debian, Ubuntu, Mint installieren
$ sudo apt-get install filelight

Filelight unterscheidet sich in der Bedienung kaum von Baobab, stellt die Speicherbelegung allerdings ausschließlich als mehrschichtiges Kuchendiagramm dar. Ich persönlich bevorzuge das Box-Modell, weil man damit schneller einen Überblick bekommt und sich nicht so leicht verliert. Nichtsdestotrotz beherrscht Filelight die wichtigsten Funktionen: Speicherinhalte analysieren, übersichtlich darstellen und direkt aus der Anwendung heraus löschen.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Wer bereits ein Raspberry-Pi-Image auf eine SD-Speicherkarte gebannt und nicht den NOOBS-Weg gegangen ist, der hat als Windows-User wahrscheinlich den Win32 Disk Imager oder als Linuxer das Dd-Kommando verwendet, um die RasPi-Software auf die Speicherkarte zu schreiben. Für das Klonen einer bestehenden Installation könnten in der Theorie abermals beide Programme zum Einsatz kommen, allerdings klappt das in der Praxis nur für die Linux-Anwender.

Der Win32 Disk Imager kann zwar Abbilder von schon gefüllten Speichermedien erstellen, allerdings immer nur von einzelnen Partitionen. Da ein typisches RasPi-Linux sich jedoch über mehrere Partitionen erstreckt und auch noch ein Bootloader gesichert werden möchte, müssen sich Windows-Anwender einen anderen Weg zum Sichern und Zurückspielen des Raspberry-Pi-Images suchen.

Unter Windows bieten sich daher nun zwei Wege zum Kopieren und Sichern eines RasPi-Images an. Zum einen macht euch die Freeware Roadkil’s Disk Image die Arbeit dank einer recht simplen grafischen Oberfläche ziemlich einfach. Alternativ könnt ihr aber auch unter Windows das Linux-Kommando Dd dazu nutzen, Festplattenimages auszulesen und wieder neu auf ein Speichermedium zu schreiben. Zu letzterem greifen vor allen Dingen erfahrene Linux-Anwender, die auf ein so leistungsfähiges Tool wie Dd auch unter Windows nicht verzichten möchten.

Raspberry-Pi-Image unter Windows sichern

Roadkil’s Disk Image macht das Erstellen der Image-Datei eures Raspberry Pi sehr einfach. Ihr müsst lediglich die Software aus dem Internet herunterladen und in einem beliebigen Verzeichnis entpacken. Danach ruft ihr die DiskImage_1_6_WinAll.exe am besten mit administrativen Rechten auf — Klickt dazu im Dateimanager mit der rechten Maustaste auf die EXE-Datei und wählt dann als Administrator ausführen aus. Im Programm geht ihr in den Reiter Store Image, wählt das zu sichernde Laufwerk aus und gebt noch den Speicherort der Zieldatei vor.

Die Nummer des zu sichernden Mediums leitet ihr entweder aus der Dateigröße ab, oder ihr schaut kurz in die Datenträgerverwaltung — das Ding müsste es ja auch noch in aktuellen Windows-Versionen geben. Nach einem Klick auf Start legt das Disk-Image-Tool dann los, das Ergebnis landet am Ende als IMG-Datei auf der Festplatte. Zur Wiederherstellung der Sicherung auf einer neuen Speicherkarte nutzt ihr den Reiter Write Image und geht einfach umgekehrt vor — die neue Karte muss natürlich ausreichend Platz bieten.

Linux-User, die zwischendurch mal auf einem Windows-System arbeiten müssen, können für diese Aufgabe auch zu Dd für Windows zurückgreifen. Die Syntax erinnert an die des Programms unter Linux, allerdings macht die Angabe der Pfade ein wenig mehr Mühe. Beim Pfad orientiert ihr euch am unten stehenden Beispiel, wobei ihr Laufwerks- und Partitionsnummer natürlich an die Ausgaben eurer Laufwerksverwaltung anpassen müsst. Die Nummer bekommt ihr abermals über die Datenträgerverwaltung. Ansonsten ist die Syntax von Dd für Windows identisch zum Original für Linux.

### Mit Dd unter Windows RasPi-Image sichern...
$ dd if=\\?\Device\Harddisk2 of=c:\temp\myimage.img bs=1M

### Mit Dd unter Windows RasPi-Image wiederherstellen...
$ dd if=c:\temp\myimage.img of=\\?\Device\Harddisk2 bs=1M

Raspberry-Pi-Image unter Linux sichern

Unter Linux müsst ihr euch nicht irgendwelche Tools besorgen. Das gute alte Dd reicht locker aus, um ein Image einer Raspberry-Pi-Karte zu erstellen und dies auf einer neuen Speicherkarte wiederherzustellen. Dazu braucht ihr allerdings als erstes die Device-ID der SD-Speicherkarte. Legt diese daher in einen an euren Rechner angeschlossenen Kartenleser und lasst euch mit lsblk die angeschlossenen Blockgeräte ausgeben. Über die Größe lässt sich das richtige Speichermedium dann wieder leicht erkennen, in meinem Fall muss ich also mit der sdd oder mit dem vollen Pfad /dev/sdd arbeiten.

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 59,6G 0 disk
├─sda1 8:1 0 53,7G 0 part /
└─sda2 8:2 0 5,9G 0 part [SWAP]
sdb 8:16 0 596,2G 0 disk
└─sdb1 8:17 0 596,2G 0 part /home
sdd 8:48 1 7,4G 0 disk
├─sdd1 8:49 1 56M 0 part
└─sdd2 8:50 1 7,4G 0 part
sr0 11:0 1 1024M 0 rom

Das Sichern und Zurückspielen des Raspberry-Pi-Image mit Dd unter Linux funktioniert nun genauso, wie auch beim ersten Einspielen der Software. Den vorhin ermittelten Pfad zum Laufwerk übergebt ihr dem if-Schalter (Input File), das Ziel dementsprechend dem of-Schalter (Output File). Die Blockgröße von 1 MByte könnt ihr wie oben beim Windows-Beispiel setzen, ihr könnt sie aber auch weglassen.

Vor dem Zurückspielen der Image-Datei würde ich nochmal kurz mit Lsblk überprüfen, ob die neue Speicherkarte auch wirklich nach wie vor noch unter /dev/sdd zu erreichen ist. Das Sync am Ende sorgt dann abschließend dafür, dass sämtliche Zwischenspeicher auf Festplatten und sonstige Datenträger geschrieben werden und die Speicherkarte aus dem Kartenleser gezogen werden kann — Dies ist auch bei Dd nötig.

### Mit Dd unter Linux RasPi-Image sichern...
$ sudo dd if=/dev/sdd of=~/raspberry-pi.img

## Mit Dd unter Linux RasPi-Image wiederherstellen...
$ sudo dd if=~/raspberry-pi.img of=/dev/sdd
$ sync

Das größte Problem bei Dd ist, dass man keine Fortschrittsanzeige angezeigt bekommt. Dd arbeitet still vor sich hin, aber speziell bei größeren Speicherkarten wisst ihr nie, wann der Vorgang nun denn abgeschlossen ist und auch wirklich alles funktioniert. Als Tipp will ich euch daher empfehlen, ab und an aus einem zweiten Terminalfenster das Signal „-USR1“ an den Dd-Prozess zu schicken. Dieser gibt dann, ähnlich wie am Ende des Vorgangs, die bereits kopierte Datenmenge und die aktuelle Schreibgeschwindigkeit in MByte/s aus. Wenn gerade nur ein Dd-Prozess läuft, lässt sich das recht einfach in einem Befehl machen.

### Pkill-Kommando schickt USD1-Signal an Dd...
$ pkill -USR1 -x dd

## Dd im zweiten Terminal gibt Fortschritt aus...
$ sudo dd if=/dev/sdd of=~/raspberry-pi.img
6789345+0 Datensätze ein
6789344+0 Datensätze aus
3476144128 Bytes (3,5 GB) kopiert, 96,136 s, 36,2 MB/s
15523840+0 Datensätze ein
15523840+0 Datensätze aus
7948206080 Bytes (7,9 GB) kopiert, 217,592 s, 36,5 MB/s

Partitionsgröße der neuen Speicherkarte anpassen

Nun habt ihr euren RasPi vielleicht einmal ursprünglich mit einer 4-GByte-Speicherkarte aufgesetzt. Die Micro-SD-Karte für den Raspberry-Pi-B+ habt ihr allerdings nur mit einer Kapazität von 8 oder gar mehr GByte bekommen. Würdet ihr jetzt einfach nur das Image der alten Speicherkarte zurückspielen und dann nichts weiter unternehmen, dann würdet ihr viel Speicherplatz verschwenden. Viele Raspberry-Pi-Distributionen bringen nun aber von Haus aus ein Tool mit, mit dem ihr die Ausnutzung des Speichers schnell optimieren könnt.

$ sudo raspi-config

Unter Raspbian und allen Distributionen, die wie etwa Raspbmc auf Raspbian aufsetzen, ruft ihr dazu Raspi-Config mit Root-Rechten auf. Dort wählt ihr dann direkt den ersten Punkt 1 Expand Filesystem aus der Liste aus. Das Kommando schaut sich die aktuelle Verteilung der Partitionen an und vergrößert dann automatisch die Root-Partition des Systems mit dem noch zur Verfügung stehenden freien Speicherplatz der größeren Speicherkarte.

Ähnliche Funktionen gibt es oft auch bei anderen Distributionen. Findet ihr sie nicht, oder bietet die von euch genutzte RasPi-Distribution sie tatsächlich nicht an — OpenELEC wäre hier so ein Fall — dann greift ihr am besten zum bewährten Partitionswerkzeug Gparted. Linux-Anwender bekommen das Programm selbstverständlich über die Paketverwaltung ihrer Distribution. Wer mit Windows unterwegs ist, der holt sich am besten das Image der Gparted-Live-CD, bannt dieses auf einen USB-Stick und bootet dann seinen Rechner mit dem Gparted-Linux — dabei geht euch euer Windows nicht verloren.

Zum Ändern der Partitionsgrößen legt ihr wie üblich die Speicherkarte in den Kartenleser und wählt die SD-Speicherkarte rechts oben über die Dropdown-Box oder über das Menü und Gparted | Laufwerke aus. Anschließend tippt ihr die Datenpartition an und sucht aus dem Kontextmenü den Punkt Größe ändern/Verschieben heraus. Daraufhin packt ihr die rechte Kante des Speicherbereichs an und zieht die Fläche komplett nach rechts, sodass der anschließende freie Speicherplatz 0 MiByte beträgt. Anschließend schreibt ihr dann mit Bearbeiten | Alle Operationen ausführen oder über den grünen Haken die Änderungen auf die Karte.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Interessant sind aber nicht nur die nackten Zahlen, sondern auch die Frage, ob es sich lohnt, teure Enterprise-Platten zu kaufen oder auf deutlich günstigere Desktop-Festplatten zu setzen — Vergleichbare Enterprise-Modelle kosten gerne mehr als doppelt so viel. Für einen Speicheranbieter wie Backblaze macht es nach eigenen Aussagen wirtschaftlich keinen Sinn, die teuren Enterprise-Festplatten zu nutzen. Selbst wenn 15% aller Desktop-Platten jährlich ausfallen und sämtliche Enterprise-Platten fehlerfrei ihren Dienst tun würden, wäre der Breakeven erst nach 10 Jahren erreicht. Kaum eine Festplatte wird allerdings so lange in den Racks des Dienstes seine Runden drehen, da aktuelle Modelle aufgrund ihrer höheren Speicherdichte deutlich wirtschaftlicher arbeiten.

Für uns kleine NAS-Betreiber stellt sich allerdings eher die Frage nach der Datensicherheit. Da Backblaze seine Daten redundant speichert, dürfen gerne einmal ein paar Festplatten ausfallen. Es muss einfach nur die Platte in das Rack geschoben werden und gut ist — das kostet nur ein wenig Zeit und damit Geld. Spendiert man seinem NAS allerdings ein RAID mit redundanter Datenverteilung, dann kommt man in denselben Luxus. Wie sind denn eure Erfahrungen in der letzten Zeit? Mein letzter Plattencrash ist einige Jahre her und meine Desktop-Rechner und Notebooks sind inzwischen dank SSDs nicht mehr ganz so empfindlich gegenüber spontanen Abstürzen — bildlich gesprochen.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Bei meinem Laptop braucht man gar nicht erst groß zu testen, man hört das Problem alle paar Minuten. Die Festplatte dreht runter und startet nach einem kurzen Päuschen sofort wieder durch. Man kann dies auch mit den Smartmontools gut nachvollziehen, installiert euch das entsprechende Paket und checkt dann im Abstand von ein paar Minuten mit smartctl den „Load_Cycle_Count“ eurer Platte, steigt dieser Zähler permanent an, dann solltet Ihr eingreifen (Anmerkung: Ich beziehe hier alle Befehle auf die erste Platte im System /dev/sda).

$ sudo apt-get install smartmontools
$ sudo smartctl -A /dev/sda | grep Load_Cycle_Count
I93 Load_Cycle_Count    [...]   15225

Der Grund für das Abschalten der Platte liegt im Powermanagement des Systems. Über APM wird die Platte zum Stromsparen in den Ruhezustand geschickt, über hdparm könnt Ihr die entsprechende Konfiguration im Akku- und Netzbetrieb auslesen. Schmeißt dazu wieder das Terminal an und führt die folgenden Befehle aus, in meinem Fall unterscheidet sich der Wert nicht, egal ob das Notebook am Netz hängt oder über den Akku mit Strom versorgt wird.

#### Im Akkubetrieb....
$ sudo hdparm -I /dev/sda |  grep level
Advanced power management level: 127

#### Im Netzbetrieb....
$ sudo hdparm -I /dev/sda |  grep level
Advanced power management level: 127

Im Netzbetrieb sollte das Abschalten der Platte eigentlich so lange wie möglich hinausgezögert werden, ein Wert von 254 wäre daher ideal, allerdings unterscheidet auf meinen System das Powermanagement der Platte nicht zwischen Akku- und Netzbetrieb. Um das permanent zu ändern öffnet Ihr die Konfigurationsdatei /etc/hdparm.conf in einem Texteditor und tragt dort an das Ende der Datei die entsprechenden Einstellungen ein, keine Angst, das ist nicht sonderlich schwer.

$ gksudo gedit /etc/hdparm.conf

Scrollt jetzt bis ans Ende des Editors und übernehmt die folgenden Zeilen, sie regeln für die /dev/sda das Stromsparverhalten. Solltet Ihr über einen Desktop-Ersatz-von-einem-Notebook mit mehreren Platten verfügen, dann müsst Ihr den Eintrag für die weiteren Platten wiederholen. Hattet Ihr vorhin im Akkubetrieb einen anderen Wert als 127, so ändert dies bitte für die Zeile „apm_battery“ entsprechend ab, ich persönlich würde nicht von den Systemvorgaben abweichen.

Speichert nun abschließend eure Änderungen ab und beendet den Editor. Weiter gibt es eigentlich nichts mehr zu tun, das „Schlimmste“ habt Ihr somit hinter euch. Bleibt nur zu hoffen, dass sich das Stromsparverhalten der Platten tatsächlich auch ändert, dies gilt es noch einmal kurz zu überprüfen.

/dev/sda {
        apm = 254            # Netzbetrieb
	apm_battery = 127    # Batteriebetrieb
	spindown_time = 0    # kein Anhalten des Spindelmotors
}

Die Änderungen werden sofort aktiv, wenn sich der Modus ändert. Zieht also einfach mal den Netzstecker und überprüft mit hdparm erneut, ob jetzt immer noch dieselben Werte für den „Advanced power management level“ ausgegeben werden. In meinem Fall sollten jetzt im Akku-Betrieb 127 und im Netz-Betrieb 254 ausgegeben werden.

#### Im Akkubetrieb....
$ sudo hdparm -I /dev/sda |  grep level
Advanced power management level: 127

#### Im Netzbetrieb....
$ sudo hdparm -I /dev/sda |  grep level
Advanced power management level: 254

In meinem Fall beruhigt die Änderung nicht nur das schlechte Gewissen die Platte vorzeitig zu schrotten, sondern auch die Ohren. Das permanente Hoch- und Runterdrehen der Platte ist gerade an einem ruhigen Arbeitsplatz mit der Zeit doch etwas nervend. Durch den Eintrag in die hdparm.conf ist eure Änderung permanent, auch ein Neustart des Systems ändert nichts mehr. Sollte euch diese Anpassung nicht mehr gefallen, dann löscht einfach die von euch eingetragenen Zeilen und schon ist wieder alles beim Alten.

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.

Im Endeffekt ist das Ganze relativ leicht umzusetzen. Erfahrenen Linux-Usern müsste ich nur die Schlagworte hdparm, die Option -S XX und die Konfigurationsdatei hdparm.conf nennen. Wer ausführliche Informationen möchte, der sollte einfach weiterlesen  Erstmal muss man dazu die Daten der Platte herausfinden, die man bei Nichtgebrauch abschalten möchte. Am einfachsten geht dies über die Laufwerksverwaltung von GNOME, die ihr über das Menü unter Einstellungen | System aufrufen könnt. Dort müsstet ihr einfach nur eure Platte raussuchen und euch das entsprechende Gerät /dev/sdXY merken.

In meinem Beispiel arbeite ich also mit der Platte /dev/sdc. Wahrscheinlich handelt es sich bei euch um ein anderes Gerät, von daher müsst ihr die folgenden Hinweise an eure Situation anpassen. Für KDEler gibt es alternativ sicherlich auch in der KDE SC ein entsprechendes Werkzeug, und wenn alle Stricke reißen, hilft auf jeden Fall ein sudo fdisk -l weiter.

Nun überprüft ihr am besten erst einmal, ob sich eure Platte überhaupt in den Leerlauf schicken lässt. Alle halbwegs aktuellen Platten und Controller sollten dazu eigentlich in der Lage sein, aber bevor ihr euch später wundert, warum das nicht funktioniert, solltet ihr erstmal einen kleinen Test machen. Ruft dazu hdparm mit der Option -C auf…

$ sudo hdparm -C /dev/sdc
/dev/sdc:
 drive state is:  active/idle

Man sieht, dass hdparm den Status korrekt abrufen konnte und die Platte läuft – man sollte dies auch an ihrem Betriebsgeräusch erkennen können. Nun könnt ihr die Platte einmal von Hand abschalten…

$ sudo hdparm -y /dev/sdc

…der Erfolg der Aktion sollte hörbar sein. Optional könnt ihr erneut mit der Option -C nachprüfen, ob die Platte auch wirklich in den Standby geschickt werden konnte.

$ sudo hdparm -C /dev/sdc
/dev/sdc:
drive state is:  standby

Sobald ihr wieder auf die Platte zugreift (bspw. über den Dateimanager), wird die Platte wieder automatisch anlaufen und ihre Daten preisgeben. Nun wäre es recht umständlich, die Platte immer von Hand abzuschalten. Besser wäre es, wenn sich die Platte nach einer gewissen Zeit ohne Zugriffe automatisch abstellen könnte.

Dazu gibt es die Option -S XX von hdparm. Über sie könnt ihr eine Zeitspanne definieren, ab der die Platte abgeschaltet wird. Der Zahlenwert hinter dem Schlüssel drückt nicht direkt die Zeit aus, sondern dient nur als Multiplikator. Ich zitiere einfach mal die man-Page…

Values from 1 to 240 specify multiples of 5 seconds, yielding timeouts from 5 seconds to 20 minutes. Values from 241 to 251 specify from 1 to 11 units of 30 minutes, yielding timeouts from 30 minutes to 5.5 hours. A value of 252 signifies a timeout of 21 minutes. A value of 253 sets a vendor-defined timeout period between 8 and 12 hours, and the value 254 is reserved. 255 is interpreted as 21 minutes plus 15 seconds. Note that some older drives may have very different interpretations of these values.

Ein Wert von bspw. 60 entspricht daher 60*5 Sekunden, also 300 Sekunden oder fünf Minuten. Zu kurz sollte man das Timeout nicht wählen, da zu häufiges Runter- und wieder Hochdrehen des Motors die Lebensdauer der Platte beeinträchtigen kann.

$ sudo hdparm -S 60 /dev/sdc

Damit das Ganze automatisch beim Start des Systems ausgeführt wird, solltet ihr diese Einstellung in der Konfigurationsdatei /etc/hdparm.conf speichern. Am besten arbeitet ihr in dem Fall mit UUIDs, sodass sich der Eintrag immer auf die gewünschte Platte bezieht, selbst wenn sich eure Plattenkonfiguration einmal ändern sollte. Bestimmt die UUID über bspw…

$ sudo blkid
[...]
/dev/sdb1: LABEL="data-intern" UUID="ff7f1cdd-431a-4e47-8b90-49737cec82b3" TYPE="ext4"
/dev/sdc1: LABEL="datengrab" UUID="4c9dca33-e3e1-4a6a-a7d4-110cdbb4cfbe" TYPE="ext3"

…und fügt dann einfach euren gewünschten Eintrag an das Ende der hdparm.conf an…

$ sudo gedit /etc/hdparm.conf
[...]
/dev/disk/by-uuid/4c9dca33-e3e1-4a6a-a7d4-110cdbb4cfbe {
	spindown_time = 60
}

…ab dem nächsten Neustart sollte die Einstellung automatisch aktiv sein und eure Platte bei Nichtgebrauch abgeschaltet werden. Abschließend noch der Hinweis, dass ihr beim Arbeiten mit hdparm wirklich euer Hirn einschalten müsst. Bei der „Schlaffunktion“ müsst ihr – wie bereits erwähnt – bedenken, dass zu häufiges Hochdrehen der Platte die Lebensdauer reduzieren kann. Setzt das Intervall daher auf keinen Fall zu kurz. [UPDATE 13.07.2012: Ich habe den Beitrag auf die aktuelle Syntax der hdparm.conf umgestellt, damit dürften einige Rückfragen aus den Kommentaren geklärt sein.]

☕ Linux und Ich unterstützen
Danke, dass du Linux und Ich liest. Wenn dir das Blog gefällt und du meine Arbeit unterstützen möchtest, findest du weitere Informationen auf der Blogspende-Seite.