RAW Images verkleinern

Di, 24. Januar 2023, Michel

Aktuell habe ich ein Image einer Festplatte erstellt. Zwei Probleme haben sich dabei ergeben. Zum einen ist das IMG viel zu gross. Darin sind nur 10 % des Speichers belegt. Zum anderen bekomme ich das nicht auf die Zielplatte, die leider etwas kleiner ist.

Was mache ich nun?

Meine ersten Recherchen haben bedauerlicherweise nichts ergeben. Doch vor kurzem bin ich zufällig auf eine mögliche Lösung gestossen, als ich herausfinden wollte, wie das automatische Expandieren der Festplatte bei Raspberry Pi Images funktioniert. Dabei kommt ein geniales Werkzeug zum Einsatz, namentlich PIShrink.

Zur Nutzung übergibt man dem Tool ein Quell und ein Zielimage und lässt es seine Arbeit tun.

pishrink.sh {QuellIMG} {ZielIMG}

Das Ergebnis ist ein in der Grösse deutlich reduziertes Image.

Bei zwei Tests bin ich allerdings auf Probleme gestossen. Zum einen kann PiShrink wohl kein BTRFS verkleinern, zum anderen klappt die Verkleinerung nur, bei der letzten Partition im IMG. Bei einem meiner Tests war die letzte Partition eine SWAP Partition.

Was tut man da? Ganz klar. Man löscht die SWAP.

Während ich so weiter zu PiShrink recherchiert habe, sind mir zwei hilfreiche Werkzeuge aufgefallen. kpartx zusammen mit gparted.

kpartx erlaubt den Schreibzugriff auf ein Image. Gnome Disks z.B. bindet IMG Dateien nur lesend ein.

sudo kpartx -av {IMGDatei}

Im Terminal wird durch Angabe von -v die loop Nummer der Partitionen angezeigt, beispielsweise loop28p1. Nun kann ich das IMG mit gparted bearbeiten. Damit gparted die Partition bearbeiten kann, muss diese schon beim Starten von gparted mit angegeben werden. z.B. gparted /dev/loop28

loop28 repräsentiert das IMG bzw. die Festplatte. Mit p1 wäre eine Partition innerhalb des Images gemeint.

Nun kann die SWAP Partition gelöscht werden. Dabei sollte zudem nachgeprüft werden, ob auch wirklich die zu schrumpfende Partition die Letzte im IMG ist. Wenn ihr möchtet, könnt ihr aber gerne auch mit gparted die Partitionen verkleinern. Leider wird PiShrink auch dann gebraucht, wenn die Partition in gparted verkleinert wird. Der Grund ist der, dass ja auch das .img File verkleinert werden muss. Wer möchte, kann dazu alternativ den Befehl truncate nutzen. Man sollte sich dabei einfach bei der erforderlichen Grösse nicht verrechnen. Da ich kein Bock auf Mathe-Fehler habe, lasse ich das dennoch PiShrink erledigen. Ich verkleinere also nur Partitionen mit gparted welche PiShrink eh nicht bearbeitet.

Nach dem Mounten mit kpartx stehen sofort die Partitionen auch im Dateibrowser zur Verfügung. Unter Gnome kann ich nun die Partition öffnen und dann die Daten modifizieren. Ich lösche den Inhalt von ~/.cache/ und prüfe den Inhalt von ~/.local/share/Trash/files/ und lösche auch diese gegebenenfalls.

Unter / lösche ich mindestens den Inhalt von /tmp/ (Ich lösche noch mehr, siehe WICHTIG weiter unten).

Weil ich dafür Root-Rechte benötige, wechsle ich mit CTRL+L in die Adresszeile des Dateibrowsers und hänge ein admin: vor den Ordnerpfad.

Nach Abschluss unmounte ich mit folgendem Befehl das IMG:

 sudo kpartx -d {IMGDatei}

Daraufhin führe ich wie eingangs erwähnt PiShrink aus:

pishrink.sh -s {QuellIMG} {ZielIMG}

Mit dem Parameter -s verhindere ich, dass PiShrink das automatische Erweitern der Partition ins System schreibt. Meine Images, mit denen ich gerade arbeite, sind keine Images von RaspberryPI.

WICHTIG:
Das Wiederherstellen eines modifizierten solchen Systems habe ich nicht getestet. Meine Backups verfolgen das Ziel, die wichtigen User Verzeichnisse unter /home/ und die Daten in /etc zu sichern. Und solange ich entweder mit GNOME Disks oder mit kpartx darauf zugreifen kann, sind die Images für mich nutzbar.

Tatsächlich habe ich nach dem Artikel bislang keinen Restore durchgeführt. Ich gehe eher hin und lösche die grossen unnötigen Dateien wie /usr/lib/, /usr/share/, /var/lib/ und /var/log/ den Rest belasse ich. Es braucht nicht so viel Speicher, und viele Backups in Images mache ich nicht. Am Ende weiss man eh nicht, was man wirklich für Daten braucht. Das hypothetische Szenario hätte ich vor zwei Jahren mal gebraucht. Zurzeit aber nicht.

Nun kann ich aber meinen Mediacenter-Pi in voller Grösse sichern und dann shrinken, wenn ich den Fall hätte, dass ich ein Backup auf einen kleineren Datenträger wiederherstellen muss. Gleichzeitig kann ich aber, ohne Probleme auch mehrere Versionen sichern, ohne Platzprobleme zu bekommen. Die ältere verkleinere ich und halte die dann auch noch vor.

Quellen:
PiShrink: https://github.com/Drewsif/PiShrink
kpartx: https://github.com/opensvc/multipath-tools
gparted: https://gparted.org/

Tags

kpartx, gparted, PiShrink, dd, cli, bash, backup, shrink, compress