Sziasztok.
Eddig a dd paranccsal "clónoztam" a 16GB- os SD kártyáimat.
Két partició van a raspbiant futtató kártyáimon. Mind a két partición van némi szabad hely, tehát nem lenne gond, ha a kártya "hibás" része kiesne a játékból. Igy 1 record miatt, ilyen módon használhatatlan az SDcard.
Van valamilyen másfajta módszer 2 db partición lévő cuccok másolására ?
--
sudo dd bs=4M if=/dev/mmcblk0 of=/dev/sdc
dd: hiba '/dev/sdc' írása közben: Nincs több hely a lemezen
3728+0 records in
3727+0 records out
15634268160 bytes (16 GB, 15 GiB) copied, 1495,62 s, 10,5 MB/s
Ezt a dd parancsot ubuntu alatt futtatom : Linux wt-ThinkPad-T420 6.2.0-34-generic #34-Ubuntu SMP PREEMPT_DYNAMIC Mon Sep 4 13:06:55 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Ha lenne más módszer a teljes mentésre annak örülnék, mert elég macerás kivenni a házi riasztóból az sd kártyát és dd- vel játszani. A raspberry pi nanora fizikailag nehézkes rácsatlakozni, tehát valami ssh-n futtatható parancsban reménykedem.
MEGOLDÁS :
- futó rendszer alatti mentés, clónozás az rpi-clone programmal. ( GitHub )
- clónozott kártyák p2 particiójának formázása f2fs- re ( gparted )
- az új, f2fs particiók feltöltése ( cp forrás- cél )
- ext4 kártya ki- f2fs kártya be és örül
Igy a mentés is és az ext4 / f2fs csere is megoldódott. Köszönöm a sok segitséget, igen tanulságos volt a sok érintőleges infó is.
Hozzászólások
ddrescue
köszi, megnézem.
üdv: virtualm
Próbáld meg ezt: USBImager. Ez tud olyant, hogy on-the-fly tömöríti a lemezképet, így sokkal kissebb helyet foglal, nem lesz "nincs több hely" hibaüzenet. Egyébként meg tömörítés nélkül is spare fájlokat gyárt (azaz az olyan blokkok, amik csupa nullák, nem lesznek tárolva, csak metaadatban feljegyezve, így nem foglalnak tényleges tárhelyet).
Megj: a honlapról a csak író felület elérhető, a fullos verzió (kiírás, lementés, tömörítés, blokkméret állítás stb.) innen tölthető le mindenféle oprendszerhez.
Neked nem a partíciókon fogy el a szabad helyed, hanem a /dev/sdc-n. Ez azért probléma, mert ha GPT-vel van partícionálva az SDCard, akkor használhatatlanná válik (GPT-t nem lehet csak úgy átmásolni, mint az MS-DOS partícionált lemezképeket, mivel a diszk végén, az utolsó szektorokban is tárol adatokat).
Ezt sürgősen felejtsd el. Ha használatban lévő, felcsatolt fájlrendszert akarsz alacsony szinten másolni, akkor garantáltan hibás lemezképet kapsz. Vagy csatold le (de akkor nem fogsz tudni ssh-t indítani ugye, kivéve ha ramdisk-es), vagy pedig használj rsync-et, ami nem alacsony szintű, hanem fájl absztrakciós szintű klónozás (tehát a fáfjlrendszerinkonzisztencia nem lehet vele probléma).
Köszi, megnézem.
üdv: virtualm
Itt nekem az látszik, hogy ahova írnál, az kisebb...
Igen 1 recorddal kisebb. A másolandó blok mérettel !M- ről lementem 256b- ra, igy lemásolta, de a PI nem fut vele.
üdv: virtualm
esetleg partition shrink - a másolás előtt?
(v átmásolod a particiókat a gépedre - nem egyből a másik SD-re - ott e2fsck-check, shrink, és így irod ki az új SD-re)
köszi, megnézem.
üdv: virtualm
Pár észrevétel:
- felesleges lemenni 256b-ra, mert 512b a minimális egység mérete
- PI nem használ GPT-t, és az sem érdekli, ha rövidebb a tényleges partíció, mint a partíciós táblabeli bejegyzés, így más gond lesz ott
- PI esetében minden gyári lemezkép olyan, hogy első induláskor egy scriptet futtat, ami megfelelőre méretezi a partíciót. Érdemes a lementett lemezképbe visszarakni ezt
Az utolsóhoz: fogsz egy gyári RaspiOS lemezképet, loop-al felcsatolod az első partícióját, majd kimásolod belőle a commandline.txt-t. Ezt elég egyszer mentenni. Ezután mindig felcsatolod a frissen mentett lemezkép első partícióját, és felülírod a benne lévő commandline.txt-t a gyáriból lementettel. Így indulás után az első dolga az lesz, hogy átméretezi neked a partíciót a megfelelőre. (A teljesség kedvéért, a commandline.txt-ben olyasmi szerepel, hogy init=init_resize.sh, ez utóbbi shell scriptet itt találod. Ez initrd-ből fut, rootfs nélkül, átméretezi a partíciót, majd kiszedi magát a commandline.txt-ből és újraindul).
Alternatívaként az is működik, hogy lefuttatod a sudo raspi-config nonint do_expand_rootfs parancsot, majd kikapcsolod a PI-t, és csak ezután mented le a lemezképet. Ez jövőbiztos, úgy is működni fog, ha átvariálják az implementációt (ha jól rémlik, szó volt róla, hogy sima initrd hook-á alakítják init script helyett, de nem tudom, ez megtörtént-e, nem néztem egy ideje.)
Köszönöm szépen.
Ez jól hangzik, remélem, hogy megtudom csinálni, ugyanis nem vagyok linux guru.
Ha a loop mountra kapnék egy működő példát azt megköszönném.
üdv: virtualm
Először is fdisk-el megnézed, hol kezdődik a partíció. Ez 512 bájtos egységekben van megadva a "Start" oszlopban. Pl. (a könnyebb érthetőség kedvéért kitöröltem a sallangot, csak a lényeget hagytam meg):
Itt ez 8192. Tehát az első partíció mountolása:
Ezután a "bootpart" nevű könyvtárban láthatod a partíció tartalmát. Természetesen bármilyen más könyvtárnevet is használhatsz, és a lemezképet is hívhatják máshogy, ez csak példa.
Egyébként úgy látszik, átnevezték az init_resize.sh scriptet firstboot-ra, a legfrissebb verzióban a cmdline.txt így néz ki:
Igazából lényegtelen is, hogy mi a script neve, neked csak ezt a cmdline.txt-t kell felülírni, hogy legyen "init=" paramétered benne, ami meghívja.
Az USBImager- el sikerült az eddig error-ra futott SD kártyákra kiirni a gyári raspbian ost.
Sikerült kinyernem a gyári os- ből a cmdline.txt és valóban init_resize.sh lett az átméretező új neve.
Akkor most van 3 db használható 16GB- os SD kártyám előkészitve és van egy SD kártyám amin a házi riasztóm raspbian rendszere, psql adatbázisa, webszervere, stb fut. Ezt a kártyát szeretném "clonozni" és nem újra kiizadni az összes setupot.
Hogyan tovább ? Hogyan csináljak bootolható, működőképes mentést ?
( Ha kell, ha muszáj akkor kiveszem az SD kártyát a riasztóból. )
üdv: virtualm
"Ha kell, ha muszáj akkor kiveszem az SD kártyát a riasztóból." - Anno nekem is volt rpi-s cuccom, én ott azt csináltam, hogy a "base image" készítéséhez kivettem az eszközből a kártyát, és pécén dd-vel cisnáltam róla egy másolatot fájlba. Erről az image-ről csináltam másolatot a tartalék kártyá(k)ra (egyszerre vásárolt, azonos gyártó/tipus/névleges méretű kártyák - ezzel biztosítva azt, hogy tényleg egyforma méretű legyen az összes kártya), ha szükség volt rá.
Amikor az eszközben frissült/változott bármi, akkor a "base" image másolatát a pécén felcsatoltam (-o loop, és egyebek, más már leírta), és oda került be rsync-kel a változás az eszközről.
Ja, ha a "riasztó"-n van webszerver meg mindenféle csingilingi, akkor az ugye kellően szeparáltan (wifi nincs, vezetékes hálózata szeparált, csak meghatározott "lukba" dugott eszköz éri el. stb.) van hálózatilag _is_ telepítve? Mert ha a belső hálózatod felől elérhető, akkor támadható is...
Igen, hasonló cipőben járok. Eddig a dd igy ment : dd bs=512M if=/dev/mmcblk0 of=/dev/sdc ez egy clonozás ami most nem ment a célméret difi miatt.
Az érdekelne, hogy miként lehet a 2 particiós kártyáról másolatot csinálni fájlba.
üdv: virtualm
"Az érdekelne, hogy miként lehet a 2 particiós kártyáról másolatot csinálni fájlba." - egyszerűen of=/ide/bele/fajl.image
super, köszi
üdv: virtualm
Igen, ez egy nagyon jó meglátás, érdemes odafigyelni erre! Javaslom, tűzfalból korlátozd le a webszerver adminfelület elérhetőségét egy bizonyos belső IP címre (ahonnan menedzselni akarod), és állíts be kétirányú TLS-t (ahol nemcsak a szervert azonosítod, hanem a klienst is asszimetrikus kulccsal engedi csak hozzáférni, lásd apache, nginx vagy lighttpd esetén). Ilyenkor csakis azzal a böngészővel érhető el az oldal, amibe a client cert-et előzőleg betöltötted.
ok, köszi a javaslatokat ( egyébként nginx fut )
üdv: virtualm
Mentés menete (ezt csak egyszer kell megtenni):
1. a raspbian-on kiadod az raspi-config parancsot, majd sudo poweroff
2. kiveszed a kártyát, és átrakod az asztali gépbe
3. USBImager-el lemented egy helyi fájlba, ezt a lemezkép fájlt jól megőrzöd
4. az SD kártyát visszarakod a Pi-be, és nem piszkálod többet, amíg nincs vele baj
Újrahúzás menete (ahányszor csak szükség van rá):
1. fogsz egy friss, ropogós SD kártyát, és berakod az asztali gépedbe
2. ugyancsak USBImager-el kiírod rá a lementett lemezképet
3. az újonnan írt SD kártyát berakod a Pi-be és bebootolod
(Azért így, mert ekkor a tömörített lementett lemezképbe eleve a módosított cmdline.txt kerül. Ha nem adod ki a raspi-config parancsot, akkor az asztali gépen ki kell csomagolni a lemezképet, bemountolni, lecserélni a cmdline.txt-t, umountolni, majd újra betömöríteni. Ez is jó és járható út, de macerásabb, mint a kártyakivétel előtt egy raspi-config parancs futtatás.)
Ez is jól hangzik, de itt elbukok : "3. USBImager-el lemented egy helyi fájlba"
üdv: virtualm
Mi a gond? A gitlap repós linkről töltsd le, ne a honlapról, és akkor lesz "Read" gomb is a felületen.
https://gitlab.com/bztsrc/usbimager/raw/master/usbimager.png
ps: a honlap az egyszerűbb, csak fájlból lemezre irányt tartalmazó verziót kínálja letöltésre (wo=write-only). A repóbeli linkeken mindenféle megtalálható, olyant válassz, aminek a nevében nincs wo. (Ne is kérdezd, néhány felhasználó panaszkodott, hogy "túl bonyolult a felület", ezért kénytelen voltam egy lebutított verziót is csinálni.)
Használata:
1. bepipálod a "Compress"-t
2. kiválasztod a legördülőből a meghajtót, amiben az SD kártya van
3. rákattintasz a "Read" gombra
4. az asztalodra kerül a lementett lemezkép, ez nevezd át akármire, rakd, ahová jólesik stb.
Egyébként a mentést végezheted dd-vel is, ha akarod (bár az nem lesz tömörítve), ugyanis a formátumuk teljesen kompatíbilis.
Letöltöttem a fullos rw USBImagert, települt, szépen elindul.
(1) Bepipáltam a "Tömöritést"
(2) "kiválasztod a legördülőből a meghajtót, amiben az SD kártya van"
Nekem a belakott, setupolt sdkártya két particiója és a fájljai jönnek be. Mert ugye korábban, sikeresen ráirtubk egy gyári raspbiant. Tehát itt nem tudok sd kártyát beolvasni és semilyen lemezkép nem kerül az asztalomra.
dd- vel sikerült a lemezkép mentés, igy ezzel nem.
Természetesen előtte, a korábban leirtak szerint kicseréltem a cmdline.txt fájlt a gyárira.
Szóvan a kisebb méretű SDre nem sikerült a mentés. 15 perc munka után az USBImager is hibát dobott.
Ezek szerint nem sikerült kihagyni azt a shell scriptes varázslatot amit honositani kéne.
A célmeghajtóm:
sdc
├─sdc1 vfat FAT32 bootfs 9E81-4F92 204,6M 20% /media/wt/bootfs1
└─sdc2 ext4 1.0 rootfs cf2895ca-6dc2-4797-8040-f76ba1508f41
A forrás meghajtóm:
mmcblk0
├─mmcblk0p1 vfat FAT32 bootfs 9E81-4F92 204,6M 20% /media/wt/bootfs
└─mmcblk0p2 ext4 1.0 rootfs cf2895ca-6dc2-4797-8040-f76ba1508f41 10G 26% /media/wt/rootfs
Megint mit rontottam el ?
üdv: virtualm
Ezt nem tudom értelmezni. A legördülőben meghajtók jelennek csak meg, nem pedig partíciók, fájlok meg semmiképp sem. A legördülő lista elemei úgy néznek ki, hogy
"(eszköz) [(méret)] (gyártó) (típus)", pl. "sdc [32Gb] Kingston Datatraveler 3.0"
Semmiféle partícióról és fájlokról nincs itt szó.
Még az sem számít, hogy formázva van-e az adott eszköz, mert a meghajtólistát a kerneltől kéri le (kivéve Windows "-a" kapcsoló nélkül, mert akkor "drive letter"-eket tartalmaz eszköz gyanánt a legördülő, de ott is tök mindegy, hogy melyiket választod, mert lekéri a drive letterhez tartozó fizikai eszközt és azt használja. Fájlok ott sem jelennek meg sehol a legördülőben.)
Valamit nagyon elrontottál. Az USBImager ellenőrzi a diszk méretét, és bele sem kezd, ha nincs elég hely. (Ez alól egyetlen kivétel van, ha olyan eljárással lett a lemezkép tömörítve, aminél nincs tárolva a kitömörített méret. Mivel dd-vel mentettél, ezért esetedben ez nem állhat fenn.)
Hát igen, csak az a megoldás képes kezelni eltérő méretű partíciókat, alacsony szintű mentés (USBImager/dd) nem.
A Clonezilla megfelelő paraméterezéssel tudja ezt kezelni.
Köszönöm, utánna olvasok.
üdv: virtualm
Csak AMD cpu architectura jön fel, ez nem ok az inteles Linux Z500 6.2.0-34-generic #34~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Sep 7 13:12:03 UTC 2 x86_64 x86_64 x86_64 GNU/Linux laptopra.
üdv: virtualm
Mondd, hogy csak viccelsz! :)
Az a 64 bites architektúra, amit ma használunk a PC-ken, az AMD találmánya, ezért hívódik hivatalosan amd64-nek, függetlenül attól, hogy a CPU-t az AMD vagy az Intel gyártotta.
Köszi, nem vicceltem. A jó pap is holtig tanul.
üdv: virtualm
Az Intel nagyon sokáig nagyot szakított az x86-os vonallal (8088/8086, 268, 386 stb.), egy csomó cég fizetett éveken át az Intelnek azért, hogy 16 és 32 bites, x86-os architektúrájú CPU-t gyárthasson, többek között az AMD is (gondolom, sokan még ma is fizetnek érte). Egy idő után sok cég elkezdett 64 bites architektúrán dolgozni, többek között az Intel is, az AMD is. Az Intel kicsit mellélőtt a dolgoknak az elképzeléseivel, szakítani akart a x86-os vonallal, azt az IA64 csak emulálni tudta volna (elég gyenge sebességgel), az AMD viszont megtartotta az x86-os támogatást, és ő nyert. Ezek után az Intel is áttért az AMD architektúrájára, de nyilván keményen fizetnie kellett a licencekért az AMD-nek. Tkp. egymásnak fizettek egy darabig, majd valahogy kiegyeztek, megegyeztek kvázi döntetlenben, és most már az AMD nem fizet az Intelnek az x86-ért, az Intel pedig nem fizet az AMD-nek az amd64-ért (vagy más nevén x86-64-ért).
És hogy teljes legyen a kép, az IA64 az Intel-HP közös szerelemgyermeke lett, amit az Intel Itanium processzoraiban öltött testet. https://en.wikipedia.org/wiki/IA-64
rsync -av /innen /oda
Tegnap nem csináltam semmit, ma folytatom, mert nem lettem kész vele! :)
Én így szoktam:
Tudom, sokszor említettem már, akit zavar, az ne olvassa. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Van valami okod arra, hogy szektorosan, s ne file-osan másolj?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Igen, a tudatlanságom a fő ok. Megfogadom a tanácsaitokat és kipróbálom az rsync -avxHASX parancsot.
Ez megy ssh- keresztül is, úgy hogy az ubuntu alól inditom és ott lesz a cél is ?
üdv: virtualm
Fentebb írtad, hogy bootolható mentést szeretnél. Az rsync erre nem alkalmas, csak az összes többire. Szóval fogsz egy gyári RaspiOS lemezképet, kiírod SD-re, bebootolod, és telepítgetés meg konfolgatás HELYETT rsync-el visszaraksz mindent, erre való.
(Ha nagyon haladó leszel, akkor könnyen megcsinálhatod majd azt is, hogy az asztali gépen fogsz egy SD kártyát, létrehozod fdisk-el a partíciós táblát rá, mkfs.vfat-el legyártod a fájlrendszert az első partícióra, mkfs.ext2-vel a második partícióra, felcsatolod ezeket, rámásolodod amit korábban rsync-el lementettél, lecsatolod, és bebootolod az RPi-n. Ezt igazából egyszer kell csak kitökölni, utánna már egyetlen shell script össze tudja rakni neked a bootolható lemezt az rsync mentett tartalomból. De ez mindenképp haladó szint már.)
Egy sima dd-s lemezkép elég hozzá, amit a korábban leírtak szerint loop device-ként felcsatol, és az élő rendszerről a változásokat már rsync-kel rá tudja tolni. És ezt követően az adott imagefájl mehet ki dd-vel egy másik sd-kártyára. Ha ráfér ugye, mert jelenleg is az a probléma, hogy nem fér el, mert kisebb az a kártya,a mire másolna, mint amiről a másolás történik...
Igen, de nincs szükség loop mountolt lemezképre, mehet egyből a kártyára. Így megspórol egy kört, gyorsabb, és a mérettel sincs gond.
Pont ezért javasoltam a shell scriptes fdisk+mkfs.vfat+mkfs.ext kombót, mert úgy akkora partíciót csinálhat, amekkorát csak tud. Mindaddig, amíg az rsync mentett fájlok ráférnek, tök mindegy, bármekkora lehet (jó eséllyel a fájlok sokkal kevesebb helyet foglalnak, a lemezképben lévő partíción nagy valószínűséggel elég sok szabad hely is tárolva van).
De ez azért már haladó szint szerintem. Mindenesetre nagyvonalakban:
Megjegyzés: nem teszteltem a fenti scriptet, csak útmutatónak szántam, hogy milyen lépésekról van szó! Skeletonnak jó, de különösen az fdisk parancsokat ellenőrizni kell, fejből írtam.
A lényeg, hogy az első partíció fix, mondjuk 512M-es legyen és W95 (0xC) típusú, a második meg akkora, amekkora tényleges hely van még az SD kártyán.
köszi az útmutatót. Megpróbálom honositani és alkalmazni.
üdv: virtualm
A "kicsi" kártya:
dc
├─sdc1 vfat FAT32 bootfs 9E81-4F92 204,6M 20% /media/wt/bootfs1
└─sdc2 ext4 1.0 rootfs cf2895ca-6dc2-4797-8040-f76ba1508f41
Az eredeti jó kártya:
mmcblk0
├─mmcblk0p1 vfat FAT32 bootfs 9E81-4F92 204,6M 20% /media/wt/bootfs
└─mmcblk0p2 ext4 1.0 rootfs cf2895ca-6dc2-4797-8040-f76ba1508f41 10G 26% /media/wt/rootfs
A pontositás kedvéért:
#!/bin/sh7
# honnan hova
RSYNCDIR=/home/wt/backup/
DEV=/dev/sdc
------------------
#!/bin/sh
# honnan :
RSYNCDIR=/home/wt/backup/
# hova :
DEV=/dev/sdc
Igy ugye mehet, kipróbálhato ?
üdv: virtualm
Megpróbáltam értelmezni és alkalmazni, de nem sikerült. A pastebinre feltettem a futtatható sh forrást és a kimenetet is.
mentes_format.sh https://pastebin.com/Whw5afRF
mentes_format_kimenet : https://pastebin.com/Ev4kSDu1
üdv: virtualm
Már az olvasástól is zsibbad a szemem, nagyon távol vagyok attól az egyetlen shell scripttől.
Köszönöm a lelkesitő segitséget.
üdv: virtualm
Jogos, én file-os másolás után értelemszerűen telepítem a boot managert, illetve a filerendszerek UUID-jét megtartom a célhelyen, vagy ha nem, akkor a megfelelő helyeken módosítom, pl. az fstab-ban.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Pi esetén nem kell telepíteni a bootloadert, mindössze fel kell másolni pár firmware fájlt a boot partícióra (ez megtörténik, amikor a /mnt/boot-ba másol).
Abban viszont tökéletesen igazad van, hogy az ext fájlrendszer UUID-ját be kell állítani fix-re, hogy egyezzen a cmdline.txt és fstab belivel (vagy másolás után sed-el át kell írni azokat arra, amilyen UUID-t kapott). Erről tényleg megfeledkeztem, ezt még hozzá kell rakni a scripthez, hogy működőképes legyen a létrehozott SD kártya. Kösz!
Alternatívaként át is lehet írni fix device nevekre, pl. /dev/mmcblk0p1 ill. /dev/mmcblk0p2 (általában ez nagyon nem tanácsos, de a Pi egy különleges eset, itt sosem fog változni a device név, szóval itt belefér).
Én hasonló célra a https://github.com/Drewsif/PiShrink -et használom.
Ez is érdekes lehet, köszi, megnézem.
üdv: virtualm
sudo dd bs=4M if=/dev/mmcblk0 status=progress conv=sync,noerror | gzip -c > /mnt/bakfile
gunzip -c /mnt/bakfile | sudo dd status=progress bs=4m conv=sync,noerror of=/dev/mmcblk0
Köszönöm a javaslatod.
Kipróbáltam ezekkel a paraméterekkel ( is ) de itt is jött a hamis hiba : "Nincs több hely a lemezen"
ami azért sánta, mert 20%- ban foglalt SD cardról beszélünk.
sudo dd bs=4M if=/dev/mmcblk0 status=progress conv=sync,noerror | gzip -c > /mnt/bakfile
15980298240 bájt (16 GB, 15 GiB) másolva, 978 s, 16,3 MB/s
3810+0 beolvasott rekord
3810+0 kiírt rekord
15980298240 bájt (16 GB, 15 GiB) másolva, 978,068 s, 16,3 MB/s
--
gunzip -c /mnt/bakfile | sudo dd status=progress bs=4M conv=sync,noerror of=/dev/mmcblk0
15925772288 bájt (16 GB, 15 GiB) másolva, 1021 s, 15,6 MB/s
dd: hiba '/dev/mmcblk0' írása közben: Nincs több hely a lemezen
0+3799 beolvasott rekord
3798+0 kiírt rekord
15931539456 bájt (16 GB, 15 GiB) másolva, 1021,55 s, 15,6 MB/s
üdv: virtualm
A dd nem a fájlrendszer tartalmát, hanem a forrás blokks eszköz valamennyi adatblokkját másolja, és te most belefutottál egy olyan SD-kártyába, ami valamiért kisebb. Ilyen van, létezik, _ugyanolyan_ gyártó/tipus/méret/sorozat között nem lesz ilyen problémád. De ha veszel egy 32GB-os kártyát, és arra próbálod megcsinálni a dd-s másolást, az fog menni.
Igen-igen. Most van 3 db vadi új, névlegesen 16GB-os SD kártyám. Új raspbián szépen települ rá,működik, csak az én riasztómban lévő "16GB"-os renszeremet nem tudom lementeniezekre, pedig csak 20%-os a foglaltsága,tehát van rajta rengeteg szabad hely. A blokkok száma 1-el kisebb mintaz eredetié, ezért próbáltam fájlmásolásokkalmenteni és visszaállitani, de valamit elcseszek mert nem működik.
üdv: virtualm
Elvileg az SD kártyán gparted-del le tudod csökkenteni a partíciók méretét, ha tényleg csak 20% foglalt bennük. De ezelőtt mindenképpen csinálni kellene egy másolatot a műteni kívánt SD kártyáról.
Mennyi hely van a cél fájlrendszeren?
$ df /mnt
Hogy a gunzip nem sikerült, az rendben van, hiszen ott legel még a helyén az, amit kimásoltál.
$ df /mnt
Fájlrendszer 1K-blokk Fogl. Szabad Fo.% Csatol. pont
/dev/sda2 921300812 500635712 373790480 58% /
Szerintem nem erre voltál kiváncsi, hanem az SDcard foglaltságára. Ez az originál jól működő SDcard:
mmcblk0 179:0 0 14,9G 0 disk
├─mmcblk0p1 179:1 0 256M 0 part /media/wt/bootfs
└─mmcblk0p2 179:2 0 14,6G 0 part /media/wt/rootfs
üdv: virtualm
Ez szerintem rendben van, most van egy okénak tűnő másolatod az SD kártyáról /mnt/bakfile néven, a gparteddel elvileg megműtheted az SD kártyán levő partíció(ka)t kisebbre. A gparted elvileg figyel arra, hogy ezt biztonságosan el lehet-e végezni.
Ha sikerül, akkor a dd-vel ki fogod tudni másolni a gyógyított SD kártya blokkjait az új 16GB-s kártyáidra.
Ha a gparted nem engedi, akkor megérkeztél, vegyél nagyobb SD kártyákat, amikre tudsz majd másolni.
A mentésből pedig jó esetben vissza tudod állítani gunzippel az eredeti állapotot, ha végleg szétkúrtál mindent, de ehhez kelleni fog egy nagyobb SD kártya.
A Gparted nem engedi a partició méretét kisebbre venni, pedig ő is látja, hogy 11,81GB szabad hely van rajta.
üdv: virtualm
Valószínűleg azért, mert fel van csatolva a fájlrendszerbe a partíció.
Szerintem azt a gparted kiírja hibaként, nem?
Ezt a kérdést nem értem. A Gparted nem irt semilyen hibát.
üdv: virtualm
Kívánt partíció kiválasztása --> jobb klikk --> menüsorban aktív a "Leválasztás" felirat?
A mount parancs kiadása is jó, ha ott látszik a listában az adott partíció, akkor az bizony fel van csatolva a fájlrendszerhez :)
Igen, akkor szerintem mindent megpróbáltál, úgy ahogy írják a többiek, próbálkozhatnál esetleg még 16GB-os SD kártyákkal, de egyszerűbb ha átállsz 32GB-ra. Banggood, Ebay, ott ha a drágábból válogatsz az is csak a fele annyiba kerül, mint itthon boltban és van esélyed, hogy a 32GB-os megfelel majd.
Néhány gondolat. Hiába van sok helyed, ha a partíciód, amelyben a filerendszer van, akár csak egyetlen szektorral is nagyobb, mint a cél eszközön rendelkezésre álló hely. Vagy a cél helyen picit hátrébb teszed, s máris kész a baj.
File-os másolás lehetséges, de nem futhat arról a filerendszerről az oprendszer, amit másolsz. Másolásnál a jogosultságokat, tulajdonosokat is másolni kell. Sokszor írtam, nekem az rsync -avxHASX forrás cél paraméterezés bevált. Amivel vigyázni kell, az a virtuális fs-ek, tmpfs-ek: /dev, /proc, /run, /sys, /tmp. Ezeket létre kell hozni, de nem szabad másolni.
Ha partíciót akrsz csökkenteni, az nem jó megoldás, hogy kisebbre veszed a partíció méretét, mondván, van szabad hely az fs-en, mert nincs olyan szabály, hogy az érvényes adat az fs elején lenne. Tehát első lépésként fs shrink kisebbre, utána partíció vége előrébb, azaz kisebbre, majd fs-t bele kell tágítani az új partícióba. Vegyük észre, hogy a partíció és az fs két külön réteg!
Ahogy fentebb említették is, ha szektorosan másolod az fs-t, az ne legyen mount-olva, továbbá nagyon fontos, hogy másolás után add ki a sync parancsot, ellenkező esetben a másolvány egy része disk cache-ben maradhat, ami nem a boldogsághoz vezető út.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Sokszor költöztettem már rendszert más diskre, partíciónként a cp -ax ..... mindig megoldotta, amit szerettem volna. Nyilván a root partíciót single user módban kell másolni.
Nem vagyok olyan bátor, hogy arról az fs-ről fusson az oprendszer, amelyet másolok. Azért, mert ha valamilyen file-t módosít közben, akkor a célhelyen nem lesz az egész konzisztens. Inkább boot-olok pendrive-ról egy live-ot, és utána file-osan másolok. Persze, jó a cp is, meg bármi is, ami viszi a jogosultságokat, én az rsync-et szoktam meg.
De amúgy igen, komplett hardware-t cseréltem én is az oprendszerem alatt, meg disk topológiát úgy, hogy nem telepítettem újra. :)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Egy alaplapos BRIX-ből raktam át az SSD-t egy ThinkCenter-be a minap. Kiszed berak, megy, örül. Ennyi.
Ezt a kurva bonyolultságot rühellem a Linuxban.
:D
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Igen, cp, rsync, tar segítségével történő mentés is működik simán, ha jól van felparaméterezve, az csak a fájlokat, jogosultságokat, linkeket viszi át, a nem használt szektorokat nem. A dd átvisz mindent, nem használt szektorok, fájlrendszer UUID, stb..
Én általában live rendszer alól csinálom, bebootolva a legfrissebb Arch telepítő iso-t, amin csak egy CLI live rendszer van, semmi GUI. Eddig minden rendszerköltöztetés simán ment. Bár a legközelebbi komplikáltabb lehet, mivel az NVMe SSD sedutil OPAL-lal van hardveres titkosítva, és a sedutil alapból nem része semmilyen disztrónak, így nagyobb a szopásfaktor, bár elvileg, ha a gépet nem áramtalanítom, akkor nem kell külön minden bootkor feloldani a hardveres öntitkosítást.
A bootfájlok se téma, mióta UEFI bootot használok, EFI partícióval, azt is rettenet könnyű menteni, néha csak a systemd bootloader konfigjában átírni egy-egy PART-UUID-t. Secure boot meg egyéb baromság nincs bekapcsolva.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Köszönöm fiúk a sok hasznos javaslatot. Van néhány buktató amit egyenként lefogok küzdeni. A raspbian cli módban, zero alaplapon sok kötöttséget hordoz, de lassan túlleszek az sd kártya gyártók és kereskedők szopatásain. A névlegesen 16GB- os nak árult kártyák gyártónként és egyedenként is eltérő kapacitásúak. Némelyiknek pár blokkal, szektorral kevesebb a fizikai mérete. Én véletlenül egy "nagyobb" kártyára izzadtam fel a cuccaimat és azt eddig nem tudtam a szokásos módokon klónozni. Most az rpi-clone ( cli ) irányába mozgok.
üdv: virtualm
Itt van a két szkript:
Lementő
A visszaállító pedig:
Ezek tarball-t mentenek és abból állítanak vissza (partíciónként egy-egy), ez jobb, mert kevesebb helyet foglal, és a trükkösebb hozzáférés biteket is jól megtartják. Mindkét szkriptet sudo-val kell hívni, különben hibát fogsz kapni.
Ha esetleg szeretnél direktben egyből egy lemezképfájlból visszaállítani, akkor nehezebb a dolog, mivel ez esetben nem bízhatod a partíciókezelést a kernelre, neked kell megtenni. A következő szkript lekéri a partíciós táblát, majd loopback device-okat definiál a megadott partíciócímre, és úgy ment / állít vissza.
Illetve a párja:
Megjegyzés: elvileg meg lehetne spórolni az losetup hívásokat, a Linuxnak támogatnia kéne a "mount -o loop,offset=X"-et, de nálam ez bugos. A hiba nem ismeretlen, folyton visszatérő probléma, olyannyira, hogy a "man mount" külön foglalkozik vele, és a fent látható manuális losetup-ot javasolja inkább helyette.
Na, hát ez nem csak az "older" kerneleket érinti, nálam a 6.5.9-es kernellel is jelentkezik pont ugyanez a bug.
Köszönöm a preciz, részleteket is magyarázó segitséget. Sokat tanultam a példáidból és magyarázataidból.
@bzt , Le a kalappal előtted, minden tekintetben, úgy szakmailag mint emberileg.
üdv: virtualm
Nekem a futó raspberry PI ZERO-n a teljes mmcblk0- ról csinál teljesértékű másolatot a picit kisebb sda- ra.
Az alapértelmezett root partició ext4.
Ezt szeretném ezzel az rpi-clone bash scripttel lecserélni f2fs- re.
Én ezt nem tudom megtenni, de egy linux guru az biztosan képes rá.
Akár forkolhatná is a github.com/billw2/rpi-clone projektet.
Igy megoldódna, okafogyottá válna a https://hup.hu/node/183484 post is.
üdv: virtualm
Az rpi-clone script a az ugyanolyan fs-t rak a targetre, mint ami az src oldalon volt. És ez így jól is van, mert ha fs-t cserélsz alatta, akkor azt is ellenőriznie kellene, hogy az adott fs-ről tud-e bootolni a másolt rendszer, ha nem, akkor azt is meg kell "hegeszteni" közben, illetve az fstab-ot is úgy kell elkészíteni/módosítani.
Az rpi-clone forrása az mmcblk0. Az mmcblk0p1- ről bootol és az mmcblk0p2 a rootfs. Ezt a p2 fst szeretném lecserélni. A cél meghajtója, jelen esetben, ahova clónoz az az sda usb stick. Hivása pedig rpi-clone sda -f . Tökéletes másolatokat csinál, de a root p2 partició az ext4. Én f2fs-t szeretnék helyette. A boot p1 úgy jó ahogy van.
üdv: virtualm
A rootfs-t f2fs-re formáznám, átmásolnám jogokkal, mindennel a forrás ext4-ről a file-okat - nem futhat az az oprendszer, amelyet épp másolsz -, ahol kell - például /etc/fstab és a bootmanager környéke - átírnám az fs uuid-eket, aztán szerencsés esetben elindul. Ha nem, addig kell szögelni, amíg jó lesz.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Igen, ez a reszelés lesz. Ezt szeretném elkerülni az rpi-clone bash script módosításával.
üdv: virtualm
Ahhoz a scriptbe bele kéne rakni a "szögelést", a másik fs miatti módosítások végrehajtását, stb. Az a script egy aránylag szépen összerakott valami - át kell gondolni/nézni, hogy a cél partíció formázása hol és hogyan kap paraméterket, hogyan tudod azt korrekten befolyásolni mondjuk egy parancssori kapcsolóval, illetve bele kell rakni a / alatti fs cseréje miatt szükséges /etc környéki módosítások automatikus elvégzését is, miután a fájlok másolása megtörtént. Nem lehetetlen, de azért gondolkodós feladat.
Ráadásul csak elszúrni lehet. Vagy nem lesz elég általános, akkor meg minek, vagy az lesz, de akkora munka, hogy azt senkinek se kívánom. Egyszerűbb a konkrét helyzetre manuálisan megoldani.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Igen, ezt próbáltam finoman megfogalmazni... A scriptet csak lazán néztem át, de ilyen szinten bővíteni a funkcionalitását, legalább olyan minőségben, ahogy jelenleg meg van írva... nem egyszerű - és prímán el...rontható. Belemászni bele lehet ott, ahol a target / fájlrendszert hozza létre - de utána a bootolhatóságot még kézzel kell biztosítani - és ez az, amihez, nem bántásként mondom, de szerintem nincs meg a szükséges tudása a kérdezőnek. Még.
Amikor először csináltam ilyet, nekem is inkább csak elképzelésem és reményem volt erről, igaz, fejben már megvolt, hogy megoldható. Úgy is lett, ahogy kitaláltam, de nem működött elsőre. Elég kihagyni az uuid átírását valahol vagy az fstab-ban, vagy a bootmanagerben, lehet valami selinuxos katasztrófa, akkor pedig filesystem relabeling kell, meg akármi. Szóval nem ment elsőre, de elszánt voltam, mondván, kizárt dolog, hogy újratelepítsem, hiszen itt van ez, minden jó, az előbb még működött, tehát most is működnie kell. :) És persze rengeteg egyedi beállítás, ami miatt semmi kedvem sem volt a reinstallhoz.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
"csak elszúrni lehet" nem túl biztató, nem túl pozitiv gondolat. A korábbi javaslatod alapján azért megoldottam a dolgot.
Csináltam 3 db ext4 clónt.
Majd az sda2 megformáztam a gparteddel f2fs- re.
Majd a cp forrás cél paranccsal rámásoltam root particiót. ( az rsync mindenféle hibákat dobott )
Ezt a 3 lépést neveztem reszelésnek. Ezt akartam lustaságból megspórolni, hogy ne lehessen hibát véteni e közben. Egy csinos forkolás megoldhatná, mert a GitHub forrás adott és a root p2 partició manipulációja egyértelmű, lásd a : https://imgur.com/a/HA7jOkL
üdv: virtualm
"az rsync mindenféle hibákat dobott" - nem kellett volna, illetve jó lenne látni pontosan, hogy milyen paraméterekkel, milyen fs-ről milyenre próbáltál vele másolni, és mire adott hibát/warningot.
A script forkolása jó lehet, de _ha_ a jelenlegi minőségben szeretnéd belerakni a target fs kiválasztásának/megadásának a lehetőségét, akkor az azért nem "csak" annyi, hogy az mkfs -nél belenyúlsz.
" nem "csak" annyi, hogy az mkfs -nél belenyúlsz."
Éppen ezért kértem itt a tudós publikumot, hogy forkoljon.
Lehet, hogy magamnak egyszer belenyúlok, játszásiból, okulásból.
Most nekem okafogyottá vált a dolog, ugyanis van 1 futó f2fs kártyám, van 3 db f2fs mentésem, de nektek még jól jöhet, ha elfogy a reszelőzsir.
üdv: virtualm
Én ahol rpi-t használtam/használok, mindenütt van 1-2 tartalék sd-kártya, illetve image-be készült mentés a gépemen a legutolsó állapotnak megfelelő setuppal (a létfontosságú fájlokat verziókezelőbe tolom fel úgyis), úgyhogy engem nem érint a "hűha, mi lesz, ha túlírás miatt kidöglik alóla a kártya" para - illetve csak annyiban, hogy akkor lesz egy döglött kártya, és egy tartalékot kell berakni a helyére. Fél maréknyi sd-kártyából eddig egy döglött meg így.
A dd-s image-et meg loop device (losetup(8)) megoldással bármikor fel tudom húzni, és akár az élő, futó rendszerről scp-vel áthúzni rá azt, amit kell.
mivel a legcsírább ssd alig drágább mint egy sd kártya (kapacitás arányosan pedig még olcsóbb is) és mindenhol áttértem ssd-re, arról is bootol, problem solved.
van egy odroid c4-em, ott ezt nem tudom megtenni (nem bootol ssd-ről direktben) ezért a kártya tartalmát menteni kell
Gábriel Ákos
Ahogy zeller is írja, az rsync hibái érdekesek lehetnek, mert ha teszem azt, a file-ok átmentek, de a tulajdonos, jogosultságok, ACL-ek, SELinux beállítások sikertelenek, abból nem lesz működő oprendszer.
Ezek a lépések voltak a nyilvánvaló, egyszerű részei. A bootolhatóvá tétel nehezebb kicsit. Bár az is lehet, hogy elsőre minden jó. Apropó, boot-ol már f2fs-ről?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Azért én átgondolnám kétszer is az f2fs használatát...:
"F2FS has a weak fsck that can lead to data loss in case of a sudden power loss",
"If the kernel version has changed between boots, the fsck.f2fs utility will perform a full file system check which will take longer to finish",
"While GRUB supports F2FS since version 2.0.4, it cannot correctly read its boot files from an F2FS partition that was created with the
extra_attr
flag enabled"https://wiki.archlinux.org/title/F2FS
Köszönöm, ez érdekes és hasznos volt.
üdv: virtualm
Nem akartam senkinek kedvét szegni, de korábbi router-embe dugott pendrive-on f2fs-t használtam, s ért váratlan meglepetés. Ugyanakkor betudtam annak, hogy annak a router-nek kevés volt a RAM-ja, lehet, hogy ezért, és semmiképp sem akartam dezinformálni, mert ez nem biztos, hogy az fs hibája.
A mostani router-emben több RAM-van, de semmit sem bíztam a véletlenre, a beledugott 120 GB-os pendrive-ot ext4-re formáztam. Még sohasem fordult elő vele megmagyarázhatatlan történés, adatvesztés, effélék.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
A boot ( p1 ) partició maradt a FAT32, az élettartam növelés miatt lett a root ( p2 ) partició ext4- ről lecserélve f2fs- re.
A riasztót nagyon nagyon ritkán bootolom, állandóan szünetmentes tápról megy, akkor is ha hatástalanitva, ki van kapcsolva, vagyis nincs beélesitve a riasztó.
Nekem most már 2 db ilyen rendszerem üzemel ( Nyaraló és Lakás https://imgur.com/a/PCaZlQD ) gond nélkül. Igaz, hogy az f2fs csak pár napja, de itt, tapasztalatokkal megerősitettek, hogy 5 éve futnak a cuccai. A fejlesztő, tervező lassan elkészül a dokumentáció publikálásával és akkor könnyebben után épithető lesz.
A feleségemnek(62), gyerekemnek(38) tetszik, könnyen kezelhetőnek tartják mert hozzászoktak az okostelefon tapicskolásához.
Nekem(70) hobbista utánépitőnek sokkal átláthatóbb és jobban felügyelhetőbb mint az előzőek, cirka 50 év alatt volt jónéhány csalódásom.
Az nekem nagyon jó, hogy emailt és smst kapunk az eseményről. Amúgy meg jó kis játék volt, a közreműködésetekkel sokat tanultam belőle.
üdv: virtualm
A dparted- el formáztam a root particiót és sudo cp -Rafu /media/wt/rootfs/* /media/wt/ef418e8b-84b0-47a3-bda9-fd0e96f160eb paranccsal másoltam a tartalmat, majd az fstab- ot javitottam.
A kérdés az, hogy a root=PARTUUID=45d6a379-02 lehet akármi, csak egyezzen a cmdline.txt- vel ?
Honnan veszem a jó, helyes PARTUUID= ???
üdv: virtualm
A blkid parancs megmutatja minden partíció PARTUUID-jét. Nem lehet akármi, fontos, hogy egyezzen a bootbejegyzés a valódi PARTUUID-vel.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Köszönöm.
üdv: virtualm
Sikerült az rpi-clone scripttel f2fs mentést csinálni. Olvasgattam, olvasgattam és láss csodát, amit nem tudtam a dd-vel az itt igy megy :
➜ ~ sudo rpi-clone sda -f
[sudo] password for argus:
Booted disk: mmcblk0 16.0GB Destination disk: sda 15.6GB
---------------------------------------------------------------------------
Part Size FS Label Part Size FS Label
1 /boot 256.0M fat32 -- 1 256.0M fat32 --
2 /root 14.3G f2fs -- 2 14.3G f2fs --
---------------------------------------------------------------------------
== Initialize: IMAGE partition table - forced by option ==
1 /boot (50.0M used) : MKFS SYNC to sda1
2 /root (4.0G used) : RESIZE MKFS SYNC to sda2
---------------------------------------------------------------------------
Run setup script : no.
Verbose mode : no.
-----------------------:
** WARNING ** : All destination disk sda data will be overwritten!
-----------------------:
Initialize and clone to the destination disk sda? (yes/no): yes
Optional destination ext type file system label (16 chars max): f2fs
Initializing
Imaging past partition 1 start.
=> dd if=/dev/mmcblk0 of=/dev/sda bs=1M count=8 ...
Resizing destination disk last partition ...
Resize success.
Changing destination Disk ID ...
=> mkfs -t vfat -F 32 /dev/sda1 ...
=> mkfs -t f2fs /dev/sda2 ...
Syncing file systems (can take a long time)
Syncing mounted partitions:
Mounting /dev/sda2 on /mnt/clone
=> rsync // /mnt/clone with-root-excludes ...
Mounting /dev/sda1 on /mnt/clone/boot
=> rsync /boot/ /mnt/clone/boot ...
Editing /mnt/clone/boot/cmdline.txt PARTUUID to use 69a4a553
Editing /mnt/clone/etc/fstab PARTUUID to use 69a4a553
e2label: Bad magic number in super-block while trying to open /dev/sda2
===============================
Done with clone to /dev/sda
Start - 13:35:40 End - 13:38:56 Elapsed Time - 3:16
Cloned partitions are mounted on /mnt/clone for inspection or customizing.
Hit Enter when ready to unmount the /dev/sda partitions ...
unmounting /mnt/clone/boot
unmounting /mnt/clone
===============================
üdv: virtualm
Mert ugye az e2label az ext2, ext3, ext4-hez való. Ellenben van f2fslabel. Azt meg kell nézni, hogyan kell paraméterezni, de a scriptbe bele kellene írni, hogy f2fs esetén az f2fslabel legyen az, amit használ.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Itt középtájt nem ilyesmiről van szó ?
-----------------------:
** WARNING ** : All destination disk sda data will be overwritten!
-----------------------:
Initialize and clone to the destination disk sda? (yes/no): yes
Optional destination ext type file system label (16 chars max): f2fs
üdv: virtualm
Azt értem, hogy azt a nevet akarod neki adni, hogy f2fs, csak ezt az e2label nevű programmal csinálod, ami ext* filerendszerekhez való. Mivel f2fs-ed van, neked másik programot kell használnod az átnevezéshez, jelesül az f2fslabel nevűt. Amúgy kb. bármilyen nevet adhatsz neki, csak a filerendszerhez való utility-vel. Ezt a scriptbe kellett volna valakinek beleírnia. Utólag manuálisan is adhatsz neki nevet, de szerintem valami fantáziadúsabbat. Pl. R-PI_image_f2fs, vagy valami ilyesmi.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Úgy látom, hogy megint igazad van. Ezért is kértem, hogy valaki aki ért a bash scripteléshez, programozáshoz forkolja meg. Mivel ez nem jtörtént meg ezért egy kicsit reszelnem kellett, Igy most 2 riasztómnak van 3- 3 db mentése. Nem csinos a megoldás, de működik. Az ubuntus laptop sokszor megtréfált az UUID- vel, a csatolási pontokkal ezért nem tudtam rendesen futtatni a @bzt mentő scripjeit. Igy nem megoldottam, hanem megkerültem a problémát. Ha erősebb leszek linuxból lehet, hogy nekifutok újra.
üdv: virtualm