| Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback |
| Oracle System Handbook - ISO 7.0 May 2018 Internal/Partner Edition | ||
|
|
||
 |
||||||||||||||||
Solution Type Problem Resolution Sure Solution 1561524.1 : Sun Server X3-2L (formerly X4270 M3) ignores BIOS boot order and skips RAID disk device at top of boot list
In this Document
Applies to:Sun Server X3-2L - Version Not Applicable and laterInformation in this document applies to any platform. SymptomsTo discuss this information further with Oracle experts and industry peers, we encourage you to review, join or start a discussion in the My Oracle Support Community - Sun x86 Systems
After installing an OS to a Sun Server X3-2L (formerly X4270 M3) you may see an issue where the system seems to ignore the boot order in the BIOS and boot from another device such as the network. For example, you may have a RAID card set as the first boot device in the BIOS as follows : RAID:PCIE6:(Bus 50 Dev 00)PCI RAID Adapter
Then when trying to boot the installed OS, the system may ignore the RAID boot device and try to boot from the network PXE:NET0 device instead, followed by other devices below this should it fail or be terminated by hitting the ESC key. If all devices in the boot list fail or are skipped (by pressing ESC key) you *MIGHT* find that the OS then boots. You may also find that selecting the RAID controller directly from the boot menu (pressing F8 during POST) *MAY* allow the OS to boot first time.
CauseThis issue can occur when the whole OS and/or the MBR boot loader (such as GRUB) is inadvertently installed to the OSA device. The OSA device (Oracle System Assistant) is a USB key which is plugged into the internal USB port on the system board inside the X3-2L.
The OSA USB key device is installed in every X3-2L system that is shipped and should be pre-installed with the bootable Oracle System Assistant software which provides a bootable environment for system recovery, repair and firmware updates. Further details on the OSA USB device can be found here
One way of confirming if the OS or the MBR boot loader (e.g. GRUB) has been installed to the internal OSA USB key is to press F9 during POST to boot from OSA device. If the system then successfully boots your installed OS first time then your OS and/or MBR boot loader has installed to the OSA USB key instead of your RAID disk controller.
If this is confirmed as the case then the issue is a software configuration issue and under no circumstances should any hardware be replaced as this will *NOT* fix the problem and could potentially introduce further problems.
SolutionIn order to avoid this you need to ensure that you select the correct disk device when you install your OS. If you are performing an automated network install of your OS you may need to alter your kickstart/autoyast (Linux) / Jumpstart (Solaris) / RIS (Windows) install scripts to select the correct physical hard disk device and also define which device the MBR boot loader such as GRUB/LILO should be installed to. There are two possible scenarios that can lead to this issue and they both need to be checked :
1. BOTH the entire OS and the MBR boot loader (e.g. GRUB) are installed to the OSA USB key. 2. Only the MBR boot loader (e.g. GRUB) is installed to the OSA USB key and the OS is installed to the REAL hard disks. This will still seemingly work if the MBR boot loader lives on the USB key and points at the OS on the hard disks. This is bad as the MBR boot loader should be on the hard disk where the OS is installed.
Again, if you are performing an automated network installation you need to check that your install scripts select the real hard disk devices to install your OS *AND* also select the real hard disk devices to install the MBR boot loader! If you are performing a manual install, you just need to be careful which disk devices you select during the install process.
If you find that your OS and/or MBR boot loader are indeed installed to the OSA USB key then you will either need to completely wipe the OSA USB key to ensure that the MBR boot loader is completely removed along with the OS OR re-install the OSA to the USB key. If you do not do this it may lead to all kinds of confusion in future.
Although you could disable the OSA USB device, you must be aware that the default is "ENABLED" so if this is forgotten about and a firmware update is done on the system in future then this will reset back to enabled again and probably cause confusion. Therefore its is recommend to leave this enabled and then wipe the USB key so that the MBR boot loader configuration isn't mixed up between the USB key and hard disks. There are two other ways to fix this issue. If you are urgently needing to get things working quickly you can simply wipe the beginning of the USB key and then re-install your OS to the system (see steps 1-2 below). If things are not as urgent then you can download the OSA image and re-install the OSA USB key and then re-install the OS to the system (see step 3 below)
One way to wipe the OSA USB key is to use the dd command, but you MUST make sure that you identify the correct device before wiping it otherwise you may wipe data from another device by mistake. On Linux you can check which device is the OSA USB key by using the lsscsi command as follows :
e.g. (This is one particular way but there are many other ways of doing this).
(On Solaris check the output from "iostat -En" or "cfgadm -alv" to identify the USB key device)
You could try temporarily disabling the OSA USB key device in the BIOS if you wan't to be 100% sure of this, but remember to re-enable it again afterwards as this may cause problems in the future should you update your firmware and the device is suddenly re-enabled. 3. Once the OS has been installed correctly on the hard disks in the system, the OSA will then need to be re-installed on the USB key. The steps on how to do this is documented HERE.
Attachments This solution has no attachment |
||||||||||||||||
|
||||||||||||||||