Go to main content

Oracle® Solaris 11.4 Release Notes

Exit Print View

Updated: May 2021

Firmware Issues

This section describes firmware issues in the Oracle Solaris 11.4 release.

x86: Some Systems With BIOS Firmware Do Not Boot If the EFI_PMBR Entry in the Master Boot Record Is Not Active (15796456)

Some systems with BIOS firmware will not boot if the EFI_PMBR entry in the master boot record, which is the only partition, is not active. After installing Oracle Solaris 11.4, the system does not boot. The following message is displayed:

No Active Partition Found

Possible Cause 1: The system firmware incorrectly handles the boot disk because the boot disk is partitioned with the GUID Partition Table (GPT) partitioning scheme.

Workaround 1: Invoke the fdisk program and then activate the Protective Extensible Firmware Interface (EFI) partition on the boot disk.

Possible Cause 2: The system was originally installed in UEFI mode but rebooted in legacy (BIOS) mode.

Workaround 2: Install the system in legacy mode by changing the firmware setup option, for example, by selecting "Boot Mode" or a similar option.

SPARC: GPT Labeled Disk Support

GPT labeled disk support is available on SPARC based systems. The following table describes the supported firmware for SPARC platforms.

SPARC Platform
At least version 9.4.2.e
At least version 9.4.2.e
At least version 8.8.1
At least version XCP2230

If your SPARC T4, T5, M5, or M10 system has older firmware, perform the following steps to download the updated firmware from My Oracle Support:

  1. Sign in to My Oracle Support.

  2. Click the Patches & Updates tab.

  3. In the Patch Search box, select the Product or Family (Advanced) search option.

  4. In the Product Is field, type a partial product name to display a list of possible matches, and then select the product name.

  5. Select one or more releases from the Release Is drop-down menu.

  6. Click the Search button to display a list of available downloads that are listed as patches.

  7. Select the patch name that you want to download.

    The download page is displayed.

  8. Click Download.

Note -  If you do not have permissions to download the patch, see the How Patches and Updates Entitlement Works knowledge article that is available on MOS.

x86: Booting in UEFI Mode From the ISO Image Is Very Slow on Oracle VM VirtualBox

Booting in UEFI mode from the ISO image is very slow. This is a known Oracle VM VirtualBox firmware issue.

Workaround: None.

x86: Oracle Solaris Does Not Boot on Disks Using Older Emulex FC HBA Cards (15806304)

On x86 systems, Oracle Solaris does not boot on disks using older Emulex FC HBA cards.

The following error message is displayed for Emulex FC HBA cards:

error: no such device: 07528c2afbec7b00.
Entering rescue mode...
grub rescue>  ls
(hd0) (hd0,gpt9) (hd0,gpt2) (hd0,gpt1) (hd1)
grub rescue>

Workaround: Choose one of the following workarounds:

  • Replace the old Emulex FC HBA cards with a recent model. You can use SG-XPCIEFCGBE-E8, SG-XPCIE1FC-EM8-Z, SG-XPCIE2FC-EM8-Z, LPe16002-M6-O or LPem16002-M6-O.

  • Ensure that the system boot volume is less than 2 TB.

ZFS Should Retry or Abort an Entire Transaction When a WCE LUN Gets a Power-On-Reset (15662604)

ZFS enables the write cache on pool devices and safely handles cache flushing in the event of a system power loss. However, a power-on-reset condition can potentially occur while data has not yet been committed to stable storage.

In an environment with no single point of failure, this situation is automatically detected and corrected by ZFS the next time the data is read. Routine pool scrubs of the pool can increase the detection and repair of any lost writes.

In an environment with a single point of failure, this problem could lead to data loss.

This problem might also occur more frequently when accessing LUNs that are exported from a clustered configuration. During cluster failover, data cached by the failing head may be lost due to a power-on-reset event that is explicitly sent by the SCSI target on the surviving head. In this situation, even pools with no single point of failure might be affected.

A symptom of this issue is clusters of persistent checksum errors. You can use the output from fmdump –eV to determine whether the checksum errors have been diagnosed as persistent. The zio_txg entry in the fmdump –eV output represents the time that a block of data is written. Note that a pattern of persistent checksum errors could also be a symptom of failing devices, software, or hardware.

Workaround: For systems that rely on LUNs exported from a cluster or systems with a single point of failure, consider disabling the write cache for devices on a system.

Perform the following steps to disable the write cache and suppress cache flushing for SCSI (sd) or FC (sd or ssd, see SPARC: Configuration Changes for Fiber Channel Storage) devices.

  1. Copy either the /kernel/drv/sd.conf file or the /kernel/drv/ssd.conf file into the /etc/driver/drv directory, depending on your storage devices.

  2. Edit either the /etc/driver/drv/sd.conf file or the /etc/driver/drv/ssd.conf file to disable the write cache and suppress cache flushing.

  3. Add lines to replace the VID, PID, or SUN COMSTAR values with the appropriate values described on the sd(4D) man page.

    sd-config-list="SUN     Storage", "throttle-max:10, physical-block-size:8192, disable-caching:true, cache-nonvolatile:true";
  4. Reboot the system and override the fast reboot option.

    # reboot -p

Note -  Applying the workaround could cause a reduction in system performance.