montar um cartão SD sem uma partição

Question

Eu tento montar um cartão SDHC no GNU / Linux. Ao contrário do que acontece normalmente, /var/log/syslog não menciona sdb1 , apenas:

Jul 26 16:07:53 xvii kernel: [  159.404842] scsi 6:0:0:0: Direct-Access     Singim   SD Card   MMC/SD 1.4F PQ: 0 ANSI: 0 CCS
Jul 26 16:07:53 xvii kernel: [  159.405115] sd 6:0:0:0: Attached scsi generic sg2 type 0
Jul 26 16:08:01 xvii kernel: [  168.239600] sd 6:0:0:0: [sdb] Attached SCSI removable disk

Além disso, fdisk -l /dev/sdb não produz nada. O que devo fazer?

EDIT (2014-07-27): Eu poderia ter este cartão SD novamente, e parece estar com defeito. Ontem, eu estava tentando através de um leitor de cartão USB. Hoje, eu testei diretamente colocando-o no slot SD do meu laptop e recebi milhares de erros de E / S:

Jul 27 11:56:35 xvii kernel: [ 8091.317234] mmc0: new high speed SDHC card at address 1234
Jul 27 11:56:35 xvii kernel: [ 8091.317477] mmcblk0: mmc0:1234 SA04G 3.68 GiB
Jul 27 11:56:35 xvii kernel: [ 8091.320119] mmc0: Got data interrupt 0x00200000 even though no data operation was in progress.
Jul 27 11:56:35 xvii kernel: [ 8091.322277] mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb00
Jul 27 11:56:35 xvii kernel: [ 8091.322289] mmcblk0: retrying using single block read
Jul 27 11:56:35 xvii kernel: [ 8091.324862] mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0
Jul 27 11:56:35 xvii kernel: [ 8091.324872] end_request: I/O error, dev mmcblk0, sector 0
Jul 27 11:56:35 xvii kernel: [ 8091.326398] mmcblk0: error -84 transferring data, sector 1, nr 7, cmd response 0x900, card status 0x0
Jul 27 11:56:35 xvii kernel: [ 8091.326405] end_request: I/O error, dev mmcblk0, sector 1
Jul 27 11:56:35 xvii kernel: [ 8091.329056] mmcblk0: error -84 transferring data, sector 2, nr 6, cmd response 0x900, card status 0x0
[...]

e gdisk -l não encontraram nenhuma tabela de partição e lsblk de saída sobre a placa:

mmcblk0                  179:0    0   3.7G  0 disk

Um pouco mais tarde, tentei novamente e o cartão foi reconhecido:

Jul 27 12:08:00 xvii kernel: [ 8776.617712] mmc0: new high speed SDHC card at address 1234
Jul 27 12:08:00 xvii kernel: [ 8776.618117] mmcblk0: mmc0:1234 SA04G 3.68 GiB
Jul 27 12:08:00 xvii kernel: [ 8776.620324]  mmcblk0: p1

e eu poderia montá-lo: / dev / mmcblk0p1 em / media / mmc tipo vfat (rw, nosuid, nodev, noexec, noatime, uid = 1000, gid = 1000, fmask = 0022, dmask = 0022, codepage = 437 , iocharset = utf8, nome abreviado = misto, erros = remount-ro, user = vinc17)

gdisk -l /dev/mmcblk0 encontrou apenas uma tabela de partição MBR, mas a segunda tabela de partição sobrepõe a última partição.

    

Answer 1

O link /dev/$disk aponta para o conjunto de um dispositivo de bloco, mas, em um disco particionado sem espaço não alocado, a única parte que também não é representada em /dev/$disk[num] é o primeiro 2kb-4mb ou mais -% tabela de partição do$disk. São apenas algumas informações gravadas no dispositivo bruto em um formato que o firmware e / ou sistema operacional possam ler. Diferentes sistemas interpretam isso de maneiras diferentes e por diferentes razões. Eu cobrirei três.

• Nos sistemas da BIOS, essa tabela é gravada no formato MBR registro mestre de inicialização para que o firmware possa descobrir onde encontrar o executável inicializável. Ele lê a tabela de partições porque, para inicializar as leituras da BIOS nos primeiros 512 bytes da partição, a tabela marca com o sinalizador inicializável e a executa. Esses 512 bytes geralmente contêm um bootloader (como grub ou lilo em muitos sistemas linux) que então carrega outro executável (como o kernel do Linux) localizado em uma partição formatada com um sistema de arquivos que o carregador entende.

• Em sistemas EFI e / ou sistemas BIOS com kernels mais recentes, essa tabela de partição pode ser um formato GPT tabela de partição GUID . O firmware EFI entende o sistema de arquivos FAT e procura a partição que a tabela descreve com o flag partição do sistema EFI , monta-a como FAT e tenta executar o caminho armazenado em sua variável NVRAM Boot0000- {GUID} . Esta é essencialmente a mesma tarefa que os gerenciadores de inicialização do BIOS foram projetados para fazer e, desde que o executável que você deseja carregar possa ser interpretado pelo firmware (como a maioria dos kernels Linux desde o v.3.3), obvia seu uso. O firmware EFI é um pouco mais sofisticado.

Após a inicialização, se uma tabela de partição estiver presente e o kernel a entender, /dev/${disk}1 será mapeado para o 4mb+ offset e terminará no ponto em que a tabela de partição diz. As partições realmente são apenas divisores lógicos arbitrários como:

start of disk | partition table | partition 1 | ... and so on | end of disk

Embora eu suponha que também possa ser:

s.o.d. | p.t. | --- unallocated raw space --- | partition 1 | ... | e.o.d. 

Tudo depende do layout que você define na tabela de partições, o que pode ser feito com ferramentas como fdisk para MBR formatos ou gdisk para GPT formatos.

• O firmware precisa de uma tabela de partição para o dispositivo de inicialização, mas o kernel precisa de um para qualquer dispositivo de bloco subdividido no qual você deseja que ele reconheça um sistema de arquivos. Se um disco é particionado, sem a tabela, o kernel não localizaria superblocos em uma varredura de disco. Ele lê a tabela de partições e mapeia esses deslocamentos para links em /dev/$disk[num] . No início de cada partição, procura o superbloco . É apenas alguns kb de dados (se isso) que informa ao kernel que tipo de sistema de arquivos é. Um sistema de arquivos robusto distribuirá backups de seu superbloco em toda a sua partição. Se a partição não contém um superbloco legível que o kernel entenda, o kernel não reconhecerá nenhum sistema de arquivos.

Em qualquer caso, o ponto é que você realmente não precisa dessas tabelas em qualquer disco que não precise ser interpretado pelo firmware - como em discos dos quais você não inicializa (que também é o único funcional) Caso GPT + BIOS) - e no qual você deseja apenas um único sistema de arquivos. /dev/$disk pode ser formatado no todo com qualquer sistema de arquivos que você goste. Você pode mkfs.fat /dev/$disk o dia inteiro se quiser - e provavelmente o Windows irá de qualquer maneira, como geralmente faz para os tipos de dispositivos que ele marca com o sinalizador removível .

Em outras palavras, é perfeitamente possível colocar um bloco de arquivos na cabeça de um disco em vez de uma tabela de partições. Nesse caso, desde que o kernel entenda o sistema de arquivos, você pode:

mount /dev/$disk /path/to/mount/point

Mas se você quer partições e elas ainda não estão lá, você precisa criá-las - o que significa escrever uma tabela mapeando seus locais no início do disco - com ferramentas como fdisk ou gdisk como mencionado.

Tudo isso junto me faz sugerir que seu problema é um desses três:

• o seu disco não tem tabela de partições nem sistema de arquivos

  • Foi recentemente apagado, nunca usado ou é corrupto.

• A tabela de partições do seu disco não é reconhecida pelo seu kernel do sistema operacional

  • BIOS e EFI não são os únicos tipos de firmware. Isso é especialmente verdadeiro no domínio móvel / incorporado, onde um cartão SDHC pode ser especialmente útil, embora muitos desses dispositivos usem camadas de sistemas de arquivos menos sofisticados que confundem as linhas entre um sistema de arquivos e uma tabela de partição.

• o seu disco não tem tabela de partições e é formatado com um sistema de arquivos não reconhecido pelo seu kernel do sistema operacional

Depois de reler seu comentário acima, tenho quase certeza de que é o último caso. Eu recomendo que você pegue um manual na tv, tente descobrir se você pode pegar qualquer sistema de arquivos que esteja usando carregado como um módulo do kernel em um desktop Linux e monte o disco lá.