Cher Journal,
Si comme moi tu utilises Proxmox et que tu as eu envie de passer du noyau 2.6 au noyau 3.10 fourni par Proxmox Server Solutions GmbH, souviens-toi que c'est en fait un noyau Red Hat qu'ils poussent sur une base Debian.
Ça assure certes une certaine stabilité, mais ça peut aussi mener à ce problème peu compréhensible: lors de ton switch de noyau, après redémarrage, tu te retrouves avec ce message
mdadm: No devices listed in conf file were found
Pour ensuite tomber dans les limbes de initramfs. Depuis la cli de initramfs, tu peux retrouver tes petits, il te suffit de faire:
initramfs> mdamd --auto-detect
initramfs> cat /proc/mdstats
initramfs> return
Pour que ton serveur veuille bien démarrer (et te confirmer que ton RAID logiciel est bien présent).
Pour résoudre le problème, Internet pourrait te faire croire qu'il faudrait ajouter des modules raid1 ou mdraid1x au démarrage de grub ou d'initramfs, mais détrompe-toi. Ton RAID est bien présent et fonctionnel.
Il faut juste accepter le fait que le noyau linux 3.10 est bien plus lourd à démarrer. Il ne faut pas qu'il lance mdadm avant que les disques soient reconnus. Laisse lui un petit délai de 5 secondes, et ça devrait faire l'affaire pour qu'il retrouve ton raid. Ça se passe dans /etc/default/grub, où il faut ajouter rootdelay=5:
[…]
GRUB_CMDLINE_LINUX_DEFAULT="quiet rootdelay=5"
[…]
Un petit update-grub, et ça repart !
# C'est un bug ? ou bien ?
Posté par bobo38 . Évalué à 1.
Ça me paraît bizarre de devoir régler ce type de soucis avec un délai. J'imagine que c'est un workaround pour utiliser cela sans modification.
Désolé pour le langage approximatif, je n'ai jamais trop bricolé de noyau. Ce ne serait pas un soucis de "hook" qu'il s'agirait de déclarer dans l' « environnement qui se chargera en premier en mémoire » ?
https://wiki.archlinux.fr/Mkinitcpio#RAID
Je ne sais pas si ce mkinitcpio est spécifique à Archlinux, et dans quelle mesure cette notion de "hook" est portable pour l'approche de Proxmox Server Solutions GmbH.
[^] # Re: C'est un bug ? ou bien ?
Posté par Coren . Évalué à 4.
Oui, c'est un workaround.
Le bug est connu:
http://www.mail-archive.com/debian-bugs-rc@lists.debian.org/msg153699.html
Et n'est visiblement pas vraiment résolu…
[^] # Re: C'est un bug ? ou bien ?
Posté par bobo38 . Évalué à 2. Dernière modification le 28 septembre 2014 à 12:29.
Whao… 2008 ! Ça parle de Debian Etch et de Lenny, pas mal.
Quoiqu'il en soit tu as bien dû te casser la tête avant de tomber sur ce contournement de bug à base de délai.
# Oh le bug chiant à détecter plus tard...
Posté par Zenitram (site web personnel) . Évalué à 0.
Et donc, tu auras un problème pseudo-aléatoire : suivant l'humeur du noyau (suivant plus ou moins de 5 secondes), tu auras un comportement différent. Le bonheur quand ton successeur ou simplement ton remplaçant pendant tes congés devra se pencher dessus sans savoir ce que tu as fait.
Hot fix, oui, mais juste ça, en attendant de trouver un vrai fix, stable!
(surtout que pour des containers, perdre 5 secondes comme ça si 0.5 suffit, c'est dommage)
Troll : vivement que systemd s'en mèle, pour qu'il donne un ordre chronologique.
[^] # Re: Oh le bug chiant à détecter plus tard...
Posté par claudex . Évalué à 7.
Il peut très bien l'avoir très bien documenté.
On parle de l'hôte là, pas des invités.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Oh le bug chiant à détecter plus tard...
Posté par Anonyme . Évalué à 4.
Ho, tu sais, en entreprise on suit les procédures officielles, on installe pas PVE sur un raid logiciel.
[^] # Re: Oh le bug chiant à détecter plus tard...
Posté par hervé Couvelard . Évalué à -2.
Et c'est un mec qui n'utilise pas linux qui parle… le comble
[^] # [HS] Préjugés
Posté par Zenitram (site web personnel) . Évalué à 0. Dernière modification le 28 septembre 2014 à 16:19.
J'aime bien les préjugés qu'ont certaines personnes. Ah oui, c'est binaire, 0 ou 1, puisqu'une personne parle parfois d'un autre, c'est qu'il n'utilise pas Linux, j'avais oublié!
Ne pas utiliser Linux != ne pas utiliser que Linux.
Et aussi : les principes de maintenance, ça n'a rien à voir avec Linux, ce serait BSD, Mac, Windows ou Hurd, ça serait pareil, donc vraiment aucun rapport.
[^] # Re: [HS] Préjugés
Posté par barmic . Évalué à 3.
Et donc, toi qui n'aime pas les préjugés, qu'est-ce qui t'a fait imaginer qu'il n'avait pas documenté son warkaround en pointant dans sa documentation le bug en question qui donne l'explication du warkaround utilisé ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
# Hmm, et t'aurais pas plutot oublié un truc?
Posté par gnumdk (site web personnel) . Évalué à 5.
Genre générer la conf de mdadm dans /etc? Une fois cela fait, il est intégré dans le initramfs…
Je viens de vérifier sur un serveur proxmox et c'est comme cela que ça fonctionne…
Après, tu peux compter sur la detection auto il est vrai… Mais ca reste du hack dans le initrd de debian parce qu'il me semble que sous arch, sans mdadm.conf, point de boot…
[^] # Re: Hmm, et t'aurais pas plutot oublié un truc?
Posté par Coren . Évalué à 1.
La conf mdadm était bien présente et fonctionnelle. Le raid était déjà là, présent et fonctionnel en kernel 2.6.32.
J'ai cherché pendant très longtemps un problème vis à vis de mdadm, alors qu'il était beaucoup plus basiquement dans initramfs directement.
# Problème Debian
Posté par ChickenKiller . Évalué à 2.
J'ai eu le même problème sous Debian (testing) il y a environ 6 mois en changeant de version de noyau (noyau de base x64, incapable de me rappeler laquelle par contre).
Même solution pour moi.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.