J'ai présentement sous les doigts une station Sun Ultra 2E avec deux
processeurs et deux gigaoctets de mémoire. Cette machine fonctionne
(presque) parfaitement une fois bootée. Elle tourne avec une
debian/testing à jour (et des bouts d'unstable pour le serveur X) et
plusieurs noyaux entre le 2.6.21 et 2.6.23.1.
Je la redémarre très peu (seulement quand je n'a pas le choix), donc
mon dernier reboot remontait à quelque quatre-vingts jours. Hier, je
décide de changer la version du noyau 2.6.21.3 (qui pose problème en
NFS) pour une version disons plus conciliante, la 2.6.23.1 que
j'avais déjà en production sur un autre serveur sparc64 et qui ne
pose rigoureusement aucun problème jusque là. Lors du boot, la
machine m'affiche un superbe :
Waiting for /dev/to be fully populated
sr0: scsi-1 drive
Uniform CD-ROM driver Revision: 3.20
sr 0:0:6:0: Attached scsi CD-ROM sr0
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:1:0: Attached scsi generic sg1 type 0
sr 0:0:6:0: Attached scsi generic sg2 type 5
done(timeout)
avec deux à trois minutes entre l'avant-dernière ligne et la
dernière. Entre temps, la charge dépasse 65 ! Partant du principe
(idiot) que le problème était dans le noyau, je reboote sur
l'ancien, soit le 2.6.21.3, idem. Pour être sûr, je teste un 2.6.22.1,
itou ! Le problème est donc dans la distribution plutôt que dans le
noyau. Je penche pour un problème lié à udev. Manque de chance :
Root fermat:[/etc/rcS.d] > time ./S03udev restart
Stopping the hotplug events dispatcher: udevd.
Starting the hotplug events dispatcher: udevd.
real 0m0.477s
user 0m0.292s
sys 0m0.184s
Root fermat:[/etc/rcS.d] >
Je ne sais plus par où chercher. J'ai googlisé pas mal de temps sans
trouver un début d'explication. Ce qui me surprend le plus, c'est
que l'U60 juste à côté, avec la même distribution et les mêmes
patches ne présente pas le problème. J'ai cherché toutes les
informations disponibles dans /var/log/whatever.log. Rien !...
Par ailleurs, lorsque je fais un df, j'obtiens :
Root fermat:[/etc/rcS.d] > df
Sys. de fich. 1K-blocs Occupé Disponible Capacité Monté sur
/dev/md1 66357552 9618184 53368536 16% /
Root fermat:[/etc/rcS.d] >
Alors que /boot est monté, et que mon $HOME est sur un disque
NFSv3/TCP accessible. La preuve :
Root fermat:[/etc/rcS.d] > cat /proc/mounts
rootfs / rootfs rw 0 0
/dev/root / ext3 rw,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid 0 0
proc /proc proc rw,nosuid,nodev,noexec 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec 0 0
/dev/root /dev/.static/dev ext3 rw,data=ordered 0 0
tmpfs /dev tmpfs rw 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec 0 0
openpromfs /proc/openprom openpromfs rw 0 0
/dev/md2 /boot ext3 rw,data=ordered 0 0
rpc_pipefs /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0
automount(pid12551) /net autofs
rw,fd=4,pgrp=12551,timeout=300,minproto=2,maxproto=4,indirect 0 0
automount(pid12631) /import autofs
rw,fd=4,pgrp=12631,timeout=300,minproto=2,maxproto=4,indirect 0 0
nfsd /proc/fs/nfsd nfsd rw 0 0
rayleigh:/export/home /import/home nfs
rw,vers=3,rsize=131072,wsize=131072,hard,proto=tcp,timeo=600,retrans=2,sec=sys,addr=rayleigh 0 0
Root fermat:[/etc/rcS.d] >
Mon intuition me dit que ces deux problèmes sont liés et que ça
tourne autour de udev, mais je ne vois pas. Je pensais certainement
naïvement que le souci tournait autour des machines Sbus (parce
qu'udev cherche aussi du PCI, ce qui expliquerait que cela ne se
produit pas sur l'U60), mais cela ne semble pas le cas
(sinon, pourquoi lorsque je lance udev à la main après le boot, cela
fonctionne ?). Bref, toute idée est la bienvenue parce que moi, je
sèche lamentablement...
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
--
Pour contacter l'équipe de modération : moderate...@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.