Stretch Lite + ImageBakery = 70MB frei

[patrickju]

Ich habe mit der ImageBakery und dem neuesten Raspberry Stretch Lite erfolgreich ein Image erstellt. Anschliessend habe ich das auf den RevPi aufgespielt, ich bin dabei der Anleitung von RaspberryPi gefolgt: https://www.raspberrypi.org/documentati ... lashing.md. Ich habe für den ganzen Prozess einen weiteren RaspberryPi verwendet.

Das hat alles gut funktioniert, der RevPi läuft. Wenn ich nun aber mit "df" schaue, wieviel Platz auf der Disk ich noch habe, sehe ich: 73756KB.

Da habe ich mir natürlich etwas mehr erhofft . Kann es sein, dass das irgendwie mit einem der neueren Commits auf der Image-Bakery zusammenhängt: "Shrink image after customization", siehe https://github.com/RevolutionPi/imageba ... ada8893787.

[patrickju]

Ohne besagte Zeilen in customize_image wird es etwas besser (550MB frei) aber wahrscheinlich mache ich dann grundsätzlich was falsch.

Ich flashe wie auf der Raspberry-Seite beschrieben mit "sudo dd if=raw_os_image_of_your_choice.img of=/dev/sdX bs=4MiB". Ist das so richtig?

[patrickju]

Ist dieses Forum der richtige Ort für diese Frage oder soll ich eine Issue direkt bei der imagebakery machen?

Ich habe nochmal alles durchgespielt und gelange zum selben Ergebnis. Ich starte das ganze mit "sudo /bin/bash customize_image.sh [MEIN_IMAGE]", ich verwende /bin/bash weil das Script sonst mit "trap: ERR: bad trap" abbricht. Das ganze findet auf einem Raspbian Stretch auf einem RaspberryPi statt.

Beim baken sehe ich gegen Ende eine Fehlermeldung: "Re-reading the partition table failed.: Invalid argument".

Code: Select all

...
>>> Created a new DOS disklabel with disk identifier 0x7ee80803.
/dev/loop0p1: Created a new partition 1 of type 'W95 FAT32 (LBA)' and of size 43.9 MiB.
Partition #1 contains a vfat signature.
/dev/loop0p2: Created a new partition 2 of type 'Linux' and of size 1.2 GiB.
Partition #2 contains a ext4 signature.
/dev/loop0p3: Done.

New situation:

Device       Boot Start     End Sectors  Size Id Type
/dev/loop0p1       8192   98045   89854 43.9M  c W95 FAT32 (LBA)
/dev/loop0p2      98304 2651183 2552880  1.2G 83 Linux

The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Invalid argument
The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).
Syncing disks.
...

Nach dem Flashen des RevPis hier das Resultat von "df"

Code: Select all

pi@RevPi:~ $ df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/root        1223744 1069664     73876  94% /
devtmpfs          469912       0    469912   0% /dev
tmpfs             474520       0    474520   0% /dev/shm
tmpfs             474520   12204    462316   3% /run
tmpfs               5120       4      5116   1% /run/lock
tmpfs             474520       0    474520   0% /sys/fs/cgroup
/dev/mmcblk0p1     44220   22139     22082  51% /boot
tmpfs              94904       0     94904   0% /run/user/1000

[lukas]

Hallo patrickju,

Sorry für die verzögerte Antwort, ich bin erst jetzt auf deine Anfrage aufmerksam gemacht worden. Du hast völlig recht, es liegt an dem von dir verlinkten Commit. Dir fehlt bloß noch das Vergrößern der root-Partition beim erstmaligen Einloggen. Das geschieht mit einem aktualisierten revpi-factory-reset Script, das Teil des kommenden Images bzw. des darin enthaltenen piserial deb-Packages ist. Wir werden dieses deb-Package zeitgleich mit der Image-Veröffentlichung in ein paar Tagen ins apt Repository stellen. Dann wird es auch beim Bauen mit imagebakery automatisch inkludiert. In der Zwischenzeit kannst du folgende Kommandos händisch in der bash ausführen, um die root-Partition zu vergrößern:

Code: Select all

# resize root partition
dev=mmcblk0
total_size="$(/bin/cat /sys/block/$dev/size)"
last_part="$(cd /dev ; /bin/ls ${dev}p* | /usr/bin/tail -1)"
last_part_start="$(/bin/cat /sys/block/$dev/$last_part/start)"
last_part_size="$(/bin/cat /sys/block/$dev/$last_part/size)"
last_part_max="$(($total_size - $last_part_start))"
if [ "$last_part_size" -lt "$last_part_max" ] ; then
        /sbin/sfdisk -q --dump "/dev/$dev" | /bin/sed -r -e "\$!n
\$s/size=[^,]+/size=$last_part_max/" | /sbin/sfdisk -q -f --no-reread --no-tell-kernel "/dev/$dev"
        /sbin/partprobe "/dev/$dev"
        /sbin/resize2fs "/dev/$last_part"
fi

Beim baken sehe ich gegen Ende eine Fehlermeldung: "Re-reading the partition table failed.: Invalid argument".

Ja, die Meldung ist normal, kann man ignorieren.

ich verwende /bin/bash weil das Script sonst mit "trap: ERR: bad trap" abbricht.

Okay, dann ersetze ich das gleich mal in den Scripten, damit immer die bash und nicht die dash benutzt wird.

Ohne besagte Zeilen in customize_image wird es etwas besser (550MB frei) aber wahrscheinlich mache ich dann grundsätzlich was falsch.

Nee du machst alles richtig, das Foundation Image ist halt zufällig so dimensioniert, dass am Ende diese 550 MB über bleiben. Die root-Partition füllt nicht das volle eMMC aus, so dass das merkwürdig klein aussieht.

Ist dieses Forum der richtige Ort für diese Frage oder soll ich eine Issue direkt bei der imagebakery machen?

Ist beides okay, bloß seh ich's auf GitHub sofort und hier müssen mich erst die Kollegen aus dem Forum-Support anstupsen.

Hoffe das hilft, gerne fragen wenn noch was nicht klappt.