ASRock 4CoreDual-SATA2, VT6102, eth1, eth2, eth3…

Nouvelle carte mère, nouveaux problèmes… Bon d’accord j’abuse. GNU/Linux n’est pas windows, pas de réinstallation système à chaque changement de périphérique. Mais on aimerai tout de même bien que tout marche du premier coup au premier boot suivant un changement de carte mère…

La ASRock 4CoreDual-Sata2 comporte un contrôleur ethernet VT6102 supporté par le module via-rhine. Premier boot après upgrade matérielle et…. tiens pas de réseau… tiens eth1 ? Aurai-je une autre NIC ? Bin… non. Késsésséssa ?

Après avoir penché pour un problème de pilote et quelques essais de rmmod/modprobe, voici arriver un troupeau de eth1, eth2, eth3, eth4… amusant… ou pas.

Mais le problème ne vient pas du pilote mais d’udev et des règles. Plus exactement du persistent-net-generator.rules. On retrouve ainsi dans z25_persistent-net.rules :
# PCI device 0x1106:0x3065 (via-rhine)
SUBSYSTEM== »net », DRIVERS== »?* », ATTRS{address}== »00:19:66:2e:b2:13″, NAME= »eth1″
Une petite correction en :
# PCI device 0x1106:0x3065 (via-rhine)
SUBSYSTEM== »net », DRIVERS== »?* », ATTRS{address}== »00:19:66:2e:b2:13″, NAME= »eth0″
Un reboot pour vérifier et voilà.

PS : merci iMil pour le tuyau.

Debian et machine virtuelle KVM

Ayant dernièrement acheté une nouvelle configuration (Intel Core2Quad Q6600 sur ASRock 4CoreDual-SATA2) j’ai, bien entendu, décidé d’enfin jouer un peu avec la virtualisation et Xen 3.1. Malheureusement le kernel Xen basé sur un 2.6.18 n’intègre pas de support pour le contrôleur IDE de la carte mère (VIA vt8237s). On remarquera que le support existe dans des nouveau kernel mais ainsi qu’un hack pour le 2.6.18. Ubuntu dispose également d’un 2.6.22 « xenifié » sous forme de paquet .deb.

Ceci étant, plutôt que de le lancer dans d’immondes bidouilles j’ai tourné mon regard vers KVM, le support de virtualisation intégré au kernel. El là, suprise ! C’est convi, rapide et simple.

Installation des outils userspace :
% apt-get install kvm qemu
Chargement du module pour le support VT Intel :
% modprobe kvm-intel
Création d’une image disque de 5 giga en CoW (Copy on Write) pour économiser de la place (les 5Go ne sont pas réellement utilisés mais uniquement l’espace effectivement occupé par les données de l’image disque):
% qemu-img create disk.cow 5G
Lancement de kvm avec utilisation de l’image ISO d’installation de Debian 4.0 (avec 512Mo de mémoire pour le système) :
% kvm -hda disk.cow -cdrom /path/debian-40r1-i386-businesscard.iso -boot d -m 512
Installation classique minimale Debian… et enfin utilisation du système via :
% kvm -hda disk.cow -m 512
La configuration par défaut est entièrement automatique. Le système hébergé reçoit une adresse IP via DHCP et le routage est automatique. Ainsi la distribution Debian peut directement être mise à jour. C’est le système de routage userspace de KVM/QEMU. Ceci n’est pas très satisfaisant à mon goût.

Ne disposant que d’une seule interface ethernet matérielle dans le système hôte (nommée eth1 en raison d’un problème udev dont je parlerai pas ailleurs) l’idée de base est de créer un bridge ethernet reliant eth1 et une interface TUN/TAP.

Phase 1, on installe le paquet uml-utilities contenant l’utilitaire tunctl :
% apt-get install uml-utilities
On descend ensuite le réseau façon Debian :
% /etc/init.d/network stop
Puis on change /etc/network/interfaces comme ceci :
auto lo eth1 tap10 br0

iface lo inet loopback

iface tap10 inet manual
pre-up tunctl -b -u denis -t tap10
pre-up ifconfig tap10 up
post-down tunctl -d tap10

iface br0 inet static
bridge_ports eth1 tap10
bridge_maxwait 0
address 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.10

iface eth1 inet manual
Dans l’ordre, on configure le loopback puis eth1. On créé ensuite tap10 (tap0 est utilisé par ailleurs avec OpenVPN) et on bridge eth1 et tap10 en donnant une adresse au bridge. eth1 et tap10 sont donc maintenant physiquement connecté au même hub virtuel. tap10 est « le bout de câble » connecté à notre eth0 dans le système Debian tournant dans la KVM. On démarre celui-ci avec :
% kvm -hda disk.cow -m 512 -net nic -net tap,ifname=tap10
Dans le /etc/network/interfaces du système on trouve :
iface eth0 inet static
address 192.168.0.200
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.10
Et voilà, le tour est joué. Le système KVM est accessible depuis le système hôte via 192.168.0.200 comme s’il était sur le réseau (en fait, il l’est via le bridge).

Désactiver ipv6 sur Debian GNU/Linux

Lorsqu’on install une nouvelle distribution Debian 4.0, par défaut le support IPv6 est activé. Il peut en découler quelques problème ou même simplement des ralentissement. En effet, toutes les applications vont, par exemple utiliser le support IPv6 pour la résolution de nom avant ou après avoir fait l’essai avec IPv4.

C’est le cas pour mplayer utilisé pour lire un flux audio ou vidéo :
[…]
Resolving live.radio-gresivaudan.org for AF_INET6…
Couldn’t resolve name for AF_INET6: live.radio-gresivaudan.org
Resolving live.radio-gresivaudan.org for AF_INET…
Connecting to server live.radio-gresivaudan.org[217.117.157.190]: 8000…
[…]
Il existe une méthode simple pour désactiver le support IPv6. Il suffit d’interdire au système de charger le module correspondant. Editez le fichier /etc/modprobe.d/blacklist et ajoutez la ligne :
blacklist ipv6
Editez ensuite votre /etc/hosts pour enlever les entrées IPv6.

Une autre solution (moins élégante je trouve) consiste à modifier /etc/modprobe.d/aliases de :

alias net-pf-10 ipv6

en

alias net-pf-10 off
alias ipv6 off

Il ne vous reste plus qu’à redémarrer le système (ce n’est pas strictement nécessaire, il est possible de faire autrement, mais c’est bien plus simple, surtout après une installation). Un petit ifconfig vous confirmera qu’IPv6 n’est plus gérer (plus de adr inet6:).

Pour les autres distributions GNU/Linux (Gentoo, Fedora, SUSE, etc), je vous recommande la lecture de ce billet sur beranger.org.

Debian GNU/Linux 4.0 released

Tadaaaa ! Tout est dans le titre du billet je crois.

Après 21 mois de développement voici l’annonce officielle d’une nouvelle distribution Stable de Debian GNU/Linux. 58 langues, prise en charge des partitions chiffrées, 11 architectures supportées, installation depuis du DVD, CD, floppy, USB… Et des paquets comme s’il en pleuvait :

K Desktop Environment 3.5 (KDE)
GNOME desktop environment 2.14
Xfce 4.4
GNUstep 5.2
X.Org 7.1
The GIMP 2.2.13,
Iceweasel/Firefox 2.0.0.3
Icedove/Thunderbird 1.5
PostgreSQL 8.1.8
MySQL 5.0.32
GNU Compiler Collection 4.1.1
Linux 2.6.18
Apache 2.2.3
Samba 3.0.24
Python 2.4.4 & 2.5
Perl 5.8.8
PHP 4.4.4 & 5.2.0
Asterisk 1.2.13
et plus de 18,000 autres paquets

Lien : le poste sur la liste qui va bien

Debian GNU/Linux sur SGI Indy

Me voici l’heureux propriétaire d’une station Silicon Graphics Indy. Le moins qu’on puisse dire c’est que la créature n’est pas de première jeunesse mais côté exotisme on est comblé. La mise en route est une autre paire de manches.

Première étape, mettre en marche. Heureusement, une Indy dispose de connecteurs PS/2 pour le clavier et la souris, du matériel PC économique fait donc l’affaire. Malheureusement, côté vidéo il n’en va pas de même, on trouve un connecteur 13W3 et faute d’écran compatible il faut se rabattre sur un adaptateur 13W3/VGA et un écran standard PC. L’adaptateur commandé n’étant pas encore arrivé, mais ne pouvant attendre, j’ai découvert ce que signifiait le terme « qualité » pour du hardware. Et hop, une console série !

Une Indy, comme d’autres station dispose de deux port série compatibles RS232 au format miniDIN 8 broches. Un null-modem et l’affaire est dans le sac… à un détail près : encore faut-il trouver un connecteur adéquate.

Dans le cas contraire c’est pistolet à colle, pattes de composants et fer à souder :

La machine était décrite comme ayant un disque de 500Mo, un volume inconnu de mémoire et une configuration pour démarrer sur le réseau. Au final l’Indy dispose de deux disques, de 32 Mo de mémoire, d’une carte graphique XL-24 et d’une carte vidéo fille. La configuration elle-même ne semblait indiquer aucun démarrage réseau.

La seconde étape de la réactivation de la station se résume donc par un premier démarrage avec une console série. L’Indy sans clavier ni souris démarre automatiquement avec une console sur le premier port série. Il suffit donc de configurer un terminal (minicom) en 9600 8N1 et zou :
System Maintenance Menu

1) Start System
2) Install System Software
3) Run Diagnostics
4) Recover System
5) Enter Command Monitor
On utilise 5 pour configurer l’ensemble et obtenir quelques informations (adresse MAC par exemple). Manque de chance, un mot de passe est défini et il faut le supprimer. Un petit cavalier sur la carte mère peut être retiré avant la mise sous tension de la machine :

De retour dans le menu de maintenance, et dans le Command Monitor, on efface le mot de passe :
Option? 5

Warning: Password jumper has been removed. Not enforcing PROM password.

Command Monitor. Type « exit » to return to the menu.
>>resetpw
Password cleared.
>>
Bon, remise en place du cavalier et reboot. Il faut maintenant démarrer l’Indy depuis le réseau pour une installation de GNU/Linux. Pour se faire on installe un serveur DHCP et un serveur TFTP sur une machine du réseau. Le serveur TFTP accueil le fichier netboot-boot.img récupéré sur l’archive Debian qui va bien.

Toujours dans le Command Monitor (et si tout est correctement configuré) on utilise :
setenv console d1
unsetenv netaddr
bootp()/netboot-boot.img
(La première commande sert simplement à forcer une console sur le premier port série à chaque démarrage) L’image est récupérée et démarrée et l’installeur Debian prend le relais. Là, il suffit de suivre les étapes classiques. En fin d’installation, un bootloader est installé, c’est arcboot. L’architecture d’une Indy n’a rien à voir avec un PC, la plupart du travail est fait par le programme en PROM qui utilise une partition spécifique du disque pour les images système à démarrer. Après l’installation de la Debian, il faut refaire un tour dans le Command Monitor pour spécifier la configuration à utiliser :
setenv SystemPartition scsi(0)disk(1)rdisk(0)partition(8)
setenv OSLoadPartition scsi(0)disk(1)rdisk(0)partition(0)
setenv OSLoader arcboot
setenv OSLoadFilename Linux
On précis la partition système, la partition où se trouve l’OS, le bootloader et l’argument passé à ce dernier. Ensuite, il suffit d’utiliser la commande boot et le système démarre normalement. Lors des prochains démarrages les valeurs enregistrées sont directement utilisées sauf si on fait usage de <ESC> pour revenir dans le mode de maintenance.

C’est tout pour l’instant. J’y reviendrai peut-être par la suite une fois l’adaptateur 13W3/VGA en ma possession et lorsque la configuration sera plus complète (serveur X, périphérique audio, code, etc). Quoi qu’il en soit, c’est via ce type d’expérience qu’on se rend compte à quel point l’architecture PC est un hack et les configurations de bien mauvaise qualité. Un BIOS PC par exemple n’est toujours pas capable de prendre en charge le choix d’un OS, d’offrir une interface de maintenance valable, etc… Bref la plupart des choses qu’on retrouve dans un bootloader comme GRUB.

Quelques liens intéressants :

http://www.reputable.com/indytech.html

http://www.pvv.org/~pladsen/Indy/HOWTO.html

http://www.zorg.org/linux/indy.php

http://geektechnique.org/projects/indyblues.html