Avertissement mdadm (système non initialisable) de update-initramfs, le correctif suggéré par mkconf semble incompatible avec la description du problème faite par mdadm
Résumé: update-initramfs indique que le système ne démarre pas, le message pointe vers mkconf, ce qui suggère de réécrire dans mdadm.conf, ce qui semblerait anéantir le système RAID (pour le moment), mais le prochain redémarrage pourrait le tuer, mais comment procéder, mdadm.conf bon mais que me dit l'avertissement update-initramfs? et pourquoi mkconf semble-t-il suggérer quelque chose de mauvais?
J'ai un serveur dédié sur 1and1.com exécutant Ubuntu 12.04 et "update-initramfs -u" signale un message d'erreur mdadm indiquant que le serveur ne redémarre pas correctement. J'ai consulté les fichiers de configuration pertinents et je n'ai pas pu identifier le problème. Je n'ai pas essayé de redémarrer depuis que j'ai vu ce message, parce que je ne veux pas "voir ce qui se passe" sur un serveur auquel je ne peux pas accéder physiquement (et peut-être même rendre le diagnostic encore plus difficile si je perdais l'accès à un système en cours d'exécution Je peux essayer de comprendre le message d’erreur et la configuration du système, jusqu’à ce que je sois certain qu’un redémarrage est susceptible de réussir.
Premièrement, le message d'erreur (de update-initramfs -u):
W: mdadm: the array /dev/md3 with UUID dffcb503:bc157198:3fb6082e:e5593158
W: mdadm: is currently active, but it is not listed in mdadm.conf. if
W: mdadm: it is needed for boot, then YOUR SYSTEM IS NOW UNBOOTABLE!
W: mdadm: please inspect the output of /usr/share/mdadm/mkconf, compare
W: mdadm: it to /etc/mdadm/mdadm.conf, and make the necessary changes.
W: mdadm: the array /dev/md1 with UUID a46d442b:4e5b8a52:3fb6082e:e5593158
W: mdadm: is currently active, but it is not listed in mdadm.conf. if
W: mdadm: it is needed for boot, then YOUR SYSTEM IS NOW UNBOOTABLE!
W: mdadm: please inspect the output of /usr/share/mdadm/mkconf, compare
W: mdadm: it to /etc/mdadm/mdadm.conf, and make the necessary changes.
Je me concentre ci-dessous sur md1 car c'est là que/boot est situé (donc "nécessaire pour le démarrage" === TRUE), mais le même message d'erreur est également généré pour md3.
La structure md provient de l'image Ubuntu par défaut du fournisseur de services Internet, cette partie du système n'a pas été touchée. Le seul changement apporté à la structure disque/partition consistait à augmenter la taille des disques logiques (lvextend et resize2fs), ce qui (bien que cela puisse affecter d'autres choses) ne semblerait pas affecter "/" (sur md1) et sa capacité à démarrer.
cat/etc/fstab
/dev/md1 / ext3 defaults 1 1
/dev/sda2 none swap sw
/dev/sdb2 none swap sw
/dev/vg00/usr /usr ext4 errors=remount-ro 0 2
/dev/vg00/var /var ext4 errors=remount-ro 0 2
/dev/vg00/home /home ext4 errors=remount-ro 0 2
proc/proc proc nodev, noexec, nosuid 0 0
Nous pouvons voir que le système md fonctionne correctement, avec md1 sur sda1 et sdb1:
cat /proc/mdstat
-----
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md1 : active raid1 sdb1[1] sda1[0]
4194240 blocks [2/2] [UU]
md3 : active raid1 sdb3[0] sda3[1]
1458846016 blocks [2/2] [UU]
Il semble que ces md soient définis dans les lignes ARRAY du fichier mdadm.conf:
cat /etc/mdadm/mdadm.conf
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#
# by default, scan all partitions (/proc/partitions) for MD superblocks.
# alternatively, specify devices to scan, using wildcards if desired.
DEVICE partitions
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes
# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
# instruct the monitoring daemon where to send mail alerts
MAILADDR root
# definitions of existing MD arrays
# This file was auto-generated on Tue, 11 May 2010 20:53:30 +0200
# by mkconf $Id$
ARRAY /dev/md1 level=raid1 num-devices=2 devices=/dev/sda1,/dev/sdb1
ARRAY /dev/md3 level=raid1 num-devices=2 devices=/dev/sda3,/dev/sdb3
Le plus récent initrd dans/boot est initrd.img-3.2.0-37-generic, et mdadm.conf mis en cache y apparaît identique (vérifié via "gunzip -c /boot/initrd.img-3.2.0-37-generic | cpio -i --quiet --to-stdout etc/mdadm/mdadm.conf ")
Donc, la situation actuelle (les md en cours d’exécution et leur définition pour le démarrage) me convient parfaitement. Pour revenir au message d'erreur "update-initramfs -u", il est suggéré de comparer le fichier mdadm.conf au résultat de/usr/share/mdadm/mkconf. C'est là que nous commençons à voir quelque chose qui semble vraiment différent:
/ usr/share/mdadm/mkconf
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#
# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions
# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes
# automatically tag new arrays as belonging to the local system
HOMEHOST <system>
# instruct the monitoring daemon where to send mail alerts
MAILADDR root
# definitions of existing MD arrays
Si je lis ceci correctement, la réécriture proposée par le système de mdadm.conf (pour corriger le fait que md1 et md3 sont "actuellement actifs, mais ... ne figurant pas dans mdadm.conf") supprimerait l'inscription de md1 et md3 dans mdadm .conf. Je ne peux donc pas concilier le message d'erreur et le correctif proposé (changez mdadm.conf pour qu'il passe de non répertorié à répertorié, mais que le correctif proposé passe de répertorié à non répertorié?) Mon incapacité à (1) rechercher un problème réel et ( 2) réconcilier le message d'erreur avec le correctif proposé, me méfie de la sortie de/usr/share/mdadm/mkconf (et du message d'erreur qui me dirige là, de update-initramfs -u). Mais je ne veux pas ignorer le système qui appelle à l'aide, en particulier pour une partie du système qui est si critique. J'espère que l'OS sait quelque chose que je ne connais pas. Et l'expérimentation (redémarrage à distance) est un dernier recours.
Lors de la recherche en ligne d'autres personnes ayant des messages d'erreur similaires, les problèmes associés semblent impliquer que mkconf génère des lignes ARRAY différentes de ce qui se trouve actuellement dans mdadm.conf (et que l'utilisation de la sortie de mkconf est généralement recommandée comme solution aux lignes ARRAY.) Dans ce cas, mkconf ne fournit aucune ligne ARRAY, cette ligne de recherche n’a donc pas conduit à une assistance appropriée. Les commentaires dans mdadm.conf indiquent qu'il recherche les superblocs MD par défaut, donc le fait que le fichier généré ne mentionne pas explicitement md1/md3 est peut-être correct (?) Si mdadm peut extraire ces informations des superblocs. Mais si tel est le cas, pourquoi le message d'erreur indique-t-il que le problème est que md1/md3 n'est pas répertorié et qu'est-ce qui ne va pas dans la configuration actuelle (pourquoi y a-t-il un message d'erreur du tout)? Donc, cette ligne de pensée (essayer de comprendre comment un fichier généré sans ARRAY peut aider) n'a pas fonctionné non plus.
C'est peut-être un mauvais arbre, mais est-ce que les noms de périphérique comme sda1 sont actuellement autorisés dans mdadm.conf sur les lignes ARRAY? Je sais que l’UUID est préférable, l’utilisation de noms de périphériques peut-elle être la cause du message d’erreur? Si tel est le cas, quelles options pourraient fonctionner: (1) aucune modification du fichier mdadm.conf et le fait que le système continue à assembler md1 en fonction des noms de périphériques; (2) utiliser la sortie de mkconf, sans md explicite (pas de nom de périphérique, ni d'UUID), en s'appuyant sur la découverte automatique basée sur les superblocs; (3) trouver les UUID et écrire de nouvelles lignes ARRAY pour mdadm.conf (qui ne seraient ni des valeurs existantes, ni le remplacement proposé par mkconf)?
Comment identifier la cause de ce message d'erreur, qu'est-ce qu'il essaie de me dire?
Informations supplémentaires qui pourraient être utiles:
mdadm --misc --detail/dev/md1
/dev/md1:
Version : 0.90
Creation Time : Sun Feb 24 19:11:59 2013
Raid Level : raid1
Array Size : 4194240 (4.00 GiB 4.29 GB)
Used Dev Size : 4194240 (4.00 GiB 4.29 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 1
Persistence : Superblock is persistent
Update Time : Sun Apr 27 23:39:38 2014
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
UUID : a46d442b:4e5b8a52:3fb6082e:e5593158
Events : 0.122
Number Major Minor RaidDevice State
0 8 1 0 active sync /dev/sda1
1 8 17 1 active sync /dev/sdb1
mdadm --misc --detail/dev/md3
/dev/md3:
Version : 0.90
Creation Time : Sun Feb 24 19:11:59 2013
Raid Level : raid1
Array Size : 1458846016 (1391.26 GiB 1493.86 GB)
Used Dev Size : 1458846016 (1391.26 GiB 1493.86 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 3
Persistence : Superblock is persistent
Update Time : Sun Apr 27 23:43:41 2014
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0
UUID : dffcb503:bc157198:3fb6082e:e5593158
Events : 0.1883
Number Major Minor RaidDevice State
0 8 19 0 active sync /dev/sdb3
1 8 3 1 active sync /dev/sda3
J'ai trouvé une solution ici: http://www.howtoforge.com/forums/showthread.php?t=65066
Obtenez l'UUID de votre tableau en question à l'aide de la commande: mdadm --misc --detail /dev/mdX (où X correspond au numéro du tableau), éditez /etc/mdadm/mdadm.conf et remplacez-les par:
ARRAY /dev/md1 UUID=dffcb503:bc157198:3fb6082e:e5593158
ARRAY /dev/md3 UUID=a46d442b:4e5b8a52:3fb6082e:e5593158
Remplacer mon périphérique/dev/mdX et mon UUID par le vôtre. Je viens de faire cela sur l'un des miens et cela a fonctionné. Je ne publie pas ce message pour vous car vous l'avez probablement résolu il y a bien longtemps, mais pour tous les autres personnes à qui cela est arrivé.