Faute d'avoir trouvé un équivalent au lspci de Linux, sous NetBSD, j'ai pu récupérer les id PCI avec pcictl:

orgrim@rateau ~ $ pcictl /dev/pci0 list
000:00:0: Intel 82855PM MCH Host Controller (host bridge, revision 0x03)
000:01:0: Intel 82855PM Host-AGP Bridge (PCI bridge, revision 0x03)
000:29:0: Intel 82801DB USB UHCI Controller (USB serial bus, revision 0x01)
000:29:1: Intel 82801DB USB UHCI Controller (USB serial bus, revision 0x01)
000:29:2: Intel 82801DB USB UHCI Controller (USB serial bus, revision 0x01)
000:29:7: Intel 82801DB USB EHCI Controller (USB serial bus, interface 0x20, revision 0x01)
000:30:0: Intel 82801BAM Hub-PCI Bridge (PCI bridge, revision 0x81)
000:31:0: Intel 82801DB ISA Bridge (ISA bridge, revision 0x01)
000:31:1: Intel 82801DBM IDE Controller (IDE mass storage, interface 0x8a, revision 0x01)
000:31:3: Intel 82801DB SMBus Controller (SMBus serial bus, revision 0x01)
000:31:5: Intel 82801DB AC97 Audio Controller (audio multimedia, revision 0x01)
000:31:6: Intel 82801DB AC97 Modem Controller (modem communications, revision 0x01)

Et pour tout avoir d'un coup:

$ dmesg | awk '$1 ~ /^pci.$/ { print $1 }' | while read x; do pcictl /dev/$x list; done

Update: lspci est disponible dans le paquet sysutils/pciutils.

Après avoir bien galéré et m'être piqué les yeux sur des fonts bien pointues pendant longtemps, j'ai enfin réussi à obtenir un visuel correct sur mon desktop NetBSD. Plusieurs choses manquaient:

• Une ligne RgbPath dans la section Files de mon xorg.conf. Ça a bien affiné l'affichage.
• Une configuration de fontconfig correcte, pour des polices TTF bien utilisées.

En fait, dans l'install de X.org natif de NetBSD, tous les fichiers de configuration fournis sont activés alors que certains sont contradictoires.

Un gros merci au wiki de Arch, pour son excellente doc sur la question. Les liens fournis sont aussi intéressants, comme celui sur les pixels des écrans LCD

En débutant sous NetBSD, j'ai eu quelques soucis pour savoir quel device monter pour accéder à ma clé USB. En effet, sous NetBSD les mêmes lettres peuvent être des slices ou des partitions DOS. FreeBSD sépare plus les deux d'où mon incompréhension. Maintenant, les choses que sont plus claires dans ma tête, j'ai donc complété le tip sur le montage de FS en userspace de NetBSDfr, voici comment faire.

Lorsqu'on branche une clé USB, le système la détecte et lui assigne un device sdX. Pour connaitre le numéro de ce device, il faut regarder les messages du kernel avec dmesg:

$ dmesg | tail
...
umass0 at uhub1 port 6 configuration 1 interface 0
umass0: Corsair Flash Voyager, rev 2.00/1.00, addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, 1 lun per target
sd0 at scsibus0 target 0 lun 0: <Corsair, Flash Voyager, 0.00> disk removable
sd0: 15424 MB, 500 cyl, 8 head, 32 sec, 512 bytes/sect x 31588352 sectors

Ici, il s'agit de sd0. Maintenant, il faut savoir quelle partition monter, cette information s'obtient avec la commande disklabel:

$ disklabel sd0
# /dev/rsd0d:
...
5 partitions:
#        size    offset     fstype [fsize bsize cpg/sgs]
 d:  31588352         0     unused      0     0        # (Cyl.      0 - 123391)
 e:  31588289        63      MSDOS                     # (Cyl.      0*- 123391)
disklabel: boot block size 0
disklabel: super block size 0

Dans l'exemple, on voit la partition d, qui correspond à tout le disque pour NetBSD et la partition e de type MSDOS, le contenu sera donc disponible en montant /dev/sd0e.

Cette méthode ne concerne pas seulement les clés USB : pour trouver une partition sur un disque, il suffit de chercher dans la sortie de dmesg le nom du device et d'obtenir les informations sur les partitions de celui-ci avec disklabel.

Lancer la commande suivante:

# wsconsctl -w bell.pitch=0

Pour un effet permanent, ajouter cette ligne dans /etc/wscons.conf:

setvar wskbd bell.pitch 0

Dans un xterm: xset -b

Pour pouvoir mettre à jour l'OS de la gateway, je me suis dis que dupliquer les services sur ma machine principale serait sympa, ça permet de garder la main et de ne pas se retrouver coupé du monde en cas de soucis.

J'ai donc posé une petite conf de bind à partir de l'install fournie par défaut dans NetBSD. La bonne surprise, c'est que chez NetBSD, ils fournissent fromage et dessert : le chrootage du bouzin est de base.

En activant le paramètre named_chrootdir=”/var/chroot/named” dans son /etc/rc.conf, la magie opère :

# rndc-confgen -a -t /var/chroot/named
wrote key file "/etc/rndc.key"
wrote key file "/var/chroot/named/etc/rndc.key"

# /etc/rc.d/named start
Migrating /etc/namedb to /var/chroot/named/etc/namedb
Starting named.

# rndc status
...
server is up and running

Conclusion : si quelque chose est dans le système de base, il vaut mieux l'utiliser, c'est fait pour.

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).