[MEGOLDVA] Disk image méretkülönbség

Debian GNU/Linux

Sziasztok!

 

Raspberry Pi speciális alkalmazáshoz egy raspios buster lite alap oprendszerre egy script állítja be/telepíti a szükséges módosításokat. Minden alkalommal, amikor a logikában változtatást eszközölünk, új image-et készítek. A szindróma, hogy az eddig előállított image 8GB-os SD kártyán 1.6GB foglaltsággal 1.3GB volt tömörítve (dd majd tar), most pedig ugyanilyen körülmények között ~6GB.

Tehát mégegyszer a folyamat:

- image felír 8GB SD kártyára

- raspberry boot, majd script megtesz minden változtatást (kártya foglaltság boot+rootfs 1.6GB)

- dd-vel imagefájl készítés az SD kártyáról, majd betömöríteni tar.gz-re

Van ötlet, miért van ez? Előre is köszi!

(Mintha az elmúlt évben már előfordult volna ez - de nem tudom mi oldotta meg. Most, ahogy leírtam, eszembe jutott, hogy teleírom a kártyát nullával és megnézem, mi lesz az eredmény a folyamat után...)

 

Üdv,

Balázs

  • 200 megtekintés

( Elbandi v | 2020. 12. 03., cs – 18:12 )

nemtudom milyen gyakran van ilyen valtozas, de a teleiras 0val nem biztos hogy jo hatassal van az sd kartyara.

miert nem egy rendes geppel modositod a letoltheto imaget, es a kesz eredmenyt irod sd-re? (bar igazabol egy rsync is eleg lenne, ha olyan)

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

A teleiras mehet az image keszites es tomorites kozott is. Szoval kb. igy:

dd if=/dev/akarmi of=target.img bs=4M status=progress
mount -o loop target.img /mnt/
dd if=/dev/zero of=/mnt/nullak
rm /mnt/nullak
umount /mnt/
7zr a -t7z -m0=lzma -mx=9 -mfb=64 -md=32m -ms=on rpi_image.7z target.img

szerk: illetve ha a teljes sd kartyarol van szo, akkor az image-en beluli particiot kell mountolni, megfelelo offsettel

pl legyen ez az sd kartyan levo particiok listaja:

Disk /dev/sdb: 3,6 GiB, 3883925504 bytes, 7585792 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xdb8d17be

Device     Boot   Start     End Sectors  Size Id Type
/dev/sdb1  *       2048   98303   96256   47M 83 Linux
/dev/sdb2         98304  585727  487424  238M 83 Linux
/dev/sdb3        585728 4198399 3612672  1,7G 83 Linux
/dev/sdb4       4198400 7585791 3387392  1,6G 83 Linux

A rola keszitett image-en levo particiokat meg igy mountoltam fel:

sudo mount -o loop,offset=1048576 ur_sd_card_sdb_full.img /mnt/
sudo mount -o loop,offset=50331648 ur_sd_card_sdb_full.img /mnt/
sudo mount -o loop,offset=299892736 ur_sd_card_sdb_full.img /mnt/

512 byte egy sector, szoval ha a particio 2048-nal indul, az offset ezek szorzata, 1048576 lesz.

A strange game. The only winning move is not to play. How about a nice game of chess?

( dotnetlinux | 2020. 12. 03., cs – 18:43 )

Nézz bele dd után az image-be hogy van-e benne szemét vagy tiszta üres a nem használt terület. Lehet az sd kartya alapból nem nullakkal van töltve.

Biztos a nemnullak okozzák a bajt, 1. 6gb adat nem lehet 6gb tömörítve. 

( kbhuinfo | 2020. 12. 03., cs – 19:22 )

Koszi az otleteket - nem gyakori. Azert kell hozza az rpi, mert telepitek-forditok es a celhardveren kell megtenni egyeb kornyezet hijan.

mar csak hajbi el a multban, azota a modern(tm) rendszereken teljesen jol lehet armos kornyezetet futtatni: itt van info: https://wiki.debian.org/QemuUserEmulation

itt meg egy masik tutorial: https://gist.github.com/bruce30262/e0f12eddea638efe7332

en orangepi imaget mountoltam es utana chroottal bele tudtam lepni abba a rendszerbe

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( dragi v | 2020. 12. 03., cs – 21:04 )

sd kártya sem töröl konkrétan csak megjelöli szerintem. Fotókat is ezért lehet visszaállítani, ha nem írtál rá csal "formáztad"