Como os mddispositivos são montados na inicialização no Ubuntu? É /etc/mdadm/mdadm.confrealmente o fator relevante aqui?

Meu mdadm.confsom está correto e eu verifiquei isso enquanto estava no ambiente do CD de resgate. Ao executá- mdadm -A --scanlo, localiza e atribui os nomes dos dispositivos conforme desejado. O mdadm.confcontém AUTO -allpara remover todo o automatismo da montagem das matrizes.

O que eu preciso fazer é ser capaz de montar automaticamente os mddispositivos, conforme descrito no mdadm.confmomento da inicialização ou que, ao montá-lo, honre o super-minorvalor da matriz 0,9 e name(aparentemente <hostname>:<super-minor>) para as matrizes 1,2 e faça a coisa certa sem isso mdadm.conf. Que peça do quebra-cabeça estou perdendo?

Eu tenho o seguinte problema. Existem dois mddispositivos com RAID1 ( md0e md1) e um com RAID6 ( md2). Estou me referindo a eles pelos nomes de dispositivos desejados . md0possui meta-dados versão 0.9, os outros dois têm versão 1.2. md0mapas para /e os outros dois não são relevantes para a inicialização .

A unidade de inicialização é particionada por GPT. Há uma cola "Partição de inicialização do BIOS" ( sda1) nela. grub-install --no-floppy /dev/sdarelata sucesso.

• md0 == sda3 + sdb3
• md1 == sda2 + sdb2
• md2 == sdc + sdd + sde + sdf + sdg + sdh
• sda1e sdb1são "partição de inicialização do BIOS" cada

GRUB2 está feliz com o /boot/grub/devicemapque eu dei e eu adicionei part_gpt, raid, mdraid09e ext2para os módulos pré-carga em GRUB2.

Como ainda tinha meu volume raiz no ambiente de resgate, simplesmente montei tudo e depois chrooteditei:

mkdir /target
mount /dev/md0 /target
mount -o bind /dev /target/dev
mount -o bind /dev/pts /target/dev/pts
mount -o bind /sys /target/sys
mount -o bind /proc /target/proc
chroot /target /bin/bash

A partir daí, redefino o super-minoron md0(com meta-dados 0.9) e nameon md1e md2. Eu também verifiquei que funcionava usando mdadm --detail .... Fora isso eu ajustei /etc/default/grub, corro update-grube também grub-install --no-floppy /dev/sdae grub-install --no-floppy /dev/sdb.

Depois disso, ao inicializar, sempre sou colocado no initramfsshell de resgate, porque o sistema de arquivos raiz não pode ser montado. O motivo, após a verificação, /proc/mdstatparece ser que o respectivo mddispositivo nem mesmo é montado e executado. Sem mencionar que as outras duas unidades (meta-data versão 1.2) recebem um número de dispositivo em algum lugar na faixa 125..127.

Nota: O GRUB2 sai do disco de inicialização. Portanto, pelo menos, foi incorporado corretamente. O problema é a transição do rootfssistema de arquivos raiz inicial para o adequado.

Processo básico de inicialização

Grub

1. O Grub lê seu código de disco, md, sistema de arquivos etc. do MBR.
2. O Grub encontra sua partição / boot e lê o resto dela. Incluindo a configuração e quaisquer módulos que a configuração especifique precisam ser carregados.
3. O Grub segue as instruções na configuração, que normalmente diz para carregar um kernel e initramfs na memória e executar o kernel.

Existe um modo de fallback, pois quando o Grub não consegue realmente ler o sistema de arquivos - porque não havia espaço suficiente para incorporar todo esse código no registro de inicialização ou porque não conhece o sistema de arquivos ou as camadas sob ele. Nesse caso, o GRUB incorpora uma lista de setores e lê o código deles. Isso é muito menos robusto e é melhor evitar. Pode até ser capaz de executar o kernel e o initramfs assim (não tenho certeza).

Núcleo

O kernel assume o controle e executa bastante init básico de hardware. Esta etapa é bastante rápida. Em seguida, o kernel descompacta o initramfs para um tmpfs e procura um /inittmpfs. Em seguida, ele é executado (no sentido normal, o kernel está sendo executado neste momento) /init. A propósito, este é um script shell simples e antigo.

Initramfs

Você pode extrair o initramfs manualmente, fazendo algo parecido mkdir /tmp/foo; cd /tmp/foo; zcat /boot/initrd.img-3.8-trunk-amd64 | cpio -idmv.

O initramfs é responsável por carregar todos os drivers, iniciar o udev e localizar o sistema de arquivos raiz. Este é o passo que está falhando para você - ele não consegue encontrar o sistema de arquivos raiz, por isso é bem-sucedido.

Depois que o initramfs termina, ele tem o sistema de arquivos raiz montado e entrega o controle para / sbin / init.

Inicialização do sistema

Nesse ponto, seu init assume o controle - acho que o Ubuntu está usando o inicio atualmente.

O que está quebrado

Não tenho certeza do que está quebrado (parte, confesso, porque estou muito mais familiarizado com o modo como ele funciona no Debian do que no Ubuntu, embora seja semelhante), mas tenho algumas sugestões:

• O initramfs possui sua própria cópia de mdadm.conf. Você pode precisar executar apenas update-initramfs -upara corrigi-lo.
• Veja as mensagens de inicialização. Pode haver um erro. Livre-se de 'quiet' e 'splash' e talvez adicione 'verbose' à sua linha de kernel para realmente vê-los.
• Dependendo do armazenamento usado, pode ser necessário definir o parâmetro rootdelay.
• Quando você é despejado no prompt do shell, não possui muitos comandos, mas o mdadm. Tente descobrir o que deu errado. Se você corrigir o problema, a inicialização poderá continuar.

Ok, eu descobri que estava faltando apenas uma peça. As initrdimagens não foram atualizadas após a atualização mdadm.conf.

Então o que eu fiz?

Eu iniciei o sistema de resgate do CD de instalação do Ubuntu Server. Optou por executar um shell no ambiente do instalador e não usar um sistema de arquivos raiz. Em seguida (comentários anexados com #):

cat /proc/mdstat
# It showed me md125, md126 and md127
# Stop those:
mdadm -S /dev/md125
mdadm -S /dev/md126
mdadm -S /dev/md127
# Assemble the root volume (meta-data version 0.9)
mdadm -Av --update=super-minor --run /dev/md0 /dev/sda3 /dev/sdb3
# Assemble the other two arrays, updating the names (meta-data version 1.2)
mdadm -Av --update=name --run /dev/md1 /dev/sda2 /dev/sdb2
mdadm -Av --update=name --run /dev/md2 /dev/sdc /dev/sdd /dev/sde /dev/sdf /dev/sdg /dev/sdh
# Check the outcome:
cat /proc/mdstat
# See preferred minor and names:
mdadm --detail /dev/md0
mdadm --detail /dev/md1
mdadm --detail /dev/md2
# All is fine, so proceed ...
# Create directory for the chroot:
mkdir /target
# Mount root volume on it
mount /dev/md0 /target
mount -o bind /dev /target/dev
mount -o bind /proc /target/proc
mount -o bind /sys /target/sys
mount -o bind /dev/pts /target/dev/pts
# Now chroot into it:
chroot /target /bin/bash
# Fix up the GRUB device map to match what 'mdadm --detail' gives as UUID:
nano /boot/grub/devicemap

nano

Estou usando nanoporque vimme causou dores de cabeça por causa do terminal burro, literalmente. Você pode usar Ctrl+ xpara sair (solicitará salvar, Ctrl+ kpara cortar a linha atual, Ctrl+ upara colar uma linha de corte, Ctrl+ opara salvar o buffer.

Isso parece complicado, mas pode ser feito também com uma bashlinha (embora longa):

for i in /dev/disk/by-id/md-uuid-*; do DEV=$(readlink $i); echo "(${DEV##*/}) $i"; done|sort|tee /boot/grub/devicemap

Isso usa os nomes atuais dos mddispositivos e seus UUIDs e cria um devicemappara leitura do GRUB2. Portanto, supondo que o acima foi feito corretamente, você já deve ter os nomes de dispositivos corretos.

Mais para frente:

# Edit the grub config
nano /etc/default/grub

Verifique se ele contém:

GRUB_PRELOAD_MODULES="part_gpt raid mdraid09 ext2"

se você configurou sua partição /ou /bootpara ser a versão 1.2 de metadados, use em mdraid1xvez de mdraid09.

Mais longe:

# Update the initrd images
update-initramfs -c -k all

Esta etapa acima foi o link que faltava . Aparentemente, isso garante que o mdadm.confefeito entre em inicialização.

# Install GRUB2 on the two drives eligible for booting, just to be sure
grub-install --no-floppy /dev/sda
grub-install --no-floppy /dev/sdb
# Make the latest config take effect
update-grub

Depois disso, deixe o chroote reinicie.