Cette section décrit les problèmes liés au microprogramme dans la version Oracle Solaris 11.3.
Certains systèmes dotés du microprogramme BIOS ne s'initialisent pas si l'entrée EFI_PMBR n'est pas active dans l'enregistrement d'initialisation maître (la seule partition). Après avoir installé Oracle Solaris 11.3, le système ne s'initialise pas. Le message suivant s'affiche :
No Active Partition Found
Cause possible 1 : le microprogramme du système ne gère pas correctement le disque d'initialisation car ce dernier est partitionné avec le schéma de partitionnement GPT (GUID Partition Table).
Solution de contournement 1 : appelez le programme fdisk et activez la partition EFI (Protective Extensible Firmware Interface) sur le disque d'initialisation.
Cause possible 2 : le système a été installé à l'origine en mode UEFI mais a été réinitialisé en mode hérité BIOS.
Solution de contournement 2 : installez le système en mode hérité en modifiant l'option d'installation du microprogramme, en sélectionnant par exemple le mode d'initialisation ou une option similaire.
La prise en charge de disque étiqueté GPT est disponible sur les systèmes SPARC. Le tableau suivant décrit le microprogramme pris en charge pour les plates-formes SPARC.
|
Si votre système SPARC T4, T5, M5 ou M10 possède un microprogramme plus ancien, effectuez les étapes suivantes pour télécharger le microprogramme mis à jour à partir de My Oracle Support :
Connectez-vous à My Oracle Support.
Cliquez sur l'onglet Patches et mises à jour.
Dans la boîte Recherche de patch, sélectionnez l'option de recherche Produit ou famille (avancé).
Dans le champ Produit, saisissez un nom partiel de produit pour afficher la liste des correspondances, puis sélectionnez le nom du produit.
Sélectionnez une ou plusieurs versions dans le menu déroulant Version ?
Cliquez sur le bouton Rechercher pour afficher la liste des téléchargements disponibles, qui sont répertoriés sous forme de patchs.
Sélectionnez le nom du patch que vous souhaitez télécharger.
La page de téléchargement s'affiche.
Cliquez sur Télécharger.
L'initialisation en mode UEFI à partir de l'image ISO est très lente. Ce problème relatif au microprogramme Oracle VM VirtualBox est connu.
Solution de contournement : aucune.
Sur les systèmes x86, Oracle Solaris ne s'initialise pas sur les disques utilisant les anciennes cartes Emulex FC HBA.
Le message d'erreur suivant s'affiche pour les cartes Emulex FC HBA :
error: no such device: 07528c2afbec7b00. Entering rescue mode... grub rescue> ls (hd0) (hd0,gpt9) (hd0,gpt2) (hd0,gpt1) (hd1) grub rescue>
Solution de contournement : choisissez l'une des solutions suivantes :
Remplacez les anciennes carte Emulex FC HBA par un modèle récent. Vous pouvez utiliser SG-XPCIEFCGBE-E8, SG-XPCIE1FC-EM8-Z, SG-XPCIE2FC-EM8-Z, LPe16002-M6-O ou LPem16002-M6-O.
Assurez-vous que le volume d'initialisation du système fait moins de 2 To.
ZFS active le cache d'écriture des périphériques de pool et assure la purge du cache en toute sécurité en cas de perte d'alimentation du système. Cependant, une condition de mise sous tension à la réinitialisation peut se produire alors que les données n'ont pas encore été validée sur une unité de stockage stable.
Dans un environnement sans point de panne unique, cette situation est automatiquement détecté et corrigée par ZFS la fois suivante où les données sont lues. Les nettoyages de routine du pool peuvent améliorer la détection et la réparation des écritures perdues.
Dans un environnement composé d'un point de panne unique, ce problème peut engendrer des pertes de données.
Ce problème peut également se produire plus fréquemment lors de l'accès à des LUN exportés à partir d'une configuration en cluster. Au cours de basculement de cluster, les données mises en mémoire cache par la tête défaillante risquent d'être perdues en cas de mise sous tension à la réinitialisation envoyés par la cible SCSI de manière explicite sur la tête encore fonctionnelle. Dans ce cas, même les pools sans point de panne unique peuvent être affectés.
Un symptôme de ce problème consiste en des clusters d'erreurs de somme de contrôle persistants. Vous pouvez utiliser la sortie de fmdump –eV pour déterminer si les erreurs de somme de contrôle ont été diagnostiquées comme persistantes. L'entrée zio_txg de la sortie fmdump –eV représente le temps d'écriture d'un bloc de données. Notez qu'un motif d'erreurs de somme de contrôle persistant peut également être un symptôme de périphériques, de logiciels ou de matériel défaillants.
Solution de contournement : pour les systèmes qui reposent sur des LUN exportés à partir d'un cluster ou disposant d'un point de panne unique, vous pouvez envisager de désactiver le cache d'écriture pour les périphériques sur un système.
Appliquez les étapes suivantes pour désactiver le cache en écriture et supprimer la purge de cache pour SCSI (sd) ou les périphériques FC (ssd).
Copiez le fichier /kernel/drv/sd.conf ou le fichier /kernel/drv/ssd.conf dans le répertoire /etc/driver/drv, en fonction de vos périphériques de stockage.
Modifiez le fichier /etc/driver/drv/sd.conf ou le fichier /etc/driver/drv/ssd.conf pour désactiver le cache en écriture et supprimer la purge de cache.
Ajoutez des lignes pour remplacer les entrées VID, PID ou SUN COMSTAR avec les valeurs appropriées sur les systèmes SPARC et x64 comme décrit dans la page de manuel sd(7D).
sd-config-list="SUN ZFS Storage", "throttle-max:10, physical-block-size:8192, disable-caching:true, cache-nonvolatile:true";
Réinitialisez le système et ignorez l'option de réinitialisation rapide.
# reboot -p