Para um projeto de robótica, eu montei um destino que usa dd (na verdade, dcfldd ) para escrever uma imagem de Jessie Raspbian no cartão SD. Dessa forma, posso ter certeza de que meu ambiente é reproduzível a partir do zero sempre que eu quiser.
O alvo do make é apenas
flash:
sudo dcfldd bs=4M if=$(IMGPATH) of=$(SDX)
sync
em que $(SDX) é / dev / sdc, e deve ser precedido por um script que monta a imagem em / mnt / img, faz algumas modificações, chama sync e então a desmonta.
O processo parece estar funcionando bem, exceto que sempre preciso chamar o destino do make duas vezes - na primeira vez, se eu ejetar corretamente todo o leitor de cartão e reinseri-lo, uma das duas partições da imagem falhará para montar, e, se eu tentar inicializar o Raspberry Pi, eu recebo um kernel panic.
Depois de experimentar o cartão flash (com o alvo Make ou manualmente no terminal), ejetando com a opção de menu de contexto "Eject parent drive" do Ubuntu, removendo e reinserindo o leitor, a partição de boot é aberta no Nautilus, mas Eu recebo o seguinte diálogo e nenhuma partição principal.
Asúltimascentenasdelinhasdedmesgsão
[100640.545190] FAT-fs (sdb1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
e
[101082.691558] EXT4-fs (sdb2): bad geometry: block count 3894272 exceeds size of device (964096 blocks)
Como o primeiro sugere, eu faço sudo fsck /dev/sdb e obtenho o seguinte.
fsck from util-linux 2.20.1
e2fsck 1.42.9 (4-Feb-2014)
fsck.ext2: No medium found while trying to open /dev/sdb
The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>
Se eu fizer
sudo dcfldd bs=4M if=/dev/sdb of=/tmp/from-sd-card.img count=1024
cmp /tmp/from-sd-card.img /home/tsbertalan/workspace/gunnar/2016-05-27-raspbian-jessie.img
Eu obtenho
/tmp/from-sd-card.img /home/tsbertalan/workspace/gunnar/2016-05-27-raspbian-jessie.img differ: char 4194342, line 1
e se eu fizer
cmp -b --verbose /tmp/from-sd-card.img /home/tsbertalan/workspace/gunnar/2016-05-27-raspbian-jessie.img
Eu obtenho
4194342 1 ^A 0 ^@
70255618 72 : 257 M-/
70255619 35 ^] 3 ^C
70255622 375 M-} 266 M-6
70255623 166 v 16 ^N
70255625 34 ^\ 114 L
70255626 345 M-e 274 M-<
70255627 4 ^D 0 ^@
70255629 77 ? 14 ^L
70255630 371 M-y 176 ~
70255631 144 d 1 ^A
70255633 326 M-V 200 M-^@
70255634 256 M-. 252 M-*
70255635 32 ^Z 1 ^A
70255661 373 M-{ 114 L
70255662 123 S 124 T
70255665 105 E 120 P
70255666 132 Z 124 T
70255669 24 ^T 2 ^B
70255754 0 ^@ 155 m
70255823 352 M-j 353 M-k
70255993 125 U 201 M-^A
70255994 323 M-S 343 M-c
70255995 257 M-/ 71 9
1815085083 72 : 0 ^@
1815085084 103 C 132 Z
Esse 4194342 parece ser consistente.
Só posso reproduzir o problema se inserir um cartão devidamente iluminado no RPI, inicialize-o e depois desligue-o. Depois disso, são necessárias duas tentativas para exibir a placa corretamente. Agora suspeito strongmente que o redimensionamento automático que o Raspbian executa na primeira inicialização pode ser parte deste problema. Se esta questão for a melhor opção para o site do stackexchange do Raspberry Pi, ela poderá ser movida para lá.
O que está acontecendo aqui? Existe alguma outra maneira que eu deveria estar escrevendo esta imagem para que funcione na primeira tentativa? Eu não quero gravar meus ciclos de gravação de cartão SD limitados desnecessariamente.
Eu só tenho um leitor de cartão para testar isso, mas eu tentei com um micro SDHC Samsung EVO de 16GB, um SanDisk Ultra micro SDHC de 8GB e um SDHC SanDisk Ultra micro de 32GB, com os mesmos resultados em todos.
[101082.691558] EXT4-fs (sdb2): bad geometry: block count 3894272 exceeds size of device (964096 blocks)
O cabeçalho do sistema de arquivos está corrompido. Definitivamente, abra um bug com os mantenedores da ferramenta de redimensionamento automático.
Tags dd sd-card linux raspberry-pi