En esta sección, se describen los problemas de firmware para la versión Oracle Solaris 11.4.
Algunos sistemas con firmware BIOS no inician si la entrada EFI_PMBR en el registro de inicio maestro (MBR), que es la única partición, no está activa. Después de instalar Oracle Solaris 11.4, el sistema no se inicia. Aparece el mensaje siguiente:
No Active Partition Found
Causa posible 1: el firmware del sistema maneja de forma incorrecta el disco de inicio, ya que el disco de inicio está particionado con el esquema de partición de la tabla de particiones GUID (GPT).
Solución alternativa 1: invoque el programa fdisk y, a continuación, active la partición protectora de interfaz de firmware extensible (EFI) del disco de inicio.
Causa posible 2: el sistema se instaló originalmente en modo UEFI pero se reinició en modo Legacy BIOS.
Solución alternativa 2: instale el sistema en modo Legacy BIOS mediante el cambio de la opción de configuración de firmware, por ejemplo, seleccionando “Boot Mode” (Modo de inicio) o una opción similar.
La compatibilidad con un disco con etiqueta GPT está disponible en sistemas basados en SPARC. La siguiente tabla describe el firmware admitido para plataformas SPARC.
|
Si su sistema SPARC T4, T5, M5 o M10 tiene un firmware anterior, realice los siguientes pasos para descargar el firmware actualizado de My Oracle Support:
Inicie sesión en My Oracle Support.
Haga clic en la ficha Parches y actualizaciones.
En el cuadro de búsqueda de parches, seleccione la opción de búsqueda Producto o Familia (búsqueda avanzada).
En el campo Producto, introduzca una parte del nombre del producto para ver una lista de posibles coincidencias y, a continuación, seleccione el nombre del producto.
Seleccione una o más versiones del menú desplegable Versión.
Haga clic en el botón Buscar para mostrar una lista de las descargas disponibles que aparecen como parches.
Seleccione el nombre del parche que desea descargar.
Se muestra la página de descarga.
Haga clic en Descargar.
El inicio en modo UEFI desde la imagen ISO es muy lento. Se trata de un problema conocido de firmware de Oracle VM VirtualBox.
Solución alternativa: ninguna.
En sistemas x86, Oracle Solaris no se inicia en discos con tarjetas HBA FC Emulex más antiguas.
Para tarjetas HBA FC Emulex aparecerá el siguiente mensaje de error:
error: no such device: 07528c2afbec7b00. Entering rescue mode... grub rescue> ls (hd0) (hd0,gpt9) (hd0,gpt2) (hd0,gpt1) (hd1) grub rescue>
Solución alternativa: opte por una de estas soluciones:
Sustituya las tarjetas HBA FC Emulex antiguas con un modelo reciente. Puede utilizar SG-XPCIEFCGBE-E8, SG-XPCIE1FC-EM8-Z, SG-XPCIE2FC-EM8-Z, LPe16002-M6-O o LPem16002-M6-O.
Asegúrese de que el volumen de inicio del sistema sea menor de 2 TB.
ZFS activa la caché de escritura en dispositivos de agrupación y maneja de forma segura el vaciado de caché en el caso de interrupción de la energía del sistema. Sin embargo, una condición de restablecimiento de encendido puede producirse si los datos aún no se han enviado al almacenamiento estable.
En un entorno sin un único punto de fallo, esta situación es detectada y corregida automáticamente por ZFS la próxima vez que se leen los datos. Las limpiezas de rutina de la agrupación pueden aumentar la detección y reparar cualquier escritura perdida.
En un entorno con un único punto de fallo, este problema puede provocar la pérdida de datos.
Este problema también puede ocurrir con mayor frecuencia al acceder a LUN exportados desde una configuración en cluster. Durante el failover del cluster, los datos almacenados en caché por el nodo principal fallido pueden perderse debido a un evento de restablecimiento de encendido enviado explícitamente por el destino SCSI en el nodo principal superviviente. En esta situación, incluso las agrupaciones sin ningún punto de fallo único pueden resultar afectadas.
Un síntoma de este problema es un cluster de errores de suma de comprobación persistentes. Puede utilizar la salida de fmdump –eV para determinar si los errores de suma de comprobación se diagnosticaron como persistentes. La entrada zio_txg en la salida fmdump –eV representa el tiempo en que se escribe un bloque de datos. Tenga en cuenta que un patrón de errores de suma de comprobación persistentes también puede ser un síntoma de dispositivos, software o hardware fallidos.
Solución alternativa: para los sistemas que se basan en los LUN exportados desde un cluster o sistemas con un único punto de fallo, considere la desactivación de la caché de escritura para los dispositivos en un sistema.
Realice los siguientes pasos para desactivar la caché de escritura y suprimir el vaciado de caché para dispositivos SCSI (sd) o FC (sd o ssd; consulte SPARC: cambios de configuración para almacenamiento de canal de fibra).
Copie el archivo /kernel/drv/sd.conf o el archivo /kernel/drv/ssd.conf en el directorio /etc/driver/drv en función de sus dispositivos de almacenamiento.
Edite el archivo /etc/driver/drv/sd.conf o el archivo /etc/driver/drv/ssd.conf para desactivar la caché de escritura y suprimir el vaciado de caché.
Agregue líneas para reemplazar los valores VID, PID o SUN COMSTAR con los valores adecuados que se describen en la página del comando man sd(4D).
sd-config-list="SUN Storage", "throttle-max:10, physical-block-size:8192, disable-caching:true, cache-nonvolatile:true";
Reinicie el sistema y sustituya la opción de reinicio rápido.
# reboot -p