Je viens enfin de réussir à booter un kernel -current (le 5.99.22 pour être précis). J'ai pas mal buté sur le manque de doc concernant l'évolution majeure : le passage aux modules par défaut. La solution est indiquée dans ce post de la ml current-users@. En gros, voici la marche à suivre:

• Compiler son kernel avec build.sh -O /usr/obj comme d'habitude:

$ build.sh -O ../obj -T ../tools -U -u kernel=GENERIC

• Installer le kernel comme d'habitude
• Compiler les modules avec et la cible modules:

$ build.sh -O ../obj -T ../tools -U -u modules

• Copier le boot loader dans /:

# cp ../obj/destdir.i386/usr/mdec/boot /

• Copier les modules dans /:

# cd ../obj/destdir.i386
# pax -rwvpe stand /

En fait, le fichier BUILDING indique que la cible module installe les modules, je pense que ça prête à confusion, ça n'installe pas dans / comme on pourrait s'y attrendre. Je ne connais pas assez le système de construction du système pour comprendre pourquoi, malheureusement.

Enfin, le fait de devoir également mettre le boot loader à jour ne s'invente pas. Tout comme le workaround pour que le système puisse monter la partition racine, qui consiste à charger le module du filesystem de / au prompt du loader :

> load /stand/i386/5.99.X/modules/ffs/ffs.kmod
> boot

En fait, c'est dur de se rendre compte à quel point on peut être passif face aux communautés des divers logiciels libres qu'on utilise. Même si j'essaye d'écrire des docs dans ce wiki chaque fois que je fais un truc potentiellement intéressant pour d'autres, ça reste planqué dans un coin du web…

Alors là, ça y est, je me sens plus et je commence à causer sur de la mailing-list suivie par des vrais gens (pas des robots d'indexation). Je viens de poster un tip sur netbsd-users@ dans une conversation concernant la configuration de fontconfig par défaut de NetBSD. En effet, quand on a x11 natif, il faut ajouter le path des fonts installées pas pkgsrc, pour que les applis utilisant fontconfig (genre firefox) puisse voir ces fonts.

On va voir ce que ça donne, émulation, indifférence ou mépris ? Dans tous les cas, ça m'apprendra des trucs…

Ces derniers temps, j'ai fait pas mal de wiki pour noter diverses choses sur mon nouvel OS préféré: NetBSD. Ce qui fait que je me suis rendu compte que le Dotclear n'avait plus trop d'intérêt comparé à DokuWiki, pour les raisons suivantes :

• Je ne raconte pas ma vie, j'ai pas le temps.
• Le Planet-Libre syndique les docs sur le FOSS, il faut donc faire des docs complètes pour que ça ait un intérêt. D'ailleurs, c'est pété depuis la modif…
• C'est pas facile de maintenir des infos dans un blog, l'édition du wiki s'y prête mieux.

C'est pourquoi, j'ai mis pleins de plugins dokuwiki et un nouveau thème, de quoi faire du blog (au cas où) et toutes les docs du dotclear sont maintenant dans le wiki.

Depuis un moment, pkg_chk me remontait un warning sur des packages installés mais n'existant plus dans l'arbre de pkgsrc. J'ai donc examiné le cas des packages *-dirs pour voir que plusieurs autres packages en avait besoin.

Les packages *-dirs ont été retirés de pkgsrc. Ils servaient à créer des répertoires potentiellement nécessaires à d'autres packages, et on été remplacés par une gestion des répertoires au niveau du package.

Bref, ça me laissait avec un peu de nettoyage à faire : retirer xdg-dirs sans tout péter ma base de packages. La solution a donc consisté à:

• Supprimer le package avec pkg_delete -f
• Editer les fichiers +CONTENTS des autres packages l'ayant comme dépendances dans /var/db/pkg, pour y supprimer toutes les lignes référençant xdg-dirs
• Utiliser un peu pkg_admin rebuild-tree pour s'assurer de la cohérence de la DB de pkgsrc

Merci beaucoup au chan IRC #netbsdfr, Guigui2 m'a pointé sur les mailing-lists, qui ne sont pas ressorties dans mes recherches.

Hier, ma machine Debian du boulot est morte. Comme le disque n'était pas en cause, j'ai simplement pris une nouvelle machine du même modèle et transféré le disque dur. La Debian a bien booté, mais avec un seul problème, la carte réseau était devenu eth1, alors qu'il n'y en a qu'une.

Un petit dmesg m'a indiqué que udev avait renommé ma carte eth1. Après une petite recherche dans la configuration d'udev, dans /etc/udev/, j'ai remarqué que le nom de device eth0 était lié à l'adresse MAC de la carte. Tout s'explique, la carte à changé, son adresse MAC aussi donc udev pensait que la carte de la nouvelle machine n'était pas eth0.

Une mise à jour de la ligne correspondante dans /etc/udev/rules.d/70-persistent-net.rules avec la nouvelle adresse MAC a résolu le problème. C'est le script udev /etc/udev/rules.d/75-persistent-net-generator.rules qui a automatiquement créé cette correspondance entre interface et adresse MAC (et donc la carte réseau).