Para sua pergunta de bônus:
mdadm --examine --scan >> /etc/mdadm/mdadm.conf
Após a inicialização, meu dispositivo RAID1 ( /dev/md_d0 *) às vezes fica em um estado engraçado e não consigo montá-lo.
* Originalmente eu criei /dev/md0 , mas de alguma forma ele se transformou em /dev/md_d0 .
# mount /opt
mount: wrong fs type, bad option, bad superblock on /dev/md_d0,
missing codepage or helper program, or other error
(could this be the IDE device where you in fact use
ide-scsi so that sr0 or sda or so is needed?)
In some cases useful info is found in syslog - try
dmesg | tail or so
O dispositivo RAID parece estar inativo de alguma forma:
# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5]
[raid4] [raid10]
md_d0 : inactive sda4[0](S)
241095104 blocks
# mdadm --detail /dev/md_d0
mdadm: md device /dev/md_d0 does not appear to be active.
A pergunta é, como tornar o dispositivo ativo novamente (usando mdmadm , eu presumo)?
(Outras vezes está tudo bem (ativo) após a inicialização, e eu posso montá-lo manualmente sem problemas. Mas ele ainda não será montado automaticamente, mesmo que eu tenha em /etc/fstab :
/dev/md_d0 /opt ext4 defaults 0 0
Então, uma pergunta bônus: o que devo fazer para que o dispositivo RAID seja montado automaticamente em /opt no momento da inicialização? )
Esta é uma estação de trabalho Ubuntu 9.10. Informações em segundo plano sobre minha configuração RAID nesta questão .
Editar : Meu /etc/mdadm/mdadm.conf é assim. Eu nunca toquei neste arquivo, pelo menos à mão.
# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes
# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
# instruct the monitoring daemon where to send mail alerts
MAILADDR <my mail address>
# definitions of existing MD arrays
# This file was auto-generated on Wed, 27 Jan 2010 17:14:36 +0200
Em /proc/partitions , a última entrada é md_d0 agora, após a reinicialização, quando o dispositivo estiver ativo novamente. (Não tenho certeza se seria o mesmo quando estiver inativo.)
Resolução : como Jimmy Hedman sugeriu , peguei a saída de mdadm --examine --scan :
ARRAY /dev/md0 level=raid1 num-devices=2 UUID=de8fbd92[...]
e adicionou em /etc/mdadm/mdadm.conf , o que parece ter resolvido o problema principal. Depois de alterar /etc/fstab para usar /dev/md0 novamente (em vez de /dev/md_d0 ), o dispositivo RAID também será montado automaticamente.
Eu descobri que tenho que adicionar o array manualmente em /etc/mdadm/mdadm.conf para fazer o Linux montá-lo na reinicialização. Caso contrário, recebo exatamente o que você tem aqui - md_d1 -dispositivos que estão inativos, etc.
O arquivo conf deve ser semelhante ao abaixo - isto é, um ARRAY -line para cada dispositivo-md. No meu caso, os novos arrays estavam faltando nesse arquivo, mas se você os listou, isso provavelmente não é uma correção para o seu problema.
# definitions of existing MD arrays
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d
Adicione uma matriz por dispositivo-m e adicione-os após o comentário incluído acima ou, se não houver tal comentário, no final do arquivo. Você obtém os UUIDs fazendo sudo mdadm -E --scan :
$ sudo mdadm -E --scan
ARRAY /dev/md0 level=raid5 num-devices=3 UUID=f10f5f96:106599e0:a2f56e56:f5d3ad6d
ARRAY /dev/md1 level=raid1 num-devices=2 UUID=aa591bbe:bbbec94d:a2f56e56:f5d3ad6d
Como você pode ver, você pode simplesmente copiar a saída do resultado da varredura para o arquivo.
Eu executo o desktop Ubuntu 10.04 LTS e, tanto quanto eu me lembro, este comportamento difere da versão do servidor do Ubuntu, no entanto, foi há muito tempo que eu criei meus dispositivos md no servidor eu posso estar errado. Também pode ser que eu tenha perdido alguma opção.
De qualquer forma, adicionando a matriz no arquivo conf parece fazer o truque. Eu executei o ataque 1 e o ataque 5 acima por anos sem problemas.
Atenção: Primeiro de tudo, deixe-me dizer que o abaixo (devido ao uso de "--force") parece arriscado para mim, e se você tiver dados irrecuperáveis, eu recomendaria fazer cópias das partições envolvidas antes de começar a tentar qualquer uma das coisas abaixo. No entanto, isso funcionou para mim.
Eu tive o mesmo problema, com uma matriz aparecendo como inativa, e nada que eu fiz incluindo o "mdadm --examine --scan > /etc/mdadm.conf", como sugerido por outros aqui, ajudou em tudo .
No meu caso, quando tentou iniciar o array RAID-5 depois de uma substituição de unidade, estava dizendo que estava sujo (via dmesg ):
md/raid:md2: not clean -- starting background reconstruction
md/raid:md2: device sda4 operational as raid disk 0
md/raid:md2: device sdd4 operational as raid disk 3
md/raid:md2: device sdc4 operational as raid disk 2
md/raid:md2: device sde4 operational as raid disk 4
md/raid:md2: allocated 5334kB
md/raid:md2: cannot start dirty degraded array.
Faz com que ele apareça como inativo em /proc/mdstat :
md2 : inactive sda4[0] sdd4[3] sdc4[2] sde4[5]
3888504544 blocks super 1.2
Eu descobri que todos os dispositivos tinham os mesmos eventos, exceto pela unidade que eu havia substituído ( /dev/sdb4 ):
[root@nfs1 sr]# mdadm -E /dev/sd*4 | grep Event
mdadm: No md superblock detected on /dev/sdb4.
Events : 8448
Events : 8448
Events : 8448
Events : 8448
No entanto, os detalhes da matriz mostraram que ele tinha 4 de 5 dispositivos disponíveis:
[root@nfs1 sr]# mdadm --detail /dev/md2
/dev/md2:
[...]
Raid Devices : 5
Total Devices : 4
[...]
Active Devices : 4
Working Devices : 4
[...]
Number Major Minor RaidDevice State
0 8 4 0 inactive dirty /dev/sda4
2 8 36 2 inactive dirty /dev/sdc4
3 8 52 3 inactive dirty /dev/sdd4
5 8 68 4 inactive dirty /dev/sde4
(O acima é da memória na coluna "Estado", não consigo encontrá-lo no meu buffer de rolagem para trás).
Consegui resolver isso parando o array e, em seguida, remontando-o:
mdadm --stop /dev/md2
mdadm -A --force /dev/md2 /dev/sd[acde]4
Nesse ponto, a matriz estava funcionando com 4 dos 5 dispositivos, e eu consegui adicionar o dispositivo de substituição e estou reconstruindo. Eu consigo acessar o sistema de arquivos sem nenhum problema.
Eu estava tendo problemas com o Ubuntu 10.04, onde um erro no FStab impedia o servidor de inicializar.
Eu executei este comando conforme mencionado nas soluções acima:
mdadm --examine --scan >> /etc/mdadm/mdadm.conf
Isto irá acrescentar os resultados de "mdadm --examine --scan" para "/etc/mdadm/mdadm.conf"
No meu caso, isso foi:
ARRAY /dev/md/0 metadata=1.2 UUID=2660925e:6d2c43a7:4b95519e:b6d110e7 name=localhost:0
Este é um fakeraid 0. Meu comando em / etc / fstab para montagem automática é:
/dev/md0 /home/shared/BigDrive ext3 defaults,nobootwait,nofail 0 0
O importante aqui é que você tem "nobootwait" e "nofail". Nobootwait irá pular todas as mensagens do sistema que estão impedindo você de inicializar. No meu caso, isso foi em um servidor remoto, por isso era essencial.
Espero que isso ajude algumas pessoas.
Você pode ativar seu dispositivo md com
mdadm -A /dev/md_d0
Suponho que algum script de inicialização seja iniciado cedo demais, antes que um membro do RAID seja descoberto ou algum problema semelhante. Como uma solução rápida e suja, você deve poder adicionar esta linha ao /etc/rc.local:
mdadm -A /dev/md_d0 && mount /dev/md_d0
Edit: aparentemente seu /etc/mdadm/mdadm.conf ainda contém o nome da configuração antiga. Edite esse arquivo e substitua as ocorrências de md0 por md_d0.
Eu tive um problema semelhante ... meu servidor não montaria md2 depois que eu crescesse as partições de dispositivos associados. Ao ler este tópico descobri que o dispositivo RAID md2 tinha um novo UUID e a máquina estava tentando usar o antigo.
Como sugerido ... usando a saída 'md2' de
mdadm --examine --scan
Eu editei /etc/mdadm/mdadm.conf e substituí a antiga linha UUID pela uma saída do comando acima e meu problema desapareceu.
Quando você finge fazer algo com /dev/md[012346789} , vai para /dev/md{126,127...} .
/dev/md0 continua montado em /dev/md126 ou /dev/md127 você precisa:
umount /dev/md127
ou
umount /dev/md126 .
Isso é temporário para permitir que você execute comandos e alguns aplicativos sem parar o sistema.
Uma maneira simples de executar o array, supondo que não há nenhum problema de hardware e de ter unidades / partições suficientes para iniciar o array, é a seguinte:
md20 : inactive sdf1[2](S)
732442488 blocks super 1.2
sudo mdadm --manage /dev/md20 --run
Pode ser que, por qualquer motivo, a matriz esteja bem, mas algo impediu que ela fosse iniciada ou construída. No meu caso, isso foi porque o mdadm não sabia que o nome da matriz original era md127 e todas as unidades foram desconectadas para essa matriz. Ao fazer a replicação eu tive que montar manualmente (provavelmente um bug onde o mdadm achava que o array já estava ativo por causa do antigo nome do array offline).
md_d0 : inactive sda4[0](S) parece errado para uma matriz RAID1. Parece sugerir que o array não tem dispositivos ativos e um dispositivo sobressalente (indicado pelo (S), você veria (F) lá por um dispositivo com falha e nada por um dispositivo OK / ativo) - para uma matriz RAID1 que não está sendo degradada, deve haver pelo menos dois dispositivos OK / ativos (e, para uma matriz degradada, pelo menos um dispositivo OK / ativo) e você não pode ativar uma matriz RAID1 sem nenhum dispositivo não sobressalente (as peças de reposição não contêm uma cópia dos dados até que sejam ativadas quando outra unidade falhar). Se eu estiver lendo que /proc/mdstat output, você não poderá ativar o array em seu estado atual.
Você tem alguma unidade física na máquina que não conseguiu girar? O ls /dev/sd* lista todas as unidades e partições que você normalmente esperaria ver nessa máquina?
Tags raid mdadm linux ubuntu software-raid