Come mdvengono assemblati i dispositivi all'avvio in Ubuntu? È /etc/mdadm/mdadm.confdavvero il fattore rilevante qui?

Il mio mdadm.confè suono e l'ho verificato mentre ero nell'ambiente del CD di ripristino. Durante l'esecuzione mdadm -A --scantrova e assegna i nomi dei dispositivi come desiderato. Il mdadm.confcontiene AUTO -allper eliminare tutto l'automatismo dall'assemblaggio delle matrici.

Quello che devo fare è essere in grado di assemblare automaticamente i mddispositivi come indicato mdadm.confal momento dell'avvio o che durante l'assemblaggio onora il super-minorvalore per l'array 0.9 e name(apparentemente <hostname>:<super-minor>) per gli array 1.2 e fa la cosa giusta senza mdadm.conf. Quale pezzo del puzzle mi manca?

Ho il seguente problema. Esistono due mddispositivi con RAID1 ( md0e md1) e uno con RAID6 ( md2). Mi riferisco a loro con i nomi dei dispositivi desiderati . md0ha meta-data versione 0.9, le altre due hanno versione 1.2. md0le mappe /e le altre due non sono rilevanti per l' avvio .

L'unità di avvio è GPT partizionata. C'è una colla "BIOS Boot Partition" ( sda1) su di essa. grub-install --no-floppy /dev/sdariporta il successo.

• md0 == sda3 + sdb3
• md1 == sda2 + sdb2
• md2 == sdc + sdd + sde + sdf + sdg + sdh
• sda1e sdb1sono "BIOS Boot Partition" ciascuna

GRUB2 è felice con l' /boot/grub/devicemapho dato e ho aggiunto part_gpt, raid, mdraid09e ext2ai moduli di precarico in GRUB2.

Dato che avevo ancora il mio volume di root nell'ambiente di salvataggio, ho semplicemente montato tutto e poi chrootinserito in esso:

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

Da lì ho resettato super-minoron md0(con meta-data 0.9) e nameon md1e md2. Ho anche verificato che funzionava con mdadm --detail .... A parte questo, mi sono adattato /etc/default/grub, corro update-grube anche grub-install --no-floppy /dev/sdae grub-install --no-floppy /dev/sdb.

Dopodiché, all'avvio, vengo sempre rilasciato nella initramfsshell di salvataggio, perché non è stato possibile montare il file system di root. Il motivo, dopo aver verificato, /proc/mdstatsembra essere che il rispettivo mddispositivo non viene nemmeno assemblato e avviato. Per non parlare del fatto che le altre due unità (versione 1.2 dei metadati) ricevono un numero di dispositivo da qualche parte nell'intervallo 125..127.

Nota: GRUB2 proviene dal disco di avvio. Quindi almeno è stato incorporato correttamente. Il problema è la transizione dal rootfsfile system radice iniziale al file radice corretto.

Processo di avvio di base

larva

1. Grub legge il suo codice disco, md, filesystem, ecc. Dall'MBR.
2. Grub trova la sua partizione / boot e ne legge il resto. Inclusa la configurazione e tutti i moduli specificati nella configurazione devono essere caricati.
3. Grub segue le istruzioni nella configurazione, che in genere gli dicono di caricare un kernel e initramfs in memoria ed eseguire il kernel.

Esiste una modalità di fallback, perché quando Grub non è in grado di leggere il filesystem, sia perché non c'era abbastanza spazio per incorporare tutto quel codice nel record di avvio, sia perché non conosce il filesystem o i livelli sottostanti. In questo caso, GRUB incorpora un elenco di settori e legge il codice da essi. Questo è molto meno robusto e meglio evitato. Potrebbe anche essere in grado di eseguire kernel e initramfs in questo modo (non sono sicuro).

nocciolo

Il kernel prende quindi il controllo e fa molti init hardware di base. Questa fase è abbastanza veloce. Successivamente, il kernel decomprime initramfs in un tmpfs e cerca un /initsu quel tmpfs. Quindi viene eseguito (in senso normale, il kernel sta eseguendo il fulling a questo punto) /init. Questo è, tra l'altro, un semplice vecchio script shell.

initramfs

Puoi estrarre gli initramfs a mano facendo qualcosa di simile mkdir /tmp/foo; cd /tmp/foo; zcat /boot/initrd.img-3.8-trunk-amd64 | cpio -idmv.

Initramfs è responsabile del caricamento di tutti i driver, dell'avvio di udev e della ricerca del filesystem di root. Questo è il passo che fallisce per te: non riesce a trovare il filesystem di root, quindi si salva.

Una volta terminato initramfs, ha montato il filesystem di root e passa il controllo a / sbin / init.

Avvio del sistema

A questo punto, il tuo init prende il sopravvento: penso che Ubuntu stia usando upstart al momento.

Cosa è rotto

Non sono del tutto sicuro di ciò che è rotto (parte, lo confesso, perché ho molta più familiarità con come funziona su Debian di Ubuntu, sebbene sia simile), ma ho un paio di suggerimenti:

• Initramfs ha una sua copia di mdadm.conf. Potrebbe essere necessario eseguire solo update-initramfs -uper risolverlo.
• Guarda i messaggi di avvio. Potrebbe esserci un errore. Sbarazzarsi di "quiet" e "splash" e forse aggiungere "verbose" alla riga del kernel per vederli effettivamente.
• A seconda della memoria utilizzata, potrebbe essere necessario impostare il parametro rootdelay.
• Quando vieni scaricato al prompt della shell, non hai molti comandi, ma hai mdadm. Prova a capire cosa è andato storto. Se risolvi il problema, l'avvio può continuare.

Ok, ho scoperto che mi mancava semplicemente un pezzo. Le initrdimmagini non erano state aggiornate dopo aver armeggiato mdadm.conf.

Quindi cosa ho fatto?

Ho avviato il sistema di ripristino del CD di installazione di Ubuntu Server. Scegliere di eseguire una shell dall'ambiente di installazione e di non utilizzare un file system di root. Quindi (commenti anteposti a #):

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

Sto usando nanoperché vimmi ha causato mal di testa a causa del terminale stupido, letteralmente. Puoi usare Ctrl+ xper uscire (ti chiederà di salvare, Ctrl+ kper tagliare la linea corrente, Ctrl+ uper incollare una linea di taglio, Ctrl+ oper salvare il buffer.

Sembra complicato, ma può essere fatto anche con un bashsolo strato (anche se lungo):

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

Questo utilizza i nomi correnti dei mddispositivi e i loro UUID e crea un devicemapperus per GRUB2. Quindi supponendo che quanto sopra sia stato eseguito correttamente, dovresti già avere i nomi di dispositivo corretti.

Più avanti:

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

Assicurati che contenga:

GRUB_PRELOAD_MODULES="part_gpt raid mdraid09 ext2"

se hai configurato la tua /o la tua /bootpartizione come meta-data versione 1.2, usa mdraid1xinvece di mdraid09.

Ulteriore:

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

Questo passaggio precedente era il collegamento mancante . Questo apparentemente si assicura che abbia mdadm.confeffetto all'avvio.

# 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

Dopo di ciò, lasciare il chroote riavviare.