16 déc. 2017

CentOS 7 : démarrer Anaconda en PXE

Je voulais, à la base, écrire un billet sur une installation particulière de CentOS 7. J'ai donc voulu utiliser mon "infrastructure de boot PXE" à la maison et commencer à gribouiller un kickstart, mais quand j'ai démarré ma machine virtuelle sur le réseau, le drame :

dracut-initqueue[584]: Warning: Could not boot.
dracut-initqueue[584]: Warning: /dev/root does not exist

Ma configuration pxelinux à ce moment est la suivante :

LABEL centos7amd64
        MENU LABEL Install CentOS 7 x86_64 (interactive)
        KERNEL pub/centos/7/os/x86_64/isolinux/vmlinuz
        APPEND initrd=pub/centos/7/os/x86_64/isolinux/initrd.img ip=dhcp inst.repo=ftp://X.Y.Z.T/pub/centos/7/os/x86_64/ inst.ks=ftp://X.Y.Z.T/pub/ks/c7_x86_64.cfg

Et bien entendu, le même type de configuration fonctionne en CentOS 6.

Ce message d'erreur arrive à des moments et des types d'installation parfois différents, de ce que j'ai lu. Et la résolution n'est pas toujours la même. Dans mon cas, il a fallu que j'ajoute le chemin vers un fichier squashfs, qui doit contenir l'OS minimal pour démarrer Anaconda je crois. Cela donne donc la configuration suivante :

LABEL centos7amd64
        MENU LABEL Install CentOS 7 x86_64 (interactive)
        KERNEL pub/centos/7/os/x86_64/isolinux/vmlinuz
        APPEND initrd=pub/centos/7/os/x86_64/isolinux/initrd.img root=live:ftp://X.Y.Z.T/pub/centos/7/os/x86_64/LiveOS/squashfs.img ip=dhcp inst.repo=ftp://X.Y.Z.T/pub/centos/7/os/x86_64/ inst.ks=ftp://X.Y.Z.T/pub/ks/c7_x86_64.cfg

J'espère que cela rendra service à d'autres !

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : Mattias - Car Glass 03.

15 déc. 2017

NetBSD : recompilation d'un noyau pour intégrer NPF dans un domU

Dans un billet précédent, j'abordais l'installation d'une machine virtuelle Xen NetBSD en mode paravirtuel. NetBSD, comme Linux, dispose en plus d'un noyau, de modules permettant d'étendre ses fonctionnalités. Ainsi, l'une des briques de pare-feu de NetBSD, NPF, est disponible sous forme de module. Le problème avec ce module, c'est qu'il n'est pas compatible avec un noyau domU. Il est donc nécessaire de recompiler un noyau NetBSD pour en profiter, en incluant le pilote NPF directement dedans plutôt qu'en module.

Récupération des sources

Recompiler un noyau NetBSD est assez facile. D'abord, je récupère les sources, ici celles de NetBSD 7.1 :

nils@shell2:/srv$ export CVSROOT="anoncvs@anoncvs.NetBSD.org:/cvsroot"
nils@shell2:/srv$ export CVS_RSH="ssh"
nils@shell2:/srv$ cvs checkout -r netbsd-7-1-RELEASE -P src

La documentation officielle le fait dans /usr/src, mais je le fais dans /srv/src, cela ne pose pas de problème.

Si vous souhaitez recompiler un système complet (et pas juste le noyau), il faudra aussi récupérer xsrc, ce que je ne ferai pas ici.

Création d'une configuration noyau personnalisée

Maintenant que les sources sont disponibles, je crée un fichier de configuration pour notre nouveau noyau. Pour cela pas besoin de repartir de zéro, je vais tout simplement copier un fichier existant, et ajouter l'option qui m'intéresse. A noter que les configurations de noyau pour NetBSD sont placées dans les sous-arborescences des différentes architectures. Dans mon cas, mes machines virtuelles sont en x86_64, ce qui correspond à amd64 côté NetBSD :

nils@shell2:/srv$ cd src
nils@shell2:/srv/src$ sys/arch/amd64/conf

Le fichier de configuration du noyau utilisé par défaut est GENERIC, et il en existe aussi un spécialisé pour un invté Xen : XEN3_DOMU. Je vais copier ce dernier au lieu de le modifier pour facilement différencier ma configuration de l'officielle :

nils@shell2:/srv/src/sys/arch/amd64/conf$ cp -vp XEN3_DOMU XEN3_DOMU_NPF

Je peux ensuite éditer mon nouveau fichier, et aller chercher cette ligne :

#pseudo-device  npf                     # NPF packet filter

Il suffit alors de commenter cette ligne, et de sauvegarder le fichier. Passons maintenant à la compilation en elle-même.

Compilation du noyau NetBSD personnalisé

La compilation d'un noyau NetBSD peut se faire de deux manières : manuellement ou via l'aide d'un script nommé build.sh. Ce script est capable, depuis n'importe quel OS compatible, de créer très simplement non seulement un noyau, mais aussi une release complète de NetBSD. Ce script est fourni dans les sources, et se trouve d'ailleurs à la racine.

D'abord, compilons les outils nécessaires :

nils@shell2:/srv/src/sys/arch/amd64/conf$
nils@shell2:/srv/src$ ./build.sh -U -u -m amd64 tools

Autre détail intéressant, et c'est aussi la raison de la présence de l'option -U dans la commande précédente, je n'ai pas besoin d'être root pour ces opérations :) Passons donc à la compilation du noyau à proprement parler :

nils@shell2:/srv/src$ ./build.sh -U -u -m amd64 kernel=XEN3_DOMU_NPF

Selon la puissance de la machine, quelques minutes plus tard un résultat similaire au suivant devrait apparaître :

===> Kernels built from XEN3_DOMU_NPF:
  /srv/src/sys/arch/amd64/compile/obj/XEN3_DOMU_NPF/netbsd
===> build.sh ended:      Sun Jun 18 20:29:39 CEST 2017
===> Summary of results:
         build.sh command:    ./build.sh -U -u -m amd64 kernel=XEN3_DOMU_NPF
         build.sh started:    Sun Jun 18 20:29:26 CEST 2017
         NetBSD version:      7.1
         MACHINE:             amd64
         MACHINE_ARCH:        x86_64
         Build platform:      NetBSD 7.1 amd64
         HOST_SH:             /bin/sh
         MAKECONF file:       /etc/mk.conf
         TOOLDIR path:        /srv/src/obj/tooldir.NetBSD-7.1-amd64
         DESTDIR path:        /srv/src/obj/destdir.amd64
         RELEASEDIR path:     /srv/src/obj/releasedir
         Updated makewrapper: /srv/src/obj/tooldir.NetBSD-7.1-amd64/bin/nbmake-amd64
         Building kernel without building new tools
         Building kernel:     XEN3_DOMU_NPF
         Build directory:     /srv/src/sys/arch/amd64/compile/obj/XEN3_DOMU_NPF
         Kernels built from XEN3_DOMU_NPF:
          /srv/src/sys/arch/amd64/compile/obj/XEN3_DOMU_NPF/netbsd
         build.sh ended:      Sun Jun 18 20:29:39 CEST 2017
===> .

Il me suffit donc de copier le fichier /srv/src/sys/arch/amd64/compile/obj/XEN3_DOMU_NPF/netbsd sur mon dom0 et de l'utiliser dans un fichier de configuration Xen pour un domU !

Et NPF alors ?

Une fois notre domU démarré à l'aide de ce noyau, il suffit de suivre la documentation de NPF.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : D - 15 photography - GT3 RS.

14 déc. 2017

pbulk : aller plus loin sur les paramètres

Aujourd'hui, je me suis dit que j'allais encore parler de mon Raspberry Pi 2. Oui, celui-là même qui en ce moment passe sont temps à compiler des paquets pkgsrc. J'avais commencé par parler de la mise en place de pbulk, puis il y a peu j'ai abordé les problèmes d'alimentation rencontrés suite à cette mise en place.

Cette fois-ci, ce n'est pas une question d'alimentation, mais de limites systèmes. J'indiquais dans mon billet les options suivantes en tête du fichier pbulk.conf :

ulimit -t 3600 # set the limit on CPU time (in seconds)
ulimit -v 2097152 # limits process address space

Le premier problème que j'ai eu s'est matérialisé sous la forme d'un pur et simple kill lors de la compilation d'un paquet. Difficile ensuite de comprendre que celui-ci arrivait au bout d'une heure ! J'ai donc compilé le dit paquet manuellement et me suis rendu compte que cela mettait bien plus d'une heure. Cela peut sembler surprenant au premier abord, mais j'avais oublié que même en ayant 4 coeurs, un Raspberry Pi 2 est bien moins puissant qu'un PC classique x86_64. Il met donc, logiquement, bien plus de temps pour créer un même paquet. J'ai donc fini par commenter ces deux directives, pour voir si d'autres paquets, auparavant en échec pour des raisons obscures, peuvent compiler sans soucis.

A l'heure où j'écris ceci, le bulk build n'est pas terminé, mais j'ai déjà pu voir que le paquet qui m'a mis sur la voie est créé avec succès, ainsi que d'autres qui ne pouvaient pas être créés du fait de l'absence de ce premier.

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : Joe deSousa - Gears.

13 déc. 2017

Raspberry Pi : Attention à l'alimentation !

Il y a quelques mois, j'avais publié un billet sur pbulk. J'avais pris en exemple la configuration mise en place sur un Raspberry Pi 2B. Ce n'était pas une totale réussite, car parfois le Raspberry Pi gelait. Non, pas passer en dessous de 0°C, mais plutôt avoir un système qui ne répond plus. Plus rien, ou presque, la petite carte ne répondant qu'au ping.

On débranche, on rebranche, et ça repart. Jusqu'au suivant. Difficile dans ces conditions de construire presque 1500 paquets logiciels pour mes autres Raspberry Pi. La configuration d'alimentation choisie à l'époque avait pour but de limiter le nombre de prises de courant occupées : un PiHub, accompagné de son alimentation 5V 3,5A. Je pensais que pour 2 Raspberry Pi B+ et 2 2B, cela allait suffire. Finalement non, et non seulement les bulks ne passaient plus et finissaient par corrompre la carte SD, mais en plus l'alimentation a fini par lâcher.

Avant que l'alimentation du PiHub ne lâche, j'avais déjà déplacé le Raspberry Pi 2B dédié aux bulks sur une alimentation dédiée, en utilisant un chargeur de téléphone mobile. Lui aussi ne suffisait pas finalement, puisque j'ai eu quelques gels. Alors que faire ?

Une fois l'alimentation du PiHub hors service, j'ai finalement craqué pour un autre bloc, délivrant cette fois-ci 4,8A au total, mais dont certains ports peuvent délivrer jusqu'à 2A d'intensité. Depuis lors, je construits mes environ 1500 paquets par semaine sans problème depuis plus de trois semaines !

Moralité : il faut bien choisir l'alimentation de ses Raspberry Pi ! Cela peut poser certains problèmes !

Vous avez aimé cet article ? Alors partagez-le sur les réseaux sociaux ! Si en plus vous avez des remarques, ou des propositions d'améliorations, n'hésitez pas : les commentaires sont là pour ça !

Crédit photo : Teresa Walter/USFWS - Electrial fixtures to control that backup power generator.

12 déc. 2017

En retard !

Je n'ai pas tenu le coup. Au moment de la publication de ce billet, 2 billets manquent à l'appel : celui du 9 et celui du 11 décembre. J'aurais pu éviter celui du 11 en publiant ce billet directement, mais je ne vois pas l'intérêt de publier à une heure tardive, autant assumer.

Et donc, qu'est-il arrivé ? Tout simplement, deux choses :

  • je suis arrivé à court de billets écrits à l'avance ;
  • mes journées se sont avérées plus longues et plus remplies que je ne le pensais, oubliant de publier le dernier billet que j'avais en stock.

J'ai donc deux billets à rattraper. Pour quand ? Je ne sais pas. Mais j'ai bien l'intention de les publier d'ici le 24 décembre !

Un autre problème s'est posé à moi durant la publication des billets récemment. Quelque chose que j'arrivais à gérer lors d'une publication hebdomadaire, mais beaucoup plus difficile à maintenir lors d'une publication quotidienne : partager mes billets sur les réseaux sociaux. En effet, j'effectue tout cela à la main, lors de la publication du billet. Pourquoi ? Quelques éléments :

  • les systèmes de partage de billets que j'ai pu tester pour Dotclear ne fonctionnent plus ;
  • hors de question de filer un accès à mes comptes de réseaux sociaux à un acteur tiers comme IFTTT ;
  • je n'ai pas encore cherché ou trouvé un système que je peux héberger moi-même pour publier mes billets sur Facebook, Twitter, Mastodon et Linkedin (et Diaspora en option) ;
  • un billet partagé a plus de visite qu'un billet non partagé sur les réseaux sociaux (oui, j'aime un minimum être lu) ;
  • j'ai, selon les billets, plus de réactions sur les réseaux sociaux que sur les commentaires.

Tant que j'y suis dans les difficultés actuelles, j'ai de plus en plus de mal à trouver des images d'illustration, de préférence dans une licence très permissive : Flickr dispose d'une option "Aucune restriction de droits d’auteur connue" bien pratique.

Malgré tout, je souhaite continuer cette série de billets quotidiens. Qui pour m'encourager ?

Crédit photo : Sergey Kochkarev - Almost 3am.

Propulsé par Dotclear