Gentoo Logo

1.  Configuration d'Arcload pour les machines Silicon Graphics

Arcload ?

Pour démarrer une machine SGI, nous utilisons maintenant le chargeur de démarrage arcload qui remplace officiellement l'obsolète arcboot que nous utilisions auparavant pour installer Gentoo.

Note : l'entête de volume SGI ne peut contenir que 16 fichiers, avec chacun 8 caractères maximum pour le nom du fichier.

Installer arcload

arcload a été écrit pour les machines qui nécessitent un noyau 64 bits et qui ne peuvent donc pas utiliser arcboot (qui demande beaucoup de travail pour qu'on puisse le compiler en tant que binaire 64 bits). Il permet également de contourner certains problèmes qui apparaissent lorsqu'on charge un noyau directement depuis l'entête de volume. Passons donc à son installation :

Exemple de code 1.1 : installer arcload et dvhtool

# emerge arcload dvhtool

Les binaires arcload ont dû être installés dans /usr/lib/arcload :

  • sashARCS : le binaire 32 bits pour Indy, Indigo2 (R4k), Challenge S et O2.
  • sash64 : le binaire 64 bits pour Octane/Octane2, Origin 200/2000 et Indigo2 Impact.

Utilisez maintenant dvhtool pour installer le bon binaire dans l'entête de volume :

Exemple de code 1.1 : placer arcload dans l'entête de volume

(Pour les Indy/Indigo2/Challenge S/O2.)
# dvhtool --unix-to-vh /usr/lib/arcload/sashARCS sashARCS

(Pour les Indigo2 Impact/Octane/Octane2/Origin 200/Origin 2000.)
# dvhtool --unix-to-vh /usr/lib/arcload/sash64 sash64

Note : vous n'êtes pas obligé de garder les noms sashARCS ou sash64, à moins que vous ne placiez les fichiers dans l'entête de volume d'un CD-ROM amorçable. Le fichier peut porter le nom que vous voulez si c'est pour démarrer sur disque dur.

Utilisez maintenant dvhtool pour vérifier que les fichiers sont correctement installés.

Exemple de code 1.1 : vérifier l'installation d'arcload dans l'entête de volume

# dvhtool --print-volume-directory
----- directory entries -----
Entry #0, name "sash64", start 4, bytes 55859

Le fichier de configuration, arc.cf, a une syntaxe à la C. Pour de longues explications sur son utilisation, voyez la page sur Arcload sur le wiki Linux/MIPS. Pour faire court, vous définissez un certain nombre d'options qui configureront le démarrage en utilisant la variable OSLoadFilename.

Exemple de code 1.1 : un exemple de arc.cf

# Configuration d'Arcload

# Quelques valeurs par défaut...
append  "root=/dev/sda3";
append  "ro";
append  "console=ttyS0,9600";

# La définition principale, vous pouvez changer ip28 si vous voulez.
ip28 {
  # Définition d'un noyau *fonctionnel*
  # Sélectionnez-le avec OSLoadFilename="ip28(working)"
  working {
    description "SGI Indigo2 Impact R10000\n\r";
    image system "/working";
  }

  # Définition d'un noyau en *test*
  # Sélectionnez-le avec OSLoadFilename="ip28(new)"
  new {
    description "SGI Indigo2 Impact R10000 - Testing Kernel\n\r";
    image system "/new";
  }

  # Pour déboguer un noyau
  # Sélectionnez-le avec OSLoadFilename="ip28(working,debug)"
  # ou OSLoadFilename="ip28(new,debug)"
  debug {
    description "Debug console";
    append "init=/bin/bash";
  }
}

À partir d'arcload-0.5, arc.cf et les noyaux peuvent résider dans l'entête de volume ou bien dans une partition. Si cette fonctionnalité vous intéresse, vous pouvez placer les fichiers directement dans votre partition /boot (ou / si vous n'avez pas de /boot séparé). arcload utilise le code du pilote de système de fichiers du populaire grub, et donc supporte les mêmes systèmes de fichiers.

Exemple de code 1.1 : placer arc.cf et le noyau dans l'entête de volume

# dvhtool --unix-to-vh arc.cf arc.cf
# dvhtool --unix-to-vh /usr/src/linux/vmlinux new

Ceci fait, tout ce qu'il reste à faire est de régler quelques options dans la PROM. Voyez cela dans la section Redémarrer le système.

1.  Configuration de CoLo pour les serveurs Cobalt

Installer CoLo

Les capacités du firmware installé sur les cartes des serveurs Cobalt sont bien plus limitées. Le BOOTROM de Cobalt est primitif en comparaison à la PROM SGI et a un certain nombre de limitations critiques.

  • Les noyaux sont limités à (environ) 675 Ko. La taille actuelle de Linux 2.4 fait que c'est pratiquement impossible d'arriver à un noyau de cette taille. Pour les noyaux 2.6, ce n'est même pas la peine d'y penser.
  • Les noyaux 64 bits ne sont pas supportés par le firmware d'origine (en tout cas c'est au stade plus qu'expérimental sur les machines Cobalt actuellement).
  • Le shell est franchement limité.

Pour s'affranchir de toutes ces limitations, un firmware alternatif nommé CoLo (Cobalt Loader) a été développé. C'est une image BOOTROM qui peut au choix être incorporée directement dans la carte du serveur Cobalt ou être chargée par le firmware actuel.

Note : ce guide va vous indiquer comment installer CoLo afin qu'il soit chargé par le firmware d'origine. C'est la seule méthode sure et recommandée d'installer CoLo.

Attention : si vous le souhaitez, vous pouvez tout aussi bien le « flasher » dans votre serveur et remplacer le firmware originel. Cela dit, vous prenez vos propres risques en faisant cela. Si quelque chose ne va pas, il vous faudra supprimer physiquement le BOOTROM et le reprogrammer vous-même avec le firmware d'origine. Si vous n'êtes pas sûr de la méthode, alors NE TOUCHEZ À RIEN. Nous ne sommes pas responsable de ce que vous ferez si vous ignorez cet avertissement.

Bon, cela étant dit, nous pouvons procéder à l'installation de CoLo. Tout d'abord commencez par installer le paquet.

Exemple de code 1.1 : installer colo

# emerge colo

Maintenant que c'est installé (j'espère que vous avez lu les messages) vous devriez jeter un coup d'œil au répertoire /usr/lib/colo qui contient deux fichiers : colo-chain.elf, qui est le « noyau » à charger par le firmware d'origine, et colo-rom-image.bin, qui est une image ROM pour remplacer son BOOTROM. Commençons par monter /boot et y mettre une copie compressée de colo-chain.elf là où le système s'attend à la trouver.

Exemple de code 1.1 : mettre CoLo à sa place

# gzip -9vc /usr/lib/colo/colo-chain.elf > /boot/vmlinux.gz

Configurer CoLo

Maintenant, quand le système démarre pour la première fois, il chargera CoLo. Celui-ci va afficher un menu sur votre LCD à l'arrière de la machine. La première option (celle par défaut qui sera validée après 5 secondes) est de démarrer sur le disque dur. Le système propose alors de monter la première partition Linux qu'il trouvera et d'exécuter le script default.colo. La syntaxe de ce fichier est très bien documentée dans la documentation de CoLo (jetez un coup d'œil au fichier /usr/share/doc/colo-X.YY/README.shell.gz — où X.YY est la version de CoLo installée) et est très simple.

Note : une astuce consiste à garder toujours deux noyaux, un kernel.gz.working dont vous savez qu'il fonctionne et kernel.gz.new, celui que vous venez de compiler. Ensuite, utilisez un lien symbolique vers l'un ou l'autre, ou faites une copie de l'un d'eux.

Exemple de code 1.1 : un fichier default.colo de base

#:CoLo:#
mount sda1
load /kernel.gz.working
execute root=/dev/sda3 ro console=ttyS0,115200

Note : CoLo refusera de charger un script qui ne commence pas par la ligne #:CoLo:#. Prenez-le comme une sorte d'équivalent à la ligne #!/bin/sh dans un script shell.

Il est également possible de proposer un menu qui vous demanderait par exemple quel noyau et configuration vous souhaiteriez charger. Le menu aurait un délai de réponse par défaut. Dans cet exemple, le menu demande à l'utilisateur quel noyau il souhaite utiliser, puis l'exécute. vmlinux.gz.new et vmlinux.gz.working peuvent être des images de noyau ou bien simplement des liens pointant vers les images sur le disque. L'argument 50 de select signifie que CoLo démarrera la première option (ici « Working ») après 50 dixièmes de secondes.

Exemple de code 1.1 : configurer avec menu

#:CoLo:#

lcd "Monter sda1"
mount sda1
menu "Quel noyau ?" 50 Working New

goto {menu-option}
var image-name vmlinux.gz.working
goto 3f
@var image-name vmlinux.gz.working
goto 2f
@var image-name vmlinux.gz.new

@lcd "Chargement de Linux" {menu-option}
load / {image-name}
lcd "Démarrage..."
execute root=/dev/sda5 ro console=ttyS0,115200
boot

Référez-vous à la documentation dans /usr/share/doc/colo-VERSION pour plus de détails.

1.  Mise en place pour une console en série

Bon, l'installation de Linux devrait désormais démarrer correctement, mais suppose que vous allez vous connecter dessus depuis un terminal physique. Sur les machines Cobalt, c'est particulièrement ennuyeux dans la mesure où les terminaux physiques... n'existent pas.

Note : ceux qui ont le luxe d'avoir une carte graphique supportée peuvent sauter ce chapitre s'ils le souhaitent.

Tout d'abord, ouvrez un éditeur et allez cherchez le fichier /etc/inittab. Dans celui-ci, vous devriez voir les lignes suivantes :

Exemple de code 1.1 : configurer inittab

# SERIAL CONSOLE
#c0:12345:respawn:/sbin/agetty 9600 ttyS0 vt102

# TERMINALS
c1:12345:respawn:/sbin/agetty 38400 tty1 linux
c2:12345:respawn:/sbin/agetty 38400 tty2 linux
c3:12345:respawn:/sbin/agetty 38400 tty3 linux
c4:12345:respawn:/sbin/agetty 38400 tty4 linux
c5:12345:respawn:/sbin/agetty 38400 tty5 linux
c6:12345:respawn:/sbin/agetty 38400 tty6 linux

# What to do at the "Three Finger Salute".
ca:12345:ctrlaltdel:/sbin/shutdown -r now

Commencez par enlever le commentaire de la ligne c0. Par défaut il est configuré pour utiliser un terminal ayant un taux de transfert de 9600bps. Sur les serveurs Cobalt, vous pouvez changer la valeur à 115200 pour que cela corresponde au taux de transfert décidé par le BOOTROM. Voici à quoi ressemble cette section après avoir commenté les lignes pour les terminaux locaux (c1 à c6) dans la mesure où ceux-ci posent problème quand ils ne peuvent pas ouvrir /dev/ttyX.

Exemple de code 1.1 : extrait de la configuration de inittab

# SERIAL CONSOLE
c0:12345:respawn:/sbin/agetty 115200 ttyS0 vt102

# TERMINALS -- These are useless on a headless qube
#c1:12345:respawn:/sbin/agetty 38400 tty1 linux
#c2:12345:respawn:/sbin/agetty 38400 tty2 linux
#c3:12345:respawn:/sbin/agetty 38400 tty3 linux
#c4:12345:respawn:/sbin/agetty 38400 tty4 linux
#c5:12345:respawn:/sbin/agetty 38400 tty5 linux
#c6:12345:respawn:/sbin/agetty 38400 tty6 linux

Finalement, nous devons indiquer au système que le port série local peut être considéré comme un terminal sûr. Le fichier qu'il vous faudra modifier est /etc/securetty. Il contient une liste de terminaux que le système peut utiliser. Il nous suffit d'ajouter deux lignes pour permettre au port série d'être utilisé pour se connecter en tant que root.

Exemple de code 1.1 : permettre la connexion de root sur la console en série

(/dev/ttyS0, le nom traditionnel du premier port série)
# echo 'ttyS0' >> /etc/securetty

(Ensuite, Linux appelle également cela /dev/tts/0, donc nous
l'ajoutons aussi)
# echo 'tts/0' >> /etc/securetty

1.  Redémarrage du système

Sortez de l'environnement « chroot » et démontez toutes les partitions montées. Ensuite, tapez la commande magique tant attendue : reboot.

Exemple de code 1.1 : sortir du chroot, démontage des partitions et redémarrage

# exit
cdimage ~# cd
cdimage ~# umount -l /mnt/gentoo/dev{/shm,/pts,}
cdimage ~# umount -l /mnt/gentoo{/boot,/proc,}
cdimage ~# reboot

Note : pour les utilisateurs de Cobalt : la suite de ce chapitre concerne la configuration de la PROM SGI afin qu'elle puisse démarrer arcload et charger Linux. Ce n'est pas applicable à la configuration des serveurs Cobalt. En fait, vous avez fini votre travail de configuration et pouvez désormais démarrer sur votre système. Passez directement au chapitre : (Finaliser votre installation de Gentoo).

1.  Peaufiner la PROM SGI

Configuration générale de la PROM

Maintenant que le chargeur de démarrage est installé, vous êtes prêt à redémarrer la machine.

Exemple de code 1.1 : redémarrer

(Quitter l'environnement chroot.)
# exit

(Démonter les disques.)
cdimage ~# umount -l /mnt/gentoo/dev{/shm,/pts,}
cdimage ~# umount -l /mnt/gentoo{/boot,/proc,}

(Redémarrer.)
# reboot

Lorsque vous avez redémarré, allez dans le menu System Maintenance Menu et sélectionnez Enter Command Monitor (5) comme lorsque vous avez démarré votre machine sur le réseau.

Exemple de code 1.1 : configurer la PROM pour démarrer Gentoo

1) Start System
2) Install System Software
3) Run Diagnostics
4) Recover System
5) Enter Command Monitor

Option? 5
Command Monitor.  Type "exit" to return to the menu.

(Quelques options pour arcload.)

(Situer l'entête de volume.)
>> setenv SystemPartition scsi(0)disk(1)rdisk(0)partition(8)

(Démarrer automatiquement Gentoo.)
>> setenv AutoLoad Yes

(Régler le fuseau horaire.)
>> setenv TimeZone EST5EDT

(Utiliser la console série : « g » au lieu de « d1 » pour les possesseurs de carte graphique.)
>> setenv console d1

(Régler la console série : de 9600 (par défaut) à 38400.)
>> setenv dbaud 9600

Les réglages suivants dépendent de comment vous démarrez votre système.

Réglages concernant le démarrage sur l'entête de volume

Nous en partons uniquement dans un soucis d'exhaustivitvé, nous vous recommandons plutôt d'utiliser arcload pour démarrer.

Note : ceci n'est valable que pour Indy, Indigo2 (R4k) et Challenge S.

Exemple de code 1.1 : configurer la PROM pour démarrer Gentoo depuis l'entête de volume

(<périphérique racine> = la partition racine (root) Gentoo, /dev/sda3 par exemple
>> setenv OSLoadPartition <périphérique racine>

(Pour obtenir la liste des noyaux disponibles, tapez « ls ».)
>> setenv OSLoader <nom du noyau>
>> setenv OSLoadFilename <nom du noyau>

(Déclarez les paramètres du noyau à passer en argument.)
>> setenv OSLoadOptions <paramètres du noyau>

Pour essayer un noyau directement, vous pouvez utiliser la commande PROM boot -f :

Exemple de code 1.1 : démarrer sans changer les variables d'environnement

(Démarrer un noyau, « new », avec des paramètres supplémentaires.)
# boot -f new root=/dev/sda3 ro

Réglages pour arcload

arcload utilise l'option OSLoadFilename pour indiquer quelles options charger depuis arc.cf. Ce fichier est essentiellement un script dont les blocs principaux définissent les images de démarrage des différents systèmes et contiennent les options. Donc, l'option OSLoadFilename=mysys(serial) ira chercher les réglages du bloc mysys et applique les options supplémentaires de serial.

Dans l'exemple suivant, nous avons un bloc système de défini, ip28, avec les options working, new et debug. Voici comment nous définissons nos variables PROM :

Exemple de code 1.1 : régler la PROM pour utiliser arcload

(Choisir le chargeur de démarrage : sash64 ou sashARCS)
>> setenv OSLoader sash64

(Utilisation de l'image « working », définie dans la section « ip28 ».)
>> setenv OSLoadFilename ip28(working)

À partir d'arcload-0.5, les fichiers n'ont plus besoin d'être chargés dans l'entête de volume, ils peuvent simplement se trouver sur une partition ext2/3. Pour dire à arcload où chercher ses fichiers de configuration et ses noyaux, vous devez définir la variable PROM OSLoadPartition. La valeur exacte dépendra d'où se situe votre disque sur le bus SCSI. Utilisez la variable PROM SystemPartition pour vous guider, seul le numéro de partition devrait changer.

Note : les partitions sont numérotées à partir de 0.

Exemple de code 1.1 : indiquer à arcload où trouver arc.cf

(Si vous souhaitez le charger depuis l'entête de volume, spécifiez la partition 8.)
>> setenv OSLoadPartition scsi(0)disk(1)rdisk(0)partition(8)

(Sinon, spécifiez le numéro et le type de partition.)
>> setenv OSLoadPartition scsi(0)disk(1)rdisk(0)partition(0)[ext2]

C'est fini

Vous êtes maintenant fin prêt pour apprécier Gentoo ! Démarrer votre installation et concluez avec la (finalisation de l'installation).

Dernière mise à jour le 12 avril 2014

Une version originale plus récente datée du 17 août 2014 existe.

Résumé : Que ce soit les machines Silicon Graphics ou les serveurs Cobalt, les deux réclament l'utilisation d'un chargeur de démarrage pour charger le noyau. Cette section couvre l'installation et la configuration de arcload (pour les machines SGI) et colo, pour les serveurs Cobalt.

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.