Início / unix / Perguntas / 516381
Accepted
bit
Asked: 2019-05-01 05:54:26 +0800 CST

Por que o lsblk está mostrando o antigo FSTYPE e LABEL de um dispositivo que foi formatado?

  • 772

Formatei um disco rígido externo (sdc) para ntfs usando o parted, criando uma partição primária (sdc1). Antes de formatar o dispositivo SystemRescueCd foi instalado no disco rígido externo usando o comando ddpara ser usado como um USB inicializável. No entanto, ao listar dispositivos com lsblk -fainda estou recebendo o antigo FSTYPE (iso9660) e LABEL (sysrcd-5.2.2) para o dispositivo formatado (sdc):

NAME       FSTYPE      LABEL           UUID   MOUNTPOINT
sda                                                                            
├─sda1     ntfs        System Reserved                       
├─sda2     ntfs                                               
├─sda3     ntfs                                               
├─sda4                                                                         
sdc        iso9660     sysrcd-5.2.2                     
└─sdc1     ntfs        sysrcd-5.2.2          /run/media/user/sysrcd-5.2.2

Conforme mostrado na saída lsblk -fapenas o FSTYPE da partição sdc1está correto, a sdc1partição LABEL, sdcblock device FSTYPE e LABEL estão errados. O aplicativo nautilus GUI também está mostrando o rótulo do dispositivo antigo (sysrcd-5.2.2).

Depois de criar uma nova tabela de partições, partedsugeri que eu reinicializasse o sistema antes de formatar o dispositivo para ntfs , mas decidi desmontar sdc em vez de reiniciar.

  • Será que o kernel ainda está usando o antigo FSTYPE e LABEL porque eu não reiniciei o sistema? Tenho que reiniciar o sistema para me livrar do antigo FSTYPE e LABEL?
  • Como alternativa à reinicialização, existe uma maneira de renomear o FSTYPE e o LABEL de um dispositivo de bloco manualmente para que eu possa alterá-los para o FSTYPE e o LABEL originais fornecidos com o disco rígido externo?
linux kernel

3 respostas

  1. Best Answer

    A partir da saída do lsblk -fpost original, suspeitei que a assinatura do SystemRescueCd instalado ainda estava presente no disco rígido externo. Então, executei o comando wipefs /dev/sdce wipefs /dev/sdc1imprimiu informações sobre sdce todas as partições em sdc:

    [root@fedora user]# wipefs /dev/sdc
DEVICE OFFSET TYPE    UUID                   LABEL
sdc    0x8001 iso9660                        sysrcd-5.2.2
sdc    0x1fe  dos                            
[root@fedora user]# wipefs /dev/sdc1
DEVICE OFFSET TYPE UUID             LABEL
sdc1   0x3    ntfs  
sdc1   0x1fe  dos

    A impressão acima confirmou que a iso9660tabela de partição criada pelo SystemRescueCd ainda estava presente. lsblkestava usando o TYPEand LABELda iso9660tabela de partição em vez da tabela de partição dos (Master Boot Record). Para lsblkexibir a tabela de partição correta, a tabela de iso9660partição teve que ser excluída. Observe que ddtambém pode ser usado para eliminar uma assinatura de tabela de partição de um dispositivo de bloco (disco), mas ddtambém pode eliminar outras tabelas de partição.

    Como queremos direcionar apenas uma assinatura de tabela de partição específica para limpeza, wipefsfoi preferível, pois, diferentemente ddde , com wipefsnão teríamos que recriar a tabela de partição novamente. A -aopção do comando wipefsapaga todas as assinaturas disponíveis no dispositivo, mas a -topção do comando wipefsquando usada em conjunto com a -aopção restringe o apagamento de assinaturas apenas a um determinado tipo de tabela de partição. Abaixo, limpamos a iso9660tabela de partição. A opção -f( --force) é necessária ao apagar uma assinatura de tabela de partição em um dispositivo de bloco.

    [root@fedora user]# wipefs -a -t iso9660 -f /dev/sdc
/dev/sdc: 5 bytes were erased at offset 0x00008001 (iso9660): 43 44 30 30 31

    Depois de apagar a iso9660tabela de partição, verificamos a tabela de partição novamente para confirmar que a tabela de partição iso9660foi apagada:

    [root@fedora user]# wipefs /dev/sdc
DEVICE OFFSET TYPE UUID LABEL
sdc    0x1fe  dos       
[root@fedora user]# wipefs /dev/sdc1
DEVICE OFFSET TYPE UUID             LABEL
sdc1   0x3    ntfs 34435675G36Y4776 
sdc1   0x1fe  dos

    Mas agora que a tabela de partição problemática iso9660foi apagada lsblkagora está usando o UUIDda partição como o nome do diretório do ponto de montagem, pois o rótulo usado anteriormente da iso9660tabela de partição não existe mais:

    NAME       FSTYPE      LABEL           UUID   MOUNTPOINT
sda                                                                            
├─sda1     ntfs        System Reserved                       
├─sda2     ntfs                                               
├─sda3     ntfs                                               
├─sda4                                                                         
sdc                            
└─sdc1     ntfs        34435675G36Y4776          /run/media/user/34435675G36Y4776

    podemos verificar quais volumes (ou seja, partições) possuem rótulos no diretório /dev/disk/by-labelque lista todas as partições que possuem um rótulo:

    [root@fedora user]# ls -l /dev/disk/by-label
total 0
lrwxrwxrwx. 1 root root 10 Apr 30 19:47 'System\x20Reserved' -> ../../sda1

    O ntfssistema de arquivos na partição sda1é a única partição que possui um rótulo

    Para tornar o nome do diretório do ponto de montagem mais legível, alteramos o rótulo do ntfssistema de arquivos na partição sdc1de nada (string vazia) para um "novo rótulo". Os comandos para alterar o rótulo de um sistema de arquivos dependem do sistema de arquivos 1 2 . Para um ntfssistema de arquivos, a alteração do rótulo é feita com o comando ntfslabel:

    ntfslabel /dev/sdc1 "new-label"

    Agora depois de alterar o rótulo no ntfssistema de arquivos lsblkusa o "new-label"como o nome do diretório do mountpoint:

    NAME       FSTYPE      LABEL           UUID   MOUNTPOINT
sda                                                                            
├─sda1     ntfs        System Reserved                       
├─sda2     ntfs                                               
├─sda3     ntfs                                               
├─sda4                                                                         
sdc                            
└─sdc1     ntfs        new-label          /run/media/user/new-label

    Observe: também que o dispositivo sdcnão possui mais um tipo e rótulo de sistema de arquivos como todos os outros dispositivos de bloco (por exemplo, sda). Somente partições devem ter um tipo de sistema de arquivos, pois o sistema de arquivos está na partição e não no dispositivo, e rótulo, pois o cabeçalho da coluna LABELé o rótulo do sistema de arquivos e não o rótulo do dispositivo.

    • 5

  2. Você já tentou reler a tabela de partição (como root)?

    partprobe /dev/sdc
    • 2

  3. lsblkprovavelmente está inspecionando primeiro o primeiro setor para ver qual tipo de sistema de arquivos o dispositivo contém, e somente se nada for encontrado, passará para locais "usuais" para superblocos de sistema de arquivos.

    Como iso9660 é reconhecível a partir de dados no primeiro setor, lsblknão procura mais e extrai o rótulo do volume de lá também.

    Simplesmente criar uma tabela de partição deixa a maior parte do primeiro setor intacto, e é por isso que você está vendo isso.

    Você precisa primeiro limpar o primeiro setor com, por exemplo dd if=/dev/zero of=/dev/sdc count=1, e depois recriar a tabela de partição. Se você recriá-lo com os mesmos parâmetros, o sistema de arquivos NTFS criado anteriormente ainda deve estar intacto.

    • 0

relate perguntas