RPI SD image - béna vagyok?

Debian GNU/Linux

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?

  • 6239 megtekintés

( kisbetu v | 2014. 06. 14., szo – 17:58 )

Pontosan ezt írtad?
Vagy csak most tévesztetted el...

Amúgy meg ránézhetnél szemmel is, hasonlít-e az eredetire.

( tovis v | 2014. 06. 14., szo – 19:03 )

Megőrülök most sikerült - 3. próbálkozás!
Mi a &@# ...

* Én egy indián vagyok. Minden indián hazudik.

( oykawa | 2014. 06. 14., szo – 19:31 )

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

( locsemege v | 2014. 06. 15., v – 00:07 )

A második parancs után kellett volna a sync parancs, 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:]' <<<locsemege
LOCSEMEGE

( gergelykiss | 2014. 06. 15., v – 09:36 )

Van egy RPI-s projektem munkahelyen, ami miatt sokat dolgozom SD-kártyákkal mostanában.

Két tanácsom lenne:

  • dd-nél "bs=4096"-ot használj, a tapasztalat alapján így lehet elérni a leggyorsabb írási/olvasási sebességeket SD-kártyáknál
  • plusz idő, de megéri, mert időben észreveszed, ha valami nem stimmel: futtass md5sum-ot az image-en és az SD-kártyán is! Ha nem azonos a hash, gyanakodhatsz, hogy valami félresiklott az image készítésénél vagy kiírásánál (pl. hibás az SD-kártya vagy a kártyaolvasó, amit használsz). Mindössze két lépés, és egy 4 GB-os Class10-es kártyánál (ha jól értem, ilyened van) csak néhány perc az egész:

    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:]' <<<locsemege
LOCSEMEGE

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:]' <<<locsemege
LOCSEMEGE

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: 


  Kingston 4GB Micro SD HC (10) card writing tests:

  dd if=/dev/zero of=/dev/sb bs=8192
  485889+0 records in
  485888+0 records out
  3980394496 bytes (4.0 GB) copied: 480.459 s, 8.3 MB/s

  dd if=/dev/zero of=/dev/sb bs=4096
  971777+0 records in
  971776+0 records out
  3980394496 bytes (4.0 GB) copied: 493.624 s, 8.1 MB/s

  dd if=/dev/zero of=/dev/sb bs=1024
  3887105+0
  3887104+0
  3980394496 bytes (4.0 GB) copied: 1053.1 s, 3.8 MB/s

  dd if=/dev/zero of=/dev/sb bs=512
  7774209+0 records in
  7774208+0 records out
  3980394496 bytes (4.0 GB) copied: 1047.23 s, 3.8 MB/s

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.