Filesystem Resize für SSDs und Festplatten

    (Zurück zum Inhaltsverzeichnis)

    Einleitung

    Ich hatte mal mit pishrink ein Image verkleinert und wollte es später auf eine etwas größere SSD zu kopieren.

    Dummerweise vergrößerte Pishrink das Image nicht wieder, sondern bootete immer wieder neu.

    Ich vermute, das das Filesystem beim Resize einen Timeout auslöste, da die SSDs mit 480 bzw. 500 GB doch etwas gross waren.

    Die Meldung(en) war zu schnell wieder weg um sie noch lesen zu können. Also war Handarbeit angesagt.


    Bei der Suche nach einem händischen Resize verschlug es mich u.A. auf die Webseiten von Hetzner und James A. Chambers

    die die wichtigsten Informationen lieferten.

    Nachdem ich 3 SSDs (240GB, 480GB, 500GB) erfolgreich "Resized" hatte, schrieb ich mir das Verfahren als Gedächtnisstütze auf meinem Wiki mit.

    Und weil ich zu faul bin die Doku immer wieder neu zu suchen.

    Für diese Anleitung habe ich eine ältere 120GB SSD eingesetzt, um das Verfahren zu dokumentieren.

    Das Betriebssytem ist Debian Buster, der verwendete Rechner ist ein Raspberry4-4GB

    Anmerkung: Als Editor benutze ich hier den Vi (Vim), aber wer will kann auch nano, ne, geany, kate, ... einsetzen.


    Bevor man die SD-Karte ausliest sollte man noch den max. USB-Strom für die SSD heraufsetzen:

    sudo vi /boot/config.txt

    Am Ende diese Zeile (Nur bei dem B+ und 2er-Modell) hinzufügen:

    max_usb_current=1

    Die 3er und die 4er können von Hause aus 1.2A, siehe: https://www.raspberrypi.org/documentation/…power/README.md

    Danke hyle für den Hinweis.


    Das Image vorbereiten

    Erstmal die SD-Karte auslesen

    Dazu habe ich die SD-Karte auf einem anderen Linux-Rechner mittels Cardreader angeschlossen, hier war es ebenfalls ein Raspberry.

    Auf genügend Speicherplatz achten! Man braucht den Platz für 2 Images, das normal Große und das geschrinke Image.

    Der Filename ist deshalb etwas "komisch", weil es sich bereits um ein für meine Zwecke zugeschnittenes (Master-)Image handelt.

    Das Device ist in diesem Fall "/dev/sda" (mit "lsblk" ermittelt)

    und nach dem unmounten wird der Inhalt der SD-Karte ins aktuelle Verzeichnis kopiert:

    sudo dd if=/dev/sda of=20200404_raspian_buster_Juergen.img

    oder mit Anzeige (dcfldd muss eventl. nachinstalliert werden)

    sudo dcfldd if=/dev/sda of=20200404_raspian_buster_Juergen.img

    Wenn das erfolgreich war, sollte die letzte Ausgabe etwa so aussehen:

    244992 blocks (7656Mb) written

    245216+0 records in

    245216+0 records out

    Und im Verzeichnis sollte sich jetzt eine ähnliche Datei befinden:

    -rw-r--r-- 1 root root 8035237888 Apr 4 20:37 20200404_raspian_buster_Juergen.img

    Hier ist es ein Image von einer 8GB SD-Karte.

    Das Image verkleinern

    Das Ziel dieser Maßnahme ist die Kopierzeit zu verkürzen, man kann diesen Schritt auch auslassen wenn man das Image direkt auf die SSD kopiert.

    Auf der Seite https://github.com/Drewsif/PiShrink/ befindet sich ein Script, mit dem sich das Image (unter Linux) einfach verkleinern läßt:

    wget https://raw.githubusercontent.com/Drewsif/PiShrink/master/pishrink.sh

    Dann ausführbar machen:

    sudo chmod +x pishrink.sh

    Jetzt kann man das Image verkleinern:

    sudo ./pishrink.sh -s 20200404_raspian_buster_Juergen.img 20200404_raspian_buster_Juergen_s.img

    Die Option "-s" verhindert, das beim ersten Booten von SSD versucht wird, das Dateisystem zu vergrößern.

    Die Ausgabe sollte etwa so aussehen:

    Hier wurde zum Auslesen und Shrinken ein Raspberry benutzt. Das Ergebnis sieht dann etwa so aus:

    -rw-r--r-- 1 root root 8035237888 Apr 4 20:37 20200404_raspian_buster_Juergen.img

    -rw-r--r-- 1 root root 3540230656 Apr 4 20:46 20200404_raspian_buster_Juergen_s.img

    Mehr als die Hälfte geschrumpft.

    Die SSD bearbeiten

    Und nun zur SSD

    Eine Warnung: Wer hier das falsche Device angibt löscht seine Platte unwiderruflich. Alle Daten sind definitiv weg!

    Daher erstmal mit lsblk das Ziel überprüfen (hier ist es wieder /dev/sda), und dann mit:

    sudo dd if=20200404_raspian_buster_Juergen_s.img of=/dev/sda

    oder mit Anzeige

    sudo dcfldd if=20200404_raspian_buster_Juergen_s.img of=/dev/sda

    auf die SSD schreiben.

    Partition ändern

    Daraufhin habe ich die SSD entfernt und mit der alten SD-Karte den RPi gebootet.

    Anschließend habe ich die SSD wieder über USB angeschlossen.

    Ein sudo blkid gab dann folgende Informationen aus:

    Code
    /dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="6341-C9E5" TYPE="vfat" PARTUUID="ea7d04d6-01"
/dev/mmcblk0p2: LABEL="rootfs" UUID="80571af6-21c9-48a0-9df5-cffb60cf79af" TYPE="ext4" PARTUUID="ea7d04d6-02"
/dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="6341-C9E5" TYPE="vfat" PARTUUID="ea7d04d6-01"
/dev/sda2: LABEL="rootfs" UUID="80571af6-21c9-48a0-9df5-cffb60cf79af" TYPE="ext4" PARTUUID="ea7d04d6-02"
/dev/mmcblk0: PTUUID="ea7d04d6" PTTYPE="dos"

    Dann ein

    sudo mount /dev/sda2 /mnt/

    gefolgt von einem

    Hier sieht man das die Partition (sda2) noch nicht vergrößert ist.

    Filesystem checken

    Für die nachfolgende Prozedur muss die Partition erstmal wieder ausgehängt werden,

    denn die nachfolgenden Prozeduren funktionieren nur wenn die Dateisysteme nicht eingehängt sind.

    sudo umount /dev/sda2

    sudo umount /dev/sda1

    Sicherheithalber die 2. Partition nochmal überprüfen:

    Code
    sudo fsck.ext4 -f /dev/sda2
e2fsck 1.44.5 (15-Dec-2018)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
rootfs: 109965/198800 files (0.4% non-contiguous), 785659/797754 blocks

    Hier wurden keine Fehler korrigiert, also nächster Schritt.

    Partition bearbeiten

    Hier sind erstmal alle Schritte am Stück, eine kurze Erklärung erfolgt danach.

    Die Erklärung

    War ein bißchen viel für den Anfang, aber der Reihe nach:

    Nachdem Aufruf den Buchstaben "p" eingeben, er listet die Informationen der Platte auf, hier sind es 2 Partitionen:

    Device Boot Start End Sectors Size Id Type

    /dev/sda1 8192 532479 524288 256M c W95 FAT32 (LBA)

    /dev/sda2 532480 6914512 6382033 3G 83 Linux

    Ich will nur die 2. Partition vergrößern und schreibe mir den Start (532480) auf, das wird noch sehr wichtig.

    Dazu lösche ich die Partition mit "d" gefolgt von der Partitionsnummer: "2"

    Command (m for help): d

    Partition number (1,2, default 2): 2

    Partition 2 has been deleted.

    Jetzt lege ich eine neue primäre Partition mit "n", gefolgt von einem "p" an:

    Command (m for help): n

    Partition type p primary (1 primary, 0 extended, 3 free) e extended (container for logical partitions)

    Select (default p): p

    Partition number (2-4, default 2): 2

    First sector (2048-234441647, default 2048): 532480

    Last sector, +/-sectors or +/-size{K,M,G,T,P} (532480-234441647, default 234441647):

    Hier muss ich bei First sector meinen Startsector (532480) eingeben, beim Last sector kann man den default übernehmen.

    Jetzt bekommt man folgende Ausgabe:

    Created a new partition 2 of type 'Linux' and of size 111,5 GiB.

    Partition #2 contains a ext4 signature.

    Do you want to remove the signature? [Y]es/[N]o: n

    Command (m for help): w

    The partition table has been altered.

    Syncing disks.

    Die Signatur sollte ext4 bleiben.

    Erst mit dem Kommando "w" wird die Partitionstabelle geschrieben, bis zu diesem Punkt kann noch abbrechen.

    Resize

    Das war die Vergrößerung der Partition, fehlt noch ein Resize:

    sudo resize2fs /dev/sda2

    resize2fs 1.44.5 (15-Dec-2018)

    Resizing the filesystem on /dev/sda2 to 29238646 (4k) blocks.

    The filesystem on /dev/sda2 is now 29238646 (4k) blocks long.

    Restarbeiten an der SSD

    Filesystem checken

    Das Filesystem nochmal überprüfen:

    Code
    sudo fsck.ext4 -f /dev/sda2
e2fsck 1.44.5 (15-Dec-2018)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
rootfs: 109965/7101136 files (0.4% non-contiguous), 1220690/29238646 blocks

    Auch in Ordnung, also weiter.

    Kurz reinschnuppern

    Filsystem testweise einhängen:

    sudo mount /dev/sda2 /mnt/

    Sieht auch gut aus. Wenn man einen Raspberry 2 oder 3 hat, kann man jetzt nach einem:

    sudo halt

    die SD-Karte entfernen und dann hoffentlich schon von der SSD booten.

    Vorerst nur für den Raspberry4

    Die PARTUUID ändern

    Das braucht man nur solange der Raspberry4 nicht von USB booten kann, genauer: solange sich die Boot-Partition auf der SD-Karte befindet.

    Durch das klonen von SD-Karte auf SSD hat man auch identische PARTUUIDs:

    sudo blkid

    /dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="6341-C9E5" TYPE="vfat" PARTUUID="ea7d04d6-01"

    /dev/mmcblk0p2: LABEL="rootfs" UUID="80571af6-21c9-48a0-9df5-cffb60cf79af" TYPE="ext4" PARTUUID="ea7d04d6-02"

    /dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="6341-C9E5" TYPE="vfat" PARTUUID="ea7d04d6-01"

    /dev/sda2: LABEL="rootfs" UUID="80571af6-21c9-48a0-9df5-cffb60cf79af" TYPE="ext4" PARTUUID="ea7d04d6-02"

    /dev/mmcblk0: PTUUID="ea7d04d6" PTTYPE="dos"

    Dadurch bootet der Raspberry weiterhin penetrant von der SD-Karte und läßt die SSD links liegen.

    Also müssen wir noch die PARTUUID ändern:

    Hier ändere ich den Diskidentifier nur um eine Ziffer, aber das reicht vollkommen aus.

    Wenn man jetzt nachsieht:

    sudo blkid

    /dev/mmcblk0p1: LABEL_FATBOOT="boot" LABEL="boot" UUID="6341-C9E5" TYPE="vfat" PARTUUID="ea7d04d6-01"

    /dev/mmcblk0p2: LABEL="rootfs" UUID="80571af6-21c9-48a0-9df5-cffb60cf79af" TYPE="ext4" PARTUUID="ea7d04d6-02"

    /dev/sda1: LABEL_FATBOOT="boot" LABEL="boot" UUID="6341-C9E5" TYPE="vfat" PARTUUID="ea7d04d7-01"

    /dev/sda2: LABEL="rootfs" UUID="80571af6-21c9-48a0-9df5-cffb60cf79af" TYPE="ext4" PARTUUID="ea7d04d7-02"

    /dev/mmcblk0: PTUUID="ea7d04d6" PTTYPE="dos"

    sieht man, das die PARTUUID für /dev/sda geändert wurde.

    /boot/cmdline.txt anpassen

    Da der Raspberry 4 noch nicht von USB booten kann, muss man zu einem kleinen Trick greifen.

    Die Startfiles bleiben dabei auf der SD-Karte, das Betriebssystem wird aber von SSD geladen.

    Dazu erstellt man erstmal eine Sicherheitskopie:

    sudo cp /boot/cmdline.txt /boot/cmdline.txt.ori

    Danach ändert man folgenden Eintrag:

    root=PARTUUID=ea7d04d6-02 auf root=PARTUUID=ea7d04d7-02

    Hier mal meine komplette Zeile als Beispiel (Eine Zeile):

    console=serial0,115200 console=tty1 root=PARTUUID=ea7d04d7-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles logo.nologo

    Die fstab auf der SSD anpassen

    Code
    sudo mount /dev/sda2 /mnt
sudo vi /mnt/etc/fstab
proc                 /proc proc defaults         0   0
PARTUUID=ea7d04d6-01 /boot vfat defaults         0   2
PARTUUID=ea7d04d7-02 /     ext4 defaults,noatime 0   1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that

sudo umount /dev/sda2

    So bleibt die Boot-Partition auf der SD-Karte, das Betriebssytem wird jetzt von der SSD geholt.

    Letzter Schritt

    Jetzt kommt der Moment wo der Frosch in den Tümpel hüpft:

    sudo reboot

    Wenn der Raspberry wieder da ist, sollte jetzt mit:

    unter /dev/root die Größe der SSD sichtbar werden.
    Die letzten beiden Partitionen werden automatisch eingehängt sobald man sich als User einloggt.

    Anmerkungen

    Ich habe hier mitgeschrieben während ich eine SSD angepasst habe,

    alle Werte, die hier stehen (Startsector, PARTUUID, Devices, ...) sind nur Beispiele

    und werden sich von Gerät zu Gerät unterscheiden. Also nicht einfach alles kopieren was bei drei nicht auf dem Baum ist.

    Weiterhin hatte ich mir ein Image erstellt, das ich schon vorkonfiguriert hatte.

    Und falls die SSD partout nicht laufen will, kann man die Option (Beispiel):

    usb-storage.quirks=152d:0578:u

    mal ausprobieren, wie hier in [Tip]Firmwareupdate für USB3.0 SATA Adapter 152d:0578 beschrieben.

    Aber Achtung, vorher mittels lsusb die Kennung des Adapters ermitteln und entsprechend anpassen!
    Der /boot/cmdline.txt sähe dann etwa so aus:

    usb-storage.quirks=152d:0578:u console=serial0,115200 console=tty1 root=PARTUUID=ea7d04d7-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles logo.nologo

    Achja, dieser Apapter brauchte wirklich das Firmwareupdate.

    MfG

    Jürgen

    Edit: Fiptehler und Formatierung nachgebessert

    Edit: Irgendetwas hat mir die Formatierung zerlegt, ich hoffe, das ich alles wieder korrigiert habe.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login