Description du processus d'initialisation

Cette section décrit le processus d'initialisation de base sur les plates-formes SPARC et x86. Pour plus d'informations sur les processus d'initialisation sur certains types de matériel, y compris les systèmes qui possèdent des processeurs de service et les systèmes physiques dotés de plusieurs domaines, reportez-vous à la documentation produit correspondant à votre matériel qui est disponible à l'adresse http://www.oracle.com/technetwork/indexes/documentation/index.html.

Le processus de chargement et d'exécution d'un programme autonome est appelé initialisation. En règle générale, le programme autonome est le noyau du système d'exploitation. Cependant, n'importe quel programme autonome peut être initialisé au lieu du noyau.

Sur les plates-formes SPARC, le processus d'initialisation se compose principalement des phases suivantes :

• Lorsque vous mettez un système sous tension, le microprogramme système (PROM) exécute un auto-test au démarrage (POST).

• Une fois que le test a été terminé avec succès, le microprogramme tente de s'autoinitialiser, si l'indicateur approprié a été défini dans la zone de stockage non volatile qui est utilisée par le microprogramme de l'ordinateur :

• Le programme de niveau secondaire est soit un bloc d'initialisation spécifique du système de fichiers lorsque vous procédez à l'initialisation à partir d'un disque, ou bien inetboot ou wanboot lorsque vous effectuez cette opération sur le réseau ou à l'aide du programme d'installation automatisée (AI).

Sur les systèmes x86, le processus d'initialisation se divise en deux phases distinctes du point de vue conceptuel : chargement, puis initialisation du noyau. Le chargement du noyau est assuré par GRUB à l'aide du microprogramme installé sur la carte système et des extensions situées dans les zones ROM des cartes des périphériques. Le microprogramme du système charge GRUB. Le mécanisme de chargement varie en fonction du type du microprogramme installé sur la carte système.

• Après la mise sous tension d'un système compatible PC, le microprogramme exécute un autotest de mise sous tension (POST), localise et installe des extensions du microprogramme à partir des zone ROM de carte des périphériques, puis entame le processus d'initialisation par le biais d'un mécanisme propre au microprogramme.

• Sur les systèmes équipés d''un microprogramme BIOS, le premier secteur physique d'un disque dur (appelé secteur d'initialisation) est chargé en mémoire et son code est exécuté. Pour les disques partitionnés GPT (GUID Partition Table), le code du secteur d'initialisation doit se comporter différemment. Il faut en effet charger ce code à partir d'un autre emplacement car le schéma GPT ne réserve pas le premier secteur de chaque partition au stockage du code du secteur d'initialisation. Dans le cas où GRUB est en cours d'exécution sur le microprogramme BIOS, cet emplacement distinct est une partition dédiée, également connue sous le nom de partition d'initialisation BIOS. Dès que le code du secteur d'initialisation GRUB charge le reste de GRUB dans la mémoire, le processus d'initialisation se poursuit.

  Le programme d'amorçage passe ensuite à l'étape suivante qui, dans le cas d'Oracle Solaris, consiste à charger GRUB. L'initialisation à partir du réseau implique un autre processus sur les systèmes équipés d'un microprogramme BIOS. Reportez-vous au Chapitre 5, Initialisation d'un système à partir du réseau (tâches).

• Sur les systèmes équipés du microprogramme UEFI, le processus d'initialisation est totalement différent. Le microprogramme UEFI recherche la partition système EFI (ESP) sur les disques énumérés, puis charge et exécute des programmes d'initialisation UEFI selon un processus défini par les spécifications UEFI. Une application d'initialisation UEFI est alors chargée dans la mémoire puis exécutée. Sur Oracle Solaris, cette application d'initialisation UEFI correspond à GRUB. La version de GRUB est conçue pour s'exécuter en tant qu'application d'initialisation UEFI. Ensuite, le processus d'initialisation se poursuit comme sur les systèmes équipés d'un microprogramme BIOS.

Pour plus d'informations sur les processus d'initialisation sur certains types de matériel, y compris les systèmes dotés de processeurs de service et les systèmes dotés de plusieurs domaines physiques, reportez-vous à la documentation produit de votre matériel sur http://www.oracle.com/technetwork/indexes/documentation/index.html.

x86 : Différences entre les méthodes d'initialisation UEFI et BIOS

GRUB 2 est en mesure d'initialiser des systèmes équipés d'un microprogramme BIOS ou UEFI et de disques portant l'étiquette GPT. Pour prendre en charge l'initialisation sur le microprogramme UEFI et BIOS, GRUB 2 a été conçu pour cibler deux plates-formes différentes : i386-pc (BIOS) et x86_64-efi (UEFI 2.1+ 64 bits). Il est donc fourni sous forme de deux ensembles discrets de binaires.

Lors de l'initialisation d'un système x86, les différences suivantes s'appliquent aux systèmes de cible BIOS et de cible UEFI :

• Différences en matière de commandes : certaines commandes exécutées par la méthode d'initialisation BIOS ne sont pas disponibles sur le microprogramme UEFI. De la même manière, certaines commandes UEFI ne sont pas disponibles sur les systèmes qui prennent en charge la méthode d'initialisation BIOS.

• Différences en matière d'initialisation réseau PXE : des modifications ont été apportées à la configuration du serveur DHCP afin de prendre en charge l'initialisation des systèmes équipés d'un microprogramme UEFI à partir du réseau. Ces modifications comprennent la prise en charge de la nouvelle valeur d'identifiant d'architecture client UEFI (option DHCP 93).

x86 : Création de partitions d'initialisation prenant en charge les systèmes équipés de microprogrammes UEFI et BIOS

Une nouvelle option -B a été ajoutée à la commande zpool create. Lorsque la commande de création zpool create est exécutée sur un disque entier, l'option -B impose à la commande zpool de diviser le périphérique spécifié en de deux partitions : la première constitue la partition d'initialisation spécifique du microprogramme tandis que la seconde correspond à la partition de données ZFS. Cette option permet également de créer la partition d'initialisation requise lors de l'ajout ou de la connexion d'un disque entier vdev à un pool root rpool existant, si nécessaire. Les conditions dans lesquelles la propriété bootfs est autorisée ont également été modifiées. Il est permis de définir la propriété bootfs pour identifier le jeu de données amorçable au sein d'un pool, à condition que les exigences en matière d'étiquetage des disques et du système soient toutes remplies dans le pool. Conformément aux exigences en matière d'étiquetage, une partition d'initialisation requise doit également être présente. Pour plus d'informations, reportez-vous à la section Gestion de votre pool root ZFS du manuel Administration d’Oracle Solaris 11.1 : Systèmes de fichiers ZFS.