La première partie est disponible ici !
Déballage, assemblage... et lamentage
C'est finalement le kit PicoPSU qui est arrivé des zuhessa en premier, suivi de près par le colis contenant la carte mère (et processeur), la RAM et le boîtier (la faute à une livraison en point relais un peu à la traîne).
Concernant le PicoPSU, le kit arrive avec un câble secteur doté d'une prise US. Ah oui, normal.
Mais je dois bien avoir dans mon bordel armoire de matos un câble avec prise européenne d'un côté et une prise Mickey de l'autre (rapport à la forme de la prise femelle sur le transfo).
farfouille
Cool en voilà un. Ah mais le transfo est-il adapté au 220V d'ici ? Consultation de l'étiquette collé dessus et croisage de doigts : oui c'est bon, ouf. Bon, c'est un signe du destin : il ne peut plus rien nous arriver d'affreux maintenant.
Passons à la partie plus classique et rassurante : les autres composants.
Behold!
La carte mère sort de son blister étincelante et chatoyante à la lumière du soleil d'une matinée dominicale (en fait c'était un début de soirée pluvieux de semaine, mais ça rend moins bien la magie de l'instant je trouve).
Je réalise ensuite que le boîtier est plus grand que ce que je n'avais imaginé. Ah oui c'est gros 20 litres. Une rapide inspection confirme toutefois les propos de l'article de Canard PC : c'est beau et fonctionnel, presque trop pour le prix.
J'installe précautionneusement la carte mère sur ses supports et les disques dans les racks derrière le ventilateur en façade, puis je branche le tout. La barrette de RAM, dans le slot... heu, ben 1, soyons logique. Je passe ensuite au PicoPSU, dont la prise ATX contient le transformateur DC-DC final délivrant le 3,3V pour le CPU et 5V pour les disques (le 12V arrivant directement du transfo 220V externe).
Un boîtier bien rempli
Heu. Tiens donc.
Mais mais. Il me manque 4 pins là !
Ce modèle de PicoPSU fournit en fait une prise ATX 20 broches, alors que la carte mère en a 24 ! (les modèles plus puissants fournissant eux une 24 pins)
Bon réfléchissons. Ça rentre bien d'un côté, ce qui est normal car je me rappelle qu'il y a quelques années les alimentations commençaient à fournir une prise ATX en deux parties 20+4 qu'on collait lors de l'enfichage, de manière à être utilisables même avec des cartes mères n'utilisant que l'ancienne prise de 20 broches, ce qui m'est parfois arrivé.
Si ça rentre, c'est que c'est compatible, admettons. Donc si j'appuie sur le bouton Power... ça devrait marcher ? Hum bon, enfilons cette combinaison hazmat, chaussons nos lunettes de soudure et bouchons nous les oreilles... j'appuie...
Et ça fait...
Rien.
Enfin si, les ventilateurs tournent, et plusieurs bips sortent du buzzer. Mais rien de plus.
D'accord, ces bips signifient qu'il y a un problème. Ça doit vraiment pas lui plaire d'avoir que 20 broches alimentées, et il me le fait savoir.
J'envisage quelques secondes la galère si je dois renvoyer le kit PicoPSU et abandonne immédiatement cette option en calculant les frais de port nécessaires.
Je cherche alors l'utilité des 4 pins supplémentaires et les réponses que je trouve indiquent qu'ils permettent de mieux répartir la puissance sur les rails 12V.
Puissance ?
Non mais j'ai pas des GeForce Titan en SLI avec un Pentium 4 overclocké là, j'ai un pauvre Atom avec GPU intégré ! Y'a pas de puissance à répartir, y'a même pas de quoi assommer une mouche ! Mais comment être sûr de ne pas faire de c... bêtise ?
Il m'a fallu poster la question sur le forum de CPC pour remettre mes idées en ordre et reprendre l'ensemble des informations dont je disposais pour exposer mon cas (finalement resté sans réponse), ce qui m'a permis de réaliser un magnifique facepalm avec triple axel et quadruple lutz mention RTFM historique.
RTFM
(pleure)
Suite à cela, je passe les détails (si si) mais il a bien dû se passer une journée avant qu'après d'intenses recherches je ne trouve la signification des bips (parce qu'elle n'était pas mentionnée dans le manuel papier ÇA SERAIT TROP SIMPLE) et constate qu'il s'agit apparemment... d'un problème de RAM.
Un éclair de génie me traverse alors l'esprit (ça fait mal quand même) et un vague souvenir me revient alors à propos de la nécessité de mettre la barrette sur le second connecteur. Après vérification c'était en commentaire sur la fiche produit de la carte mère, que j'avais pourtant lue et relue. double facepalm
Je m'exécute et tente à nouveau l'appui fatidique sur le bouton Power, cette fois sans combinaison hazmat, faut pas déconner.
Ô miracle ! Ça démarre !
Booting, please wait...
Avant de tenter quoi que ce soit sur l'installation aux petits oignons que je me suis mijotée pendant trois ans, je décide :
- d'un : de faire un backup avec Clonezilla (ça coûte pas cher, merci le NAS);
- de deux : de restaurer cette image sur un disque vierge seul branché sur la nouvelle carte mère afin de tester le bon fonctionnement du changement de configuration sans toucher au disque d'origine.
Mauvaise surprise : ça ne boote pas. GRUB ne s'affiche pas après le POST ce qui me plonge donc dans un grand désarroi.
Je décide d'aller dans le Setup du BIOS pour voir si une petite phase de configuration additionnelle ne serait pas nécessaire. Ah, en fait il ne s'agit pas d'un BIOS mais d'un UEFI.
Enfin Léon, soyons modernes.
Bon là j'avoue ne pas me souvenir de ce que j'ai pu faire pour résoudre cette erreur. Sûrement activer la compatibilité BIOS, ou mettre le firmware à jour, ou même simplement réordonner les périphériques de boot, je ne sais plus.
Toujours est-il que finalement le GRUB s'est bien affiché et j'ai pu constater avec effarement que Linux n'était absolument pas dérangé par le changement de configuration matérielle. J'avais quand même pris garde à ne pas brancher le câble réseau afin d'éviter les conflits et les interactions avec les autres machines du réseau (eh oui, il s'agissait alors d'un clone parfait d'une "autre" machine).
J'ai quand même dû modifier deux-trois choses ici et là, certains périphériques ayant malgré tout changé. La carte réseau étaient notamment vues comme une nouvelle interface et a donc pris l'identifiant "eth2" (mais j'avais déjà eu le cas lorsque sur Usul I j'avais ajouté la carte réseau PCI-Express Gigabit Intel qui avait pris l'identifiant "eth1"). À part ça tout semblait fonctionner.
J'ai finalement branché les disques définitifs, refait les mêmes opérations validées précédemment, et j'ai lancé le "rodage" : laisser la machine tourner un jour ou deux afin de m'assurer de la stabilité de l'ensemble.
Coup d'oeil au compteur
Avant même de commencer à remettre les doigts sur le terminal, il me fallait connaître enfin si un des objectifs de cette nouvelle configuration était rempli : abaisser encore la consommation électrique par rapport à Usul I.
Je dégaine donc mon Conserve Insight de Belkin et relève la consommation observée à la prise. Victoire ! Pas écrasante mais quand même : 28W environ en idle. Cela fait donc 5W gagnés, soit 15% de moins qu'Usul I. Pas énorme mais difficile de faire mieux. Je pourrais gagner le double si je retirais un des deux disques durs (ça consomme pas mal à cette échelle ces petites bêtes !).
0,000000028 Gigowatts Marty !
Le principal est que cette nouvelle plateforme matérielle soit "mieux" que l'ancienne, c'est-à-dire que le ratio puissance/consommation soit bien supérieur à ce qu'il était. De ce côté-là, c'est clairement gagné. La mesure de la puissance brute sera peut-être effectuée ultérieurement au moyen de mon benchmark maison basé sur sysbench.
Mise à niveau de Debian
Lorsque j'avais monté Usul I en 2010, mon choix de distribution s'était logiquement porté sur Debian, pour la stabilité et ma bonne connaissance de l'environnement. J'avais choisi la version "unstable", qui allait devenir la version stable quelques semaines plus tard : Squeeze (version 6).
Trois ans plus tard, Squeeze était devenue la "oldstable" et sa remplaçante se nommait Wheezy. C'était l'occasion où jamais de monter en version mon installation et profiter de paquets tout frais contenant des logiciels à jour (hum, ou presque, on parle de Debian hein).
Cela tombait bien, car le changement de matériel avait eu un petit effet que je n'avais pas remarqué immédiatement : les capteurs de températures et des ventilateurs n'étaient pas reconnus par le kernel, trop vieux pour eux ! Pour une machine qui reste au fond d'un placard 24h/24 il est quand même préférable d'avoir des alertes programmées sur ces informations ! La montée en version s'avérait donc nécessaire.
Pour avoir connu plusieurs déboires sur des montées en version d'Ubuntu par le passé, je décide de préparer le terrain minutieusement, en commençant par lire les instructions fournies par le site Debian (la menace du triple facepalm n'étant pas loin). Celui-ci précise un mode opératoire détaillé dans les notes de publication qui commence par la nécessité de sauvegarder la configuration complète du système, c'est-à-dire principalement /etc.
En ce qui me concerne, j'ai un job cron qui se charge d'archiver sur le NAS le contenu de ce répertoire toutes les nuits, donc pas de souci à ce niveau.
Comme la mise à niveau implique principalement l'utilisation du (ou des) gestionnaires de paquets, il est ensuite fortement conseillé de nettoyer la base de données des paquets et ses dépôts.
Fort judicieux ! Surtout que depuis quelques mois, sérieusement limité par les versions obsolètes de nombreux logiciels, j'ai bidouillé peu à peu mes dépôts et mes directives de mises à jour pour profiter de quelques paquets normalement inaccessibles à ma version de Debian, ce qui me cause régulièrement quelques galères avec les mises à jour.
Je passe donc au moins une heure à remettre tout à plat, quitte à supprimer quelques logiciels (notamment Deluge) que je note quand même dans un coin histoire de ne pas oublier de les réinstaller une fois la mise à niveau effectuée. Les instructions données sont faites pour être claires mais j'avoue cependant ne pas comprendre la totalité des commandes à lancer, n'étant pas un spécialiste de la gestion des paquets. Enfin bon, j'arrive quand même à obtenir un environnement qui semble suffisamment stable pour lancer la mise à niveau vers Wheezy. Au pire j'ai toujours l'image de la partition système que je peux restaurer si jamais quelque chose se passe mal.
Je démarre la mise à jour, et jette un oeil régulièrement à l'avancée du téléchargement des centaines de mégaoctets qui arrivent des serveurs miroirs...
Un bon moment plus tard, j'obtiens un prompt m'indiquant que la procédure est terminée. L'instant crucial du reboot est arrivé.
Allez allez, marche !
Et il passe ! Sans heurt majeur, hormis le fait que j'ai dû appuyer sur S(kip) pour passer le montage de partages réseaux mentionnés dans /etc/fstab lors du boot. Hum, bizarre.
La plupart des services se lancent sans aucun problème, et mes applications PHP et Java sont de retour sur des versions de plateformes presque récentes ! Je passe notamment d'un PHP 5.2 vieillissant à la série 5.3.
Le noyau Linux prend aussi un coup de jeune en passant de la série 2.6.32 à la 3.2. PostgreSQL - le SGBD que j'ai choisi pour cette machine au détriment d'un classique MySQL - change de version majeure de la 8.4 à la 9.1. Pour celui-ci par contre mise à niveau n'est pas totalement automatique et j'ai suivi les instructions (finalement très simples) disponible par exemple ici pour migrer mes données d'un moteur vers un autre. Il s'agit simplement de faire un dump, d'arrêter le daemon, de basculer le moteur et sa configuration puis de le redémarrer, et enfin restaurer le dump. Rien d'impossible sur une machine locale. Sur un serveur de prod par contre ce serait un poil plus délicat !
Reste à voir à présent le résultat du rodage et les configurations supplémentaires qu'il faudra immanquablement effectuer... dans la troisième et dernière partie !