Fórumok
Adva van egy jól működő raspbian - eléggé kopasz de nekem így megfelel.
Mindez egy 4G micro SD HC 10(!) kártyán. A javallott módon, egy USB kártya olvasóval (Bus 001 Device 012: ID 14cd:8168 Super Top) bedugom és beolvasom a dd segítségével:
# dd if=/dev/sdb of=rpi-img.bin bs=1M
Utána egy pontosan ugyanilyen micro SD kártyára felírom amit így lementettem:
# dd if=rpi-img.bin of=/dev/sdb bs=1M - JAVÍTVA!
Bedugom és lereked a bootban, ott ahol felszabadítja a kernel memóriát.
Miért? Mit lehet elrontani egy ilyen egyszerű művelettel?
Hozzászólások
Pontosan ezt írtad?
Vagy csak most tévesztetted el...
Amúgy meg ránézhetnél szemmel is, hasonlít-e az eredetire.
Javítottam! - gondolom a fájl névre gondoltál (bin és a bs paraméternél az egyenlőségjelre). Nem jól adtam ki a parancsot, csak rosszul idéztem.
Arra gondolsz hogy mountoljam be és nézzem meg fájl rendszer szinten?
* Én egy indián vagyok. Minden indián hazudik.
Pontosan arra. Két partíció, egyik FAT, másik EXT. Ha nem az, akkor rossz.
(De ha az eredeti jó, akkor kezdd azzal, lesz mintád.)
Megőrülök most sikerült - 3. próbálkozás!
Mi a &@# ...
* Én egy indián vagyok. Minden indián hazudik.
2 sd-kártya sohasem lesz ugyanakkora fizikai méretre!
Én azt szoktam, hogy inkább kézzel megcsinálom a másik kártyára a 2 particiót (100mb + a maradék)
Utána mkfs.vfat és mkfs.ext4 és simán rámásolom a működő rendszerről!
Nekem így van egy fullos tartalék kártyám!
Oykawa
Ez lenne még a legszimpatikusabb - kipróbálom :)
(már nézegettem, de azt gondoltma egyszerűbb image -kel dolgozni)
* Én egy indián vagyok. Minden indián hazudik.
A második parancs után kellett volna a
syncparancs, hiszen nincs filerendszered, nem tudsz umount-olni, de van disk cache-ed, és ki tudja, mennyi maradt a RAM-ban, amikor lehúztad az sdb block eszközt a csatlakozóról. Érdemes végiggondolni, mit csinálsz, mi történik. File-ból file-ba másolsz, illetve block device-ra, ami file-ként látszik. Amikor a dd elkészült, minden blokkot átadott ugyan - a kernelnek, de senki nem mondta, hogy az a fizikai eszközre ki is íródott.Gondolom, harmadjára vártál annyit, hogy a kernel úgy gondolta, kiírja a cache-t. A másik lehetőséget említették. Ha a cél eszköz kisebb, mint az image, akkor eleve egy sérült filerendszered lesz, illetve a partíciós táblában érvénytelen bejegyzés, amelyik túlmutat az eszköz méretén.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
+1
Van egy RPI-s projektem munkahelyen, ami miatt sokat dolgozom SD-kártyákkal mostanában.
Két tanácsom lenne:
md5sum rpi-img.bin
md5sum /dev/sdb
Az utóbbi hetekben tucatnyi image-et készítettem és írtam ki azonos méretű és hasonló típusú kártyákra (Samsung 16GB Class6 és Class10 kártyák), és sosem volt probléma velük. A dd van annyira alacsony szintű, hogy ne hibázzon, persze mint minden I/O műveletnél, fontos, hogy hibátlanul tegye a dolgát a CPU és a memória, illetve a gépben lévő diszkvezérlő és persze a használt kártyaolvasó megbízhatósága sem lényegtelen (én egy Kingston eszközt használok, eddig nem volt vele semmi gondom).
Olyanba is belefutottam már, hogy az egyik kártyán a sok ki-be húzkodás miatt az írásvédettséget állító kis kapcsoló meglazult, és a kártya behelyezésekor átkapcsolt "köztes állapotba". Ez okozott kellemetlen meglepetéseket (I/O error-ok image készítés/kiírás közben). Lehet, hogy csak ennél az adott típusnál probléma ez, de érdemes odafigyelni rá.
+1 azzal az észrevétellel, hogy amennyiben az image kisebb, mint az eszköz, úgy annak ellenére eltérő lesz a hash, hogy jó a kiírás, továbbá a sync a másolást követően nélkülözhetetlen, mert lehet jó a részben disk cache-ből visszaolvasott image úgy is, hogy fizikailag még nincs az eszközön.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Jogos észrevétel, én mindig teljes lemezképekkel dolgozok, ezért evidensnek tekintettem. Ez esetben a dd count paramétere segíthet, pl. ha kereken 4 GB-os az image:
dd if=/dev/sdb bs=4096 count=1048576 | md5sum
Igen! A sync elmaradt. Tény hogy ilyen műveleteknél szoktam elvonulni vlmi mást csinálni, de sync nélkül nem tudhatom mikor űrül ki a cache.
A kártya író/olvasó tippet is köszönöm - nincs 3.0 USB a gépemen, így konkrétan ez a típus nem biztos hogy jó lesz nekem. Tény hogy a legmegbízhatóbb eredményeket a régi kis Minix netbookomon értem eddig el, nem az USB író/olvasómmal.
Megörültem az md5sum -nek de ha a fizika miatt ez nem megbízható, hát akkor ez épp csak arra nem jó amire szánnám :(
OFF: Kicsit úgy érzem magam mintha floppy -val dolgoznék, lehet hogy írok egy kis scriptet, hogy tényleg minden ilyen apróság megoldható legyen.
* Én egy indián vagyok. Minden indián hazudik.
Az md5sum (vagy akár sha256sum) jó akkor, ha
- az image-ről csinálsz md5sum-ot
- dd-vel az eszközre másolod az image-et
- sync-et mondasz neki - ez a lépés nagyon fontos!
- ha teljesen biztosra akarsz menni, lehúzod az USB interface-ről a kártyát
- visszadugod az USB interface-re a kártyát
- dd-vel pontosan image hossznyi adatot másolsz az md5sum-nak, így előállítva az érvényes szakasz ellenőrző összegét
- összeveted a két md5sum értéket
Érdemes még megnézned a cmp parancsot is, ez byte-ról byte-ra végez összehasonlítást.
tr '[:lower:]' '[:upper:]' <<<locsemegeLOCSEMEGE
Az usb3-as olvasó lehet jobb sebességet ér el még usb2 portba dugva is :) Persze, ha a kártya is bírja a sebességet. Ez azért lehet, mert az usb3 olvasót már felkészítették nagyobb sebességre, jobb chipset van benne. Igaz, főleg olvasásban van komoly különbség. Usb2 olvasóban 22MB/sec fölé nem ment, az usb3-as olvasómat usb2 portba dugva megvolt a 30MB/sec, míg ha a port is usb3 volt, akkor 42MB/sec körül vitte. Mondjuk ilyen sebességeknél már majdnem mindegy :)
Igen, a 4096 optimálisnak tűnik:
Működik a cmp is. Ráadásul nem is kell root -nak lenni, sima gyalog user is kezeli :)
Úgy tűnik a kulcs a sync volt.
* Én egy indián vagyok. Minden indián hazudik.
Egy diff-et rá lehetett volna küldeni a blokkeszközre és az image fájlodra. :)
------------------------------------------------------------------------------
www.woodmann.com/searchlores/welcome.htm