SD kártyán futó Linux mentése

Linux-kezdő

Sziasztok !

Raspberry Pi 3B+ környezetben milyen mentési módszert, programot ajánlotok, ha USB-HD és LAN-PC mentési lehetőség is szóbajöhet.

Nem szeretném a micro SD kártyát kiszedegetni, cserélgetni, hanem alkalomszerűen menteném a kártya tartalmát úgy, hogy egy bootolható, használható rendszert kapjak a mentés végén.

Az elmúlt hetek- hónapok nyüglődései során kialakult rendszerkörnyezetet nem szeretném elveszíteni és újracsinálni mert kihullana a hajam.

  • 10940 megtekintés

( sigellef | 2019. 03. 12., k – 22:32 )

dd?

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Köszi, ez egy jó, de nem praktikus megoldás lenne.

"Célszerű, hogy a menteni kívánt partíció, vagy egész meghajtó ne legyen használatban, ne legyen mountolva, valamint a mentés nem készülhet arra a partícióra, amelyikről a mentés készül."
--
üdv: virtualm

A pín szerintem nem nagyon van mbr. Tök másképp bootol. Megkockáztatom hogy az rsync vagy az *fsdump pont elég, csak a nyitott/írt fájlokkal kell megküzdeni. A cink az, ha az fs/os/rencer nem a sd kártyán van, hanem image-ben, és mellé írja a deltákat. Istennek se ugrik be ennek a neve, pedig csináltam ilyet...

Egy párszor csináltam vele teljes merevlemezről tükröt, olyanról, amelyről az adott rendszer futott. Boot-oláskor a /tmp partíciót úgy is üríti, a többi ideiglenes cuccot meg újraépíti, kb. annyi hatással sincs a rendszerre, mintha kapna egy áramszünetet (persze adatvesztéstől nem kell tartani).

Ha partíciónként írod ki, akkor meg akár a /tmp és a /home el is hagyható.

Kiírni meg bárhová ki lehet, amit tud kezelni az adott rendszer. Mivel sd kártyán lakik, szerintem a legoptimálisabb kiírni fájlba, aztán azt a fájlt egy másik sd kártyára, tesztnek.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Találtam egy csinos, összefoglaló áttekintést, ( http://szabadszoftver.kormany.hu/letoltesek/keretrendszer/02-Backup_meg… ) de nem találok olyan megoldást ami futó rendszerről csinál mentést, ráadásul bootolható formában. Lehet, hogy Linux alatt nincs ilyen?
--
üdv: virtualm

Olvasgatom a man oldalát ( https://linux.die.net/man/8/xfsdump ) de nem látom át a használatának a módját, menetét.

Ugye van egy SD kártyán futó rendszerem, némi segéd programokkal és egy kevés python forrás kóddal. Ezt a rendszert hogyan mentem le az xfsdump programmal, hogy a másik SD kártya is ugyanazt a bootolható állapotot, kernel + x környezet setup + home alatti cuccok legyenek mentve. Baj esetén kártyát cserélek és minden megy tovább ugyanúgy mint előtte.

Jól értelmezem,(?) hogy a megfelelően felparaméterezett xfsdump programmal mentek egy külső eszközre, majd az xfsrestore megfelelő felparaméterezésével pedig megírok egy SD kártyát a mentett állományból. Tesztelés és használata pedig: gép leállítás után SD kártyacsere és ugyanolyan rendszer és környezet kell, hogy működjön a raspberry pin mint a mentés előtt. Ha ez ok, akkor a továbbiakban nincs is szükség a kártyacserékre csak az időközi xfsdump mentésekre és csak baj esetén kell új SD kártyát írni az xfsrestore- al. Ezt az új kártyát előzőleg XFS filesystemre formázni kell valamilyen módon? ( milyen módon ? )
--
üdv: virtualm

( uid_4672 | 2019. 03. 13., sze – 01:24 )

rsync?
én úgy szoktam, hogy mindig felmountolom a root particiót pl. a /mnt/xxx-be (is) és ezt backupolom, ilyenkor nem kell kínlódni az exclude-okkal. és álltottam is vissza rendszert ilyen backupból...

A /dev alatti cuccot azt a rendszer hozza létre bootoláskor. Csak az üres mappa mentődik. Ugyanígy van ez a /proc, /sys, és egyéb virtuális fájlrendszeren is. Ezek nincsenek rajta a fájlrendszeren, csak a futó rendszer látja így saját magát.

Ha bebootolsz, és kiírod az sdkártya tartalmát, amiről bootoltál akkor is csak az üres mappák íródnak, a virtuális fájrendszer tartalma nem.

Ami a /dev -ben van, azt az initscriptek, udev, stb... hozzák létre.
A /proc /sys pedig:

mount -t proc none /proc
mount -t sys none /sys

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

( AiRLAC v | 2019. 03. 13., sze – 05:34 )

"Nem szeretném a micro SD kártyát kiszedegetni, cserélgetni, hanem alkalomszerűen menteném a kártya tartalmát úgy, hogy egy bootolható, használható rendszert kapjak a mentés végén."

Én alkalomszerűen kiveszem a kártyát, lementem a tartalmát egy image-be és ennyi. Szerintem túlgondolod.

--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

+1, nálam néhány vlan-nak a dhcp-szerverét adja egy régi pi, van rá időablak, amikor megállhat, akkor megy a dd-s dump a kivett kártyáról, egyébként meg a fonrosabb könyvtárakról ha nagyon kell, akkor rsync valahova, bár a releváns konfigokat behúzva git-be az sem kell, csak legfeljebb egy lista az aktuálisan telepített csomagokról (dpkg --get-selections), aztán ennyi.

Mondjuk egy olyan is felmerült bennem, hogy fogod a dd-vel készült image-fájlt egy linuxos gépen, losetup, mount -o rw,loop, és utána az így felcsatolt területre tolod rsync-kel a mentést - bár ebben ugye ott van az a rsync-kel szinkronizálod ay rpi tartalmát. Ebben mondjuk az a kockázat, hogy ha az sd-kártyán sérültté válik/véletlenül törlésre kerül egy fájl, akkor azt is bután átszinkronizálod, amit pont nem kéne.
Viszont van olyan, hogy Borg Backup, ami pont erre (nagy fájlok kis változásainak a mentése) szolgál (deduplikáció) - azzal menteném az image-fájl változásait, minden olyan rsync futtatást követően, amikor történt változás.
https://borgbackup.readthedocs.io/en/stable/index.html

Azaz (a cikus feltételeit finomítani kell a megtartani kívánt full/inkrementális mentések számának megfelelően - friss full backup-hoz goto 1, ha pl. bootmanager csere/frissítés történt):
1. dd-s mentés a kártyáról
2. sdcard.img-ről borgbackup-pal mentés
3. a sdcard.img loopback-mount
4. rsync-kel mentés az rpi-ről a loopback mountolt területre.
5. goto 2.

nem...
a backup szerver backupolja le a device-okat: telefonok, laptopok, masik szerver, külső szerverek, etc. (van amit n óránként, van amit naponta, előtte pingel), a btrfs vagy zfs itt van.

megsnapshotolja a legutolsó snapshot-ot ("verziót"), majd erre rsyncel... ha nem változott semmi, akkor nem fogy a disk space (kivéve a btrfs metadata). persze kezeli a hourly, daily, monthly, yearly snapshotokat...

a btrfs-sync szkript az csak összesynceli a source-on lévő btrfs snapshotokat. elvileg gyorsabb a dolog, de ugye mindkét helyen btrfs kell legyen...

( AiRLAC v | 2019. 03. 13., sze – 08:47 )

Ja igen, 3+, akkor tud PXE bootot kártya nélkül. Case solved :)
--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

( virtualm v | 2019. 03. 13., sze – 20:20 )

Köszönöm a javaslatokat, végig veszem őket. Egyenlőre a dd működött, de macerás a kártya kivesz berak pláne ha majd egy összeszerelt, dobozolt készülékről lesz szó. Ezt a dd módszert kell majd kombinálni valamivel, kiegészíteni valami jól scriptelhető módon. ( amúgy meg a python forrás munkák azok mennek a repoba. )
--
üdv: virtualm

A nyelvészet mellett azért na, nem ártana azt is figyelembe venni hogy a pi nem használja az mbr-t, csak rá kell másolni a fájlokat az sd kártyára és jónapot. A mentés is kb. annyi hogy le kell másolni. Azaz nem a dd a kérdés, hanem hogy mi lesz a nyitott/írás alatti fájlokkal.

A móka akkor van, ha squashfs van a masinán, de ha jól láttam az nincs.

Kombinálni nem nagyon lehet. dd az kell a bootolhatóság miatt, és a kártyát is ki kell venni, mert nem futhat róla rendszer dd-zés közben.

A sima rsync is jó mentést csinál, de az nem lesz bootképes.

Ha csak úgy nem érted a vegyítést, hogy először csinálsz egy alap dd-s mentést legelőször (kártyát kivéve), majd rendszeres időközönként rsync-eset (ehhez nem kell kivenni a kártyát), és ha vissza akarod húzni a rendszert, akkor először a dd-s lemezképet húzod vissza (kártya kivesz), majd az rsynceset.

No keyboard detected... Press F1 to run the SETUP

Szerintem SD kártyára mindenképp megéri az f2fs. Kíméli az élettartamát. SSD-nél mindegy, ott bármilyen fájlrendszer használható, nem kell kímélgetni a közhiedelemmel ellentétben. De pendrive-ot, SD kártyát, ilyesmit érdemes f2fs-sel, noatime-mal, stb-vel használni, azoknál minden csepp írásspórolás számíthat. Persze attól is függ, hogy mire van használva, ha valami embedded feladat, aminél csak bebootol a rendszer az SD kártyáról, de nem nagyon írogat rá, annál mindegy. De ha intenzíven van benne használva a kártya, akkor érdemes bevállalni a macerát.

No keyboard detected... Press F1 to run the SETUP

Igen, ezért írom, hogy SSD-n nem kell, mert ott van aktív vezérlő, ami ilyen FTL-ről külön gondoskodik, meg ügyel a cellák egyenletes fárasztására, csinál garbage collectiont. De pendrive-oknál, SD kártyáknál nincs ilyen, azok emiatt sokkal kisebb írásterhelhetőséggel bírnak.

No keyboard detected... Press F1 to run the SETUP

FTL az lehet, hogy van, de rendes aktív vezérlő, ami gondoskodni tudna a Flash cellák egyenletes fárasztásáról, olyan biztosan nincs SD kártyákon, pendrive-okon sem. Tapasztalatból mondom, hogy ezek tényleg sokkal kevesebb írást bírnak, főleg akkor finganak ki nagyon gyorsan, ha OS fut róluk, ami rendszeresen írogat sok fájlt. Valami hihetetlenül gyorsan ki tudnak fingani. Adattárolásra lettek ezek kitalálva, nem rendszer futtatására.

No keyboard detected... Press F1 to run the SETUP

Szamodra mit jelent az "aktiv" vezerlo? Milyen egy "passziv" vezerlo?

Tudomasom szerint van wear leveling, csak kisebb a tartalek terulet es gyengebb minoseguek a cellak, igy van hogy csak 250-1000 irasi ciklust tudnak. Tovabba gyakoribb a nem vart tapelvetel (+ESD), ami szinten gyakran okozza a pendrive halalat.

Azt értem aktív vezérlőn, ami önálló hatáskörben molyol a cellákon, adatokat helyez át közöttük, szemetet takarít, hogy egyenletesen fáradjanak a cellák. Tudtommal nem csak a NAND más, hanem a pendirve-SD kártyán csak valami passzív, bedrótozott logikájú IC randomizálja valamennyire az írásokat, de ilyen belső adatmenedzselő hatáskörrel nem bír. Így pl. egy pendrive-on nem csak azért 10000× kevesebb az írásterhelhetőség, mert a Flash-memória kevesebbet bír (azért is, de ebben még csak olyan 100-500×-os lenne a különbség), hanem ezek a egyenletes adatelosztási trükközés. Pl. ha egy 32 gigás pendrive-ra vagy SD kártyára felteszel 16 GB állandóan tárolt adatot, és emellett irkálsz rá újabb 10-16 GB-ot, akkor csak a Flash-memória fele fog fáradni, azok a cellák, amikben az állandó adat van, nem fognak kopni, míg a meghajtó többi részén meg többszörös terhelésnek lesz kitéve, így meg sokkal gyorsabban adja be a kulcsot.

Nem véletlen eszik egy SSD 6-7 W-ot, meg melegszik fel 50-70 fokra, míg az ilyen SD kártyák mW-ban mérhetőek. Attól még hogy Flash-memóriába dolgoznak, számottevő működésben is a különbség.

No keyboard detected... Press F1 to run the SETUP

Na csak megnéztem:
https://ts.data61.csiro.au/publications/nicta_slides/8311.pdf

Nincs bedrótozott logika, 8051/ARM MCU-k vannak bennük és van wear leveling. Ráadásul újabb kártyák akár 1-2.88 W teljesítményűek.
Az említett NILFS2 is érdekes. És most beugrott, hogy még régi eMMC-k is használtak wear levelinget, ami néhány chip verzióban bugosra sikeredett és SDS lett az eredménye:
https://undocumented.software/wiki_dump/EMMC_Bugs.html

( khiraly | 2019. 03. 14., cs – 08:04 )

Nem jobb megoldas, hogyha mentesz egy kiindulasi rendszert (akar raspbian adott verziojat), es utana vagy erre kitalalt programmal (pl ansible), vagy egy shell scripttel
felepited a rendszert?

A backup pedig celiranyosan azok a fajlok, amik keletkeznek. Pl. egy sqlite fajl.

Azt, hogy mit miert installaltal, mar egy honap mulva elfelejted. Amikor uj verziot kell kiadni, 2 het csak azzal fog eltelni, hogy a kornyezetet ujraepitsd, mert "egyszer mar mukodott".

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( azbest | 2019. 03. 14., cs – 09:04 )

a futás közbeni dd-vel problémák lehetnek, mert mentés közben is változhatnak fájlok, ami inkonzisztenciát okoz.

Van okosabb megoldás, amikor egy image fájlt hozunk létre és abba szinkronizáljuk a fájlokat. Másik előnye, hogy bár dd-vel kiírható képet csinál, de csak akkora lesz a mentés, mint az adat, nem pedig akkora, mint az sd kártya mérete

https://prohardver.hu/tema/raspberry_pi/hsz_29897-29897.html

Ez lesz a nyerő, több oknál fogva is, ugyanis a 32GB kártya csak 29GB- ot enged használni.

Érdekes, hogy Ők az eredeti cikkben azt írják, hogy a script a pín fut, ott csinálja meg a csökkentett méretű image fájlt, amit elmenthetsz, majd új és kisebb kártyára ki is irhatod. A bootoláskor a mentéskori állapotokkal indul. Ez jól hangzik, kipróbálom.
--
üdv: virtualm

( virtualm v | 2019. 03. 14., cs – 20:25 )

A dd- vel sikerült a mentésem. A 32GB- os kártya 3/4- e üres. A tartalék 32GB- os kártyára nem tudtam visszaírni a képfájlt mert kevés a hely üzit kaptam. Teljesen leürítettem, formáztam, igaz előtte el kellett távolítanom a több kisebb partíciót és végül 29GB- nak formázódott a cucc és így keveselte a dd.

Ti mivel formáztok és hogyan nyerhetem vissza a 32GB- os méretet?
Hogyan kellene úgy menteni, hogy csak az aktív foglalt méretre legyen szükség?
Hiába van egy csomó szabad hely az új kártyán, mégis kevesli a kártya méretet.
--
üdv: virtualm

Tulajdonképpen valami hasonló megoldást szeretnél szerintem, mint, amit azbest is írt fent.
Nem feltétlen a konkrét scripttel (nem tudom, pl. az fdisk működése mennyire változik a későbbiekben), de ez működőképes dolog.
Visszaállítás után pedig az új kártyán "kiterjeszthető" a partíció a kártya pontos méretére.

Ehhez gyakorlatilag létre kell hozni egy fájlt a szükséges méretben.
Ez felcsatolható loop eszközként (gyakorlatilag mintha ez lenne az SD-kártya), azon belül létrehozható a két partíció, a megfelelő fájlrendszer, ezt követően pedig mehetnek rá az adatok.
Lényegében a fenti megoldás is ezt csinálja.

Köszönöm, most tényleg ez kell mert a kártyám kisebbnek mutatja magát mint valójában. ( 32GB helyett )

fdisk /dev/sdc

Unpartitioned space /dev/sdc: 29,7 GiB, 31913917952 bytes, 62331871 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes

Start End Sectors Size
2048 62333918 62331871 29,7G

Nem találom a módját, hogy miként tudom a teljes kártya méretet használni.

--
üdv: virtualm

Gyakorlatilag létrehozol rajta két partíciót a boot + rendszer adatainak és átmásolod rájuk a fájlokat.

...vagy a fent írt módon előkészített image-et kiírod és a fájlrendszer típusa által támogatott módon megcsinálod, hogy a lemez végéig érjen (a pontos metódus eltérhet).

Esetleg gparted-ben grafikus felületen is össze lehet kattintgatni, egyúttal a partíció pontos mérete is beállítható.

Most utólag próbálkoztam az alapos megtekintéssel, de nem volt sikeres. Ime a látható SD kártya képek:
https://i.imgur.com/J4hPiUW.png
https://i.imgur.com/hfxiOM6.png
https://i.imgur.com/foTnbfY.png
https://i.imgur.com/smI1uoc.png
https://i.imgur.com/2SCOxUi.png
Ezen a hivatalos Rpi SD kártyán és a csomagoláson nem találtam az említett G- Gi adatokat.
--
üdv: virtualm

Ez az egész emlékeim szerint valahol ott kezdődött, amikor elkezdték az 5-600MB-os merevlemezeket tíz hatványaival marketingelni.
Így lett a ~640 MB-os merevlemezem 610 MB körüli.

Ekkortájt volt persze az is, hogy okosoknak szemet szúrt az, hogy az SI-prefixek szerint a kilo 1000 (10^3), mega 10^6, stb, míg informatikában a bináris számrendszerből következően a kilo 1024 (2^10), a mega pedig 2^20, stb... prefixeket használták.
Gondolták, hogy "egységesítik" a dolgot, így nincs belőle félreértés... a kilo legyen mindig 1000, ellenben informatikában használják a "kibi"-t, ami 1024, stb... így lett belőle kibibájt, ami persze megosztotta az embereket.

Szumma szummárum, azóta kétféle jelölés létezik... a hagyományos, és az új, ez pedig félreértéseket és kavarodásokat tud okozni.

Így marketing anyagokban GB-ot használnak tíz hatványaival, szakmai környezetben pedig odabiggyesztik a kis i-t a bináris leképezéshez (ld. GiB), ha korrektek akarnak lenni; minden más esetben gigabájtokról beszélnek és sok esetben kettő hatványait értik alatta...

Visszatérve a memóriakártyákra, ott a marketing szöveg 32GB-ot mond, ami alatt kb. 32000000000 byte-ot ért.
A program viszont kb. 29.8 GiB-ot lát ugyanebből, mert ő a konkrét, bináris adatokkal dolgozik, kettes számrendszerben reprezentálva a fentit

Persze ő sem lát pontosan 29.8 Gib-ot, mert ő a konkrét adatokkal dolgozik, ami ennél kevesebb (ezért volt fent a kb.) - pl. lehetnek hibás cellák a flash-ben, amit a vezérlő elfed, ill. egyéb terület is, ami nem közvetlen a hasznos adatterülethez tartozik...

Ez a hosszú magyarázat a fentire. :)

Köszönöm a hasznos információkat.

Még azt kéne tudni, hogyan lehet a particionálásba, formattálásba bevonni az első 4MB nem használt területet, mert úgy tűnik, hogy ennek a hiánya miatt nem sikerült a dd- vel mentett 32GB- os kártyát, 32GB- osra átírni a hely hiány miatt. A hely takarékos mentés és visszaállítás ugyan megoldódott a remek kis scripttel, de nem akarok hülyén meghalni. Nem gondolnám, hogy pont az első 4MB hibás, illetve lehet, mert nem tudom megvizsgálni, hogy valóban az e vagy én bénázok valamit a particionálással, hogy az ott marad parlagon.

Linux alatt van olyan alacsonyszintű formattáló program ami megmutatja a rossz területeket?
--
üdv: virtualm

Veszel két, azonos tipusú, azonos sorozatban készült kártyát, ez az egyik lehetőség, a másik, hogy addig keresgélsz, amig ugyanakkora vagy nagyobb nyers méretű 32GB-os kártyát találsz.
Sajnos a dd-s mentés csak legalább ugyanakkora médiára pakolható vissza (oké, fájlrendszertől függ, mert van, aminek lecsatolva csökkenthető a mérete, de ez erősen átgondolós játék egy dd-vel kreált image esetén, hiszen első körben a losetup-ot kell ügyesen használni :-))

Ha a dd-vel a teljes eszközt olvasod / írod (sda / sdb, stb), akkor mindent másol - a partíciós táblát, a partíciókat, az adatokat, még az "üres helyet" is.

Lemásolni valószínűleg azért nem tudtad, mert a két SD-kártya eltér - éppen úgy, hogy a korábbi kártyád nagyobb kapacitású, mint, amire át szeretted volna másolni. Az eltérés valószínűleg nem nagy (néhány tíz MB talán vagy akár még annyi sem), de éppen elég ahhoz, hogy "túllógjon" a kártyán.
Kapacitásbeli eltérések egyébként nem csak uSD kártyák között lehetnek, egyes gyártók HDD-i között is volt.

Ha mindenképpen dd-vel szeretnél teljes lemezt klónozni, megteheted, hogy úgy készíted el a 32GB-os kártyádat, hogy a partíciót 100-200MB-tal rövidebbre veszed, és az image-et csak eddig a pontig olvasod be. Így beleférsz más kártyának a méretkorlátjába is, vagy az eredeti, teljes image-et kiírva az új eszközre a hibajelzés ellenére működni fog (amennyiben előbb befejeződik a partíció mint az új kártya fizikai vége).

...hogy miért pont 4MB-ot hagy ki a lemez elején, azt nem tudom pontosan, de oka van.
Annak idején az MBR a merevlemez első 512 byte-ját foglalta el (első szektorát), itt helyezkedik el a partíciós tábla és a rendszerbetöltő.
Később az egyes rendszerbetöltők az MBR és az első partíció közötti területre tették magukat, így pl. a GRUB egy része is itt van, ha "MBR-be telepítik".
Feltételezem, emiatt hoz létre a particionáló program egy 4MB-os fenntartott területet az első partíció elé.

Egyébként van olyan eset is, amikor nem kerül partíciós tábla az eszközre (pendrive, uSD), hanem rögtön a fájlrendszer kerül rá.
Mostanában már nem jellemző, de régebben láttam több, ilyen módon létrehozott pendrive-ot is.

Nem valószínű, hogy találsz olyan programot, ami a uSD kártya esetleges hibás részeit megmutatja.
Ha van is ilyen, az gyártói program, vagy legalábbis gyártóspecifikus.
Egyes SSD-khez vagy pendrive-okhoz létezik olyan program, amivel újra lehet inicializálni, így egy esetlegesen nem működő eszköz visszahozható az életbe - de ezek nem hivatalosan kiadott programok és csak egyes vezérlőkkel működnek, vagyis nem nagy az esély rá, hogy, ha ilyennel találkozik is az ember, a programot is felleli a megoldáshoz...

Szívesen. :)

Annyi kiegészítés még a fentihez, hogy az MBR-ben lévő kód ugrik elvileg a boot sector-ra, de, mivel az újabb boot manager-eknek ennél (1. sector) nagyobb hely kell, ezért ez ugrik pl. a Grub kódjára, ami lehet az első partíció előtt még (vagy a partíció elején), és ez végzi a tényleges rendszerbetöltést.
Ez viszont megadja a lehetőséget arra, hogy akár teljesen eltérő operációs rendszereket töltsön be.

Ha jól emlékszem, a Windows NT-től a Windows betöltője sem 512 byte-os volt, hanem talán 2048 vagy 4096, de egy ideje a valós szektorméret is ennyi...

...aztán van még a GPT. :-)

Plusz kis adalék:
a kártyáknál és pendriveknél lehetnek különbségek a GB és GiB mértékegységek körüli kavarás nélkül is.

Egyszerűen arról van szó, hogy sok más területhez hasonlóan, itt is vannak hibás területek (ahogy te is írtad). Ezt a gyárban az adott példány minőségének megfelelően állítják be valamelyik méretre a termékpaletta változatai szerint. Lehet, hogy 32GB-os flash chip van a 8GB-os kártyában is, csak nagyon sok volt a hibás terület rajta, ezért a 8-as volt a legelső méret lefelé haladva, amit teljesíteni tudott.

Namost, ha a 8 az valójában csak 7.9, míg a 16 valójában 15.8, akkor több példány fogja teljesíteni a nagyobb méretű besorolást. Jobb lesz a kihozatal és magasabb áron tudják eladni, mintha tényleg a névleges értékre lövik be. A márkásabb gyártók drágább kártyáinál, pendriveinél általában komolyabban veszik a méretezést, szigorúbb feltételeket írnak elő vagy akár a termékinfónál fel is tüntetik azt. Az olcsóbb és noname-ebb eszközöknél pedig jellemzően kicsit alá lőnek, ezért pár száz megával is kisebbek lehetnek. Ezért nem jön ki sehogy a matek némelyik kártyánál :)

De ugyanannak a gyártónak a különböző modeljei közt is lehet különbség aszerint, hogy hogyan pozicionálják az árazást és kihozatalt. Viszont azonos sorozatból való példányoknál jellemezően pontosan azonos a kapacitás is.

A kétféle mértékegység rendszer közti kavarással meg jól jártak a gyártók, mert a binárisan gyártható és SI szerint megadott méret különbségébe beleférhet a firmware helye, tartalék szektorok és némi ráhagyás a kihozatal biztosításához :)

( virtualm v | 2019. 03. 15., p – 18:39 )

azbeszt és VaZso barátunk találta meg nekem azt a scripttet amivel az élő futó rendszert image fájlba írtam, majd másik linuxos gépre is lementettem, majd ott a kisebb méretű kártyára dd- vel kiírtam, ami ugyan nem lett bootolható, de már lett egy jó mentésem. Ezután az SD copier nevű linuxos alkalmazással az előzőleg mentett fájlt copiztam az új kisebb méretűre, teljes sikerrel. Ez bootolható és mindenem megmaradt ami volt az előző rendszeren.

Az eredeti és az új SD mentett SD kártyák particioi igy néznek ki:
origin : https://i.imgur.com/8TyWSfd.png
mentett : https://i.imgur.com/tJnHYX4.png

Az új kártyán hiába csináltam meg a f2fs fájlredszert, az SD copier felülírta és az eredetit leutánozta, pedig jó lenne átállni majd erre.

Ez a mentő script : https://pastebin.com/URtidbmc jó és gyorsan lefut. Kicsit kéne rajta thuningolni, például, hogy távolra mentsen és dátumidő legyen a fájlnévben és akkor nem írja felül a régi mentést. Na de nem lehet minden tökéletes, ez így is jól használható.

Van még néhány dolog amit ki fogok próbálni, de most "hirtelen" ennyi elég. Köszönöm mindenkinek az aktív segítségét.
--
üdv: virtualm

( virtualm v | 2019. 03. 18., h – 22:36 )

A post első felében, baloghge barátunk megemlítette, hogy f2fs- t használ. Utána olvasva ez egy nagyon jó dolog és szeretném a mentésem scriptjében alkalmazni a lényegét. A jól működő mentésem eredeti mentő scriptje : https://pastebin.com/URtidbmc 162. sorától van rá lehetőség mert ott úgy látom, hogy a mentés helyének a fájl rendszerét hozza létre.

A kérdésem az, hogy itt szabad e, helyes e az mkfs.vfat -F 32 -I $LOOPDEVICE'p1'
és mkfs.ext4 $LOOPDEVICE'p2' helyett f2fs alkalmazása ?
Tehát az mkfs helyes felparaméterezése a lényegi kérdés, vagy más módon kell létrehozni az új helyen a 2fs fájl systemet?

A boot sector maradhat vfat ? mkfs.vfat -F 32 -I $LOOPDEVICE'p1'
A gyakran irogatott home terület pedig mkfs.f2fs $LOOPDEVICE'p2' re módosulhat és akkor megússzhatjuk a macerás fájl rendszer cserét, mert az itt ugye most megtörtént. http://whitehorseplanet.org/gate/topics/documentation/public/howto_ext4… amit

A visszaállítás, kártyára írás ugye a dd- vel történik. Az akkor ott az f2fs fájl rendszert fogja visszaállítani?
Egy életem- egy halálom ezt holnap kipróbálom.

--
üdv: virtualm

A boot partíció csak FAT lehet, más fájlrendszerről nem fog elindulni.
Ezzel alapvetően nincs gond, normál körülmények között nem módosul, nem írogatja a rendszer.

Az, hogy f2fs-ként hozod létre a fájlrendszert, egy dolog, de ezt az op.rendszernek is meg kell mondani.
Most nincs előttem PI, de a boot partíción van talán egy config.txt (cmdline.txt?), itt biztosan át kell állítani a fájlrendszer típusát.
A /etc/fstab-ban is biztos, hogy át kell írnod a típust.
...és reménykedni, hogy a kernel ismeri ezt a fájlrendszert. :)

Ha a kernel nem ismeri, akkor ezt is bele kell fordítani, esetleg keresni egy alternatív kernelt, amiben benne van...