8

Comment les mdappareils sont-ils assemblés au démarrage dans Ubuntu? Est-ce /etc/mdadm/mdadm.confvraiment le facteur pertinent ici?

Mon mdadm.confest sain et je l'ai vérifié pendant que j'étais dans l'environnement du CD de secours. Lors de l'exécution, mdadm -A --scanil trouve et attribue les noms de périphérique comme vous le souhaitez. Le mdadm.confcontient AUTO -allpour supprimer tout automatisme de l'assemblage des tableaux.

Ce que je dois faire est de pouvoir assembler automatiquement les mdpériphériques comme indiqué mdadm.confau moment du démarrage ou que lors de l'assemblage, il honore la super-minorvaleur du tableau 0.9 et name(apparemment <hostname>:<super-minor>) pour les tableaux 1.2 et fait la bonne chose sans mdadm.conf. Quelle pièce de puzzle me manque?

J'ai le problème suivant. Il y a deux mdpériphériques avec RAID1 ( md0et md1) et un avec RAID6 ( md2). Je me réfère à eux par les noms d'appareils désirés . md0a la version 0.9 des métadonnées, les deux autres ont la version 1.2. md0les cartes vers /et les deux autres ne sont pas pertinentes pour le démarrage .

Le lecteur de démarrage est partitionné GPT. Il y a une colle "BIOS Boot Partition" ( sda1) dessus. grub-install --no-floppy /dev/sdasignale le succès.

md0 == sda3 + sdb3
md1 == sda2 + sdb2
md2 == sdc + sdd + sde + sdf + sdg + sdh
sda1et sdb1sont "BIOS Boot Partition" chacun

GRUB2 est heureux avec le /boot/grub/devicemapje lui ai donné et j'ajouté part_gpt, raid, mdraid09et ext2aux modules de pré - charge dans GRUB2.

Étant donné que j'avais toujours mon volume racine dans l'environnement de sauvetage, j'ai simplement tout monté, puis je l'ai chrootédité:

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à, j'ai réinitialisé le super-minoron md0(avec les métadonnées 0.9) et le nameon md1et md2. J'ai également vérifié que cela fonctionnait en utilisant mdadm --detail .... A part ça, j'ai ajusté /etc/default/grub, couru update-grubet aussi grub-install --no-floppy /dev/sdaet grub-install --no-floppy /dev/sdb.

Après cela, au démarrage, je suis toujours tombé dans le initramfsshell de sauvetage, car le système de fichiers racine n'a pas pu être monté. La raison, après vérification /proc/mdstatsemble être que l' mdappareil respectif n'est même pas assemblé et exécuté. Sans oublier que les deux autres disques (méta-données version 1.2) reçoivent un numéro de périphérique quelque part dans la plage 125..127.

Remarque: GRUB2 provient du disque de démarrage. Donc, au moins, il a été correctement intégré. Le problème est la transition du rootfssystème de fichiers racine initial vers le système racine approprié.

— 0xC0000022L
source

1

N'utilisez pas /dev/mdXexactement pour cette raison. Utilisez /dev/md/NAMEplutôt. Cela ne changera jamais.

— Patrick

@Patrick: Je ne comprends pas ce que vous essayez de dire. Le problème n'est pas les noms en soi. C'est plus ou moins cosmétique. Le problème était que le volume racine ne serait pas assemblé, donc pas disponible pour le démarrage et donc je ne pouvais pas démarrer. J'utilise des UUID pour indiquer à GRUB2 quel appareil est lequel et j'utilise des UUID /etc/fstab. La configuration ne repose pas sur les noms, je voudrais toujours qu'ils soient comme ça;)

— 0xC0000022L

J'aurais dû clarifier. Cela n'a été conseillé que comme résolution de votre commentaire Not to mention that the other two (meta-data version 1.2) drives receive a device number somewhere in the 125..127 range. Je ne sais pas assez comment ubuntu assemble les volumes de raid pour répondre au plus gros problème.

— Patrick

17

Processus de démarrage de base

Ver

Grub lit son disque, md, système de fichiers, etc. dans le MBR.
Grub trouve sa partition / boot et en lit le reste. Y compris la configuration et tous les modules que la configuration spécifie doivent être chargés.
Grub suit les instructions de la configuration, qui lui indiquent généralement de charger un noyau et des initramfs en mémoire et d'exécuter le noyau.

Il existe un mode de repli, lorsque Grub ne peut pas réellement lire le système de fichiers, soit parce qu'il n'y avait pas assez d'espace pour incorporer tout ce code dans l'enregistrement de démarrage, soit parce qu'il ne connaît pas le système de fichiers ou les couches sous-jacentes. Dans ce cas, GRUB incorpore une liste de secteurs et leur lit le code. C'est beaucoup moins robuste et mieux vaut éviter. Il peut même être capable de faire du noyau et des initramfs comme ça (pas sûr).

Noyau

Le noyau prend alors le contrôle et fait beaucoup d'init de matériel de base. Cette étape est assez rapide. Ensuite, le noyau décompresse les initramfs dans un tmpfs et recherche un /initsur ce tmpfs. Il s'exécute ensuite (dans le sens normal du terme, le noyau est en cours d'exécution) /init. Il s'agit, en passant, d'un vieux script shell simple.

Initramfs

Vous pouvez extraire les initramfs à la main en faisant quelque chose comme mkdir /tmp/foo; cd /tmp/foo; zcat /boot/initrd.img-3.8-trunk-amd64 | cpio -idmv.

L'initramfs est responsable du chargement de tous les pilotes, du démarrage d'udev et de la recherche du système de fichiers racine. C'est l'étape qui échoue pour vous - il ne peut pas trouver le système de fichiers racine, donc il se libère.

Une fois initramfs terminé, le système de fichiers racine est monté et passe le contrôle à / sbin / init.

Démarrage du système

À ce stade, votre init prend le relais - je pense qu'Ubuntu utilise actuellement upstart.

Qu'est-ce qui est cassé

Je ne suis pas tout à fait sûr de ce qui est cassé (en partie, je l'avoue, car je suis beaucoup plus familier avec son fonctionnement sur Debian qu'Ubuntu, bien que son similaire), mais j'ai quelques suggestions:

Les initramfs ont leur propre copie de mdadm.conf. Vous devrez peut-être simplement exécuter update-initramfs -upour le réparer.
Regardez les messages de démarrage. Il peut y avoir une erreur. Débarrassez-vous de «silencieux» et de «éclaboussures» et ajoutez peut-être «verbeux» à votre ligne de noyau pour les voir réellement.
Selon le stockage utilisé, vous devrez peut-être définir le paramètre rootdelay.
Lorsque vous êtes transféré à l'invite du shell, vous n'avez pas beaucoup de commandes, mais vous avez mdadm. Essayez de comprendre ce qui n'a pas fonctionné. Si vous résolvez le problème, le démarrage peut continuer.

— derobert
source

2

votre première suggestion était parfaite. Votre réponse est arrivée pendant que j'écrivais la mienne. Merci d'avoir pris le temps de répondre. Très appréciée. Je pense que votre question fournit des informations supplémentaires. +1 plus accepter.

— 0xC0000022L

2

D'accord, j'ai découvert qu'il me manquait simplement une pièce. Les initrdimages n'avaient pas été mises à jour après avoir bricolé mdadm.conf.

Alors qu'est-ce que j'ai fait?

J'ai démarré dans le système de secours du CD d'installation d'Ubuntu Server. Choisissez d'exécuter un shell à partir de l'environnement d'installation et de ne pas utiliser de système de fichiers racine. Ensuite (commentaires précédés de #):

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

J'utilise nanoparce vimque ça m'a causé des maux de tête à cause du terminal stupide, littéralement. Vous pouvez utiliser Ctrl+ xpour quitter (vous invite à enregistrer, Ctrl+ kpour couper la ligne actuelle, Ctrl+ upour coller une ligne de coupe, Ctrl+ opour enregistrer le tampon.

Cela semble compliqué, mais peut aussi être fait avec une bashdoublure (quoique longue):

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

Cela utilise les noms actuels des mdpériphériques et leurs UUID et crée un devicemappour la lecture de GRUB2. Donc, en supposant que ce qui précède a été fait correctement, vous devriez déjà avoir les noms de périphérique corrects.

Plus loin:

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

Assurez-vous qu'il contient:

GRUB_PRELOAD_MODULES="part_gpt raid mdraid09 ext2"

si vous avez configuré votre partition /ou /bootpour qu'elle soit la version 1.2 des métadonnées, utilisez mdraid1xplutôt que mdraid09.

Plus loin:

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

Cette étape ci-dessus était le lien manquant . Cela garantit apparemment que le mdadm.confprend effet au démarrage.

# 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

Après cela, quittez le chrootet redémarrez.