David Madore's WebLog: Comment perdre beaucoup de temps à monter un ordinateur

Une tragédie en cinq actes (qui respecte l'unité de lieu — l'appartement de Ruxor et du pousinet — et d'action — beaucoup d'énervement —, mais certainement pas de temps) :

Acte I. Présentation du nouvel ordinateur

(Scène 1.) Lundi 29 août, j'ai reçu les trois quarts des pièces de mon nouvel ordinateur (la carte mère, la mémoire, et l'alimentation).

(Scène 2.) Mardi 30, j'ai reçu le quatrième quart (le processeur). J'ai ressorti de ma cave un ordinateur qui y traînait, pour en récupérer le boîtier, et j'ai commencé à monter le tout. Mais les difficultés qu'on rencontre ne sont pas toujours celles qu'on croit : j'ai perdu beaucoup de temps, par exemple, parce que je n'avais que six des neuf vis (je ne sais pas comment appeler ça au juste : ce sont des choses qui sont une vis d'un côté et un écrou — enfin trou à vis — de l'autre) qui servent à relier la carte mère à la plaque arrière du boîtier, et il me fallait donc trouver une solution. Finalement, mon poussinet m'a trouvé les trois vis manquantes.

(Scène 3.) Ensuite, j'ai dû comprendre pourquoi la machine ne bootait pas : elle émettait une série de bips (et montrait un code sur son petit panneau lumineux interne) signifiant qu'elle ne trouvait pas de carte graphique. De fait, je n'avais pas mis de carte graphique, mais je pensais que cette carte mère avait un chipset graphique basique[#] intégré puisqu'elle avait des sorties VGA, DVI et HDMI : la vérité est simplement que cette carte mère est prévue pour accepter les processeurs ayant un coprocesseur graphique intégré (ce qui n'est pas le cas du Xeon E3-1230v5 que j'ai acheté). (Scène 4.) Ce malentendu dissipé (ce qui m'a pris un certain temps, quand même), la machine démarre correctement sur une Ubuntu live.

[#] Ce qui ferait sens pour une carte mère destinée à un serveur (lequel a rarement besoin de quelque chose de très performant en la matière, et un chipset graphique intégré sur la carte mère conviendra donc).

Acte II. De petites complications apparaissent

Mon projet était le suivant : monter une configuration minimale, dans le boîtier que j'ai sorti de ma cave, avec ma nouvelle carte mère (plus processeur et mémoire), et un disque dur de récupération, le temps de vérifier que tout fonctionne, et de préparer une configuration de noyau Linux qui marche bien sur ce matériel, et seulement ensuite déplacer les disques (que je garde) vers ce boîtier. Mon poussinet me dit que mon idée était idiote, que j'aurais dû monter directement la nouvelle carte mère dans le boîtier que j'utilisais déjà (et qui contenait les disques, donc), et régler les problèmes au fur et à mesure qu'ils apparaissaient. Mais je savais que ça pouvait être long, et je préférais ne pas me passer d'ordinateur pendant ce temps.

Bref, mardi 30 au soir, j'avais cette configuration minimale qui marchait : comme expliqué à l'acte I, j'avais dû y mettre une carte graphique elle aussi de récupération. Pour afficher la sortie sur ma télé (faute d'autre écran d'ordinateur qui marche), j'avais aussi dû acheter un adaptateur DVI→HDMI. (Scène 1.) Seulement, mercredi 31, je me suis rendu compte que le ventilateur de cette carte graphique de récupération ne tournait pas, et qu'elle surchauffait : j'ai dû acheter une carte graphique premier prix (30€ environ). Heureusement, ce n'est pas encore complètement impossible d'acheter du matériel informatique à Paris, mais j'ai quand même perdu un peu de temps avec ça (et mon adpatateur DVI→HDMI ne me servait finalement à rien, vu que la carte graphique en question a une sortie HDMI contrairement à celle qui traînait dans ma cave).

(Scènes 2 et 3.) Jeudi 1er septembre et samedi 3 (vendredi, j'avais vraiment autre chose à faire), je me suis occupé de préparer mes disques durs à pouvoir démarrer en mode UEFI (parce que la nouvelle carte mère n'a pas de BIOS traditionnel) ; ceci implique de changer le type de table des partitions (vers GPT). J'ai surtout passé mon temps à comprendre ce que tout ceci signifie, et à mettre au point un plan[#2] pour avoir un système qui peut démarrer, indifféremment, sur n'importe quel disque, que ce soit en mode BIOS traditionnel ou en mode UEFI.

Mais là aussi, les difficultés ne sont pas toujours celles qu'on prévoit : j'ai passé un temps fou à comprendre, par exemple, pourquoi la Ubuntu live, que j'utilisais sur mon (ancien) ordinateur pour faire les manipulations, ne voyait[#3] pas mon disque externe (non concerné par les manipulations, mais sur lequel j'avais stocké des données destinées à les aider).

(Scène 4.) En parallèle de tout ça, je peaufine une configuration de noyau Linux prête à tourner proprement sur la nouvelle machine (et qui continue aussi à tourner sur l'ancienne).

[#2] Pour ceux qui veulent plus de détails : j'ai à la fois un Grub dans le MBR et une partition de type 21686148-6449-6e6f-744e-656564454649 (qui sert à démarrer en mode traditionnel), et un autre dans une partition EFI que j'ai créée après être passage en GPT. Une difficulté était que j'utilisais un vieux Grub, qui ne comprend pas les partitions GPT, donc j'ai dû changer sa version en même temps (et comprendre comment le nouveau fonctionne). Par ailleurs, il est heureux que j'aie l'habitude de laisser plein de place inoccupé entre mes partitions, et au début et à la fin du disque, parce que la création de la table des partitions GPT, et aussi de la partition spéciale pour Grub, ont utilisé une partie de cet espace. J'ai donc évité d'avoir à faire des déplacements sur quelques téra-octets de donnés.

[#3] La solution consistait à ajouter modprobe.blacklist=pata_marvell ahci.marvell_enable=1 dans la ligne de commande du noyau Linux, le genre de choses qui font que les non-linuxiens se moquent des linuxiens et de leurs incantations arcanes. J'avais dû trouver ça autrefois quand j'avais commencé à faire fonctionner cette carte mère, mais j'avais complètement oublié depuis, et la réponse était cachée dans la configuration de mon noyau. Non franchement, je me demande pourquoi le module ahci a une option marvell_enable dont le défaut est à 0 : il faut lui dire explicitement de faire fonctionner ce chipset particulier, c'est un peu absurde (il est vrai que ce chipset a cette bizarrerie qu'il peut gérer soit un port SATA soit un port PATA, mais pas les deux à la fois, donc si on active le SATA, ça désactive le PATA et vice versa ; dans mon cas, cependant, le port PATA n'existe même pas, tout ceci est un reliquat d'une époque un peu ancienne).

Acte III. Le coup de tonnerre

(Scène 1.) Nous arrivons donc le dimanche 4 : je vérifie que tout est prêt au niveau logiciel (je supprime, par exemple, dans la configuration du routeur tout ce qui fixe l'adresse MAC de mon PC) ; je vais profiter d'une absence du poussinet (donc d'une possibilité d'étaler mon matériel informatique dans tout le salon) pour déplacer les disques durs.

(Scène 2.) Je sors les disques de l'ancienne machine. L'opération est un peu longue et compliquée (environ une heure), parce qu'il y en a quatre, et surtout parce qu'il y en a un qui est dans un berceau (pour le mettre sur un emplacement 5″¼ et ainsi gagner de l'espace), et pour le faire sortir du boîtier sans taper dans quelque chose, il faut démonter les barrettes de RAM, déconnecter l'alimentation, et jouer à chercher le chemin qui passe sans taper dans quelque chose d'important.

(Scène 3.) Je refais l'opération à l'envers pour monter les disques dans le nouveau boîtier. De nouveau environ une heure passe.

(Scène 4.) Enfin, tout est prêt. J'appuie sur le bouton d'alimentation.

Rien ne se passe.

Je me dis que j'ai dû défaire les connexions entre le bouton et la carte mère en montant les disques. Je vérifie. Pas d'amélioration. Bon, la carte mère a un bouton d'alimentation directement sur la carte (c'est une excellent idée, soit dit en passant, et je félicite Asus de l'avoir eue). J'appuie dessus. Pas mieux.

(Scène 5.) Je commence à paniquer.

C'est peut-être l'alimentation qui est morte : après tout, il ne se passe rien, pas un ventilo qui tourne, même pas celui de l'alim elle-même. (Il y a des LEDs sur la carte mère qui s'allument quand on branche l'alim, mais rien ne change quand on appuie sur le bouton d'alimentation.) Je vérifie avec l'ancienne carte mère et l'ancienne alim : la nouvelle alim parvient à démarrer l'ancienne carte mère, mais l'ancienne alim ne parvient pas non plus à démarrer la nouvelle carte mère. C'est donc bien la carte mère qui est morte.

La carte mère que j'ai reçu il y a moins d'une semaine est donc morte !

(Scène 6.) Dépité, je mets l'ancienne carte mère dans le boîtier où j'ai transféré les disques. Heureusement, elle n'a pas été abîmée par toutes ces opérations. Il n'y a que la pile CMOS qui est morte, rien de grave. (Bilan de la journée : j'ai simplement déplacé tout le contenu de mon ordinateur d'un boîtier à un autre, pour rien.)

Entracte

Qu'est-ce qui a bien pu se passer pour que cette carte mère meure ? Je n'en sais rien. Je sais à ce stade que c'est forcément la carte mère (si c'était le processeur, les ventilateurs au moins démarreraient ; si c'était la mémoire, il y aurait une série de bips ; pour que rien ne se passe, c'est forcément la carte mère qui est morte — peut-être un condensateur défectueux ou abîmé).

Une possibilité : cette carte mère était défectueuse, elle n'aura tenu que deux ou trois allumages (après tout, je ne l'ai que très peu allumée et éteinte, un défaut peut ne pas se manifester tout de suite). Une autre : je l'ai cassée sans m'en rendre compte en montant les disques. Ça pourrait venir d'un choc électrostatique ou d'un choc mécanique. Mais je ne me suis aperçu de rien, mes observations attentives ne m'ont pas permis de trouver le moindre composant d'apparence suspecte, et un choc électrostatique aurait eu plus de chances d'endommager la mémoire (or je sais qu'elle ne l'a pas été).

Acte IV. Vers un dénouement ?

(Scène 1.) Je commande une nouvelle nouvelle carte mère, identique, et je prépare le retour de celle qui est cassée (vus les délais, il semble que les conditions d'Amazon me permettent d'obtenir un remboursement, et je n'ai certainement pas envie d'attendre un retour). Cette fois avec livraison express.

(Scène 2.) Nous sommes maintenant mercredi 7 septembre. Je reçois la (nouvelle nouvelle) carte mère. Je déplace le processeur dessus. Doute : que faut-il faire pour la pâte thermique ? Pour l'installation initiale, le radiateur fourni par Intel venait avec de la pâte thermique préappliquée. Forcément, cette pâte thermique a été chauffée et s'est dispersée. Quand je retire le radiateur pour déplacer le processeur, avant de le remettre en place, est-ce que je dois réappliquer de la pâte thermique ? réétaler celle qui est déjà là ? J'ai choisi d'en rajouter un petit peu, et j'ai passé un temps fou à essayer de faire un niveau bien plat et mince, mais je crois que j'ai quand même un moins bon contact thermique maintenant que lors de la première installation.

(Scène 3.) Je sors l'ancienne carte mère du boîtier, je mets la nouvelle (nouvelle) à la place. Moralité : mon poussinet avait sans doute raison, c'est plus facile et moins risqué de changer une carte mère que de changer quatre disques.

(Scène 4.) Mercredi soir, l'ordinateur démarre correctement sur une Ubuntu live (comme à la fin de l'acte I, quoi…), mais toujours pas sur mes anciens disques, malgré le noyau spécialement prévu pour. Ou plus exactement, elle démarre, mais je n'ai ni clavier, ni souris, ni réseau. J'ai fini par comprendre qu'il fallait charger le module xhci-pci (ceci expliquait que l'USB ne fonctionnait pas), et que j'avais branché le câble Ethernet dans la mauvaise prise réseau. Rien de compliqué à résoudre, mais trouver le problème exact n'a pas été facile (quand on a un ordinateur qui démarre sans périphérique d'entrée et qu'on ne peut débugguer qu'en modifiant les scripts de démarrage, ça prend forcément un certain temps).

(Scène 5.) Enfin, tout semble marcher. La fin de l'histoire ?

Roulement de tambour…

Acte V. Happy end ou pas ?

(Scène 1.) Mon nouvel ordinateur marche, au moins dans les grandes lignes. (Et avoir 32Go de mémoire au lieu de 8Go rend certaines choses beaucoup plus confortables, c'est incontestable.)

Il est maintenant temps de vérifier un peu plus dans les détails, et notamment les choses pour lesquelles j'ai tenu à acheter une carte mère de serveur.

(Scène 2.) La mémoire ECC semble fonctionner. (Elle fonctionne, bien sûr, mais la question est de savoir si elle fonctionne bien en tant que mémoire ECC.) Évidemment, c'est difficile à tester, parce que les erreurs mémoires sont quand même très (très) rares. Je devrais peut-être monter une attaque rowhammer pour tester. Mais au moins, j'ai un utilitaire Linux (edac-util, couplé au module ie31200-edac) qui prétend lire le nombre d'erreurs par barrette, et qui me signale 0 erreurs sur chaque barrette : j'imagine (j'espère) que si la mémoire n'était pas ECC, il renverrait une erreur. Mais j'avoue que j'aimerais voir dans les réglages du BIOS une indication quelconque du fait que la mémoire est en mode ECC, ce qu'il n'y a pas (ou alors, je ne l'ai pas trouvée).

(Scène 3.) Je crois que je suis censé avoir sur cette carte mère une technologie Intel qui, selon la phase de la Lune et l'humeur d'Intel, s'appelle Active Management Technology (AMT) ou Management Engine (ME), ou encore vPro. (En gros, il y a un second processeur sur la carte mère, qui écoute sur le réseau, et sait répondre à des commantes du genre, allumer ou éteindre la machine, la redémarrer, simuler un clavier et un écran par réseau, et quelques choses de ce genre.)

Cette technologie est certainement un trou de sécurité monstrueux, et un cauchemar pour les paranoïaques (genre, il est certain que grâce à elle, la NSA a un back door complet vers ma machine), mais elle présente aussi des fonctions qui pourraient m'intéresser, notamment le fait de redémarrer à distance. Mais je n'ai absolument rien compris à la façon de m'en servir. On doit sans doute pouvoir l'activer depuis le BIOS, mais je n'ai rien trouvé de la sorte. Linux détecte bien un truc (il crée un device /dev/mei quand on charge le module mei-me, et il a l'air de détecter plein de choses), mais je n'ai rien compris à la manière de m'en servir. Il y a du vieux code fourni avec le noyau, qui ne marche pas (il me renvoie ENOTTY, en fait parce qu'il essaie de passer des commandes avec un UUID qui n'est pas bon). Il y a plein de doc chez Intel, mais elles se contredisent, datent de plein d'époques différentes, et finalement je n'y comprends rien.

Je me demande si je ne suis pas censé payer à Intel une licence pour avoir le droit d'administrer ma machine, ce qui est quand même un peu fort de café. Mais bon, je n'ai rien compris. En tout cas, pas compris comment faire quoi que ce soit d'utile de cette technologie (ni même comment l'activer, ou au contraire comment être sûr qu'elle est désactivée).

(Scène 4.) Je veux vérifier que mon watchdog matériel marche bien (je répète, pour ceux qui n'ont pas suivi, que le watchdog est un composant matériel qui sert à redémarrer la machine automatiquement en cas de plantage : une fois qu'on l'a activé, il doit recevoir un signal à intervalles réguliers, faute de quoi il provoque un reset). Cette scène se déroule elle-même en plusieurs saynettes.

(Scène 4a.) D'abord, j'ai eu peur, parce que Linux ne semblait pas le détecter du tout (le chargement du module iTCO-wdt n'avait aucun effet). J'ai fouillé dans les docs d'Intel, j'ai eu la confirmation que ce watchdog devait bien être présent dans le chipset C236 que j'ai. Je me suis dit que peut-être le noyau ne connaissait pas cette variante et qu'il fallait ajouter un identifiant PCI ou quelque chose de ce genre. Après des heures passées à éplucher des sources illisibles, j'ai fini par avoir une illumination : il faut charger le module i2c-smbus (en plus de i2c-i801), parce que le watchdog est sur un bus dit SMBus, une variante de I²C (je ne comprends pas du tout pourquoi il est nécessaire de savoir ça, alors que ces bus sont essentiellement des détails matériels, en quoi le logiciel arrive à les « voir », mais bon, c'est un fait). Avec ça, le watchdog est détecté.

(Scène 4b.) Maintenant que mon watchdog matériel est reconnu par Linux, je m'apprête à tester qu'il fonctionne bien. J'active le watchdog et je cesse de lui parler, au bout de quelques minutes le système doit redémarrer.

Mais il ne redémarre pas : il plante complètement.

Plus de réaction. Plus de clavier, plus d'écran, plus rien. J'appuie sur le bouton reset : pas d'effet. J'appuie sur le bouton d'alimentation, la machine s'éteint, je réappuie, ja machine se rallume…

…mais ne redémarre pas.

Sueur froide. Est-ce que j'aurais cassé une deuxième carte mère en à peine dix jours ?

(Scène 5.) Non : en éteignant au niveau de l'alimentation et en attendant assez longtemps pour que la carte mère soit totalement hors tension, si je rallume, la machine redémarre bien. Ouf !

Mais l'effet est reproductible : j'ai un watchdog qui, au lieu de redémarrer l'ordinateur, sert à le planter complètement, au point qu'il faut couper l'alimentation complètement pour qu'il remarche. Voilà qui est merveilleusement utile !

Vu que j'ai acheté cette carte mère précise essentiellement pour deux fonctions cruciales, la mémoire ECC et le watchdog, je suis quand même vert de rage.

Rideau.

⁂

Épilogue (ou teaser pour la suite ?)

Je suis absolument furieux de cette histoire de watchdog. J'hésite à acheter une nouvelle nouvelle nouvelle(!) carte mère, mais encore faudrait-il être absolument certain qu'elle a un watchdog qui marche.

Sinon, deux possibilités :

(1) Comprendre l'origine du problème et peut-être le résoudre. En fait, j'ai une petite idée de l'origine : ce n'est pas que le watchdog ne provoque pas de reset, c'est que ce reset échoue. Asus a eu la bonne idée de mettre un petit afficheur LCD sur la carte mère qui, lors du démarrage, montre différents codes correspondant aux différentes étapes de l'initialisation. Lorsque le watchdog s'active, cet afficheur passe par la même suite de nombres que lors d'un démarrage « normal » (19, 41, 50(?), 4c, 28, 31, 4b, 34, 3e, 3a, 46, 32, 35, 45, 36, 37, 3b, 3c, 38, 39, 3f, 5c, 55, 69(?), 3b, 32, 35, 60, 61, 9a, 62, 72 — tout ça en un tout petit peu plus que 11 secondes) ; mais ensuite, alors que l'initialisation normale continue (79, 96, b2, 9c, 64, 99, b2, a2, 99, ad), le reboot par watchdog revient au code 62 et y reste bloqué. La signification de ces codes est donnée dans le manuel de la carte mère, le code 62 se traduit par Initialization of the PCH Runtime Services (je sais que PCH signifie Platform Controller Hub, c'est essentiellement synonyme de chipset, en l'occurrence le Intel C236 ; mais je ne sais pas ce que sont ces runtime services).

Ceci ressemble à un bug du BIOS[#4] : j'imagine que le reset provoqué par le watchdog laisse je ne sais quel composant ou périphérique dans un état tel que le BIOS ne sait pas l'initialiser, et qu'il plante. (Peut-être la carte graphique ? Quand on cherche Initialization of the PCH Runtime Services dans Google, les gens se font souvent diriger vers un problème de carte graphique. Je ne sais pas. Peut-être que le BIOS n'a été testé complètement qu'avec des processeurs ayant un coprocesseur graphique intégré.)

Mais bon, la magie du logiciel propriétaire et opaque, c'est que s'il y a un bug dans mon BIOS, je ne peux pas le corriger, quand bien même j'en serais capable. J'ai écrit au support technique d'Asus. J'ai reçu une réponse qui n'était pas terrible (ils me demandent de faire toutes sortes de tests basiques comme vérifier que le processeur et les barrettes mémoires ne sont pas défectueux, dont certains tests que je ne peux pas vraiment faire), on va voir si je peux accéder à un niveau supérieur.

J'ai aussi lancé différents appels à l'aide (ici et là) pour savoir si des gens ayant des cartes mères semblables (ou pas, justement) peuvent reproduire le problème. Je n'ai reçu jusqu'à présent essentiellement qu'une réponse. Mais quelqu'un me dit avoir le même problème sur une carte mère d'Asrock (qui a un chipset Intel différent mais qui, comme la mienne, a un BIOS écrit par AMI), ce qui suggérerait que le problème peut venir de là.

Évidemment, mes chances d'arriver à faire remonter l'information jusqu'aux programmeurs qui ont écrit le BIOS, et à plus forte raison de leur faire corriger le problème, sont très minces. Je n'ai pas de carnet d'adresses, et je ne peux vraiment pas faire passer le message (pourtant hautement précis) il y a un problème dans le code d'initialisation des services runtime des PCH des chipsets Intel récents lorsqu'ils sont provoqués suite à un reboot initiié par le watchdog TCO à la bonne personne. C'est rageant. D'ailleurs, je n'arrive même pas à trouver plus qu'une personne prête à faire l'expérience que je demande, alors qu'il y a des milliers de fois plus de gens qui pourraient (des gens ayant une carte mère récente avec chipset Intel, ce n'est pas super rare).

Mise à jour (2016-09-20) : J'ai écrit des instructions pour tester le problème à partir d'une Ubuntu live (donc sans avoir à installer Linux) ici. Si des gens veulent tester sur différentes cartes mères à chipset Intel, je suis intéressé par les résultats. (Par exemple, Simon, dans les commentaires, m'apprend que le problème se produit aussi avec une carte mère Gigabyte Gaming 7 de chipset Z170, ce qui, en plus de l'exemple sur une carte mère Asrock H110M-HDS de chipset H110, porte encore plus les soupçons sur les BIOS AMI.) • Par ailleurs, le support technique d'ASUS, à qui j'ai transmis le lien précédent, m'a affirmé avoir remonté le problème à leur cellule d'expertise, on verra s'il en ressort quelque chose.

[#4] Enfin, du firmware : il paraît qu'en UEFI il ne faut plus dire BIOS — mais comme les auteurs du firmware eux-mêmes le disent, je vais le dire aussi.

(2) Trouver une autre solution pour redémarrer la machine quand elle plante. La technologie AMT mentionnée ci-dessus devrait être une solution, mais je n'arrive décidément pas à savoir si ma carte mère la gère, ou, dans ce cas, comment l'activer (ou vérifier si elle est active) ou comment en faire quoi que ce soit (ou comment parler au /dev/mei que Linux peut faire apparaître sur mon système).

Reste la solution bricolée (mais je déteste le principe) : une prise électrique commandée par USB : je brancherais la commande sur mon routeur (qui lui, a un watchdog qui fonctionne), et je me servirais du routeur comme watchdog pour le PC (mais ce serait très malcommode, donc peut-être simplement que je garderais la possibilité de me connecter au routeur pour éteindre et allumer le PC). Même comme ça, trouver une prise électrique commandée par USB et qui fonctionne sous Linux, ce n'est pas franchement gagné. Je suis tombé sur essentiellement deux produits :

• Aviosys USB Net Power 8800 (une seule prise), vendue 39€ ici, qui a un pilote Unix ici
• EnerGenie EG-PMS2 (6 prises protégées contre les surtensions, dont 4 commandables indépendamment), vendu 45€ ici, qui a un pilote Unix packagé par Debian sous le nom sispmctl

Si je dois acheter un de ces produits, je préférerais que ce soit à des gens qui ont fait l'effort, sinon d'écrire un driver libre, au moins de publier les spécifications techniques (qui doivent être franchement assez triviales s'agissant d'une bête prise qu'on peut allumer ou éteindre)[#5]. Pour le premier, ce n'est clairement pas le cas ; pour le second, je ne sais pas bien. Il y a peut-être des produits plus ouverts.

[#5] J'ai toujours du mal à comprendre comment on peut être un connard au point de vendre un produit qui est une simple prise commandée par USB et de refuser d'en publier les spécifications techniques qui permettraient d'écrire un pilote pour un pilote pour un autre système d'exploitation que Windows. J'aimerais pouvoir avoir une conversation en face à face avec un décideur de ce genre, et arriver à comprendre ce qui lui passe par la tête.