mdadm Boot Error, démarrage incrémental d'une matrice de disques durs Ubuntu SErver 14.04

J'ai eu la même chose. Dans mon environnement : 2 disques durs SAS configurés en raid10.

Le problème était que mpt2sas.ko n'a pas été chargé, et donc mdadm ne pouvait pas voir de disque. Ceci était à son tour causé par une erreur d'empaquetage : quand apt supprimait les paquets wlan inutiles comme crda, il supprimait aussi automatiquement le paquet linux-image-extra-$VERSION qui possède en fait mpt2sas.ko .

Pour s'assurer que le module est chargé avant les modules de raid, j'ai également fait un fichier de type

echo mpt2sas >>/etc/initramfs-tools/modules

Sur ma machine (Ubuntu trusty), cela a été causé par un noyau plus récent (xenial 4.4.0 -series) installé sous /boot et utilisé par défaut.

J'ai résolu ce problème en démarrant une ancienne version du noyau puis en l'exécutant :

update-initramfs -u
update-grub

A finalement "réparé" l'erreur. Version courte : Le Transcend SSD (TS128GSSD25S-M) en combinaison avec la carte mère ASRock B85M Pro4 a causé l'erreur. Après avoir cloné le système avec clonezilla sur un Samsung 840 Evo, j'ai démarré 30 fois sans problème.

dans le rapport sur les problèmes profonds : Mais pourquoi mdadm s'affiche-t-il avec des problèmes de raid array sans aucun rapport ? Et bien lors de la création du Raid Array (ou peut-être par défaut ? je ne sais pas exactement) mdadm met un raid initialization script dans le initramfs. Ce script vérifie si le rootfs est monté, si le rootfs (sur mon SSD) n'est pas monté, il saute à la fonction mountroot_fail.

message "Incrementally starting RAID arrays..."
if mdadm --incremental --run --scan; then
message "Incrementally started RAID arrays."
return 0

Cela conduit à une sortie confuse. Après avoir supprimé ces scripts d'initramfs, je suis tombé sur le vrai problème :

J'ai abandonné l'idée de chercher un appareil à racines. Problèmes communs :

• Arguments de démarrage (cat /proc/cmdline)
  • check rootdelay= (le système a-t-il attendu assez longtemps ?)
  • check root= (le système a-t-il attendu le bon périphérique ?)

• modules manquants (cat /proc/modules ; ls /dev)

  ALERT! /dev/disk/by-uuid/01234567-89ab-cdef-0123-456789abcdef does not exist. Dropping to a shell!
  BusyBox v1.13.3 (Ubuntu 1:1.13.3-1ubuntu11) built-in shell (ash)
  Enter 'help' for a list of built-in commands.
  (initramfs) 

Comme l'erreur n'est pas persistante, j'ai pensé à essayer un autre SSD, et BAM, ça marche.

Pour moi, la solution était l'absence des entrées "dm-mod", "dm-snapshot" et "dm-mirror" dans /etc/initramfs-tools/modules. Il m'a fallu un certain temps pour résoudre ce problème car les messages d'erreur parlaient de "mdadm" et de raid - alors comment deviner que lvm est le problème.

Mon installation : sda -> sda1 (0xfd linux raid autodetect, 500MB), sda2 (0xfd linux raid autodetect, 250G) même chose pour sdb

• sda1 + sdb1 --> /dev/md0 (mdadm) "/boot"
• sda2 + sdb2 --> /dev/md1 (mdadm) --> lvm volume for "swap" and "/"

Je n'ai pas mis "/boot" dans le LVM pour éviter le casse-tête avec Grub/lvm en premier lieu. Mais il semble que je sois tombé dans une autre fosse de Grub/lvm/raid :(

Je suppose que le problème était que Grub montait correctement les initramfs et ensuite il ne pouvait pas monter / (à cause de modules lvm manquants) il a essayé d'initialiser certains périphériques raid.

El incrementally starting raid arrays est quelque peu trompeur car il peut s'agir de n'importe quel module manquant qui inhibe / de se faire monter. Voir également le message ci-dessus concernant l'absence de mpt2sas module.

De plus, je pensais que le dm_ Les modules n'étaient pas nécessaires car ils le sont pour dmraid - ce qui est faux : ils sont aussi nécessaires pour LVM. Dans ma situation, j'ai basculé de dmraid vers le bon vieux mdadm parce que dmraid (fakeraid) a causé des problèmes (un répertoire a disparu).

Et enfin, je me suis demandé si je pouvais ajouter dm-mod , dm-snapshot and dm-mirror to /etc/modules and /etc/initramfs-tools/modules altough there are not really and Les fichiers .ko` de ce nom. Ce doit être une sorte d'alias de module.

Dans mon cas, j'utilisais un noyau 3.x et j'ai été mis à jour vers 4.4.x. Le démarrage du noyau 3.x a réglé le problème et j'ai depuis supprimé le 4.4, il y a certainement quelque chose d'incompatible ou un problème avec l'initramfs qui l'accompagne.