Ubuntu: Como os dispositivos md são montados na inicialização?

Question

Como os dispositivos md são montados na inicialização no Ubuntu? O /etc/mdadm/mdadm.conf é realmente o fator relevante aqui?

Meu mdadm.conf é bom e verifiquei isso enquanto estava no ambiente do CD de resgate. Ao executar mdadm -A --scan , ele localiza e atribui os nomes dos dispositivos conforme desejado. O mdadm.conf contém AUTO -all para remover todo o automatismo da montagem dos arrays.

O que eu preciso fazer é montar automaticamente os dispositivos md conforme descrito em mdadm.conf no momento da inicialização ou que, quando montá-los, honre o valor super-minor para a matriz 0.9 e o name (aparentemente <hostname>:<super-minor> ) para os arrays 1.2 e faz a coisa certa sem mdadm.conf . Que peça de quebra-cabeça eu estou sentindo falta?

Eu tenho o seguinte problema. Existem dois dispositivos md com RAID1 ( md0 e md1 ) e um com RAID6 ( md2 ). Estou me referindo a eles pelos nomes dos dispositivos desejados . md0 tem versão de metadados 0.9, os outros dois têm versão 1.2. md0 mapeia para / e os outros dois não são relevantes para inicializar .

A unidade de inicialização é particionada pela GPT. Há uma cola "BIOS Boot Partition" ( sda1 ) nela. grub-install --no-floppy /dev/sda informa o sucesso.

• md0 == sda3 + sdb3
• md1 == sda2 + sdb2
• md2 == sdc + sdd + sde + sdf + sdg + sdh
• sda1 e sdb1 são "Partição de inicialização do BIOS" cada

O GRUB2 está satisfeito com o /boot/grub/devicemap que dei e eu adicionei part_gpt , raid , mdraid09 e ext2 aos módulos para pré-carregar no GRUB2.

Como ainda tinha meu volume de raiz no ambiente de recuperação, simplesmente montei tudo e, em seguida, chroot ed:

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

De lá eu redefinir o super-minor on md0 (com metadados 0,9) e o name on md1 e md2 . Também verifiquei que funcionava usando mdadm --detail ... . Além disso, ajustei /etc/default/grub , execute update-grub e também grub-install --no-floppy /dev/sda e grub-install --no-floppy /dev/sdb .

Depois disso, ao inicializar, sempre deixo cair no shell initramfs rescue, porque o sistema de arquivos raiz não pôde ser montado. O motivo, após a verificação de /proc/mdstat , parece ser que o respectivo dispositivo md nem sequer é montado e executado. Sem mencionar que as outras duas unidades (meta-dados versão 1.2) recebem um número de dispositivo em algum lugar na faixa de 125 a 128.

Nota: O GRUB2 vem do disco de inicialização. Então, pelo menos, foi incorporado corretamente. O problema é a transição do rootfs inicial para o sistema de arquivos raiz adequado.

    

Answer 1

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 de si mesmo. 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 geralmente dizem para carregar um kernel e initramfs na memória, e executar o kernel.

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

Kernel

O kernel então assume o controle e faz um monte de inicialização básica de hardware. Este estágio é bastante rápido. Em seguida, o kernel descompacta o initramfs para um tmpfs e procura por um /init nesse tmpfs. Em seguida, ele é executado (no sentido normal, o kernel está cheio executando neste momento) /init . Este é, a propósito, um script de shell simples e simples.

Initramfs

Você pode extrair o initramfs manualmente fazendo algo como 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 encontrar o sistema de arquivos raiz. Esta é a etapa que está falhando para você - não é possível encontrar o sistema de arquivos raiz, portanto, ele é liberado.

Uma vez que o initramfs tenha terminado, ele tem o sistema de arquivos root montado e entrega o controle para / sbin / init.

Inicialização do sistema

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

O que está quebrado

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

• O initramfs tem sua própria cópia de mdadm.conf . Você pode precisar executar update-initramfs -u para 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, talvez seja necessário definir o parâmetro rootdelay.
• Quando você é enviado para o prompt do shell, você não tem muitos comandos, mas você tem o mdadm. Tente descobrir o que deu errado. Se você corrigir o problema, a inicialização poderá continuar.

Answer 2

Ok, descobri que estava faltando apenas uma peça. As imagens initrd não foram atualizadas depois de mexer com mdadm.conf .

Então, o que eu fiz?

Eu iniciei no sistema de recuperação do CD de instalação do Ubuntu Server. Escolheu executar um shell do ambiente do instalador e não para usar um sistema de arquivos raiz. Então (comentários prefixados 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

I'm using nano because vim caused me headaches because of the dumb terminal, literally. You can use Ctrl+x to quit (will prompt to save, Ctrl+k to cut the current line, Ctrl+u to paste a cut line, Ctrl+o to save the buffer.

Isso parece complicado, mas pode ser feito também com um bash one-liner (embora um longo):

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 dispositivos md e seus UUIDs e cria um devicemap para a leitura do GRUB2. Portanto, supondo que o acima foi feito corretamente, você deve ter os nomes dos dispositivos corretos já.

Mais adiante:

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

Certifique-se de que contém:

GRUB_PRELOAD_MODULES="part_gpt raid mdraid09 ext2"

se você configurou a partição / ou /boot como metadados versão 1.2, use mdraid1x em vez de mdraid09 .

Além disso:

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

Este passo acima foi o elo perdido . Isso aparentemente garante que o mdadm.conf tenha efeito na 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 chroot e reinicie.