Supermicro makes some really amazing motherboards and are a key piece of my home lab whitebox strategy. I’m incredibly happy with the built-in IPMI and remote KVM / Media abilities that come standard with the X9SCM board. With that said, I recently acquired a pair of Emulex 10102-FX UCNA cards to provide some 10 GbE connectivity testing between two of my vSphere lab hosts, with hopes of adding a 10 GbE switch in the future. For now, the two hosts are directly connected using a cross-over LC/LC SR fiber optic cable.
I did have a bit of difficulty getting the cards to correctly load and become available in vSphere 5.1. After a bit of troubleshooting I finally discovered the root cause: the motherboard BIOS version was too far out of date to support the cards. This post will go over how to easily update the BIOS on a Supermicro board, along with another post that will cover using the Emulex OneCommand software plugin for vCenter to easily discover and update the CNA firmware.
Supermicro BIOS Update / Flash Procedure
Some call it flashing the BIOS (like me) and others call it updating the BIOS. Either way, the goal is to wipe the old BIOS firmware and load the latest and greatest. The method that I found to be easiest was to use Rufus to create a bootable USB stick, and then just add the Supermicro BIOS firmware onto the USB stick. Here are the three steps to follow:
Step 1 – Grab The Latest Supermicro Firmware
Fire up the Supermicro download page and put in your motherboard model. In my case, it’s the X9SCM.
Click the BIOS Downloads or Get BIOS button. The latest firmware will be offered for download, with a giant warning telling you that upgrading firmware is risky business. I strongly recommend making sure that your server is plugged into a UPS before moving forward with the upgrade.
Once you click on the link you’ll need to read and accept a EULA. Then you can download the zip file. Inside are a handful of files – the large file with a weird extension is the actual BIOS bin file.
Note: There are also two batch files included – AMI_1.BAT is for BIOS 1.1a or lower, and AMI_2.BAT is for BIOS 2.00 or higher. In my case I am running 1.1a so I’ll need to use AMI_1.BAT in Step 3.
Extract the contents of the zip to a folder for later.
Step 2 – Bootable USB Stick With Rufus
If you’ve not used Rufus before, it’s just a simple little app that formats a USB stick so that it boots into DOS. I use it all the time for OS-less firmware upgrades on various servers and components. Download the app, pop in a USB stick (pretty much any size will do), and tell Rufus to make the USB stick bootable. I used the default configuration, but still took a screenshot below for you to refer to.
Once completed, copy over the extracted zip folder from Step 1 and put it in the root directory of the Rufus USB stick.
Step 3 – Flash The BIOS
The final step is to insert the Rufus USB stick (or mount it over IPMI) and fire up the server. To make sure that the server boots to the USB stick, enter the BIOS settings before the server boots into the hypervisor and do a manual boot override to the Rufus USB stick. Alternatively, I just end up removing the existing USB stick that holds vSphere ESXi on it because I have no other bootable media inserted – this gives the board no choice but to boot into the Rufus USB stick.
Once the Rufus USB stick has booted to DOS, do the following:
- cd <name of directory you copied over in Step 2 with BIOS>
- Run the update batch file
- If your current BIOS is 1.1a or lower, run AMI_1.BAT <name of BIOS file>
- If your current BIOS is 2.00 or higher, run AMI_2.BAT <name of BIOS file>
- The AMI Firmware Update Utility will launch and erase the flash, then write the new BIOS file to the flash
The final screen looks something like this:
That’s it. Easy!
If you used AMI_1.BAT I typically advise rebooting the server and then running Step 3 a second time with AMI_2.BAT instead. It should finish without any final warning messages.
You can remove the Rufus USB stick and reboot the system into your normal vSphere hypervisor environment.
Next Steps
Now that the Supermicro board has been flashed to the latest BIOS, it’s time to prepare the vSphere hosts with the proper Emulex CIM extension, UCNA drivers, and leverage the power of the OneCommand vCenter plug-in to update the card firmware.
Continue to the Emulex OneCommand Manager in the vSphere Web Client post!
[…] hassle keeping them updated with the latest firmware. As an expansion on my previous post covering how to update the BIOS of my Supermicro whitebox servers, this post will go deeper into managing my home lab. Specifically, we’ll cover the […]
Thanks for this – I’ve been doing it the hard way with a cd.
Supermicro bios is always so buggy. Do they even test these things
+1
Thank you!!! I have been looking all over for something like Rufus!! 🙂
Too easy! Thank you. Rufus!
Just had to upgrade my lab host too, and while this all works its unbelievable that DOS boot disks are still needed in 2014. Supermicro do have a way of upgrading BIOS via the IPMI card but it’s an additional licence and I couldn’t find any information about buying it anyway. A more painful procedure than it should be. Aren’t we in the era of software defined, not jumpers on motherboards and DOS? Sigh.
Can’t get this working even in Rufus. I basically made a bootable USB using Rufus. As your post shows, I copied extracted files into root of USB. I tried to attach the USB using virtual storage/media via IPMI and get this.
http://imgur.com/a/dq7sS
Screenshots show my usb structure and attachment error.
I had some difficulties with BIOS update of out X10SRi-F too. I have Hyper-V 2012 R2 on it in EFI mode.
What to check for:
– In BIOS: all (U)EFI things switched off (or to Legacy) first … after update change to EFI again (I had blank/black screen – it turned out I forgot one more EFI settings under PCIe/PCI/PnP Configuration : Onboard Video Option ROM)
– make bootable USB with Rufus as mentioned in this post (if you have small USB like 512MB, try FAT instead of FAT32)
– try to plug this bootable USB in your USB2 port (best in back ports of your motherboard) rather then USB3 before you try to mount it in KVM as Virtual storage …. my USB3 front ports didn’t work for me
– I launced KVM from SuperMicro free tool: IPMI View v2.10.2 (in case you use Chrome and have troubles with java etc.)
I case this too does not work, there is another way:
– https://ami.com/?AMIBIOS_and_Aptio_AMI_Firmware_Update_Utility.zip
– I was able to update using AFUWINx64.EXE with same switches as are in FLASH.BAT in orig BIOS zip file… for me it was: afudos BINIMAGE /P /B /N /K /R /ME
– I did not try the EFI way: AfuEfix64.efi (it shoul work by placing AfuEfix64.efi and BIOS file on usb, then boot to EFI shell from BIOS and finally cd to USB and run AfuEfix64.efi BINIMAGE /P /B /N /K /R /ME) … not guaranteed 🙂
Get a mainboard with IPMI, all boards with a “-F” in the name and a BIOS update license which costs very little money (around $10 or 20). Then you can update the BIOS from inside IPMI which works much more reliable. AND .. if you shall have flashed badly, then then you can Connect via LAN to IPMI Management and re-flash ! Simple as that.
I attempted to update the bios in my Supermicro X9SRI-F board using a FAT32 flash drive and the current AMI.BAT file listed on Supermicro’s site. It successfully reads the file, FFS checksum is ok, then takes about 5 minutes before displaying “Erasing Flash … 0x00060000 (9%)” and is now locked up. I’ve attempted it with the JPME1 jumper in the force update setting with the same result. My board is an early model that still has bios ver. 1.0b. Supermicro no longer has 2 batch files – one for early bios versions and another for later versions. I’m wondering what differences there were in command line switches between the AMI1.BAT and AMI2.BAT files. I have also attempted to update the bios using their SuperDoctor utility. I got the same result – locking up windows server 2012 R2 so that I could not even get to the task manager. Supermicro tech support has apparently not run into this issue before and has no words of wisdom. At this point I’m wondering if the bios chip has a bad address that is preventing the update but has not prevented the original bios from functioning. I’m afraid to start experimenting with flash utility command line switches for fear I will permanently disable the board.
Thanks for the assistance.
Unfortunately, whatever I tried I couldn’t get the BIOS to boot from the USB in Legacy mode. I had to create the USBdisk using MSDOS (instead of FreeDOS).
Then (in SuperMicro’s infinite wisdom of creating the worst and most frustrating BIOS in the history of PCs), the BIOS flash process reset every BIOS setting, including the SATA mode setting (eg. RAID mode was reset to AHCI). This meant that although my RAID 1 volumes had been seemingly reset to individual AHCI disks, I should just be able to configure the BIOS settings back the way the were and the RAID volumes should come back. This means set the SATA mode back to RAID, make sure I’m using the same RAID ROM type (Intel or LSI) as I was previously (in my case Intel). The the onboard RAID controller should read the disks and their RAID volume configs and the RAID volumes should magically appear they way they were… and they did.
So after resetting all the BIOS configs back to the way they should be, I configured the SATA mode to RAID. Reboot and check the Intel controller picks up the RAID volumes correctly, yes. Reboot back to the BIOS to configure the boot order so it boots from the Intel RAID volume. Reboot again to boot the OS and this is where it turned real bad.
The server blue screens with the fatal BSOD Stop error 0x0000007B (Inaccessible Boot Device).
This normally is an error switching from AHCI to RAID mode (or IDE to AHCI) without enabling drivers first in the registry. But I was already using RAID mode before the BIOS update and hadn’t booted the OS before setting the BIOS back to the way it was prior to the BIOS flash.
I tried modifying a few other settings in the BIOS before deciding to try using F8 during boot to access Safe Mode but that met with the same BSOD 0x7B error.
I decided to try my luck with the “Last Known Good Config” boot option and behold, the server booted.
Then after logging in I was greeted with a driver update “You must restart your computer to apply these changes” which is what happens when the IDE/AHCI/RAID mode is changed with the registry changes first applied to enable the driver to install.
Seems it might be a result of updating the Intel ME or the Intel RST drivers to a newer version during the BIOS flash.
Hope it helps anyone else with the same BSOD after flashing.
[…] Next day I updated the BIOS which was a very intens process because if you want to do a BIOS update trough the IPMI you need some kind of stupid licence (SFT-OOB-LIC) which cost around $30. Because getting this licence would take more then 1 day I could not wait I decided to follow this procedure. […]
This would be great if… uhm.. you know, Rufus actually allowed you to make boot disks. But it doesn’t. Not without downloading other tools. Your tutorial needs to be reviewed.
Your “Default configuration” is not default, you had FreeDOS installed. Most of us don’t, therefore can’t follow this tutorial.
Well, keep in mind that this post is 4 years old. At the time, I didn’t have to install anything beyond the Rufus installer, but maybe today you have a separate installation requirement? Thanks for the comment, though!
@Whyyy Rufus (get from here https://rufus.akeo.ie) absolutely does allow the creation of a DOS boot disk without downloading anything else. It comes with FreeDOS.
Download the .exe, run it (and with the default options), you too will be able to create a DOS boot disk.
Hi,
I used the method described here: http://crashmag.net/creating-a-bootable-firmware-bios-update-iso-for-your-supermicro-motherboard
In addition to his instructions and coinciding with this post, I also removed (REM’d out) the line “REN AFUDOSU.SMC AFUDOSU.EXE” ins ami_1.bat and ran ami_1.bat x9scm5.220 (for my mobo).