copiar um cartão sd usando dd não copia exatamente

Question

Eu estou tentando fazer uma cópia do meu cartão SD para que eu possa movê-lo para o meu cartão SD de 64GB. Eu fiz isso com o SD-Card de um pi de framboesa, sem problemas.

O cartão SD consiste em duas partições: BOOT (fat32) e linux (ext4)

Eu tentei criar uma imagem de todo o cartão SD usando:

sudo dd of=Images/orangepi.img if=/dev/sdd bs=1M status=progress

E colocando de volta em um cartão SD:

sudo dd if=Images/orangepi.img of=/dev/sdd bs=1M status=progress

Eu não consegui montar a imagem, pois ela consistia em duas partições. Então eu criei BOOT e linux separadamente usando:

sudo dd of=linux.img if=/dev/sdd2 bs=1M status=progress 
sudo dd of=BOOT.img if=/dev/sdd1 bs=1M status=progress

Como você pode ver na imagem que eu adicionei, a imagem criada (à direita) do cartão SD não corresponde ao cartão SD (à esquerda).

Minha pergunta é: por que isso acontece e como faço uma imagem adequada do meu cartão SD?

A pasta pessoal do meu cartão SD tem uma pasta chamada "Música" contendo pastas com arquivos mp3.

Minha imagem tem um x-font.ttf com o nome "Music". As pastas parecem se transformar em arquivos aleatórios quando gravadas.

O cartão SD é um disco ubuntu funcional para o meu pc orangepi e está funcionando neste momento.

**sudo apt install dcfldd
lsblk**
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 465.8G  0 disk 
└─sda2   8:2    0 465.8G  0 part /media/Shared
sdb      8:16   0 238.5G  0 disk 
├─sdb1   8:17   0   500M  0 part 
├─sdb2   8:18   0 116.8G  0 part 
├─sdb3   8:19   0 117.3G  0 part /
├─sdb4   8:20   0     1K  0 part 
└─sdb5   8:21   0   3.9G  0 part [SWAP]
sdc      8:32   1   7.5G  0 disk 
├─sdc1   8:33   1    64M  0 part /media/fhfs/BOOT
└─sdc2   8:34   1   7.4G  0 part /media/fhfs/linux
sdg      8:96   0 465.8G  0 disk 
└─sdg1   8:97   0 465.8G  0 part /media/fhfs/0c91eeb6-7199-47b6-a603-04432a091fdc
sr0     11:0    1  1024M  0 rom  
**ls -lha /dev | grep sd**
brw-rw----   1 root disk        8,   0 Oct 18 14:54 sda
brw-rw----   1 root disk        8,   2 Oct 18 14:54 sda2
brw-rw----   1 root disk        8,  16 Oct 18 14:54 sdb
brw-rw----   1 root disk        8,  17 Oct 18 14:54 sdb1
brw-rw----   1 root disk        8,  18 Oct 18 14:54 sdb2
brw-rw----   1 root disk        8,  19 Oct 18 14:54 sdb3
brw-rw----   1 root disk        8,  20 Oct 18 14:54 sdb4
brw-rw----   1 root disk        8,  21 Oct 18 14:54 sdb5
brw-rw----   1 root disk        8,  32 Oct 20 18:11 sdc
brw-rw----   1 root disk        8,  33 Oct 20 18:11 sdc1
brw-rw----   1 root disk        8,  34 Oct 20 18:11 sdc2
brw-rw----   1 root disk        8,  48 Oct 18 14:54 sdd
brw-rw----   1 root disk        8,  64 Oct 18 14:54 sde
brw-rw----   1 root disk        8,  80 Oct 18 14:54 sdf
brw-rw----   1 root disk        8,  96 Oct 18 14:54 sdg
brw-rw----   1 root disk        8,  97 Oct 18 14:54 sdg1

**sudo dcfldd if=/dev/sdc2 of=linuxdcfl.img hash=md5,sha1 hashlog=hashlog.txt**
242944 blocks (7592Mb) written.
243056+1 records in
243056+1 records out
**sudo dcfldd if=/dev/sdc2 vf=linuxdcfl.img verifylog=verify.log**
0 - 0: Mismatch
Total: Mismatch

Eu tentei o dcfldd e obtive uma incompatibilidade, sem log de erros. verify.log está vazio. O hashlog tem apenas as somas sha e md5.

    

Answer 1

dd tem um longo histórico de criação de bits exatos para duplicados de bits. diff pode ser usado para provar isso com bastante facilidade

Nota: você não menciona qual versão do Ubuntu você está executando. A única razão que faz a diferença é que o uso da mudança de status mudou.

Ubuntu 14.04 Trecho de man dd

 status=WHICH
              WHICH info to suppress outputting to stderr; 'noxfer' suppresses
              transfer stats, 'none' suppresses all

Trecho do Ubuntu 16.04 de man dd

status=LEVEL
              The  LEVEL of information to print to stderr; 'none' suppresses everything but error messages, 'noxfer' suppresses
              the final transfer statistics, 'progress' shows periodic transfer statistics

Tudo isso de lado, as únicas coisas em que consigo pensar resultariam em um arquivo de imagem com um padrão de bits diferente do que sua origem:

Erro do usuário:

A) Uma tentativa de criar uma imagem de uma partição montada (uma idéia extremamente ruim)

B) Falha em sync deixando dados no buffer do kernel.

ou

Falha de hardware:

C) Uma área com falha no disco onde você armazenou a imagem. Isso implica em falha iminente da unidade (espero que você tenha backups, se não, espere!)

D) Uma conexão desonesta que fornece conectividade deficiente para o dispositivo de mídia de origem ou de destino

Você seria sensato em verifique o status inteligente da unidade em que você armazenou a imagem.

O fato de que dcfldd também resultou em uma incompatibilidade me leva a acreditar que você tem um cabo com falha ou uma mídia de armazenamento com falha (seja na mídia de entrada ou na mídia de saída)

    

Answer 2

Sim, você pode montar partições dentro de uma imagem usando kpartx

sudo apt install kpartx
cd Images 
sudo kpartx -a orangepi.img

Ele criará dispositivos em / dev / mapper e os dispositivos deverão ser detectados pelo nautilus para permitir que suas respectivas partições sejam montadas.

Para remover o dispositivo em / dev / mapper, após desmontar a partição,

cd Images
sudo kpartx -d orangepi.img

Por que a partição é diferente no seu caso, não tenho idéia do que você fez para acabar com esse resultado. Deveria ter sido o mesmo.

    

Answer 3

Eu sempre evito fazer dd em partições individuais. Exceto exatamente o mesmo meio de armazenamento, mesmo tamanho, número do modelo ...

Parece que você criou uma partição maior no novo cartão e modificou algo com os inodes no processo.

Você disse que não conseguiu montar a imagem, mas funciona como pretendido no cartão SD de destino? Deveria ...

Eu adivinho, você está tentando mudar para um cartão maior. Minha maneira preferida é dd o cartão inteiro. Em seguida, inicialize em um live ou conecte outro computador, carregue o Gparted, reduza a partição de um par de MB e volte ao tamanho original. Ele recuperará o novo espaço livre e levará apenas 2 a 3 minutos.

    

Answer 4

As datas e os tamanhos dos arquivos .xsession-errors são completamente diferentes entre as duas listagens de arquivos na sua imagem. Não há como o 'dd' conseguir fazer isso sem embaralhar todo o sistema de arquivos além do reconhecimento.

Você não deve usar o dd em sistemas de arquivos montados. Isso é difícil de evitar quando a maioria dos sistemas é montada automaticamente assim que você conecta um cartão SD.

Use 'df' e 'dmesg' para encontrar o / dev / sd_ # do seu cartão SD. Aviso: pode haver mais de um para esse cartão SD se você tiver várias partições nele.

sudo umount /dev/sd_#

para desmontar o cartão SD, mas ele ainda será conectado e não será ejetado.

Execute o comando 'df' novamente para verificar se foi desmontado.

Agora você pode 'dd' ler ou escrever no cartão SD como um todo (o primeiro par de pôster original de 'dd').

Diga ao sistema para ejetar o cartão SD. [No Ubuntu 16.04, clique com o botão direito no cartão SD e selecione "Eject parent drive". Eles realmente devem adicionar "montar" e "desmontar" opções] Se você não consegue encontrar uma opção de ejeção, execute 'sync' e aguarde o prompt para retornar para liberar os buffers de gravação antes de remover o cartão SD.

    

Answer 5

O cartão SD pode ter blocos ruins.

'sudo badblocks -s -w / dev / sd #' no cartão SD de destino para executar um teste padrão de modo de gravação. Tenha muito cuidado com o / dev / sd #. 'badblocks -w' é DESTRUTIVO! Você pode querer verificar / dev / sd # contra 'ls-l / dev / disk / by-id /' para ter certeza de que você tem o dispositivo de bloco correto.

Eu corro isso em todos os meus novos dispositivos de armazenamento e suspeitos de serem ruins. Um HD SATA de 1 TB leva cerca de 24 horas para completar uma passagem dos quatro padrões de -w. Um cartão SD será significativamente mais rápido. Eu encontrei unidades flash USB ruins, cartões SD, discos rígidos e até mesmo alguns leitores de cartões micro-SD USB ruins dessa maneira.

Se algum número de bloqueio incorreto aparecer, você poderá tentar o dispositivo RMA se ainda estiver na garantia.