Print-friendly Version

GRUB et le SE Solaris 10 1/06 : le nouveau chargeur de démarrage pour les plates-formes x86

Shudong Zhou et Jan Setje-Eiler, décembre 2005

Cet article décrit l'architecture de démarrage du système d'exploitation Solaris 10 1/06 sur les plates-formes x86, ainsi que l'expérience de l'utilisateur. Remarque : certains détails de cet article peuvent changer sans préavis. Consultez les pages du manuel et les documents d'administration du SE Solaris pour connaître les interfaces prises en charge.

Le nouveau chargeur de démarrage décrit dans ce document est disponible avant le lancement formel du SE Solaris 10 1/06 auprès de OpenSolaris Project ou du programme Solaris Express.

1. Présentation du processus de démarrage

Lors de la mise sous tension d'un système x86, le BIOS initialise la CPU, la mémoire et le matériel de la plate-forme. Une fois cette opération terminée, le BIOS charge le logiciel d'initialisation initial (c'est-à-dire le chargeur de démarrage) depuis le périphérique de démarrage configuré et lui transmet les commandes. Le SE Solaris 10 3/05 et les versions antérieures utilisent un chargeur de démarrage développé par Sun qui comporte un shell interactif et un assistant de configuration du périphérique géré par menu, basé sur les pilotes en mode réel.

A partir de la version Solaris 10 1/06, le GRUB ou GNU GRand Unified Bootloader open source (voir la référence 1) est utilisé comme chargeur de démarrage. La première distribution est basée sur la version GRUB 0.95 et sera mise à jour à mesure de que nouvelles versions seront disponibles. Le noyau Solaris est totalement compatible avec la spécification Multi-initialisation (référence 2) ; par conséquent, le SE Solaris peut être démarré avec n'importe quel chargeur de démarrage mettant en oeuvre la spécification Multi-initialisation.

Le passage au GRUB présente plusieurs avantages pour les clients Solaris.

• GRUB permet de spécifier très facilement le noyau et les options de démarrage dans le menu de démarrage.

• Pour les utilisateurs finaux, le démarrage et l'installation à partir d'unités DVD USB est désormais pris en charge.

• Il est plus facile pour le SE Solaris de coexister avec d'autres systèmes d'exploitation sur la même machine. En particulier, le SE Solaris peut partager le même chargeur de démarrage GRUB avec Linux.

• Le déploiement du SE Solaris via le réseau est également simplifié, en particulier dans le domaine de la configuration du serveur DHCP. Les options spécifiques du fournisseur ne sont plus nécessaires dans la configuration du serveur DHCP.

• Les développeurs n'ont plus besoin de travailler avec des pilotes en mode réel, qui faisaient partie du chargeur de démarrage requis pour les versions précédentes de Solaris.

• Pour les revendeurs de matériel informatique, il est désormais possible de fournir les pilotes au moment de l'installation via CD/DVD en plus des disquettes.

Enfin, en adoptant un chargeur de démarrage développé par la communauté open source, les clients Sun peuvent exploiter la considérable expérience de GRUB accumulée par cette communauté.

2. Initialisation du SE Solaris avec GRUB

Une fois que GRUB contrôle les opérations, il affiche un menu sur la console, invitant l'utilisateur à choisir une instance du SE à initialiser. L'utilisateur peut choisir une option de menu, modifier une option de menu avec l'éditeur intégré ou charger manuellement un noyau du SE en mode commande. Pour initialiser le SE Solaris, GRUB doit charger un fichier boot_archive et un programme "multiboot" (multi-initialisation). L'archive d'initialisation est une image de disque RAM qui contient les modules de noyau et les données Solaris. GRUB la place simplement en mémoire sans aucune interprétation. Le programme multi-initialisation est un exécutable ELF avec un en-tête compatible avec la spécification multi-initialisation. Une fois le chargement terminé, GRUB redonne le contrôle au programme multi-initialisation. GRUB proprement dit devient inactif et sa mémoire est récupérée.

Le programme multi-initialisation est responsable d'assembler les modules du noyau de base en mémoire en lisant boot_archive et en transmettant des informations relatives à l'initialisation (déterminées dans la spécification multi-initialisation) au noyau. Notez que le programme multi-initialisation va avec le fichier boot_archive. Vous ne pouvez pas mélanger et assembler des informations de multi-initialisation et deboot_archiveà partir de versions ou d'instances différentes du SE.

Lorsque le noyau obtient le contrôle, il initialise la CPU, la mémoire et les périphériques d'E/S, et monte le système de fichiers racine sur le périphérique, comme spécifié par la propriété bootpath avec un type de système de fichiers spécifié par la propriété fstype. Les propriétés peuvent être définies dans/boot/solaris/bootenv.rc via la commande eeprom(1M) ou dans la commande GRUB via le menu ou le shell GRUB. Si les propriétés ne sont pas spécifiées, le système de fichiers racine adopte UFS par défaut sur /devices/ramdisk:a, comme c'est le cas lors du démarrage de la mini racine d'installation.

3. Installation

Le SE Solaris peut être installé à partir d'un CD, d'un DVD et des serveurs d'installation en réseau. Le SE Solaris 10 1/06 diffère de la version Solaris 10 3/05 par plusieurs aspects :

• Mémoire minimale requise : le système doit disposer de 256 Mo de mémoire vive pour initialiser la mini racine d'installation. Les systèmes dont la mémoire est insuffisante reçoivent un message du GRUB : "Selected item can not fit in memory" ("Mémoire insuffisante pour l'élément sélectionné").

• Prise en charge du lecteur USB : l'installation depuis les lecteurs de CD/DVD connectés via des interfaces USB est intégralement prise en charge.

• Installation réseau : la procédure standard de configuration des images d'installation réseau demeure identique. Les clients sont supposés s'initialiser via le mécanisme Preboot eXecution Environment (PXE). Les clients incapables de s'initialiser via le PXE peuvent utiliser une disquette GRUB (voir l'annexe B).

Lors de l'initialisation de la mini racine d'installation, un menu GRUB s'affiche. Un utilisateur peut éditer les options d'initialisation interactivement (voir la section 4.2). Une fois le SE Solaris chargé par le GRUB, le menu d'installation suivant s'affiche :

1. Solaris Interactive (par défaut)
2. JumpStart personnalisé
3. Texte Solaris Interactive (session Bureau)
4. Texte Solaris Interactive (session console)
5. Appliquez les mises à jour du pilote
6. Shell mono utilisateur

L'assistant de configuration du périphérique et le shell interactif associé, que les utilisateurs ont rencontrés dans les versions Solaris 10 3/05 et antérieures, n'existe plus. Les utilisateurs qui souhaitent ajouter les pilotes nécessaires pendant l'installation (par exemple, des pilotes d'adaptateur hôte) doivent choisir l'option 5 et fournir une disquette ou unCD/DVD ITU (Install Time Update, mise à jour d'installation).

L'option 6 est disponible pour récupérer le système. Elle permet d'accéder rapidement à une invite root sans passer par l'identification du système. Cette option est identique à une session de secours Solaris (voir la section 4.4).

4. Gestion du sous-système d'initialisation

4.1 BIOS

Il est généralement préférable de mettre à jour le microprogramme BIOS selon la révision la plus récente avant d'installer le SE Solaris. Vous pouvez généralement le faire en consultant la page d'assistance du fabricant de l'ordinateur.

Par rapport à la version Solaris 10 3/05, le SE Solaris 10 1/06 utilise un sous-ensemble de caractéristiques BIOS différent. En particulier, le noyau utilise davantage d'informations de la table Advanced Configuration and Power Management Interface (ACPI), en utilisant l'analyseur du logiciel ACPI CA d'Intel.

Sur les systèmes non conformes aux spécifications BIOS 2.0, le syslog peut contenir des messages concernant l'analyse de la table ACPI, tels que :

ACPI-0725: *** Warning:
Type override - [4s] had invalid type (DEB_[\200IODB

Ces messages sont inoffensifs et n'exercent aucune influence sur le fonctionnement normal du système. Si des erreurs ACPI empêchent l'initialisation normale du système, l'utilisateur peut désactiver l'analyseur ACPI en réglant acpi-user-options sur 2 (voir eeprom(1M)) dans la ligne de noyau du menu GRUB :

kernel .. -B ...,acpi-user-options=2

Dans ce cas, le système suppose qu'un ensemble de périphériques ISA est présent, notamment un clavier, une souris, deux ports série et un port parallèle.

4.2 Options d'initialisation

Pour initialiser le SE Solaris, un utilisateur peut spécifier le noyau à charger, les options à transmettre au noyau (voir kernel(1M)), et une liste de noms et de valeurs de propriétés pour personnaliser les comportements du système (voir eeprom(1M)). Lors de l'installation de Solaris, un ensemble de valeurs par défaut sont choisies pour le système et stockées dans/boot/solaris/bootenv.rc. Les utilisateurs peuvent changer les paramètres en éditant le menu GRUB ou en modifiant le fichier bootenv.rc indirectement via la commande eeprom(1M).

La spécification du nom et des options du noyau via eeprom exige de paramétrer la propriété boot-file. Pour initialiser le noyau 32 bits en mode détaillé, exécutez la commande suivante :

# eeprom boot-file="kernel/unix -v"

Pour spécifier la même chose dans le menu GRUB, modifiez la commande kernel du menu GRUB :

kernel /platform/i86pc/multiboot

pour :

kernel /platform/i86pc/multiboot kernel/unix -v

Voir kernel(1M) pour connaître les arguments d'initialisation supplémentaires que le noyau Solaris accepte.

Les propriétés autres que boot-file peuvent être spécifiées dans la ligne de commande du noyau GRUB avec cette syntaxe :

kernel /platform/i86pc/multiboot -B prop1=val1[,prop2=val2...]

Pour configurer la console série surttya (com1), définissez la propriété console sur ttya:

kernel /platform/i86pc/multiboot -B console=ttya        

Si la valeur de propriété contient des virgules, la valeur doit être entre guillemets. La commande GRUB paramètre la console Solaris sur ttya à haute vitesse.

kernel /platform/i86pc/multiboot -B console=ttya,ttya-mode="115200,8,n,1,-"

En bref, le fait de spécifier "-B foo=bar" dans le menu GRUB revient à exécuter "eeprom foo=bar". L'option -B dans le GRUB est principalement destinée à des redéfinitions temporaires. Les paramètres permanents doivent être spécifiés via eeprom(1M) afin d'être conservés par le processus de mise à niveau de Solaris.

4.3 Archive d'initialisation

L'archive d'initialisation se rapporte au fichier platform/i86pc/boot_archive. Il s'agit d'une collection de modules noyau et de fichiers de configuration compressés au format UFS ou ISOFS. Pendant l'initialisation, le GRUB charge l'archive d'initialisation dans la mémoire système. Le noyau peut dorénavant s'initialiser à partir des données et du texte de l'archive d'initialisation sans E/S vers le périphérique racine. Lorsque le noyau a obtenu une capacité d'E/S suffisante, il monte le système de fichiers racine sur le périphérique racine réel comme spécifié par la propriété bootpath. A ce stade, l'archive d'initialisation chargée par le GRUB est éliminée de la mémoire.

Le contenu de l'archive d'initialisation est spécifié dans /boot/solaris/filelist.ramdisk. Lors de l'arrêt du système, ce dernier recherche les mises à jour du système de fichiers racine et les mises à jour de l'archive d'initialisation, s'il nécessaire. Le système peut mettre à jour manuellement l'archive d'initialisation avant l'arrêt, en exécutant la commande bootadm(1M).

4.4 Entrée de menu de secours

Le fichier /boot/x86.miniroot-safe, nouveauté du SE Solaris 10 1/06, contient une image Solaris autonome et amorçable. Ce fichier peut être chargé en choisissant l'entrée Solaris failsafe dans le menu GRUB. Ceci pour le confort des administrateurs système lorsque l'initialisation avec l'entrée normale échoue.

Imaginez que vous ajoutez un nouveau package contenant un pilote défectueux et que le système panique pendant l'initialisation. Lors de la réinitialisation, vous pouvez choisir l'entrée Solaris failsafe. En session de secours, montez le système de fichiers racine sur /a et exécutez pkgrm -R pour supprimer le package défectueux. Ensuite, vous pouvez réinitialiser l'entrée Solaris normale pour reprendre l'exploitation du système.

Le fichier /boot/x86.miniroot-safe peut également être copié sur un support portable tel qu'une clé USB comme outil de récupération.

4.5 Maintien du système amorçable

Pour garantir que le système demeure amorçable, les blocs d'initialisation GRUB, le menu GRUB et l'archive d'initialisation doivent être à jour.

Les blocs d'initialisation GRUB résident dans la partition Solaris. Si les blocs GRUB sont corrompus, ils doivent être réinstallés avec la commande installgrub(1M). Notez que installboot(1M) et fmthard(1M) ne sont pas utilisables pour écrire les blocs d'initialisation GRUB.

Le menu GRUB réside dans/boot/grub/menu.lst (ou /stubboot/boot/grub/menu.lst si une partition d'initialisation Solaris est utilisée). La maintenance du menu est effectuée avec la sous-commande bootadm(1M) update-menu. Le GRUB nommant les disques en fonction du numéro de disque BIOS, une modification de configuration du périphérique d'initialisation BIOS peut, dans certains cas, rendre les entrées de menu GRUB incorrectes. L'exécution de bootadm update-menu crée l'entrée de menu correcte dans de tels cas.

L'archive d'initialisation doit être mise à jour à mesure que le système de fichiers racine est modifié. En cas de défaillance du système (panne de courant ou erreur grave du noyau) faisant immédiatement suite à une mise à jour du fichier noyau, l'archive d'initialisation peut être désynchronisée du système de fichiers racine. Dans de tels cas, le service system/boot-archive, géré par Solaris Service Manager (voir svcadm(1M) par exemple), échoue à la réinitialisation suivante. Solaris imprime un message indiquant à l'utilisateur qu'il est toujours possible d'initialiser et d'effacer l'événement à l'origine de l'erreur, mais il est plus prudent de réinitialiser le système, sélectionner une session de secours et mettre à jour l'archive d'initialisation au cours de la session de secours.

5. Configuration de la multi-initialisation

S'il existe d'autres partitions amorçables, le programme d'installation de Solaris tente d'ajouter des entrées GRUB pour elles. A l'heure où nous écrivons, Microsoft Windows et les partitions de diagnostic sont reconnus. Les utilisateurs peuvent ajouter d'autres systèmes d'exploitation en éditant directement le menu GRUB.

Imaginez que vous avez un système comportant le SE Solaris, Linux et Windows disposés comme suit sur le même disque :

        fdisk partition 0:      Windows
        fdisk partition 1:      Linux
        fdisk partition 2:
                slice 0         Solaris 9
                slice 3         Solaris 10 1/06

Le menu GRUB doit présenter l'aspect suivant :

#---------- ADDED BY BOOTADM - DO NOT EDIT ----------
title Solaris 10 1/06
        root (hd0,2,d)
        kernel /platform/i86pc/multiboot
        module /platform/i86pc/boot_archive
#---------------------END BOOTADM--------------------
title Solaris 9
        root (hd0,2,a)
        chainloader +1
        makeactive
title Linux
        root (hd0,1)
        kernel <from Linux's GRUB menu...>
        initrd <from Linux's GRUB menu...>
title Windows
        root (hd0,0)
        chainloader +1

Notez que la partition de disque Solaris fdisk doit être active. Ne placez pas "makeactive" sous le menu Windows. Sinon, le système initialisera toujours Windows.

Le GRUB obtenu auprès d'autres sources que Sun ne reconnaît pas actuellement les formats Solaris sur disque VTOC et UFS. Sun a soumis des modifications au projet GRUB pour les prendre en charge ; jusqu'à leur intégration, seul le GRUB Solaris fonctionne. Si Linux a installé le GRUB sur le bloc d'initialisation maître, vous ne pourrez pas accéder au SE Solaris, même si vous rendez la partition Solaris active. Dans ce cas, vous pouvez charger en chaîne depuis le GRUB Linux en modifiant le menu dans Linux. Sinon, vous pouvez aussi remplacer le secteur d'initialisation maître par le GRUB Solaris de l'exemple ci-dessus, en utilisant la commandeinstallgrub(1M) :

installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c0t2d0s3

En attendant la propagation de l'implémentation Solaris de l'UFS et de la VTOC à la version standard du GRUB, seule la version Solaris du GRUB fonctionne.

6. Initialisation réseau et clients sans disque

L'initialisation depuis un réseau exige généralement un serveur DHCP configuré pour les clients PXE et un serveur d'initialisation offrant le service TFTP. En l'absence d'un serveur PXE/DHCP disponible (ou si le BIOS ne contient pas le code PXE), il est possible de charger le GRUB à partir d'une disquette, d'un CD-ROM ou d'un disque local, de configurer le réseau manuellement dans le menu GRUB et d'initialiser le SE Solaris à partir d'un serveur de fichiers. Voir l'annexe B pour des informations plus détaillées.

La configuration du serveur DHCP est une tâche spécifique au site qui relève de l'administrateur du réseau local. Voir le document Sun BluePrints, “Configuring JumpStart Servers to Provision Sun x86-64 Systems”: http://www.sun.com/blueprints/0205/819-1692.pdf.

Pour initialiser le SE Solaris, le serveur DHCP doit répondre à la demande du BIOS PXE avec l'adresse IP du serveur de fichiers et le nom du fichier d'initialisation (pxegrub). Le serveur d'initialisation est responsable de la fourniture du binaire pxegrub, du menu GRUB, du programme multi-initialisation et d'une archive d'initialisation. Des outils standard sont fournis pour configurer le serveur d'initialisation.

6.1 Serveur d'installation réseau

La commande add_install_client(1M) sert à configurer l'installation réseau pour les clients d'installation. Pour les versions Solaris 10 1/06 et ultérieures, add_install_client(1M) doit toujours être appelé avec l'option -d pour l'initialisation PXE/DHCP, même si une disquette GRUB est utilisée pour initialiser sur le réseau.

Après l'exécution de add_install_client, /tftpboot/01<eth_addr> doit figurer sous forme de lien vers pxegrub et /tftpboot/menu.lst.01<eth_addr> contenant une entrée de menu GRUB. <eth_addr> est l'adresse Ethernet de l'interface réseau du client en capitales. En outre, le répertoire /boot de l'image réseau est monté en loopback sous/tftpboot pour rendremultiboot et x86.miniroot accessibles via tftp.

6.2. Clients sans disque

La commande smdiskless(1M) sert à configurer les clients sans disque. Dans les versions précédentes, smdiskless(1M) configure les systèmes de fichiers root et usr et exporte vers les clients par NFS. Toutefois, les utilisateurs doivent configurer manuellement la zone /tftpboot pour initialiser les clients. Cette étape manuelle a été supprimée dans le SE Solaris 10 1/06. La commande smdiskless(1M) appelle automatiquement un script dans/usr/sadm/lib/wbem/config_tftp pour configurer la zone/tftpboot pour l'initialisation PXE.

Après l'exécution de smdiskless, /tftpboot/01<eth_addr> doit figurer sous forme de lien verspxegrub et /tftpboot/menu.lst.01<eth_addr> contenant une entrée de menu GRUB. <eth_addr> est l'adresse Ethernet de l'interface réseau du client en capitales. En outre, /export/root/<hostname>/boot est monté en loopback sous /tftpboot pour rendre la multi-initialisation et l'archive d'initialisation du client accessible via tftp.

L'archive d'initialisation des clients sans disque est automatiquement mise à jour à l'arrêt du client. Si l'archive d'initialisation du client est périmée lors de l'arrêt du client, elle peut être mise à jour du côté serveur en utilisant :

# bootadm update-archive -R /export/root/<hostname>

Cette méthode fonctionne sur les serveurs sur plate-forme SPARC et x86 servant des clients x86.

7. Problèmes liés aux éléments hérités

7.1 La partition d'initialisation Solaris x86

Pour les systèmes x86, la partition d'initialisation Solaris est une toute petite partition (environ 10 Mo) principale fdisk au format PCFS (FAT). Elle a été introduite dans la version Solaris 2.6, principalement parce que, à l'époque, le microprogramme du BIOS ne pouvait pas accéder aux blocs de disques au-delà de 1024 cylindres. Il était nécessaire de placer le code d'initialisation dans une petite zone proche du début du disque. La partition d'initialisation permettait d'installer le SE Solaris sur un disque non amorçable avec des exigences d'espace minimes sur le disque d'initialisation.

Avec les systèmes modernes, la partition d'initialisation est devenue inutile. A partir du SE Solaris 10 1/06, les utilisateurs n'ont plus l'option de créer une partition d'initialisation. Lors de la mise à niveau d'une ancienne version, une partition d'initialisation x86 peut être conservée pour maintenir le système amorçable sans intervention manuelle. Dans de tels cas, la partition d'initialisation x86 est montée au niveau/stubboot et contient les blocs d'initialisation GRUB et un fichier de menu/stubboot/boot/grub/menu.lst. L'utilisateur peut éliminer la partition d'initialisation x86 en supprimant l'entrée /stubbootde /etc/vfstab, en modifiant /boot/grub/menu.lst, et en reconfigurant le BIOS pour qu'il démarre depuis la partition du disque Solaris.

7.2 Pilotes en mode réel

Avant le SE Solaris 10 1/06, les pilotes en mode réel étaient exécutés dans le cadre du processus d'initialisation. Il est possible que certains pilotes de noyau dépendent implicitement d'un pilote en mode réel correspondant pour placer le matériel dans un état spécifique. Les pilotes en mode réel ne faisant plus partie de l'initialisation GRUB, un tel pilote de noyau peut ne pas fonctionner correctement. Si vous rencontrez ce type de cas, signalez le problème au fournisseur du pilote afin de modifier le pilote de noyau.

Annexe A. Bases GRUB

Cette annexe décrit les concepts de base du GRUB. Certains détails de cette annexe peuvent changer sans préavis. Consultez la documentation GRUB pour des informations plus détaillées.

A.1 Nommage du périphérique

L'objectif principal d'un chargeur de démarrage consiste à charger des données d'un périphérique de stockage dans la mémoire du système. Pour utiliser le GRUB, il est nécessaire de comprendre comment il nomme les périphériques.

La disquette est nommée :

(fd0) -- first, second floppy

Le GRUB ne peut référencer qu'une seule interface réseau :

(nd) -- network interface

Il s'agit presque toujours de l'interface sondée par le BIOS et configurée via DHCP. Il est également possible de configurer une interface réseau en initialisant le GRUB à partir d'une disquette ou d'un autre support local (voir l'annexe B).

Les noms des disques durs commencent par hd et un chiffre, dans lequel 0 mappe vers le disque BIOS 0x80 (premier disque énuméré par le BIOS), 1 mappe vers 0x81, et ainsi de suite.

(hd0) -- first bios disk (also the BIOS boot disk 0x81)
(hd1) -- second bios disk (BIOS disk 0x81)
(hd0,1) -- first bios disk, second primary partition
(hd0,0,a) -- first bios disk, first fdisk partition, Solaris/BSD slice 0 and 1

Sachez que la numérotation des disques par le BIOS peut changer lorsque la configuration du BIOS est modifiée. Par conséquent, le menu GRUB peut être invalidé si vous changez l'ordre du disque d'initialisation BIOS ou si vous modifiez la configuration du disque. Pour résoudre les problèmes liés à la renumérotation des disques dans le BIOS, il est essentiel de connaître les conventions de nommage des disques.

A.2 Composants fonctionnels

Le composants fonctionnels GRUB comprennent stage1, stage2 et menu.lst. stage1 est installé sur le premier secteur de la partition Solaris fdisk et peut être facultativement installé dans le secteur d'initialisation maître. stage2 est installé dans une zone réservée de la partition Solaris. menu.lst est situé dans/boot/grub et lu par le GRUBstage2.

Notez que vous ne pouvez pas utiliser dd(1M) pour écrire stage1 et stage2 sur le disque car stage1 doit savoir oùstage2est situé sur le disque. La commande installgrub(1M) représente la méthode prise en charge pour installer les blocs d'initialisation GRUB.

Le shell GRUB, bien que présent dans /boot/grub/bin/grub, n'est pas encore pris en charge, et certaines des commandes ne fonctionnent pas avec le SE Solaris en raison des limitations du système pour les appels de BIOS.

A.3 Le menu GRUB

Le fichier de menu par défaut est /boot/grub/menu.lst. Les éditions manuelles de menu.lst prennent effet à la réinitialisation suivante. Un menu GRUB présente généralement l'aspect suivant :

default 0
timeout 10
serial --unit=0 --speed=9600
terminal serial
#---------- ADDED BY BOOTADM - DO NOT EDIT ----------
title Solaris
  root (hd0,0,a)
  kernel /platform/i86pc/multiboot -B console=ttya
  module /platform/i86pc/boot_archive
#---------------------END BOOTADM--------------------
#---------- ADDED BY BOOTADM - DO NOT EDIT ----------
title Solaris failsafe
  root (hd0,0,a)
  kernel /boot/multiboot -B console=ttya -s
  module /boot/x86.miniroot.safe
#---------------------END BOOTADM--------------------

La ligne "default" spécifie quel élément initialiser en cas d'expiration du minuteur. La ligne "timeout" indique le nombre de secondes d'attente de la saisie de l'utilisateur avant d'initialiser l'entrée par défaut. Si timeout est -1, une entrée utilisateur est nécessaire. Ensemble, les commandes serial et terminal basculent la sortie GRUB vers le port série spécifié dans la ligne tip serial –unit. La commande root spécifie à partir de quel disque, quelle partition et quelle tranche charger les fichiers. GRUB détecte automatiquement le type de système de fichiers. La commande kernel doit être suivie d'un programme multi-initialisation. La chaîne suivant la multi-initialisation est transmise au SE Solaris sans interprétation.

Pour spécifier explicitement un noyau 64 bits, modifiez la commande de noyau GRUB pour :

kernel /platform/i86pc/multiboot kernel/amd64/unix

De la même façon, la commande suivante initialise le noyau 32 bits :

kernel /platform/i86pc/multiboot kernel/unix

A.4 Mode commande GRUB

Vous pouvez initialiser le SE en tapant les commandes à l'invite GRUB. Pour obtenir l'invite GRUB, appuyez sur 'c' dans le menu GRUB; Tapez 'help' pour obtenir la liste des commandes disponibles. Appuyez sur Echap pour revenir au menu. Vous pouvez aussi appuyer sur 'e' pour modifier une option de menu existante. Une fois la modification terminée, appuyez sur 'b' pour initialiser le système avec l'entrée GRUB modifiée.

Annexe B. Déploiement en réseau

Cette annexe décrit les meilleures pratiques de déploiement du SE Solaris sur les plates-formes x86 via le réseau. Certains détails de cette annexe peuvent changer sans préavis. Consultez les pages du manuel et les documents d'administration de Solaris pour connaître les interfaces prises en charge.

B.1 Vue d'ensemble du déploiement de Solaris en réseau

L'idée de déployer le SE Solaris sur le réseau vise à placer les images du SE Solaris dans un emplacement centralisé. Toute machine connectée au réseau peut initialiser et installer la version choisie avec une intervention minime ou nulle de l'administrateur. Le processus d'installation peut même être effectué de façon pratique via le logiciel Solaris JumpStart.

L'initialisation à partir du réseau nécessite généralement un serveur DHCP configuré pour les clients PXE et un serveur de fichiers offrant le servicetftp. Le serveur DHCP est responsable de la fourniture des informations nécessaires au client pour configurer son interface réseau. La réponse du DHCP contient également l'adresse IP du serveur de fichiers et le nom du fichier d'initialisation (pxegrub). Le serveur de fichiers est responsable de fournir le binaire pxegrub, le menu GRUB, le programme multi-initialisation et l'archive d'initialisation. Par défaut, le fichier de menu GRUB est menu.lst.01<eth_addr>. Si ce fichier n'existe pas, pxegrub revient à l'option DHCP 150 (si elle est spécifiée) ou à /tftpboot/boot/grub/menu.lst.

L'initialisation du SE Solaris en utilisant PXE fonctionne comme suit :

1. L'utilisateur configure le BIOS à partir d'une interface réseau.
2. Le BIOS envoie une requête DHCP.
3. Le serveur DHCP répond avec l'adresse du serveur et le nom du fichier d'initialisation.
4. Le BIOS télécharge pxegrub depuis le serveur via tftp et exécute pxegrub.
5. Le système télécharge un menu GRUB via tftp et affiche les entrées de menu.
6. L'utilisateur sélectionne l'entrée de menu et démarre le téléchargement du SE Solaris.

Dans un scénario de déploiement type, pxegrub télécharge le programme multi-initialisation et le fichier x86.miniroot, qui est décompressé dans une mini racine en mémoire. Une fois la mini racine en cours d'exécution, elle monte l'image Solaris (comme spécifié dans la propriété install_media dans le menu GRUB) sur /cdrom, et le processus d'installation commence.

Dans les sections qui suivent, nous entrerons dans les détails de configuration du serveur DHCP, les exigences du client et plusieurs scénarios de déploiement.

B.2 Le service DHCP

Lorsqu'un client envoie une requête DHCP, le serveur est informé de l'identité du client (généralement son adresse Ethernet), de la "classe" de la requête et du sous-réseau dans lequel le client réside. Le serveur DHCP Solaris forme les macros basées sur les réponses correspondant aux requêtes du client :

• Une macro de classe

• Une macro de réseau

• Une macro IP

• Une macro de client

La macro de classe est nommée par une "chaîne de classe" intégrée à la requête DHCP. Sur les plates-formes x86, le BIOS effectue toujours une requête DHCP avec la classe PXEClient:Arch:00000:UNDI:002001. Lorsqu'une macro portant ce nom est définie dans la configuration du serveur DHCP, le contenu de la macro est envoyé aux clients x86 à l'étape (c) de la section B.1.

La macro de réseau est nommée par l'adresse IP du sous-réseau. Si une macro 129.146.87.0est définie sur le serveur DHCP, le contenu de la macro est envoyé à tous les clients de ce sous-réseau, quelle que soit la classe de la requête. Si une option est définie dans la macro de classe et dans la macro de réseau, cette dernière prend le pas.

La macro IP est nommée par l'adresse IP. Elle est rarement utilisée dans le contexte d'initialisation du SE Solaris sur les plates-formes x86.

La macro de client est nommée par le type de client (01 pour ether) et l'adresse MAC en lettres capitales. Pour un client dont l'adresse Ethernet est 0:0:39:fc:f2:ef, le nom de macro correspondant est 01000039FCF2EF.

Imaginons que nous avons un client dans le sous-réseau 129.146.87.0 dont l'adresse Ethernet est 0:0:39:fc:f2:ef effectuant une requête DHCP de classePXEClient.

Le serveur DHCP contient des macros correspondantes :

- PXEClient
BootSrvA:  129.146.87.194
BootFile:  pxegrub
- 129.146.87.0
Router:    129.146.87.1
NISdmain:  sunsoft.eng.sun.com
- 01000039FCF2EF
BootFile:  01000039FCF2EF

La réponse effective du DHCP est la suivante :

BootSrvA:  129.146.87.194
BootFile:  01000039FCF2EF
Router:    129.146.87.1
NISdmain:  sunsoft.eng.sun.com

Notez que BootFile dans la macro client prend le pas sur BootFile dans la macro de classe.

B.3. La configuration d'initialisation réseau la plus simple

Vous devez disposer au strict minimum d'un serveur et d'un client. Le serveur doit comporter un serveur DHCP fonctionnel et disposer d'une image de distribution Solaris. La machine cliente est connectée au même sous-réseau que le serveur capable de prendre en charge une demande d'initialisation PXE. Voici des étapes de configuration du serveur, en supposant que l'adresse IP du serveur est 192.168.0.123 et que l'adresse Ethernet du client est 0:0:39:fc:f2:ef.

a. Accédez au répertoire Tools de l'image de distribution Solaris et exécutez :

# add_install_client -d -e 0:0:39:fc:f2:ef i86pc

b. Créez un nom de macro client 01000039FCF2EF pour le service DHCP avec :

BootSrvA:  192.168.0.123
BootFile:  01000039FCF2EF

Vous pouvez le faire à partir de l'IG dhcpmgr ou des interfaces de ligne de commande.

Vous pouvez maintenant initialiser le client et installer le SE Solaris.

B.4. Installation en réseau sans PXE/DHCP

Il est possible de télécharger le GRUB à partir d'une disquette, d'un CD-ROM ou d'un disque local, de configurer le réseau manuellement dans le GRUB et de télécharger multiboot et boot_archive depuis le serveur de fichiers. Vous pouvez le faire pour de nombreuses raisons :

• Le BIOS du client ne prend pas PXE en charge.
• La carte réseau n'a pas UNDI ROM;
• Il n'y a pas de service DHCP sur le réseau.
• Vous pouvez automatiser les séquences d'installation/réinitialisation sans reconfigurer l'ordre des périphériques d'initialisation dans le BIOS.

Lestage2 standard du GRUB installé avec le SE Solaris contient la prise en charge de l'initialisation réseau. Vous pouvez utiliser la fonction en appuyant sur 'c' dans le menu GRUB pour passer en mode commande. Voici un exemple concret :

grub> ifconfig --address=192.168.0.02 --gateway=192.168.0.1 
   --mask=255.255.255.0 --server=192.168.123.110
grub> root (nd)
grub> kernel /multiboot.I86PC.Solaris_10-1 kernel/unix -B
   install_media=192.168.123.110:/export/setje/boot_74L2
grub> module /x86.miniroot
grub> boot

Bien entendu, la commande ifconfig doit être spécifiée avec des valeurs appropriées pour votre environnement de réseau local. Vous pouvez aussi ajouter une entrée de menu avec les commandes ci-dessus au fichier menu.lst sur le disque ou la disquette.

N'oubliez pas d'éditer /boot/grub/menu.lst sur la disquette avant de l'utiliser. Si votre carte réseau contient UNDI ROM, choisissez simplement l'image UNDI de la disquette. Sinon, choisissez l'image de la disquette avec le nom de pilote Solaris correspondant (bge, e1000g, et ainsi de suite). Si vous avez unstage2 GRUB spécial et que vous souhaitez préparer votre propre disquette, voici les instructions correspondantes :

<format floppy>
# mount -F pcfs /dev/diskette /mnt (you may have to disable vold prior to doing this)
# cd /boot/grub
# /sbin/installgrub stage1 stage2 /dev/rdiskette
stage1 written to boot sector on floppy
first 2 sectors of stage2 written on floppy

Editez /mnt/boot/grub/menu.lst afin qu'il contienne l'entrée suivante :

title Solaris
  ifconfig --address=192.168.0.2 --gateway=192.168.0.1 
     --mask=255.255.255.0 --server=192.168.123.110
  root (nd)
  kernel /multiboot.I86PC.Solaris_11-1 kernel/unix -B
     install_media=192.168.123.110:/export/setje/boot_74L2
  module /x86.miniroot

B.5. Gestion de plusieurs images Solaris

En présence de plusieurs images Solaris, il vous faut une méthode de sélection de la version ou construction à installer pour chaque client. Voici quelques possibilités pour ce faire.

1. Conservez le serveur DHCP inchangé et exécutez add_install_client sur le serveur d'initialisation.
2. Conservez le serveur d'initialisation inchangé et modifiez la macro de client DHCP (via l'interface web) pour choisir la version/construction.
3. Maintenez le serveur d'initialisation et le serveur DHCP inchangés, et le client choisit la version/build dans le menu GRUB.

Le cas (a) est la méthode de gestion standard du serveur d'initialisation. L'administrateur réseau effectue une seule configuration du service DHCP pour chaque client. Ensuite, l'utilisateur du client se connecte au serveur d'initialisation et exécute add_install_client. Si vous avez une configuration DHCP fonctionnelle pour les clients FCS Solaris 10, la même configuration fonctionne avec une initialisation basée sur pxegrub.

Le cas (b) nécessite d'utiliser l'option DHCP 150 pour fournir le fichier de menu GRUB. Lorsque l'utilisateur sélectionne une version/build pour un client, la configuration DHCP est modifiée pour définir l'option 150 dans le fichier de menu contenant la version/build sélectionnée. Notez que le fichier de menu pour chaque version/build doit être créé à priori sur le serveur d'initialisation. Si la version/build sélectionnée n'utilise paspxegrub pour s'initialiser, l'ancien paramètrage Solaris est configuré.

Le cas (c) ne fonctionne que pour les versions ou build basées surpxegrub. Lorsqu'une nouvelle image est ajoutée côté serveur, une entrée de menu est annexée. Lors de l'initialisation d'un client, la nouvelle entrée de menu est disponible et peut être sélectionnée. Malheureusement, pxegrub ne peut pas "charger en chaîne" l'ancien programme d'initialisation réseau de Solaris (intitulé nbp). Pour que les sélections du client fonctionnent entre nbp et pxegrub, vous pouvez configurer pxelinux sur le serveur, qui peut charger nbp ou pxegrub. L'étude détaillée de pxelinux dépasse l'étendue de cet article.

B.6. Séquence de déploiement automatisée

Le déploiement automatisé effectue souvent la séquence suivante :

• Initialisation du réseau et installation du SE Solaris sur un disque via le logiciel Solaris JumpStart.
• Réinitialisation du disque et exécution d'un ensemble de tâches préconfigurées.

A l'issue du déploiement, la machine reste en attente de l'action suivante.

Dans la plupart des cas, l'initialisation réseau initiale peut être déclenchée manuellement en appuyant sur la touche F12 (ou une autre séquence de touches, selon la plate-forme). Toutefois, certains systèmes ne prennent pas en charge la redirection de console série BIOS, et il n'est pas raisonnable d'exiger la présence d'un utilisateur à la console physique. De plus, certains BIOS offrent un créneau temporel très court pour demander l'initialisation réseau, ce qui est inconfortable pour l'utilisateur. Une solution de contournement consiste à initialiser depuis la disquette vers le réseau, puis à réécrire la disquette pour initialiser le disque. Cette méthode n'est plus viable car les plates-formes les plus récentes ne sont plus livrées avec des lecteurs de disquette.

Nous recommandons de charger le GRUB depuis le disque. Ajoutez l'entrée de menu suivante dans/boot/grub/menu.lst pour initialiser sur le réseau pour JumpStart et faites-en l'entrée d'initialisation par défaut par l'intermédiaire de cette commande :

 # bootadm set-menu default=<menu_entry_number>

où <menu_entry_number> est l'option de menu (numérotation à partir de 0) de l'option que vous ajoutez ci-dessous :

title Solaris Jumpstart
        dhcp
        root (nd)
        kernel .../multiboot kernel/unix - install -B console=...
        module ../x86.miniroot

Une fois le système installé, l'entrée par défautboot =. est modifiée automatiquement pour initialiser à partir du disque. Ainsi, l'ensemble de la séquence de déploiement peut être initiée via un cycle de puissance.

B.7. Dépannage

Qu'advient-il si cela ne fonctionne pas ? Voici quelques conseils de dépannage.

a. Le client s'initialise directement du disque sans tenter d'initialisation réseau.

Cela signifie généralement que le client PXE ROM est désactivé ou que le BIOS est configuré pour initialisation depuis le disque avant le réseau. Pour résoudre ce problème, accédez au BIOS et modifiez la configuration. Les détails varient selon la machine.

b. Le client tente l'initialisation réseau, mais n'obtient pas de réponse.

Effectuez les vérifications habituelles de câbles réseau, témoins DEL (le cas échéant) sur la carte réseau, et ainsi de suite. Exécutez snoop sur le serveur :

# snoop -v [-d <interface>] 0:0:39:fc:f2:ef

où <interface> est quelque chose comme bge0. L'option -d n'est nécessaire que si le serveur compte plusieurs cartes d'interface réseau. Voici ce que vous devez voir :

• DHCPDISCOVER (client -> serveur)
• DHCPOFFER (serveur -> client)
• DHCPREQUEST (client -> serveur)
• DHCPACK (serveur -> client)

S'il n'y a pas de messageDHCPDISCOVER, le client ne transmet pas, généralement en raison d'un câble ou d'une carte interface défectueux.

Si vous voyez le paquet DHCPDISCOVER mais pas de message DHCPOFFER, cela signifie que le serveur ne répond pas. Regardez le message DHCPDISCOVER pour vérifier que l'adresse Ethernet correspond au nom de macro dans le serveur DHCP. Si le serveur utilise des macros de classe, vérifiez que la chaîne de classe correspond. La chaîne de classe dans la requête DHCP du BIOS est toujours la suivante :

PXEClient:Arch:00000:UNDI:002001

c. Le client affiche un message de délai d'attente TFTP.

Ceci peut arriver lorsque le service tftp est mal configuré. Vérifiez sur le serveur que tftp est activé (in.tftpd est exécuté) et que le fichier/tftpboot/01000039FCF2EF existe et qu'il est lié au binaire pxegrub. L'étape add_install_client est supposée configurer le fichier tftp et le service tftp.

d. Le client se fige au milieu du téléchargement de x86.miniroot.

Le protocole TFTP peut transférer des blocs jusqu'à 65K. Certains serveurs tftp (par exemple ceux qui exécutent le SE Solaris 8) ne prennent en charge que des blocs de petite taille (512), résultant en une taille maximale de fichier de 32 Mo, moins de la moitié de la taille dex86.miniroot (environ 45 Mo). La mise à niveau du serveur tftp résoudra le problème.

Si le serveur exécute le SE Solaris 8, vous pouvez copier /usr/sbin/in.tftpd du SE Solaris 9, jusqu'à ce que le patch TFTP pour le SE Solaris 8 soit disponible.

e. Le client termine le téléchargement de x86.miniroot puis se fige.

Il est probable que la sortie de la console soit allée ailleurs. Vérifiez que la variable console est correctement configurée dans la ligne de menu GRUB. Configurer les périphériques d'entrée/de sortie fonctionne également. Voir la section 4.2.

f. Le client affiche le message "No ethernet card found" (carte Ethernet introuvable).

Ceci peut se produire en initialisant le GRUB depuis un support local et en chargeant le SE Solaris depuis le réseau. C'est une indication que le GRUB ne trouve pas d'interface réseau utilisant le service PCI BIOS32.

g. Le client affiche le message "No PnPBios found" (PnPBios introuvable).

Ceci peut se produire en initialisant le GRUB depuis un support local et en chargeant le SE Solaris depuis le réseau. Dans ce cas, le GRUB a localisé l'interface réseau, mais n'a pas réussi à localiser le service PnP Bios pour installer UNDI ROM à partir de la carte d'interface réseau.

Références

1. Page web GNU GRUB (http://www.gnu.org/software/grub/grub.html)
2. Page web Spécification multi-initialisation sur le site GNU (http://www.gnu.org/software/grub/manual/multiboot/multiboot.html)
3. FAQ pour le GRUB et le SE Solaris 10 1/06 : le nouveau chargeur de démarrage pour les plates-formes x86 (http://www.sun.com/bigadmin/features/articles/grub_boot_faq.html)

Unless otherwise licensed, code in all technical manuals herein (including articles, FAQs, samples) is provided under this License.