A partição está faltando em / dev

Question

Estou tendo um problema estranho desde que me mudei do Centos5 para o Centos6. Eu tenho três discos, dois primeiros são usados como um RAID1, e um terceiro é um disco de backup independente que não está listado em / etc / fstab (ele é montado quando necessário e depois desmontado).

Meu problema : Após uma inicialização, o / dev / sdc existe, mas o / dev / sdc1 não. Além disso, os links em / dev / disks também estão ausentes na primeira partição do sdc. O disco em si é bom, e se eu removê-lo e conectá-lo novamente, / dev / sdc1 parece ok e tudo está funcionando.

Minha pergunta : qual subsistema gerencia a descoberta automática de discos, partições etc. durante o processo de inicialização (por exemplo, o que cria / dev / disks / by-label)? Como faço para configurá-lo para escanear / dev / sdc e criar todos os arquivos e links relevantes em / dev?

Edit: Aqui está a parte relevante da saída do dmesg (o único lugar que o sdc aparece). Ele lista sdc1, mas não está em / dev!

sd 1:0:0:0: [sdb] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
sd 3:0:0:0: [sdc] 976773168 512-byte logical blocks: (500 GB/465 GiB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sd 3:0:0:0: [sdc] Write Protect is off
sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00
sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sdb:
 sdc:
sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks: (1.00 TB/931 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 sda:
DMAR:[DMA Read] Request device [00:1e.0] fault addr 361bc000 
DMAR:[fault reason 06] PTE Read access is not set
 sdb1 sdb2 sdb3
 sdc1
 sda1
sd 1:0:0:0: [sdb] Attached SCSI disk
sd 3:0:0:0: [sdc] Attached SCSI disk
 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk

    

Answer 1

Eu finalmente encontrei o motivo para esse problema. O disco é membro do Intel RAID array e a assinatura RAID da Intel sobreviveu a particionamento e reformatação em outro computador:

mdadm -Evvv /dev/sdc

              Magic : Intel Raid ISM Cfg Sig.
        Version : 1.1.00
.................................................
[Archive Volume]:
           UUID : xxxx
     RAID Level : 1
        Members : 2
          Slots : [UU]

O mdadm descobriu que esse disco pertence a um array RAID externo e até lê os metadados da Intel: nome do volume, níveis de RAID, etc. É claro que todos esses dados são obsoletos e não são mais verdadeiros.

O fato de o disco ser considerado membro de um RAID externo foi o motivo pelo qual esse disco não estava recebendo suas partições atribuídas em / dev.

Como corrigir

mdadm --zero-superblock /dev/sdc

Substitua seu próprio dispositivo por /dev/sdc , é claro. Este deve ser não-destrutivo para o sistema de arquivos que já está no disco, pelo menos meu sistema de arquivos sobreviveu a isso sem nenhum problema. O superbloco de RAID geralmente está no (s) último (s) setor (es) do disco.

Moral desta história

Sempre, sempre limpe o disco antes de retirá-lo do RAID e reutilize-o em outro lugar! A Internet está repleta de histórias de discos estrangeiros sendo montados em uma matriz ao vivo, arruinando-a no processo. Eu tive sorte e tive esse pequeno problema.

Geralmente zerar os primeiros e últimos setores é o suficiente. Você deve fazê-lo no sistema antigo em que o disco foi originalmente usado ou em outro local durante a inicialização do CD de recuperação (se estiver usando somente o software RAID!).

    

Answer 2

Eu tive o mesmo problema no Debian Squeeze e nos discos VMware, as partições para um disco simplesmente não estavam em /dev , mas eram visíveis pelo fdisk e no dmesg. Eu atualizei o pacote udev de 164 (encontrado no estável) para 175 (encontrado no teste) e depois da reinicialização tudo funciona como deveria.