Eu criei com sucesso um RAID (espelhamento) utilizando mdadm. No entanto, devo executar os seguintes comandos após cada inicialização:
mdadm --stop --scan // to stop /dev/md127 - I don't know where the number 127 even comes from
mdadm --assemble --scan // to start /dev/md0
O que estou fazendo de errado / por que preciso executar esses comandos na inicialização? Qual é a maneira correta de iniciar automaticamente o RAID a cada (re) inicialização?
Respostas:
NB: Você precisa estar logado como root ou usar o sudo para fazer tudo isso ...
Se o arquivo nem existir, cole o seguinte no novo arquivo vazio:
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#
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 root
# definitions of existing MD arrays
Salve o arquivo
Execute o seguinte comando para adicionar uma referência à sua configuração de matriz no final do arquivo:
mdadm --detail --scan >> /etc/mdadm/mdadm.conf
Isso deve adicionar uma linha como a seguinte no final do mdadm.conf:
ARRAY / dev / md0 level = raid5 num-devices = 3 metadados = 00.90 UUID = a44a52e4: 0211e47f: f15bce44: 817d167c
Se o comando mdadm adicionou outros itens acima da linha ARRAY, remova-o. Por exemplo, em uma das minhas máquinas, o comando retorna 'mdadm: formato de metadados 00.90 desconhecido, ignorado'. antes da linha ARRAY.
Sua matriz agora deve ser auto-compilada na inicialização e, portanto, você pode adicionar uma entrada no / etc / fstab para montá-la (se ainda não estiver lá)
mdadm -Esvez disso.
grub-install /dev/sdapara torná-lo trabalho (substitua sda para qualquer coisa apropriada para você)
md.auto=1... Na verdade, eu não testei isso completamente, mas supostamente ele os detecta e os monta (ou pelo menos tenta fazê-lo). Mas o kernel.org/doc/html/v4.15/admin-guide/md.html é um pouco ambíguo: quando o md é compilado no kernel (não como módulo), as partições do tipo 0xfd são verificadas e montadas automaticamente em matrizes RAID. [...] A partir do kernel 2.6.9, apenas unidades com um superbloco do tipo 0 podem ser detectadas automaticamente e executadas no momento da inicialização. E não se refere ao md.auto (ou o que quer que fosse), então não tenho certeza agora.
Sei que essa é uma pergunta mais antiga, mas tive um tempo frustrante com isso na versão de 32 bits do Ubuntu Server 12.04.
A corrida mdadm --detail --scan >> /etc/mdadm/mdadm.confanexou a linha
ARRAY / dev / md0 metadados = 1.2 nome = ubuntu: 0 UUID = a8a570c6: 96f61865: 05abe131: 5c2e2f7e
Após uma reinicialização, eu nunca conseguia ver / dev / md0. Executando o mdadm --detail --scannovamente (sem colocar o resultado em um arquivo) eu veria
ARRAY / dev / md / ubuntu: 0 metadados = 1.2 nome = ubuntu: 0 UUID = a8a570c6: 96f61865: 05abe131: 5c2e2f7e
e a montagem manual /dev/md/ubuntu:0funcionaria. No final, foi isso que coloquei no arquivo fstab também.
Não sei ao certo o que estou errado, se é assim que funciona no Ubuntu 12.04 ou se é uma má prática. Só queria compartilhar o que funcionou para mim.
No Debian wheezy, é necessário mais um passo: no /etc/default/mdadmconjunto autostart de false para true
#COMEÇO AUTOMÁTICO: # o mdadm deve iniciar as matrizes listadas em /etc/mdadm/mdadm.conf automaticamente # durante a inicialização? AUTOSTART = true
Também tive que usar em mdadm -Es >>/etc/mdadm/mdadm.confvez da --scanopção, pois isso não funcionou para mim.
sudo mdadm -Es >> /etc/mdadm/mdadm.conf
Agora edite as linhas adicionadas ao /etc/mdadm/mdadm.conf da seguinte maneira. Exclua tudo, exceto as partes básicas. Deve parecer
ARRAY /dev/md5 UUID=031cea92:50a7a28c:6b077fe7:8817092a
ARRAY /dev/md6 UUID=53454954:4044eb66:9169d1ed:40905643
Nota: você pode escolher X no mdX para sua conveniência.
Agora reinicie
sudo update-initramfs -u
sudo reboot
EDIT: comando corrigido.
Eu tive esse problema no meu Raspberry Pi 2 executando o Raspbian GNU / Linux 8 (jessie). Eu tinha uma matriz RAID /dev/sda1e /dev/sdb1não conseguiu montar na inicialização. Eu tinha no meu /etc/mdadm/mdadm.confarquivo a entrada
ARRAY /dev/md/0 metadata=1.2 UUID=53454954:4044eb66:9169d1ed:40905643 name=raspberrypi:0
(seus números serão diferentes; veja outras respostas sobre como obter isso.)
Eu tinha no meu /etc/fstabarquivo a entrada
/dev/md0 /data ext4 defaults 0 0
(e é claro que /datarealmente existia)
Como o OP, eu conseguia montar e montar o array RAID manualmente após a inicialização, mas não consegui que isso acontecesse automaticamente durante a inicialização, apesar de aparentemente configurá-lo corretamente.
Consegui resolver o problema da seguinte maneira. Eu investiguei o script /etc/init.d/mdadm-raide inseri uma linha de código de depuração
ls /dev > /home/pi/devices.txt
Reiniciar e conferir esse arquivo eu aprendi que os dispositivos /dev/sdae /dev/sdbexistia na época a mdadm-raidinicialização aconteceu, mas as partições /dev/sda1e /dev/sdb1estavam faltando. Editei o /etc/init.d/mdadm-raidarquivo e inseri a linha
partprobe
após o cabeçalho (ou seja, após o ### END INIT INFOmas antes do início do script). Isso fez com que as partições fossem detectadas e, portanto, o mdadm-raidscript conseguiu montar a matriz RAID, resolvendo o problema. Espero que isso ajude alguém!
Eu tenho lutado com isso no Raspbian usando um par de HDDs externos em um Raspberry Pi. Eu tive que mexer com a ordem de início dos serviços para garantir que o mdadm-raid iniciasse após as unidades USB serem reconhecidas pelo udev, mas antes do checkfs.sh (que verifica os sistemas de arquivos no momento da inicialização). Se o mdadm-raid iniciar muito cedo, as unidades não estarão disponíveis e, portanto, a matriz não será montada. Isso significava que o fsck falhou posteriormente e o processo de inicialização foi interrompido para um prompt de manutenção (porque a matriz de ataque é necessária para outros serviços).
A modificação das dependências de inicialização para iniciar o mdadm-raid após o checkroot.sh, mas antes do checkfs.sh e da execução update-rc.d mdadm-raid defaults, seguido por update-initramfs -uv -k `uname -r`(note backticks around uname), corrigiu (finalmente). Para mim, enfim, YMMV.
Tendo o Raspberry Pi 3, adicionando o rootdelay=5ao /boot/cmdline.txtresolveu esse problema para mim.
O crédito vai aqui .
update-initramfs -u