¿Cómo mdse ensamblan los dispositivos durante el arranque en Ubuntu? ¿Es /etc/mdadm/mdadm.confrealmente el factor relevante aquí?

Mi mdadm.confsonido es y lo comprobé mientras estaba en el entorno del CD de rescate. Al ejecutarlo mdadm -A --scan, encuentra y asigna los nombres de los dispositivos según lo deseado. El mdadm.confcontiene AUTO -alla sacar todo el automatismo de montaje de las matrices.

Lo que necesito hacer es poder ensamblar automáticamente los mddispositivos como se describe en mdadm.confel momento del arranque o que al ensamblar respeta el super-minorvalor de la matriz 0.9 y name(aparentemente <hostname>:<super-minor>) para las matrices 1.2 y hace lo correcto sin él mdadm.conf. ¿Qué pieza del rompecabezas me estoy perdiendo?

Tengo el siguiente problema. Hay dos mddispositivos con RAID1 ( md0y md1) y uno con RAID6 ( md2). Me refiero a ellos por los nombres de dispositivo deseados . md0tiene metadatos versión 0.9, los otros dos tienen versión 1.2. md0los mapas /y los otros dos no son relevantes para el arranque .

La unidad de arranque tiene particiones GPT. Hay un pegamento "BIOS Boot Partition" ( sda1) en él. grub-install --no-floppy /dev/sdainforma de éxito.

• md0 == sda3 + sdb3
• md1 == sda2 + sdb2
• md2 == sdc + sdd + sde + sdf + sdg + sdh
• sda1y sdb1son "BIOS Boot Partition" cada uno

GRUB2 está contento con el /boot/grub/devicemaplo di y añadí part_gpt, raid, mdraid09y ext2a los módulos de precarga en GRUB2.

Como todavía tenía mi volumen raíz en el entorno de rescate, simplemente monté todo y luego lo chrootedité:

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

Desde allí reinicio el super-minorencendido md0(con metadatos 0.9) y el nameencendido md1y md2. También verifiqué que funcionó usando mdadm --detail .... Aparte de eso, ajusté /etc/default/grub, corrí update-gruby también grub-install --no-floppy /dev/sday grub-install --no-floppy /dev/sdb.

Después de eso, al arrancar, siempre me dejo caer en el initramfsshell de rescate, porque el sistema de archivos raíz no se pudo montar. La razón, después de verificar, /proc/mdstatparece ser que el mddispositivo respectivo ni siquiera se ensambla y ejecuta. Sin mencionar que las otras dos unidades (metadatos versión 1.2) reciben un número de dispositivo en algún lugar en el rango de 125..127.

Nota: GRUB2 sale del disco de arranque. Por lo menos, se ha incrustado correctamente. El problema es la transición del rootfssistema de archivos raíz inicial al correcto.

Proceso básico de arranque

Comida

1. Grub lee su código de disco, md, sistema de archivos, etc. del MBR.
2. Grub encuentra su partición / boot y lee el resto de sí misma. Incluyendo la configuración, y cualquier módulo que la configuración especifique necesita cargarse.
3. Grub sigue las instrucciones en la configuración, que generalmente le indican que cargue un núcleo e initramfs en la memoria y ejecute el núcleo.

Hay un modo alternativo, para cuando Grub no puede leer el sistema de archivos, ya sea porque no había suficiente espacio para incrustar todo ese código en el registro de arranque, o porque no conoce el sistema de archivos o las capas debajo de él. En este caso, GRUB incorpora una lista de sectores y lee el código de ellos. Esto es mucho menos robusto y es mejor evitarlo. Incluso puede hacer kernel e initramfs de esa manera (no estoy seguro).

Núcleo

El kernel luego toma el control y realiza una gran cantidad de hardware básico init. Esta etapa es bastante rápida. A continuación, el núcleo desempaqueta initramfs a tmpfs y busca un /inittmpfs en ese. Luego se ejecuta (en el sentido normal, el núcleo se está ejecutando por completo en este punto) /init. Este es, por cierto, un antiguo script de shell.

Initramfs

Puede extraer los initramfs a mano haciendo algo como mkdir /tmp/foo; cd /tmp/foo; zcat /boot/initrd.img-3.8-trunk-amd64 | cpio -idmv.

Initramfs es responsable de cargar todos los controladores, iniciar udev y encontrar el sistema de archivos raíz. Este es el paso que le está fallando: no puede encontrar el sistema de archivos raíz, por lo que se rescata.

Una vez que el initramfs ha finalizado, tiene el sistema de archivos raíz montado y entrega el control a / sbin / init.

Sistema de arranque

En este punto, su init se hace cargo: creo que Ubuntu está usando el sistema de arranque actualmente.

Que esta roto

No estoy completamente seguro de lo que está roto (parte, lo confieso, porque estoy mucho más familiarizado con Debian que Ubuntu, aunque es similar), pero tengo un par de sugerencias:

• El initramfs tiene su propia copia de mdadm.conf. Es posible que solo necesite ejecutar update-initramfs -upara solucionarlo.
• Mira los mensajes de arranque. Puede haber un error. Deshágase de 'quiet' y 'splash' y quizás agregue 'verbose' a su línea de kernel para verlos realmente.
• Dependiendo del almacenamiento utilizado, es posible que deba establecer el parámetro rootdelay.
• Cuando te vuelven al indicador de comandos de shell, no tienes muchos comandos, pero tienes mdadm. Intenta descubrir qué salió mal. Si soluciona el problema, el arranque puede continuar.

De acuerdo, descubrí que me faltaba simplemente una pieza. Las initrdimágenes no habían sido actualizadas después de jugar mdadm.conf.

¿Entonces qué hice?

Arranqué en el sistema de rescate del CD de instalación del servidor Ubuntu. Elija ejecutar un shell desde el entorno del instalador y no usar un sistema de archivos raíz. Luego (comentarios precedidos por #):

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

Estoy usando nanoporque vimme causó dolores de cabeza debido a la terminal tonta, literalmente. Puede usar Ctrl+ xpara salir (se le pedirá que guarde, Ctrl+ kpara cortar la línea actual, Ctrl+ upara pegar una línea de corte, Ctrl+ opara guardar el búfer.

Esto suena complicado, pero se puede hacer también con una bashsola línea (aunque sea larga):

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

Esto utiliza los nombres actuales de los mddispositivos y sus UUID y crea una devicemaplectura de GRUB2. Asumiendo que lo anterior se hizo correctamente, ya debería tener los nombres de dispositivo correctos.

Más allá:

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

Asegúrese de que contenga:

GRUB_PRELOAD_MODULES="part_gpt raid mdraid09 ext2"

si ha configurado su /o /bootpartición para ser metadatos versión 1.2, use en mdraid1xlugar de mdraid09.

Más lejos:

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

Este paso anterior era el eslabón perdido . Aparentemente, esto se asegura de que mdadm.conftenga efecto en el arranque.

# 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

Después de eso, deje el chrooty reinicie.