A unidade não pode ser montada automaticamente, mas a montagem manual é bem sucedida

Question

Eu tenho um disco rígido externo que, de repente, dá um erro quando o Linux Mint tenta montá-lo automaticamente quando está conectado. Por algum motivo, vejo dois rótulos "External Drive" (nome da unidade) no Nemo , mas ambos dão um erro semelhante ao tentar acessá-los. A única diferença é que o erro de acesso ao segundo disco tem /dev/sdb2 , em vez de sdb3, conforme mostrado abaixo.

Error mounting /dev/sdb3 at /media/branden/External_Drive: Command-line 'mount -t "ntfs" -o "uhelper=udisks2,nodev,nosuid,uid=1000,gid=1000,dmask=0077,fmask=0177" "/dev/sdb3" "/media/branden/External_Drive"' exited with non-zero exit status 12: NTFS signature is missing.
Failed to mount '/dev/sdb3': Invalid argument
The device '/dev/sdb3' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

Eu fui montar manualmente a coisa, mas encontrei algo ainda mais estranho. O comando que funcionou foi:

mount /dev/sdb /mnt

O que parece estar montando a unidade em vez de uma partição . Eu posso acessar a unidade inteira fazendo isso, mas não tenho certeza do porquê disso ter funcionado dessa maneira. Deve haver apenas uma única partição no externo, por isso não sei por que os seguintes resultados (mostrados abaixo) estão sendo observados. Se eu tentar montar /dev/sdbX , onde X é 1, 2, 3 ou 4, eu recebi "special device /dev/sdbX does not exist" .

Aqui está a saída que se obtém do fdisk -l , a formatação do texto foi péssima, por isso vou postar uma imagem:

Enovamenteemparted-l:

Alguma sugestão?

Mais uma vez, a formatação do texto devido a caracteres especiais em / etc / fstab tornou-o ilegível.

Eu nunca fiz provisões especiais para montar este dispositivo em um ponto específico da minha estrutura de diretórios. Ele simplesmente é montado como um dispositivo de mídia na inicialização assim que é reconhecido. Eu fiz um clone de unidade recentemente e depois que a unidade não montou na inicialização por mais tempo.

Saída de ls / dev / sdb *

/dev/sdb  /dev/sdb2  /dev/sdb3

tl; dr - O drive não é montado como dispositivo de mídia (já que é um disco rígido externo com interface USB) após o HDD ser clonado de outro disco. Além disso, devo montar o dispositivo na estrutura de diretórios como mount /dev/sdb /mnt , em vez de selecionar uma partição específica como em mount /dev/sdb1 /mnt . As saídas de fdisk e parted são diferentes, com a primeira exibindo várias partições que não deveriam existir.

    

Answer 1

O que aconteceu?

Então, passei algum tempo investigando isso e tenho quase certeza de que isso é causado por um bug do kernel. O bug é acionado pelo fato de você ter um sistema de arquivos NTFS na raiz do disco (isto é, o sistema de arquivos começa logo no início do disco). Normalmente, a raiz do disco conterá uma tabela de partições e os sistemas de arquivos estarão dentro das partições individuais.

Normalmente isso funcionaria bem com outros sistemas de arquivos, mas parece que o fato de ser NTFS tem o kernel confuso. Em vez de reconhecer o sistema de arquivos NTFS e passar sobre ele, ele o reconhece como uma tabela de partições MBR e continua a criar alguns arquivos de dispositivos relacionados a partições inexistentes.

Não sei por que você não recebe um sdb1 . Tanto o início quanto o final do disco são passados no final do disco para sdb4 , portanto, ele não aparece. Presumivelmente, o kernel encontra algum outro problema com sdb1 e não o cria. Você recebe sdb2 e sdb3 .

Solução alternativa

A solução é tentar fazer com que o resto do sistema ignore as partições desonestas. Para fazer isso, primeiro execute o comando sudo udevadm info /dev/sdb | grep ID_SERIAL= quando o disco estiver conectado para descobrir seu número de série, isso é tudo depois do = . Em seguida, crie um arquivo com o caminho /etc/udev/rules.d/99-hide-partitions.rules . Coloque as duas linhas abaixo e substitua xxxxx pelo número de série anterior.

ID_SERIAL=xxxxx, ID_PART_ENTRY_NUMBER=="2", ENV{UDISKS_IGNORE}="1"
ID_SERIAL=xxxxx, ID_PART_ENTRY_NUMBER=="3", ENV{UDISKS_IGNORE}="1"

Depois de salvar o arquivo, desconecte e conecte seu disco e as coisas devem estar ok.

Alternativa

A alternativa do curso é reformatar o disco e colocar uma tabela de partição e um sistema de arquivos NTFS ou apenas usar um sistema de arquivos diferente.

Esta pode ser a melhor solução para o longo prazo, como presumivelmente a razão para ter uma partição NTFS é para compatibilidade com o Windows. Minha experiência com o Windows é que ele não gosta de discos sem tabela de partição (provavelmente a razão pela qual esse bug não surgiu no Linux antes). Você pode verificar (ou talvez você já saiba) se a unidade funciona com o Windows. Se este for o caso, ter um sistema de arquivos NTFS que não funciona com o Windows em um disco que não funciona bem no Linux provavelmente não é muito útil.

Note que se você quer um sistema de arquivos que funcione bem com o Linux e o Windows, um bom teste é UDF .

Relatório de bugs

Provavelmente seria uma boa ideia relatar este bug para os desenvolvedores do kernel. O que seria útil é uma cópia dos primeiros 512 bytes da unidade que é mal interpretada como uma tabela de partições MBR. Seria útil reproduzir o erro caso ele não apareça em todos os sistemas de arquivos NTFS. Para copiar a seção da unidade faça para mbr.bin :

sudo dd if=/dev/sdb of=mbr.bin bs=512 count=1

Se você quiser denunciar o bug, fique à vontade. Caso contrário, por favor poste o arquivo online em algum lugar para que alguém aqui possa fazê-lo. Se você for reformatar, obviamente faça isso primeiro.