könnte mir bitte jemand Schritt für Schritte erklären wie man ein Backup Image das mit Win32 Disk Imager erstellt worden ist mit dem Tool PiShrink verkleinert?
Bei Google sind unter den ersten 10 Treffern zu "PiShrink" mind. 7 Anleitungen.
Meine SD Karte ist 8Gb groß.
Der USB-Stick hat eine Größe von 16Gb.
Wenn dein USB-Stick größer ist als das Image von der SD Karte brauchst du doch gar kein PiShrink?
Ich komprimiere die Backup-Datei einfach mit der Standardfunktion im Windows-Explorer.
Das dient natürlich nur der Platzersparnis und ermöglicht kein Restore auf einer kleineren SD.
Ich habe mir jetzt ein 64GB große Micro SD Karte von Sandisk gekauft.
Da wird das Backup ja sehr groß. Aus diesem Grund will ich das Image danach verkleinern.
Mir erschließt sich der Sinn davon nicht. Wenn das Betriebssystem vom Raspberry und die ganzen Plugins nur wenige GB einnehmen, warum nimmt man eine 64GB große Karte, wo jedes mal ein Backup-Image in der Größe der SD Karte angelegt wird, welches danach verkleinert werden muss? Hast du zu viel Zeit, dass du 3 Stunden warten kannst, bis das 64GB große Backup fertig ist, obwohl du das ganze Betriebssystem auch auf eine 8GB Karte bekommst und davon ein Backup nur 30min dauert?
mit "mount" solltest du sehen wo der Stick gemountet ist
zB so:
in /mnt/sda1/
pishrink.sh -? gibt aus:
ohne AutoRestore
pishrink.sh -rs quell.img quell_shrink.imgmit AutoRestore
pishrink.sh -r quell.img quell_shrinkAutoRestore.imgIch lasse das Backup durch gzip laufen
dd -> gzip -> USB Stick
Ich lasse das Backup durch gzip laufen
Da wird die Datei kleiner, aber man kann das Image nicht auf einer kleineren SD Karte wieder herstellen
Alles anzeigenmit "mount" solltest du sehen wo der Stick gemountet ist
zB so:
in /mnt/sda1/
pishrink.sh -? gibt aus:
ohne AutoRestore
Codepishrink.sh -rs quell.img quell_shrink.imgmit AutoRestore
Codepishrink.sh -r quell.img quell_shrinkAutoRestore.img
Das -rs ist doch eine Kombination von beiden oder?
Was ist den besser für eine Option herzunehmen?
Ich hätte jetzt bloß -sZ benutzt das ich das Image eventuell auf eine 16GB oder 32GB SD-Karte spielen kann und das das Image zum archivieren komprimiert wird. Oder sollte man lieber -rsZ nutzen?
Das -rs ist doch eine Kombination von beiden oder?
genau ist eine Kombination aus r und s, r ist vorsichtshalber. Falls es Fehler findet wird eine erweiterte Reparatur benutzt. (was ich im Batchmodus schon brauchte)
z (zip) und Z (gz) sind nur für anschliessendes Packen des Image. Dauert länger und brachte dann nicht sehr viel bei mir.
Werde mir lieber mal 2-3 8GB Karten holen, dann hab ich das Problem nicht. Oder besser 16er, was meint ihr?
wenn es einmal runter geladen ist, reicht das.
Nur nach einer Aktualisieren muss es neu runter geladen werden.
cd /mnt/sda1
sudo pishrink.sh -rsZ ./imagefile.img ./newimagefile.imgwenn der USB Stick in /mnt/sda1 gemounted wurde.
Zu beachten ist das pishrink die ImageDatei erst kopiert (mind. freier Platz für 2x das Image auf dem USB Stick) und dann shrinkt.
Dann wird es geschrinkt und anschliesend gepackt.
Also sollte mindesten Platz sein auf dem USB Stick für 2 bis 2,5 mal die Image Datei.
Am Ende wird die geshrinkte Image Datei wieder gelöscht.
Werde mir lieber mal 2-3 8GB Karten holen, dann hab ich das Problem nicht. Oder besser 16er, was meint ihr?
Nützt nur wenn diese alle aus einer Scharge sind,.
Sobald welche in der gleichen Grösse nach gekauft werden oder von anderem Hersteller sind.
Kann es sein das diese etwas zu klein ist und das Image sich nicht flashen lässt.
Alles anzeigenmit "mount" solltest du sehen wo der Stick gemountet ist
zB so:
in /mnt/sda1/
pishrink.sh -? gibt aus:
ohne AutoRestore
Codepishrink.sh -rs quell.img quell_shrink.imgmit AutoRestore
Codepishrink.sh -r quell.img quell_shrinkAutoRestore.img
Was bringt mir eigentlich die AutoRestore Funktion?
Was bringt mir eigentlich die AutoRestore Funktion
Da wird nach dem ersten Start des raspberry die Partition (benutzbare Platz) automatisch erweitert auf das Maximum der SD Karte.
Alles anzeigenwenn es einmal runter geladen ist, reicht das.
Nur nach einer Aktualisieren muss es neu runter geladen werden.
Codecd /mnt/sda1 sudo pishrink.sh -rsZ ./imagefile.img ./newimagefile.imgwenn der USB Stick in /mnt/sda1 gemounted wurde.
Zu beachten ist das pishrink die ImageDatei erst kopiert (mind. freier Platz für 2x das Image auf dem USB Stick) und dann shrinkt.
Dann wird es geschrinkt und anschliesend gepackt.
Also sollte mindesten Platz sein auf dem USB Stick für 2 bis 2,5 mal die Image Datei.
Am Ende wird die geshrinkte Image Datei wieder gelöscht.
Ich hab mir jetzt einen USB Stick mit 256GB gekauft da sollte jetzt mal ausreichend Speicher zur verfügung stehen.
Ich hab aber jetzt noch mal eine Frage für was braucht man den ./ ?
Reicht der Befehl so nicht aus!?
sudo pishrink.sh -rsZ imagefile.img newimagefile.imgfür was braucht man den ./
Er soll die Dateien aus diesem Ordner nehmen wo man gerade steht. Also vorher mit cd in den Ordner gehen.
(da der Ordner mit den img-Dateien nicht im Suchpfad steht)
jetzt hab ich mal das Image mit diesen Befehl verkleinert.
sudo pishrink.sh -drsZ ./ Raspberry_Pi.img ./new_ Raspberry_Pi.imgDas Problem wo jetzt noch besteht ist das das Image nicht mit xz komprimiert wird.
Das ist das Logfile dazu.
pishrink.sh v0.1.2
pishrink.sh: Copying ./Raspberry_Pi.img to ./new_Raspberry_Pi.img... ...
pishrink.sh: Gathering data ...
Line 296
beforesize: 30G
parted_output: BYT;
/media/usb/new_Raspberry_Pi.img:31914983424B:file:512:512:msdos::;
1:4194304B:272630271B:268435968B:fat32::lba;
2:276824064B:31914983423B:31638159360B:ext4::;
partnum: 2
partstart: 276824064
parttype: primary
tune2fs_output: tune2fs 1.44.5 (15-Dec-2018)
Filesystem volume name: rootfs
Last mounted on: /
Filesystem UUID: 5cc77913-6bcb-4f0c-8bc2-12209fb2095b
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 1880448
Block count: 7724160
Reserved block count: 315472
Free blocks: 6365385
Free inodes: 1685446
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 208
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 7968
Inode blocks per group: 498
Flex block group size: 16
Filesystem created: Sat Sep 7 23:28:17 2019
Last mount time: Tue Jan 26 18:01:27 2021
Last write time: Sat Sep 7 23:29:43 2019
Mount count: 103
Maximum mount count: -1
Last checked: Sat Sep 7 23:28:17 2019
Check interval: 0 (<none>)
Lifetime writes: 69 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: 6f92e79a-d5cd-401f-9cb8-be5f9ebccac8
Journal backup: inode blocks
currentsize: 7724160
blocksize: 4096
Skipping autoexpanding process...
pishrink.sh: Checking filesystem ...
rootfs: 195002/1880448 files (1.2% non-contiguous), 1358775/7724160 blocks
resize2fs 1.44.5 (15-Dec-2018)
Line 325
currentsize: 7724160
minsize: 1502065
Line 333
extra_space: 6222095
Line 340
minsize: 1507065
pishrink.sh: Shrinking filesystem ...
resize2fs 1.44.5 (15-Dec-2018)
Resizing the filesystem on /dev/loop0 to 1507065 (4k) blocks.
Begin pass 2 (max = 204503)
Relocating blocks ----------------------------------------XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 236)
Scanning inode table ----------------------------------------XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 26494)
Updating inode references ----------------------------------------XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/loop0 is now 1507065 (4k) blocks long.
Line 359
partnewsize: 6172938240
newpartend: 6449762304
pishrink.sh: Shrinking image ...
Line 384
endresult: 6449762816
pishrink.sh: Using xz on the shrunk image ...Ich hab es gestern Abend so gegen 22 Uhr angestoßen und heute in der Früh um 5 Uhr sah es dann so aus.
Länger ist das log nicht?
Ist noch Platz auf dem Ziel?
Evtl. mal mit -drsz testen, das benutzt gzip
Hat den Vorteil man kann mit Etcher gleich die zip Datei als Restore Quelle nutzen.