Come fare un'immagine (.img) da ciò che è sulla scheda SD (ma compatto come quello originale)?

Provai:

sudo dd bs=4k if=/dev/mmcblk0 of=/media/1BAB47551C66A42B/raspbian_migs2.gz

Crea un file .img con 7,6 GB (dimensioni della scheda, MA ciò che è sulla scheda ha 700 MB).

E:

sudo dd bs=4k if=/dev/mmcblk0 | gzip > /media/1BAB47551C66A42B/raspbian_migs2.gz

crea un file .gz con 2,7 GB.

L'originale Raspbian ( Debian 7 (Wheezy)) da http://www.raspberrypi.org/downloads ha 494,44 MiB.

Da cosa c'è sulla scheda SD, come posso rendere un'immagine di dimensioni simili?

(Sono su Ubuntu.)

In un commento a RooTer menzioni che A) hai ridotto la dimensione iniziale della partizione gparted, ma ddcopia comunque l'intera scheda e B) che desideri includere entrambe le partizioni nell'immagine.

Il problema "A" è facile da spiegare: stai ancora copiando l'intera carta perché è ciò che si /dev/mmcblk0riferisce. Le singole partizioni sono ovviamente /dev/mmcblk0p1e /dev/mmcblk0p2. Questa è la complicazione nel problema "B", ma non è possibile semplicemente ddogni partizione e concatenare i due file insieme, a causa della tabella delle partizioni all'inizio della /dev/mmcblk0 quale indicizza l'inizio e la lunghezza di ciascuna partizione. Senza quello, l'immagine sarà inutilizzabile.

Tuttavia, è possibile ottenere la lunghezza di ciascuna partizione fdisk -le utilizzarla per determinare alcuni parametri per dd. Per esempio:

> fdisk -l /dev/mmcblk0

Disk /dev/mmcblk0: 16.1 GB, 16138633216 bytes
4 heads, 16 sectors/track, 492512 cylinders, total 31520768 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
Disk identifier: 0x00017b69

Device Boot      Start         End      Blocks   Id  System
/dev/mmcblk0p1    8192      122879       57344    c  W95 FAT32 (LBA)
/dev/mmcblk0p2  122880    26746879    13312000   83  Linux

Le unità "Start" e "End" sono settori e si noti che la dimensione del settore è data, 512 byte. Per /dev/mmcblk0p2, 26746879 (l'ultimo settore) - 122880 (il primo settore) = 26623999/2 (per 2 settori per kB) / 1024 (kB per MB) / 1024 (MB per GB) = 12.69, che ho fatto crescere la partizione usando gparted a 12 GB, quindi questo sembra corretto (in realtà dovrei usare 1000 e non 1024 come divisore con memoria, che funziona a 13.31 GB, ma sospetto che partizionato e alcuni altri strumenti usano anche 1024).

Quindi la prima cosa che vuoi controllare è che la tua seconda partizione abbia davvero le dimensioni più piccole su cui la imposti. Quindi, basta usare quei numeri con dd; per me sarebbe:

dd if=/dev/mmcblk0 of=rpi.img bs=512 count=26746880

Ho un settore in più lì per evitare qualsiasi tipo di off da un malinteso su come ddfunziona. C'è un modo semplice per verificare se ha funzionato:

> fdisk -l rpi.img

Disk rpi.img: 102 MB, 102400000 bytes
255 heads, 63 sectors/track, 12 cylinders, total 200000 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
Disk identifier: 0x00017b69

Device Boot      Start         End      Blocks   Id  System
rpi.img1          8192      122879       57344    c  W95 FAT32 (LBA)
rpi.img2        122880    26746879    13312000   83  Linux

Nota che qui c'è un po 'di discrepanza: i settori "Inizio" e "Fine" corrispondono alla tabella delle partizioni originale, ma la dimensione totale nella parte superiore delle statistiche è di soli 102 MB! Questo perché in realtà l'ho usato count=200000come parametro ddperché non volevo davvero preoccuparmi di una copia da 12 GB (notare anche "totale 200000 settori"). Il motivo per cui la tabella in fondo non riflette questo è perché fdisk sta ottenendo le sue informazioni dai dati della partizione copiati alla lettera all'inizio dell'immagine sulla scheda SD, che, come ho già detto nel secondo paragrafo, è vitale mantenere. Se avessi (correttamente) copiato il resto, i numeri sarebbero copacetici e l'immagine sarebbe stata praticabile.

Provalo. :)

Immagino che il problema risieda in settori una volta utilizzati che hanno ancora sporcizia. Una volta eliminato il file, vengono rimossi dal file system solo i metadati, non i dati stessi, lasciando alcuni zeri casuali anziché blocchi a zero zero facili da comprimere.

Soluzione semplice, ma richiede la riscrittura di tutto lo spazio libero sulla scheda. Ricorda che la durata della scheda SD è limitata dal numero di riscritture, quindi questo non è il metodo preferito.

dd bs=4M if=/dev/zero of=/root/junk
sync
rm junk

Soluzione più complessa, poiché è necessario installare zerofree su un altro computer che al momento non utilizzerà tale scheda SD.

zerofree /dev/mmcblk0p2

Per maggiori informazioni su http://intgat.tigress.co.uk/rmy/uml/index.html

Quello che devi ricordare è che facendo dd di / dev / mmcblk0 copi l'intero dispositivo, anche se le partizioni sono più piccole. Se hai usato raspi-config per espandere la partizione principale prima di eseguire uno dei metodi sopra, starai bene.

PS Se non ti dispiace cambiare il formato del file immagine, puoi usare il partimage che per i filesystem conosciuti omette i blocchi liberati anche se hanno ancora del terriccio. Anche in questo caso è meglio usare il partimage quando il filesystem non è montato per evitare il danneggiamento del backup. Probabilmente potresti cavartela rimontandola in sola lettura, ma la lascerò a tua discrezione.

Risposta breve: utilizzare una scheda SD da 2 GB.

Risposta lunga, ddnon ha idea di dove finiscano i "buoni" dati, devi dirlo in qualche modo.

Esistono due modi, il più semplice è utilizzare una scheda SD da 2 GB, che interromperà automaticamente la copia oltre i 2 GB e comporterà file compressi da 500 MB come desideri.

L'altro modo, più complicato, è calcolare la dimensione corretta dei dati dalla tabella delle partizioni e specificare questa dimensione corretta come parametri da ddcomandare. A tale scopo è possibile utilizzare i parametri bs=XXX(dimensione blocco) e count=XXX(conteggio blocco). Ad esempio, è possibile specificare bs=10Muna dimensione del blocco di 10 MB (che renderebbe sicuramente la copia molto più veloce rispetto alla dimensione del blocco di 4k utilizzata nei comandi) e count=200di copiare 10 MB * 200 = 2000 MB (2 GB). Potrebbe essere necessario regolare la dimensione e il conteggio dei blocchi in base allo schema di partizione della scheda SD .

dd - copy and convertnon è lo strumento giusto per fare il lavoro che hai richiesto. È uno strumento di basso livello, settore per settore, copia (e converti), ideale per copiare settori di avvio, formattare dispositivi e ogni tipo di attività di basso livello. Quando lo usi dd, copi settore per settore nell'immagine, anche se non è incluso nella struttura del file system.

Le immagini fornite dalla fondazione Raspberry Pi sono immagini appositamente compilate con script di installazione, file binari decompressi e installazione iniziale, dopo di che devi comunque ottenere aggiornamenti da Internet - Il che è del tutto deliberato ma piuttosto un compito per farlo funzionare in questo modo.

Una soluzione popolare per evitare di copiare settori vuoti è quella di utilizzare un sistema di copia a livello di file - e CloneZilla è autonomo, avviabile da un CD, simile ye olde Norton Ghostma clonezilla supporta i file system Linux (e altro). Quindi, copierà solo i file in uso e creerà un contenitore solo da quei file. Riduce le dimensioni in modo significativo!

• Ecco una guida che dimostra da un CD avviabile il backup del Pi dalla SD

Avevo la stessa domanda esatta e volevo uno strumento facile da usare. Dopo aver cercato e non trovato uno ho scritto mkimg.sh . Descrivo il processo che ho usato su: /raspberrypi//a/37899/32585