Greboca  

LinuxFr.org : les journaux  -  Debian, installations automatiques et ARM

 -  16 janvier - 

Sommaire

Salut.

À la base, je ne suis qu'un développeur, mais comme «malheureusement» dans ma boîte je suis celui qui connaît le mieux le système (en tout cas ceux que l'on déploie: Debian avec kernel linux), je suis celui qui s'occupe en pratique de configurer et déployer les machines (je ne me considère pas comme un admin sys, par manque de compétences).

Installation réseau automatisée pour x86

Les premiers systèmes sur lesquels j'ai «officié» étaient basés sur des architectures x86, je me suis donc orienté vers un démarrage «diskless» PXE qui log automatiquement l'utilisateur root, qui a lui-même un .profile qui lance le formatage du «disque dur» et y installe un chroot via (c)debootstrap (en mode minimal, histoire que je puisse avoir la plus grosse maîtrise possible sur ce qui est effectivement installé: non, wamerican n'a aucun intérêt, par exemple…), chroot qui est ensuite utilisé pour installer la base de données et les divers logiciel nécessaire à mon taf (je laisserai cet aspect de côté, parce que ce que j'ai fait est sale. J'y gagnerais à nettoyer et surtout finir, mais pour ça, il me faudrait du temps… sigh).
Plutôt simple, dans le fond (enfin, quand on sait, y'a des trucs qui s'inventent pas), mais je vais rappeller ici ce qu'il est nécessaire de faire ou, en tout cas, comment moi j'ai fait:

  • installer et configurer un DHCPd (isc-dhcp-server pour moi, c'est le mieux documenté de ceux sous Debian) pour servir les requêtes DHCP/BOOTP (réseau physique différent du lan, parce que je n'ai pas encore trouvé le temps d'avoir le lan sous contrôle). Pas forcément le meilleur outil, mais au moins, trouver de la doc voire des exemples est relativement simple. À noter tout de même, selon les implémentations du client PXE, la machine qui doit servir le fichier à exécuter est déterminée de façon différente, mais je pense que c'est lié au fait que je n'avais pas spécifié à l'époque de routeur dans le DHCPd: en tout cas, les machines physiques utilisaient l'IP du DHCPd, alors que virtualbox nécessitait une URI complète. Je tiens aussi à mentionner l'option 'dynamic-bootp', ou un truc du genre;
  • installer et configurer un TFTPd (tftp-hpa pour moi), pour permettre le téléchargement par la cible d'un exécutable, ici un binaire de pxelinux. Outil super simple à utiliser, vraiment.
  • installer et configurer un bootloader (pxelinux… blabla), qui s'occupe de télécharger le noyau et l'initrd. La doc est un peu obtuse, notamment sur comment passer au noyau l'interface à utiliser si par malheur le système cible à plusieurs ports ethernet (et tant qu'à faire un PXE pour la 1ère fois, autant que ça ne soit pas dans la configuration la plus simple, pas vrai?) sans quoi ce dernier… freeze. Je remercie stack overflow sur ce coup, quelqu'un m'a filé une piste qui m'a permis de comprendre ce que je lisais dans la doc, plus spécificiquement, il est possible d'ajouter «BOOTIF=[MAC-ADDRESS]» afin que syslinux file la bonne interface au noyau (honnêtement, j'ai mis du temps avant de comprendre qu'il s'agit d'une option de syslinux et non du noyau… quoique, j'ai une doute? Je regarderai au taf demain au pire);
  • installer (c)debootstrap(-static) et l'utiliser pour créer un système complet;
  • configurer initramfs-tools dans le bootstrap afin de générer une image qui inclue les pilotes NFS, et probablement d'autres détails que j'ignore;
  • installer et configurer nfs-kernel-server afin de permettre l'accès par le réseau au bootstrap. Dans mon cas, j'ai mis l'accès en rw, j'aurai préféré ro, voire utiliser autre chose que NFS, peut-être TFTP ou SFTP ou SCP… surtout que je ne comprend pas quel daemon fait quoi dans NFS… mais bon, ça juste marche, et vu que c'est pour le taf, j'ai pas le choix de laisser des trucs moyennement maîtrisés tant qu'il n'y a pas une vraie raison de maîtriser (oui, ça me fait chier cette façon de faire)…
  • et bien sûr, créer un script qui partitionne automatiquement (sfdisk est bien pratique de ce point de vue), formate les partitions, crée les points de montages, les monte, invoque (c)debootstrap(-static), crée le fstab, initialise les mots de passe (merci à chpasswd sur ce coup) et mets en place les divers éléments nécessaires.

mauvais sujet, changer sujet

Bon, tout ça, c'est bien (ou pas, d'ailleurs, pour être franc c'est aussi une sorte de mea culpa pour mon manque de maîtrise), mais c'est pour des archis de type intel. Ça aidera peut-être quelques mollusques ici (j'en doute, mais, sait-on jamais?) mais ce n'était pas le sujet. J'ai bien précisé ARM dans le titre, après tout.
Hors, il s'avère que les machines ARM, ça ne boote pas comme nos bons (enfin, tant que le spectre de la sécurité ne nous hante pas quoi) vieux CPU intel, équipés de leurs bons vieux firmwares majoritairement fermés, quelques peu buggués (surtout depuis l'avènement de l'UEFI, d'ailleurs!).
De ce que j'ai compris (pour info, j'écris ceci le jour même ou j'ai finallement réussi à booter une beaglebone black via le réseau, je suis loin de maîtriser tout) le contenu d'une mémoire est chargé et exécuté. Comment et pourquoi, je n'en sais encore rien (mais j'ai l'intention d'apprendre pour un projet perso).
Ce qui est sûr, c'est que dans le cas des beaglebone black que j'ai au boulot, ça charge une version de «Das U-boot» vieille de 3 ans (au pifomètre), et que la «documentation» est franchement triste. Bien sûr, mes prédécesseurs ne maîtrisaient pas non plus le sujet, et ils ne sont de toute façon plus là… sinon s'pas drôle, pas vrai?
Trouver des articles de gens qui en parle est également difficile, et le peu que j'ai trouvé datent d'il y a plusieurs années. Le problème, c'est que le support d'ARM à été, comme tout bon bivalve le sait, considérablement remanié, et ces remaniements ont manifestement pas mal affecté le beaglebone black. Notamment, la configuration matérielle est à priori modifiable à l'exécution, peut-être est-ce lié à une sombre histoire de fermiers, je ne sais pas.

on cause d'ARM?

ARM, boot standard

Ce que je sais, c'est que j'ai dû dumper le contenu des variables, qui servent également de scripts, passer ce dump dans un script (fait maison, je n'ai pas connaissance d'outil fait pour) histoire de tranformer des one-liners de plusieurs dizaines d'instructions en un script lisible (30 lignes de shell, certes, mais c'est pénible quand même) qui ne liste que le code potentiellement appellé.
Par défaut, le contenu de la variable «bootcmd» est exécuté.
En pratique, on pourrait résumer ce script en ces quelques étapes (sur une BBB, hein):

  • configurer quelques connecteurs;
  • chercher comment accéder à la mémoire de masse;
  • reconfigurer les connecteurs;
  • chercher comment accéder à une autre mémoire de masse;
  • si pas de mémoire de masse trouvée, faire la gueule;
  • autrement charger un fichier de config (uEnv.txt) qui peut se trouver à divers endroits (sinon s'pas drôle, quoi);
  • éventuellement l'exécuter;
  • charger le noyal, l'initrd ET un fichier de config dtd qui, de ce que j'ai compris, permets de configurer les connecteurs (oui, ça fait potentiellement 3 fois qu'on les config, et si ça se trouve le système lui-même va les re-bidouiller…) en mémoire;
  • lancer le noyal avec en paramètres (passés par les registres du CPU à vue de nez) l'adresse de l'initrd et celle de la config hardware à utiliser;

ARM, boot réseau

Tout ça, c'est ce qui se fait en démarrage normal. Les docs (leS, parce que je parle a la fois de celle sur le site officielle, de celle à laquelle on peut accéder via help bla dans le prompt u-boot, et de celle dans le code-source) mentionnent une commande DHCP, qui, selon elles, permet de télécharger et d'exécuter un fichier.
Ne les croyez surtout pas!!! En pratique, la commande DHCP se contente de récupérer la configuration réseau et de charger en mémoire le fichier éventuellement indiqué par le serveur DHCP. Charger. Pas exécuter. Et non, il n'est pas possible de spécifier l'URI du fichier à télécharger depuis la carte ARM (ou, du moins, pas de cette façon).
Une fois la commande DHCP faite, nous avons donc récupéré une configuration IP, et chargé un fichier en mémoire. Il faut donc l'exécuter, et non, cela ne se fait pas forcément avec une commande nommée "bootmachinchose", on peut aussi utiliser la commande «source». Pourquoi pas, après tout, un binaire et un script sont 2 choses différentes, pas de souci ici.
Du coup, le but est de créer un fichier source. Un simple fichier texte qui contiendrait les instructions? Ah non, ça le fait pas: il faut créer un binaire via la commande mkimage. Ce binaire contiendra l'information de format, de compression, d'architecture probablement, et j'imagine d'autres trucs, mais pas trop, vue la taille du header…
Ce fichier pourrait, par exemple, utiliser la commande tftp (non, elle n'est pas dans la doc, je l'ai trouvée en lisant le code des scripts par défaut, et, oui, c'est built-in) afin de télécharger un fichier arbitraire à un emplacement mémoire arbitraire.
J'ai commencé par suivre plus ou moins bêtement un article de blog qui indiquait de ne télécharger que le fichier de config matérielle et le noyau. Grâce au fait d'avoir monté un PXE classique, j'ai été intrigué de l'absence explicite de l'initrd… à raison. Non, ça ne boote pas sans initrd ou, en tout cas, pas une Debian standard.
Il faut donc télécharger 3 fichiers: le noyau, l'initrd, et le dtb (config matérielle). Sauf que, ça ne boote toujours pas…
Pour une raison qui m'échappe, il faut, pour que ça démarre, passer l'initrd par la commande mkimage, sans quoi U-boot se mêle de ce qui ne le regarde pas (le format de l'initrd) et refuse de démarrer.

Tout ce bazard ne remplace que la configuration de pxelinux….

Conclusion et purge du cerveau, à grands coups de traSH

U-boot, je trouve ça sale.
La doc est à la fois incomplète et erronée, centrée sur un produit bien précis et donc tout sauf générique, les scripts exécutables sont dans des variables indiscernables des vraies variables, et j'ai du mal a avaler le fait d'avoir passé plus d'une semaine à comprendre comment ça marche en surface! Parce que non, je ne comprend toujours pas comment ça marche vraiment (alors que quand j'avais 15 ans, j'ai été capable de comprendre comment un BIOS bootait un kernel en quelques jours hein).
Comme je veux mettre à jour U-boot, par exemple pour qu'il soit capable de comprendre que non, je n'ai pas l'intention de n'avoir qu'un seul système viable sur la mémoire (double banque pour les MàJ) je sais que je vais encore en chier, et pas qu'un peu. Je vais sûrement finir par juste chainer les bootloaders…
Je peux aussi ajouter le fait que le chemin d'exécution originel, qui est la faute de Texas Instruments, pèse plus de 400 lignes alors que moins de 10 sont vraiment nécessaires (bon, je peux comprendre ça, et puis, ça reste super rapide) mais surtout le fait de faire des one-liners! Je ne sais pas si c'est à cause de Das U-boot ou de TI, mais c'est vraiment super moche. Le langage lui-même semble encourager le «code d'aviateurs» avec de looooooooongues ailes constituée de cascades de IFs.
Bref, c'est libre donc c'est génial, mais ça reste moche techniquement, selon moi. Mais je n'ai probablement pas tout compris…

PS: désolé pour le formatage

Commentaires : voir le flux atom ouvrir dans le navigateur

par freem

LinuxFr.org : les journaux

LinuxFr.org : Journaux

Sécurité, vie privée... et Google Analytics!

 -  14 février - 

Ave, 'nal (ça fait vénal, je sait, c'est fait exprès). Il y a un détail qui m'intrigue: c'est très bien de vouloir la vie privée renforcée sur (...)


Suivre les amendements débattue à l'assemblée nationale avec Eliasse

 -  13 février - 

Il m'arrive parfois de suivre les séances de débats à l'assemblée nationale via la diffusion en direct ou en regardant les rediffusions vidéo. Le (...)


Utilisation de GtkTreeModel, GtkTreeView et consorts

 -  11 février - 

Sommaire Introduction Création du modèle et ajout des données Ajout d'un tri sur le modèle Ajout d'un filtre sur le modèle Affichage des données du (...)


Mettre en place des build automatiques avec jenkins et docker

 -  10 février - 

Sommaire Mettre en place des build automatiques avec jenkins et dockerOutils installation de docker installation de jenkins Création d'un agent (...)


Delta Chat est prêt pour le bureau

 -  7 février - 

Delta Chat est un logiciel de messagerie instantanée comme il en existe des milliers: on ajoute des contacts, on crée des groupes et s'envoie des (...)