Forum: PC Hard- und Software Raspberry PI -> Pishrink -> ERROR: Image already shrunk to smallest size


von RPier (Gast)


Lesenswert?

Hey Leute,

Leider funktioniert bei mir da PIShrink.sh nicht wirklich so, wie ich es 
will.
Ich kann es normal starten, bekomme dann aber folgende Ausgabe:
1
Copying /tempusb/big.img to /tempusb/lil.img...
2
/dev/loop2: 66795/181424 files (1.9% non-contiguous), 539551/728235 blocks
3
resize2fs 1.44.5 (15-Dec-2018)
4
ERROR: Image already shrunk to smallest size

Hat jemand schon mal da Problem gehabt, oder erahnt eine Lösung?

von Oliver S. (oliverso)


Lesenswert?

RPier schrieb:
> ERROR: Image already shrunk to smallest size

Könnte es denn so sein, wie das Script es behauptet?

Oliver

von RPier (Gast)


Lesenswert?

Nein. Die beiden Datein sind gleich gross.
Ausserdem wird NICHTS weiter ausgegeben.
Normalerweise sieht die Ausgabe ganz anders aus.

Früher hat es funktioneirt.
Da habe ich aus meinem 8GB Image eines mit 2GB draus gemacht.

von Karl (Gast)


Lesenswert?

RPier schrieb:
> Da habe ich aus meinem 8GB Image eines mit 2GB draus gemacht

War wohl ein ziemlich leeres Image. Oder ein Wunder.

von RPier (Gast)


Lesenswert?

Karl schrieb:
> RPier schrieb:
>> Da habe ich aus meinem 8GB Image eines mit 2GB draus gemacht
>
> War wohl ein ziemlich leeres Image. Oder ein Wunder.

Ähhhhnm. Wenn ein Datenträger 8GB hat aber nur 123MB auf dem Datenträger 
belegt sind, wie gross ist das Image?
Stimmt -> 8 GB.

Warum wird PIShrink verwendet?
Genau. Das das Image nachher die (imaginären) 123MB hat.

Habe jetzt schon unter Stretch und Buster probiert.
Scheint da gleiche Problem zu sein.
Image mit Win32Diskimage und DD gezogen:
Selbes Problem.

RechteProblem sollte es auch nicht sein, denn
sudo /usr/local/sbin/pishrink.sh /tempusb/big.img /tempusb/lil.img
kopiert zuerst die img and bricht danach mit dem Fehler ab.

Darum nochmals die modifizierte Frage in die Runde:
Wer kennt PiShrink, kann es nutzen und kann zu meinem Problem 
konstruktive Lösungsvorschläge bringen?

von Mario P. (Gast)


Lesenswert?

Der Blick ins Script zeigt, daß hier lediglich der standard-Kopierbefehl 
"cp mit der Option "--sparse=always" genutzt wird.:

# cp --reflink=auto --sparse=always "$1" "$2"


Der Blick in die man-page des cp-Befehls zeigt:

"By default, sparse SOURCE files are detected by a crude heuristic and 
the corresponding DEST file is made sparse as well. That is the behavior 
selected by --sparse=auto. Specify --sparse=always to create a sparse 
DEST file whenever the SOURCE file contains a long enough sequence of 
zero bytes. Use --sparse=never to inhibit creation of sparse files. "

Es werden nur Sequenzen mit NULL-Bytes entfernt. Es findet keine Analyse 
des Dateisystems zur Ermittlung nicht benutzer Bereiche statt. In Deiner 
Imagedatei scheinen keine nennenswerten Bereiche mit Null-Bytes zu 
existieren.

Zur Lösung Deines Problems ist einiges in 
https://www.debian.org/doc/manuals/debian-reference/ch09.de.html zu 
finden. Es ist allerdings etwas Handarbeit erforderlich.

Kapitel "9.6.3. Einbinden der Festplatten-Abbild-Datei" um Zugriff auf 
das Dateisystem zu erlangen

Kapitel "9.7.9. Einen ungenutzten Bereich einer Festplatte löschen" um 
den nicht benutzten Speicherplatz mit NULL-Bytes zu überschreiben

Anschließend wird auch PiShrink.sh wieder etwas ausrichten können


Gruß
Mario

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.