sda e sdb block specials apontam para o mesmo dispositivo e se misturam (o hardware RAID não funciona após a nova instalação do 12.04)

3

Acabei de instalar o Ubuntu 12.04 mais recente e, obviamente, ele estraga alguma coisa. Não tenho certeza se isso tem algo a ver com o fato de que eu tenho um Raid 1, mas no momento, tenho sda e sdb que apontam para o mesmo dispositivo:

# blkid
/dev/sda1: UUID="88aa922a-4304-406e-8abd-edc2e9064d79" TYPE="ext2" 
/dev/sda2: UUID="22b881d5-6f5c-484d-94e8-e231896fa91b" TYPE="swap" 
/dev/sda3: UUID="e1fa161b-b014-4a6b-831a-9d8f9e04be07" TYPE="ext3" 
/dev/sda5: UUID="6ed19886-1cba-47b2-9ce0-7c2ea8f9c3c9" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sdb1: UUID="88aa922a-4304-406e-8abd-edc2e9064d79" TYPE="ext2" 
/dev/sdb2: UUID="22b881d5-6f5c-484d-94e8-e231896fa91b" TYPE="swap" 
/dev/sdb3: UUID="e1fa161b-b014-4a6b-831a-9d8f9e04be07" SEC_TYPE="ext2" TYPE="ext3" 
/dev/sdb5: UUID="6ed19886-1cba-47b2-9ce0-7c2ea8f9c3c9" TYPE="ext3" 

Mas eu tenho apenas um disco rígido "visível", então isso deve ser sda. Na minha versão anterior (10.10) o / dev / mapper cuidou disso. Olhe para os pontos de montagem abaixo. Na versão atual, isso não funciona mais, então eu inseri os pontos de montagem sda para fstab no início, o que parecia funcionar, mas quando eu executo o comando mount, vi que uma partição foi montada como sdb ao invés de sda. Então eu tentei usar o UUID como sistema de arquivos no fstab, mas o problema ainda existe. O que é ainda pior: mistura os dois dispositivos. Isso significa que, às vezes, montar uma partição como sda, na próxima reinicialização é sdb. E ele se comporta como montaria discos rígidos diferentes, porque minha partição / home foi montada uma vez como sda, agora como sdb e as alterações e as configurações que eu fiz no sistema de arquivos foram subitamente "redefinidas". O que eu posso fazer? Devo excluir todos os especiais do bloco sdb?

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    nodev,noexec,nosuid 0       0
#/dev/mapper/pdc_ccfhbjbeeg3 /               ext3    errors=remount-ro 0       1
#/dev/mapper/pdc_ccfhbjbeeg1 /boot           ext2    defaults        0       2
#/dev/mapper/pdc_ccfhbjbeeg5 /home           ext3    defaults        0       2
#/dev/mapper/pdc_ccfhbjbeeg2 none            swap    sw              0       0
#/dev/sda1                   /boot           ext2    defaults        0       2
#/dev/sda2                   none            swap    sw              0       0
#/dev/sda3                   /               ext3    errors=remount-ro 0     1
#/dev/sda5                   /home           ext3    defaults        0       2

UUID=e1fa161b-b014-4a6b-831a-9d8f9e04be07      /               ext3    errors=remount-ro 0     1
UUID=88aa922a-4304-406e-8abd-edc2e9064d79       /boot           ext2    defaults        0       2
UUID=6ed19886-1cba-47b2-9ce0-7c2ea8f9c3c9      /home           ext3    defaults        0       2
UUID=22b881d5-6f5c-484d-94e8-e231896fa91b       none            swap    sw     0       0

UPDATE
a propósito, o instalador do Ubuntu mostra o array RAID e não as partições. Veja também link

    
por Bevor 29.04.2012 / 15:05

5 respostas

1

Eu encontrei uma solução muito fácil para fazer meu (obviamente falso) RAID de hardware funcionar novamente.

Depois que eu reinstalei o Ubuntu 12.04 eu não reiniciei, mas fiquei no modo try. Então montei / e editei

/usr/share/initramfs-tools/scripts/local-top/dmraid

Eu adicionei dmraid -ay após o último comentário:

# Activate any dmraid arrays that were not identified by udev and vol_id.
dmraid -ay
if devices=$(dmraid -r -c); then
    for dev in $devices; do
        dmraid-activate $dev
    done
fi

Eu acho que é isso, mas no começo eu adicionei

dm-raid45
dm-mirror
dm-region-hash

para

/etc/modules

Eu não tenho certeza se isso é importante, porque depois da primeira inicialização (que finalmente funcionou sem voltar ao console de manutenção), o / etc / modules não continha mais esses 3 módulos, então eu acho que você pode omiti-lo .

Quando executo o mount, vejo o / dev / mapper montado novamente:

/dev/mapper/pdc_ccfhbjbeeg3 on / type ext3 (rw,errors=remount-ro)
/dev/mapper/pdc_ccfhbjbeeg1 on /boot type ext2 (rw)
/dev/mapper/pdc_ccfhbjbeeg5 on /home type ext3 (rw)
    
por 30.04.2012 / 19:33
1

Veja se você pode ocultar seus discos reais se ativar um ataque. Esta é possivelmente uma configuração no principal ou no RAID-BIOS do seu PC.

Eu tive problemas similares com o CentOS 5.5, que foi embora depois de uma atualização para o 5.6.

Depois de navegar na web um pouco sobre esses pseudo-raid-devices eu segui o conselho dado lá e o desativei. Depois eu recompus para um software-raid puro com meios Linux ( man mdadm ).

No caminho, não perdi nenhum dado e ganhei muito espaço - coloquei algumas de minhas partições em uma configuração RAID0 para dados que precisam ser rápidos e que podem ser restaurados com muita facilidade.

    
por 29.04.2012 / 21:38
1

Suspeito que você tenha um controlador "RAID falso" . Esses controladores RAID fornecem apenas suporte mínimo no BIOS; a maior parte do trabalho é feita em um driver do Windows. O Linux geralmente lida mal com esses controladores porque não possui drivers do Windows. Ver um único UUID, mas dois discos, é um sintoma comum de falso RAID (o driver do Windows saberia que existem dois discos, mas eles devem ter conteúdo idêntico).

Se você tiver um dispositivo RAID falso (e provavelmente o faz: controladores RAID de nível de consumidor são quase sempre RAID falso) e você não está compartilhando os discos com o Windows, desative o RAID no BIOS. Em seguida, habilite o software RAID do Linux, que para o RAID-1 é superior em todos os aspectos (exceto quando você está compartilhando os discos com o Windows).

Veja também o howto RAID falso do Ubuntu , Como faço para diferenciar o" falso RAID "do RAID real?

    
por 30.04.2012 / 02:58
0

/dev/md* são dispositivos de ataque. Se você configurou o RAID como afirma ter, não deverá estar acessando diretamente os discos subjacentes ( /dev/sd* ).

saída blkid da configuração do meu RAID (5):

/dev/sda1: UUID="aac68ff3-3351-4a2a-82ea-7e897a1ad340" TYPE="swap"
/dev/sda2: UUID="aadb3ed5-2365-04e5-b346-60fb1d3e86d5" UUID_SUB="10f3563d-0192-de95-5ca2-f72389ba2ea4" LABEL="localhost.localdomain:0" TYPE="linux_raid_member"
/dev/sda3: UUID="401bb12a-05ca-74a0-24bc-a3406d480931" UUID_SUB="36083341-9766-5646-dc70-e58fb031c078" LABEL="localhost.localdomain:1" TYPE="linux_raid_member"
/dev/sdc1: UUID="7981b4e0-a056-4eeb-98d7-a50a86e6f214" TYPE="swap"
/dev/sdc2: UUID="aadb3ed5-2365-04e5-b346-60fb1d3e86d5" UUID_SUB="43ef231e-baf7-ddd5-c5ff-9415b328dd1a" LABEL="localhost.localdomain:0" TYPE="linux_raid_member"
/dev/sdc3: UUID="401bb12a-05ca-74a0-24bc-a3406d480931" UUID_SUB="e034768e-8c1d-47c9-67f1-7f9dd255221c" LABEL="localhost.localdomain:1" TYPE="linux_raid_member"
/dev/sdb1: UUID="d4d654c8-9eba-4c06-93b0-f4e753031950" TYPE="swap"
/dev/sdb2: UUID="aadb3ed5-2365-04e5-b346-60fb1d3e86d5" UUID_SUB="033c2e47-f5e2-d3e6-193f-b528ded6781d" LABEL="localhost.localdomain:0" TYPE="linux_raid_member"
/dev/sdb3: UUID="401bb12a-05ca-74a0-24bc-a3406d480931" UUID_SUB="409f0399-657b-39a3-9809-a8142e6f11cf" LABEL="localhost.localdomain:1" TYPE="linux_raid_member"

Estas são as partições físicas

/dev/md0: UUID="2a535ad6-130b-4d4a-b71c-04a708d24dbf" TYPE="ext4"
/dev/md1: UUID="uHEOea-lPCj-XbNi-afv5-rL4o-2Kda-00Zec0" TYPE="LVM2_member"

Estes são os dispositivos RAID, eles são usados como volumes físicos para o LVM abaixo

/dev/mapper/vg0-root: LABEL="Fedora-13-x86_64" UUID="791ec0fb-6fcd-42c7-9d47-f2fdf2d0ad8b" TYPE="ext4"
/dev/mapper/vg0-tmp: UUID="32d0abc7-e035-4acf-a0fa-95109f6ef4e2" TYPE="ext4"
/dev/mapper/vg0-mail: UUID="c6779ecb-bc95-4af7-8c10-b749b37d5989" TYPE="ext4"
/dev/mapper/vg0-mm: UUID="f317f0be-971e-4d53-a8d0-cd7e685fb444" TYPE="ext4"
/dev/mapper/vg0-data: UUID="c3f37fd7-4c21-4423-b33a-faf384386a4d" TYPE="ext4"
/dev/mapper/vg0-srv: UUID="ebb588ea-53fc-4fba-90a9-47190823cec4" TYPE="ext4"
/dev/mapper/vg0-virt: UUID="dd77de03-61b5-403b-ac23-a61fdbf1749a" TYPE="ext4"
/dev/mapper/vg0-var: UUID="be092184-dd3a-4be1-83a0-624f01d25431" TYPE="ext4"
/dev/mapper/vg0-home: UUID="88462fa0-2e4c-4b8b-971b-c014f15a2ec8" TYPE="ext4"

Você pode ver quais dispositivos RAID estão disponíveis verificando /proc/mdstat , deve conter algo como:

$ cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4]
md1 : active raid5 sda3[0] sdc3[3] sdb3[1]
      1950372864 blocks super 1.1 level 5, 512k chunk, algorithm 2 [3/3] [UUU]
      bitmap: 2/8 pages [8KB], 65536KB chunk

md0 : active raid1 sda2[0] sdc2[2] sdb2[1]
      524276 blocks super 1.0 [3/3] [UUU]

unused devices: <none>

Aqui também você vê os dispositivos md* . Se você não tiver, você não está realmente usando o RAID.

O Software RAID HOWTO é uma boa referência para saber mais sobre isso.

    
por 29.04.2012 / 16:11
0

Como você não está inicializando duas vezes com o windows, você deve parar de usar o fakeraid e reconstruir o sistema usando o software raid mdadm. Desde que você montou os discos individuais, você corrompeu a matriz de ataque, ficando as duas cópias fora de sincronia umas com as outras. Mesmo se você montar o array corretamente, as leituras podem, às vezes, retornar dados fora de sincronia do outro disco, o que poderia causar corrupção massiva no sistema de arquivos.

Note que você tem que realmente apagar o array raid para se livrar dele, não apenas mudar o modo do controller de volta para o non-raid, ou o Ubuntu ainda irá reconhecer e tentar usá-lo.

Lembre-se também que o ataque não é um substituto para backups. Destina-se a aumentar a velocidade e / ou reduzir o tempo de inatividade em caso de falha de hardware; não protege contra perda de dados.

    
por 30.04.2012 / 21:19