Motherboard Dead? Maybe not, check your firmware first.

I have been building computers for my clients and myself for a long time.

I switch between AMD and Intel setups depending on the requirements. Every now and then I come across a piece of hardware that is DOA (Dead on Arrival), it's unavoidable as since these parts are mass produced their is always a chance you get unlucky and it's time to pack it up and send it back under warranty. On a completely new build it sometimes is tricky to find out what is causing the issue if a system simply won't boot, as it could be the PSU (Power Supply Unit), CPU, RAM or the motherboard. So when I recently got a batch of Gigabyte GA-B85M-HD3 motherboards and 2 out of 3 were not working I was puzzled. As I ended up testing everything PSU, RAM, Motherboard and couldn't figure out what was going on. The system would not even get to post but it was powering up.

2 out of 3 in one order couldn't be DOA could they?

I then finally checked the CPU's (Intel I5-4590), it seems as though the newer Haswell CPU even though still LGA1150 was not compatible with the firmware that shipped on 2 of the motherboards I received. I have to update the firmware to somehow get my CPU's working with these boards but since it can't even get to BIOS I was struggling to figure out how to do it. 

Luckily I had an older Haswell CPU lying around so I had to transfer it into the motherboards, boot to the bios, update from a usb drive and then swap back the newer Intel Haswell and all were working. Problem is that if you weren't in possession of an older CPU then you will have no choice but returning the boards to the supplier for them to update the firmware for you, which really is a pain especially if you needed the computers built and delivered quickly.

So next time you think you have a DOA motherboard on your hands ask yourself, is there a chance that the firmware is simply incompatible with the CPU I have on board?

QNAP firmware Updates and Virtual Machines use Caution

One of my clients QNAP devices was largely out of date running version 3.2 something, I really wanted to get them onto 4.0 so I could get some nice Rsync and NAS to NAS backups happening. The QNAP runs as an NFS share with 2 VM's and vmdk files located on it and its connected directly to the ESXi server.

I started by shutting down all the VM's, then proceeded to update the QNAP to version 4.0. Update was successful and all looked well in the world of QNAP, however, something had happened where now I could not access the share via windows explorer for example before I could access \\192.168.0.199\VMStorage directly and see the vmdk files,  but now it was prompting for a username and a password.

Why do you need a password now?

The firmware update had brought with it some additional security settings which had caused the direct referencing of the share not to show the files anymore and it broke the connection with my datastore on my ESXi server. I was using the 'everyone' user in order to access the VMStorage. To fix this I had to create a new user on the QNAP and re-map the datastore on the ESXi server. Then I could boot my VM's no problems.

So if you are running a QNAP with several VM's on it with no security on the area where your VM's are stored then I would be cautious when updating the QNAP firmware. The best thing would be to have security on your VMStorage folder when you first set it up as QNAP is going to require you to do this when you upgrade.