Asus Maximus VI Gene – Error 55

It’s been quite a while since I built a computer but I decided to give it a try for a new hypervisor/NAS box at home. I picked up an Asus Maximus VI Gene motherboard since it had some good parts installed and it seems to work well with Linux. This was my first time doing water cooling for the CPU and I picked up a Seidon 240M after getting some recommendations.

Rubber hits the road

Once everything was in the box and the power was applied, I was stuck with an error code. There’s a two-digit LCD display on the motherboard that rapidly flips between different codes during boot-up. If it stays on a code for a while and you don’t get any display output, you have a problem. For me, this Asus Q code was 55.

The manual says it means that RAM isn’t installed. I pulled out my four sticks of RAM and reseated all of them. I still got the same error. After reading a bunch of forum posts, I ran through a lot of troubleshooting steps:

  • Reseat the RAM
  • Try one stick of RAM and add more until the error comes back
  • Reseat the CPU cooler (at least three times)
  • Reseat the CPU (at least three times)
  • Upgrade the BIOS
  • Clear the CMOS
  • Curse loudly, drink a beer, and come back

I still had error 55 and wasn’t going anywhere fast. After some further testing, I found that if I left the two RAM slots next to the CPU empty, the system would boot. If I put any RAM in the two left RAM slots (A1 and A2), the system wouldn’t boot. Here’s an excerpt from the manual:

Asus Maximus VI Gene Motherboard CPU/memory layout

CPU is on the left. RAM slots are A1, A2, B1, B2, left to right.

Fine-tuning the Google search

I adjusted my Google terms to include “A1 A2 slots” and found more posts talking about CPU coolers being installed incorrectly. Mine had to be correct — I installed it four times! I decided to try re-installing it one last time.

When I removed the CPU cooler from the CPU, I noticed something strange. There are four standoffs around the CPU that the cooler would attach to with screws. Those standoffs screwed into posts that connected to a bracket on the back of the motherboard.

Asus motherboard cpu cooler standoff

The lower two standoffs are highlighted.

I removed the two standoffs that were closest to the A1/A2 RAM slots and noticed something peculiar. One side of the standoff had a black coating that seemed a bit tacky while the other side of the standoff was bare metal. Three of the standoffs had the black side down (against the board) while one had the black side up. I unscrewed that standoff and found that the bare metal side was wedged firmly onto some connections that run from the CPU to the A1/A2 RAM slots. Could this be the issue?


After double-checking all of the CPU cooler standoffs and attaching the cooler to the board, I crossed my fingers and hit the power button. The machine shot through POST and I was staring down a Fedora logo that quickly led to a GDM login.

Badly installed cpu cooler standoff

The culprit

I don’t talk about hardware too often on the blog, but I certainly hopes this helps someone else who is desperately trying to find a solution.

Audit RHEL/CentOS 6 security benchmarks with ansible

Ansible logoSecuring critical systems isn’t easy and that’s why security benchmarks exist. Many groups and communities distribute recommendations for securing servers, including NIST, the US Department of Defense (DoD), and the Center for Internet Security (CIS).

Although NIST and DoD are catching up quickly with newer OS releases, I’ve found that the CIS benchmarks are updated very regularly. CIS distributes auditing tools (with paid memberships) that require Java and they’re cumbersome to use, especially on servers where Java isn’t normally installed.

A better way to audit security benchmarks

I set out to create an Ansible playbook that would allow users to audit and (carefully!) remediate servers. The result is on GitHub. Before we go any further, I’d just like to state that I’m not affiliated with CIS in any way and this repository hasn’t been endorsed by CIS. Use it at your own risk.

Getting the playbook onto a machine is easy:

git clone

PLEASE review the README and NOTES files in the GitHub repository prior to running the playbook.


Seriously. I mean it. This playbook could knock production environments offline.

The tasks are split into sections (just like the CIS benchmarks themselves) and each section is split into Level 1 and 2 requirements.

Benchmark levels

Level 1 requirements provide good security improvements without a tremendous amount of intrusion into production workloads. With that said, they can still cause issues.

Level 2 requirements provide stronger security improvements but they can adversely affect production server environments. This is where you find things like SELinux, AIDE (including disabling prelinking), and some kernel tweaks for IPv6.

How to use it

I strongly recommend some dry runs with Ansible’s check mode before trying to modify a production system. Also, you can run the playbook against a freshly-installed system and then deploy your applications on top of it. Find out what breaks and disable certain benchmarks that get in the way.

The entire playbook takes less than a minute to run locally on a Rackspace Performance Cloud Server. Your results may vary over remote ssh connections, but I was seeing the playbooks complete over ssh within three to four minutes.

You can also review the variables file to find all the knobs you need to get more aggressive in your audits. If you spot something potentially destructive that needs a variable added, let me know (or submit a pull request).

It’s open source

The entire repository is licensed under Apache License 2.0, so please feel free to submit issues, pull requests, or patches.

Start Jenkins on Fedora 20

Installing Jenkins on Fedora 20 is quite easy thanks to the available Red Hat packages, but I ran into problems when I tried to start Jenkins. Here are the installation steps I followed:

wget -O /etc/yum.repos.d/jenkins.repo
rpm --import
yum -y install jenkins
systemctl enable jenkins
systemctl start jenkins

Your first error will show up if Java isn’t installed. You can fix that by installing Java:

yum -y install java-1.7.0-openjdk-headless

After installing Java, Jenkins still refused to start. Nothing showed up in the command line or via journalctl -xn, so I jumped into the Jenkins log file (found at /var/log/jenkins/jenkins.log):

Aug 13, 2014 2:21:44 PM org.eclipse.jetty.util.log.JavaUtilLog info
INFO: jetty-8.y.z-SNAPSHOT
Aug 13, 2014 2:21:46 PM org.eclipse.jetty.util.log.JavaUtilLog info
INFO: NO JSP Support for , did not find org.apache.jasper.servlet.JspServlet

My Java knowledge is relatively limited, so I tossed the JSP error message into Google. A stackoverflow thread was the first result and it talked about a possible misconfiguration with Jetty. I tried their trick of using the OPTIONS environment variable, but that didn’t work.

Then I realized that there wasn’t a Jetty package installed on my server. Ouch. The installation continues:

yum -y install jetty-jsp

Jenkins could now get off the ground and I saw the familiar log messages that I’m more accustomed to seeing:

Aug 13, 2014 2:24:26 PM hudson.WebAppMain$3 run
INFO: Jenkins is fully up and running

Much of these problems could stem from the fact that Jenkins RPM’s are built to suit a wide array of system versions and the dependencies aren’t configured correctly. My hope is that the Jenkins project for Fedora 21 will alleviate some of these problems and give the user a better experience.

httpry 0.1.8 available for RHEL and CentOS 7

Red Hat Enterprise Linux and CentOS 7 users can now install httpry 0.1.8 in EPEL 7 Beta. The new httpry version is also available for RHEL/CentOS 6 and supported Fedora versions (19, 20, 21 branched, and rawhide).

Configuring EPEL on a RHEL/CentOS server is easy. Follow the instructions on EPEL’s site and install the epel-release RPM that matches your OS release version.

If you haven’t used httpry before, check the output on Jason Bittel’s site. It’s a handy way to watch almost any type of HTTP server and see the traffic in an easier to read (and easier to grep) format.

Quickly post gists to GitHub Enterprise and

GitHub Logo
The gist gem from GitHub allows you to quickly post text into a GitHub gist. You can use it with the public site but you can also configure it to work with a GitHub Enterprise installation.

To get started, add two aliases to your ~/.bashrc:

alias gist="gist -c"
alias workgist="GITHUB_URL= gist -c"

The -c will copy the link to the gist to your keyboard whenever you use the gist tool on the command line. Now, go through the login process with each command after sourcing your updated ~/.bashrc:

source ~/.bashrc
gist --login
(follow the prompts to auth and get an oauth token from
workgist --login
(follow the prompts to auth and get an oauth token from GitHub Enterprise)

You’ll now be able to use both aliases quickly from the command line:

cat boring_public_data.txt | gist
cat | workgist