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
Hozzászólások
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?
Ok, ez lesz a kovetkezo, ha az eredeti otlet nem mukodik.
Koszi - az sd kartyat telezerozva futtatva az eredeti folyamatot .9GB-os tar.gz lett a vege. Koszi a segitseget, a problema a multe!
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.
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!
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"
Ha jól tudom, akkor ugyan ez van a vinyókál is. Ezért is visszállítható sok mimden onnan is törlés után.