3.6. Configuration matérielle et système avant l'installation

Cette section passe en revue les réglages matériels que vous devrez peut-être effectuer avant d'installer Debian. En général, cela implique de vérifier, et parfois de modifier, les réglages du micrologiciel (BIOS, etc.) sur votre système. Le micrologiciel est le logiciel de base utilisé par le matériel ; il est plus spécifiquement exécuté pendant le processus d'amorçage (après la mise sous tension). Les problèmes matériels connus qui affectent la fiabilité de Debian GNU/Linux sur votre système sont aussi mis en lumière.

3.6.1. Appel d'OpenBoot

OpenBoot fournit les fonctions de base nécessaires à l'amorçage de l'architecture SPARC. Les fonctions sont à peu près similaires à celles du BIOS de l'architecture x86, mais c'est plus joli. Les PROM d'amorçage Sun possèdent un interpréteur Forth intégré qui permet de faire pas mal de choses, comme des tests, des scripts simples, etc.

Pour obtenir l'invite d'OpenBoot vous devez maintenir la touche Stop (ou la touche L1 sur les vieux claviers Type 4) et appuyer sur la touche A. Si vous avez un adaptateur de clavier PC, maintenez la touche Pause (ou Break) et appuyez sur A. Cela vous donnera une invite, soit ok soit >. Il est préférable d'avoir l'invite ok. Si vous obtenez le vieux modèle d'invite (>), appuyez la touche n pour obtenir le nouveau modèle d'invite.

Si vous utilisez une console série, envoyez un « break » à la machine. Avec Minicom, utilisez Ctrl-A F ; avec cu, utilisez Enter. Puis saisissez %~break. Veuillez consulter la documentation de votre terminal si vous utilisez un programme différent.

3.6.2. Sélection du périphérique d'amorçage

Vous pouvez utiliser OpenBoot pour démarrer à partir de périphériques spécifiques, et aussi pour modifier le périphérique de démarrage par défaut. Cependant, vous devez connaître certains détails sur la manière dont OpenBoot nomme les périphériques ; c'est assez différent du nommage de périphériques sous Linux, décrit dans Section B.4, « Noms des périphériques sous Linux ». De plus, la commande varie légèrement, selon la version d'OpenBoot que vous avez. Vous trouverez plus d'informations sur OpenBoot dans la référence OpenBoot Sun .

Dans les versions récentes, vous pouvez utiliser les périphériques OpenBoot tels que « floppy », « cdrom », « net », « disk » ou « disk2 ». Ceux-ci ont des significations évidentes [3]. Le périphérique « net » sert à démarrer par le réseau, « floppy » sert à démarrer sur une disquette, « disk » sur le premier disque dur, et « disk2 » sur le second disque. Le nom des des périphériques OpenBoot est de cette forme :

nom-pilote@
adresse-unité:
arguments-périphériques

. Avec les anciennes versions d'OpenBoot, le nommage des périphériques est légèrement différent. Le lecteur de disquettes s'appelle « /fd », et les noms des disques durs SCSI sont de la forme « sd(contrôleur, disk-target-id, unité-logique-du-disque) ». La commande show-devs dans les nouvelles versions d'OpenBoot est utile pour voir les périphériques actuellement configurés. Pour des informations complètes quelle que soit votre version d'OpenBoot, voyez la référence OpenBoot Sun.

Pour démarrer sur un périphérique spécifique, utilisez la commande boot device. Vous pouvez positionner ce comportement comme valeur par défaut en utilisant la commande setenv. Cependant, le nom de la variable à positionner a changé entre les versions d'OpenBoot. Dans OpenBoot 1.x, utilisez la commande setenv boot-from device. Dans les versions ultérieures, utilisez la commande setenv boot-device device. N.B. On peut faire ce réglage à partir de la commande eeprom sous Solaris, ou, sous Linux, en modifiant les fichiers dans /proc/openprom/options/. Par exemple sous Linux :

# echo disk1:1 > /proc/openprom/options/boot-device

et sous Solaris :

# eeprom boot-device=disk1:1

3.6.3. Problèmes matériels à surveiller

Beaucoup de personnes ont essayé de faire fonctionner leur processeur 90 MHz à 100 MHz, etc. Cela fonctionne parfois, mais le système devient sensible à la température et à d'autres facteurs et cela peut réellement l'endommager. Un des auteurs de ce document a changé la fréquence de son propre système pendant un an et puis le système a commencé à interrompre le programme gcc par un signal inattendu pendant qu'il compilait le noyau du système d'exploitation. Baisser la vitesse du processeur à sa valeur de départ a résolu le problème.

Le compilateur gcc est souvent le premier à subir des dysfonctionnements à cause d'une mémoire RAM défectueuse (ou d'autres problèmes matériels qui changent les données de manière imprévisible), parce qu'il construit des structures de données gigantesques qu'il traverse plusieurs fois. Une erreur dans ces structures de données le fera exécuter une instruction illégale ou accéder à une adresse inexistante. Le symptôme de ce défaut est la mort de gcc par un signal inattendu.

3.6.3.1. Plus de 64 Mo de mémoire vive

Le noyau Linux peut ne pas toujours détecter la quantité de mémoire vive. Si c'est le cas, veuillez regarder : Section 5.2, « Paramètres d'amorçage ».



[3] N.D.T : pour les anglophones