OpenBSD 4.2

J’ai mis à jour mon petit soekris net4801 de 4.1 vers 4.2 et suis heureux de vous annoncer qu’il s’est bien remis de l’opération. Je conseille bien sûr une lecture approfondie du guide de mise à jour afin de ne rien manquer. Surtout le passage ou si comme un grouik (voire comme moi) vous avez changé /etc/rc.conf, tout va être recouvert à la mise à jour. Il faut en effet utiliser /etc/rc.conf.local à présent.

Voilà une petite spec, à dans 6 mois pour la 4.3 :)


Hostname: oblivion.frlinux.net - OS: OpenBSD 4.2/i386 -
CPU: Geode(TM) Integrated Processor by National Semi ("Geode by NSC" 586-class) 267 MHz -
Processes: 29 - Uptime: 45 Minutes - Load Average: 0.10 - Memory Usage: 28.72mb/255.59mb (11.24%) -
Disk Usage: 0.49gb/1.48gb (33.11%) - Network Traffic (sis0): In/Out 3.8mb/35.9mb

Kamikaze 1 – dd-wrt 0

C’est en lisant un post du journal d’Imil sur pourquoi dd-wrt est sale, j’ai décidé de sauter le pas et de télécharger la dernière version de Xwrt Kamikaze, une image libre d’openWRT qui complémente son interface graphique (le projet n’est d’ailleurs pas un fork mais un complément).

Eh bien un reboot plus tard, j’ai passé mon 54gl sous OpenWrt Kamikaze 7.09 et je suis content :) Je note également clairement que le projet a fait beaucoup de progrès dans la gestion du wireless. Seul point noir, je dois rester en noyau 2.4 pour le moment vu que mon Linksys utilise un chipset broadcom.

Il va sans dire qu’il faut lire la documentation d’installation avant d’en tenter une et que celle-ci vous apprendra que le wireless est désactivé par défaut (ce qui est bien) donc il faut l’activer. Enfin, il faut faire çà :


nvram set boot_wait=on
nvram commit

OpenBSD et Soekris demenagent !

J’ai passé la soirée à investiguer pourquoi j’avais des perfomances aussi abominables sur mon Soekris net4801 (contenant le dernier OpenBSD 4.1) et ma ligne ADSL 8Mo. J’ai finalement trouvé la réponse après quelques heures à faire des tests et il s’agit en fait de deux réponses.

La première concerne pppoe userland (activé dans /etc/ppp/ppp.conf) qui me donnait des pointes à 300ko/s et finissait généralement proche de 50ko/s … J’ai alors finalement tenté le kernel pppoe et ce fut la révélation : pleine vitesse aussitot que j’ai …

… réglé le second problème : pf. J’ai en effet rajouté une ligne comme celle-ci : scrub out on pppoe0 max-mss 1440 et hop, pleine vitesse, plus de problème de téléchargement. Je suis content d’avoir prouvé qu’une fois de plus : détermination est preuve de réussite (boo-ya !).

AAC0: bios 2.8-1[6098]

En fait, il s’agissait d’un bug de firmware de controlleur Perc … Remerciements à mon support personnalisé Dell (tu te reconnaîtras petit homme) ainsi qu’a paparoot pour l’idée de CD-ROM (vu que mon lecteur de disquettes est mort).

Beware of ze quennelle …

J’ai un serveur qui commence à avoir pas mal de services, le tout tourne sur une carte raid AAC (Perc 3/Di). Ce soir, elle a décidée qu’il était temps de péter un cable :


kernel: AAC:PANIC: length of sg list is too big
kernel: AAC:Fatal Error: See system event log
kernel: AAC:NO CORE DUMP, Trace not started.
kernel: sd 0:0:0:0: scsi: Device offlined - not ready after error recovery

Donc le fix a été dans un premier temps de redémarrer sur un noyau non Xen, puis de faire du ménage. J’ai trouvé un article qui m’a incité à lire un peu plus sur la nouvelle limite de quennelle que j’ai donc rencontré. Le problème est que cela ne marche pas sur mon kernel (2.6.18 etch + Xen).

J’ai ensuite trouvé deux autres articles, un de 3ware et un autre de lwn.net. J’ai donc modifié çà :


echo 512 > /sys/block/sda/queue/nr_requests

Je n’ai par contre pu changer d’autres settings pour le moment car étant en lecture seule …