Hardware Detection Tool (HDT), un module particulier de Syslinux

Posté par  (Mastodon) . Modéré par tuiu pol.
Étiquettes : aucune
36
16
déc.
2009
Linux
HDT, pour Hardware Detection Tool porte bien son nom : il s'agit de détection matérielle. Cette dépêche ne rentrera pas dans les détails et se concentre sur la présentation pour tous de cet utilitaire.

HDT est sorti initialement en version publique en avril 2009. À cette époque, HDT révision 0.2.7 avait intégré le projet Syslinux alors en version 3.74. Il s'agit donc d'un module de type com32 pour Syslinux (NdR : nous en sommes maintenant à HDT v0.3.6).

Syslinux, vous le savez, c'est le tout premier message qui s'affiche à chaque fois que vous démarrez une machine GNU/Linux à partir d'un support amovible (clef USB, CDROM ou DVDROM d'installation ou live de nos chères distributions) et ce juste avant que le noyau Linux lui-même ne se charge.

Mais si... Regardez de plus près... SYSLINUX, copyright H Peter Anvin... Haa, voilà : vous voyez que vous connaissez ;-) Syslinux en quelques mots :

Syslinux a pour objectif initial de permettre de démarrer le noyau Linux sur un modèle de système de fichiers de type MS-DOS FAT. Avec Syslinux, les débutants pouvaient démarrer le noyau Linux facilement. Mais Syslinux n'est pas un outil, plutôt une suite complète d'outils. Le plus connu d'entre eux est ISOLINUX car il est massivement utilisé afin de créer tout système amorçable depuis un un système de fichier ISO 9660 ; en fait toutes nos distributions l'utilisent, que cela soit pour leur système d'installation ou bien leur LiveCD. Il existe également le moins connu EXTLINUX, qui est un petit frère de lilo et grub, rapide, simple, efficace : il permet d'amorcer le noyau Linux sur un système de fichiers de type EXTended. Enfin, tout administrateur normalement constitué utilise, a utilisé et utilisera PXELINUX, permettant d'amorcer depuis un serveur de type PXE/TFPT sur le réseau.

Le projet Syslinux comporte, en plus de cette suite d'utilitaires, des modules permettant d'ajouter des fonctions. Le plus connu du grand public est certainement MEMTEST86, développé pour réaliser des tests sur la mémoire vive afin de valider son fonctionnement et de déceler d'éventuels problèmes.

HDT est un de ces précieux et peu nombreux modules de Syslinux :

Il permet d'analyser le matériel d'une machine et ce, sans avoir besoin d'amorcer un quelconque système d'exploitation. HDT ira même jusqu'à vous dire de quels modules le noyau linux a besoin pour faire fonctionner ce matériel !

Pour ceux d'entre vous ne connaissant que peu les utilitaires classiques que l'on trouve avec nos distributions, ils pourront aller tester : lsmod (permet de lister les modules noyaux en cours de fonctionnement) / lspci (lister le matériel) / lsusb (lister le matériel usb) / ainsi que l'essentiel dmidecode (tout savoir sur son matériel). Eh bien, HDT permet tout cela, avant même de lancer un système d'exploitation.

Dès lors, on pourrait se dire naturellement qu'en dehors des OEM, des assembleurs de PC, et de quelques professionnels, il ne sert à rien, étant certainement trop dur à appréhender pour les Mr et Mme Michu que nous sommes.
Non, rassurez-vous : HDT présente ces informations simplement, d'une manière agréable et claire, permettant à tout un chacun de connaître rapidement et facilement son matériel. Il propose ainsi une présentation en mode "graphique", avec menus et explications.

Bref vous l'aurez compris, l'utilitaire HDT est un utilitaire à avoir sur soi... Vérifiez complètement le matériel du portable que vous lorgnez sur le présentoir...et payez vous le luxe de connaître les modules noyaux dont votre GNU/Linux aura besoin pour ce portable-là, sans perdre de temps à lancer un liveCD dessus ! En ces fêtes de Noël, en ces moment de cadeaux, être sûr de ce qu'on offre est bien pratique.

HDT est distribué sous licence MIT, comme tous modules com32 de Syslinux. Il est déjà utilisé par de nombreux projets, dont vous trouverez une liste non exhaustive sur le site officiel. Téléchargement de la version stable actuelle, incluse dans Syslinux :
http://www.kernel.org/pub/linux/utils/boot/syslinux/
Téléchargement du module HDT seul, version stable, mais pour Syslinux version 3.84 :
http://www.hdt-project.org/raw-attachment/wiki/hdt-0.3.6/hdt(...)
Les sources, quant à elles, sont dans le dépôt git de Syslinux.

Voici en quelques mots, pour une réalisation en moins d'une minute, comment créer sa clef USB bootable avec Syslinux de manière non destructive (vous n'avez pas besoin d'effacer vos fichiers et/ou de formater votre clef, préservant ainsi l'usage de votre clef).
L'espace occupé est minime et vous pouvez continuez d'utiliser votre clef USB normalement. Ceci évite d'avoir à lancer une distribution liveCB ou liveUSB pour prendre connaissance entièrement du matériel. C'est rapide : les informations sont obtenues en moins de dix secondes.
  • Installez Syslinux (soit avec le gestionnaire de paquets de votre distribution, soit en le téléchargeant sur le site du projet) ;
  • Branchez votre clef USB ;
  • Montez la clef, puis créez-y un répertoire pour Syslinux, par exemple : mkdir /media/clef/syslinux. (où clef est le point de montage, par exemple /media/zyrus) ;
  • Lancez la commande : syslinux -d syslinux mon_dev # où mon_devest votre clef, par exemple : syslinux -d syslinux /dev/sdb1 ;
  • Copiez le module hdt.com32 et le fichier modules.pcimap dans le même dossier ;
  • Créez un fichier, toujours dans le même dossier, nommé syslinux.cfg et contenant par exemple :
    label hdt
    kernel hdt.c32
    append modules=modules.pci
  • Bootez votre clef.

Feuille de route :

Les administrateurs pourront noter qu'en plus de tout ça, la feuille de route de HDT prévoit l'utilisation de LWIP, dès qu'il sera intégré à Syslinux, peut être pour la version 4 de syslinux. LWIP est une pile IP particulièrement légère.
Remerciements à l'équipe de HDT : Erwan Velu (Project Leader), Pierre-Alexandre Meyer (Core developer), Gert Hulselmans (Testing), Alexander Andino (Design & Art)

Aller plus loin

  • # Excellent article

    Posté par  (site web personnel) . Évalué à 5.

    Merci, vraiment instructif! J'ai hate te voir ca dans les prochaines distributions !
  • # Matériel non-géré

    Posté par  (site web personnel) . Évalué à 3.

    Est-ce que les matériaux non-géré par linux sont indiqué de manière clair ?
    • [^] # Re: Matériel non-géré

      Posté par  . Évalué à 4.

      Ça m'étonnerait, ne serait-ce que parce que le matériel géré par un noyau Linux donné dépend très précisément de la version de ce noyau: à chaque nouvelle version, on a des pilotes en plus, et parfois d'autres pilotes qui s'en vont.

      Ajoute à cela les pilotes, libres ou pas, qui ne sont pas intégrés au noyau mais y sont intégrables.

      THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

      • [^] # Re: Matériel non-géré

        Posté par  (Mastodon) . Évalué à 3.

        Oui oui, excusez le manque de précisions au sujet de cette possibilité annexe. Mais tout est sur ( nouveau et zoli) site web, regardez en particulier les liens 'define modules.pcimap' et 'define pci.ids' ;)
        (C est pas un rtfm (!!!) c est juste que cet aspect est bien détaillé)
      • [^] # Re: Matériel non-géré

        Posté par  (Mastodon) . Évalué à 5.

        Oui, et les options de pci maps décrites ci dessous sont très souples (encore, excusez le manque de précisions à ce sujet pour la dépêche).

        Par exemple :
        Comment savoir si sa Fedora / ArchLinux / Debian / (et les autres) dans la version que l'on veut, prend en charge le portable sur lequel on lorgne depuis quelques temps ? Et cela sans avoir besoin de recopier le résultat de hdt, pour le comparer ensuite ? Ben avec ces options, c'est possible :
        Copier les fichiers modules.pcimap et pci.ids dans le même repertoire, sur votre clef usb dans le même dossier, toujours l'exemple d'un dossier se nommant syslinux. Puis écrivez le fichier syslinux.cfg de la sorte :

        LABEL hdt
        COM32 hdt.c32
        APPEND modules_pcimap=syslinux/modules.pcimap pciids=syslinux/pci.ids

        Vous trouverez ces fichiers dans les dossiers respectifs : /usr/lib/modules/_version_noyau pour modules.pcimap et /usr/share/hwdata/ pour pci.ids.

        Ainsi, vous saurez si votre dernière Ubuntu/Mandriva (et les autres) est ok avec ce zoli portable, là, sur l'étagère, "tu as vu, comme il est pas cher" ;-)
        • [^] # Re: Matériel non-géré

          Posté par  (site web personnel) . Évalué à 1.

          Comment savoir si sa Fedora / ArchLinux / Debian / (et les autres) ...

          La réponse est données plus haut : c'est dans Mandriva depuis la version 9.1.
          Il suffit de booter sur une Mandriva One et le tour est joué !

          Alors que j'étais un habitué des versions cooker et powerpack, j'ai installé il y a quelques jours une Mandriva 2010 One sur un EeePC 900 (1Go de RAM et 16Go de SSD). J'ai été bluffé par cette version. Wifi, webcam, accélération graphique, installation des miroirs pour les mises à jour, tout fonctionne tout fonctionne comme par enchantement.
          • [^] # Re: Matériel non-géré

            Posté par  . Évalué à 2.

            C'est cool, mais ce n'est pas parce que ça marche sous Mandriva que ça marche partout: les versions du noyal sont différentes entre les versions, les attitudes vis-à-vis des pilotes "plus ou moins" privateurs aussi.

            THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

  • # Très intéressant

    Posté par  (site web personnel, Mastodon) . Évalué à 2.

    Ça a l'air d'être un très bon outil qui comble un gros manque des BIOS.

    Comme grub2 arrive et que le liveUSB de ma distrib peut également utiliser maintenant grub2, je me demande dans quelle mesure ce module syslinux pourrait être adapté pour être lancé par grub2. Est-ce que c'est un binaire lançable depuis un gestionnaire de démarrage comme grub(2), lilo, syslinux, ou uniquement par syslinux.
    J'ai du mal à comprendre la dépendance à syslinux. Peut-on m'expliquer svp.
    • [^] # Re: Très intéressant

      Posté par  (Mastodon) . Évalué à 5.

      Je trouve également que cela apporte une grosse avancée, en complément du (peu) d info des bios.

      Pour grub2 c est oui et non à la fois :
      Non techniquement, on ne peux pas lancer hdt depuis grub2. A noter que c'est une demande récurente. Cela réponds également à la question de la dépendance à syslinux : hdt est un module pour syslinux.
      Et oui aussi, car il est possible de jongler entre grub et syslinux. Il faut regarder comment font les projets utilisant déjà hdt, (ultimate-bootcd ou partmagic sont des livecd, n'ont pas d usage de grub donc. Mais il me semble que d autres jonglent sans pb).
      Par contre, je n en vois l intéret exact, dans la mesure ou hdt est taillé pour la découverte, je ne vois d intérêt à l'avoir dans/pour un grub. Par contre sur un serveur pxe pour les admins et/ou les dev, oui. Autant que sur une clef usb qu on pourra booter partout, y compris sur son pc déjà installé ;-)
    • [^] # Re: Très intéressant

      Posté par  . Évalué à 4.

      Salut,

      Tu peux tres bien charger hdt depuis un grub, soit en chargant nos images disquettes, soit en chargant l'image iso.

      Tu trouveras les details ici:
      http://www.hdt-project.org/wiki/howtostarthdt
  • # liveCB

    Posté par  . Évalué à 5.

    He oui, vous pouvez aussi installer votre Linux préféré sur une carte bancaire!
    • [^] # Re: liveCB

      Posté par  . Évalué à 10.

      HDT permet-il, dans ce cas, d'accéder facilement au contenu des cassettes du distributeur ?

      The capacity of the human mind for swallowing nonsense and spewing it forth in violent and repressive action has never yet been plumbed. -- Robert A. Heinlein

  • # Automatisation de la compilation du kernel?

    Posté par  (site web personnel) . Évalué à 2.

    On peut espère une automatisation de la compilation du kernel des distributions source (type Gentoo?) en fonction des machines? Ou je dis une grosse ânerie... -_-
    • [^] # Re: Automatisation de la compilation du kernel?

      Posté par  . Évalué à 5.

      HDT n'est pas vraiment l'outil fait pour ça. Par contre, le code de syslinux permettrait par exemple de refaire a la volée un initramfs en fonction du matériel.

      Syslinux permet de detecter le matériel dans sa quasi intégralité, il est en suite facile de realiser des modules pour délencher des actions en fonction de ces elements.
      • [^] # Re: Automatisation de la compilation du kernel?

        Posté par  (site web personnel) . Évalué à 2.

        En gros, cela pourrait aider à faire une partie de initramfs et peut être aussi changer la donne concernant udev et tmpdevfs au moment du boot. A-t-on besoin de tmpdevfs si on arrive à passer cela au noyau sur la ligne de commande de manière automatique ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.