Microcode_ctl-2.1-16 Hard Crash On Intel E5 2667 V4 CPUs

Home » CentOS » Microcode_ctl-2.1-16 Hard Crash On Intel E5 2667 V4 CPUs
CentOS 3 Comments

Hello all!

I’m brand new to the mailing list, and I’ve encountered an issue with the microcode_ctl package version 2.1-16 being installed during the CentOS 7.3
upgrade. It causes my servers to hard stop and they need to be forcibly powered off and back on again with the power button to continue.

This RedHat thread https://bugzilla.redhat.com/show_bug.cgi?id98698 details the issue, and version 2.1-18 available from Petr Oros’ personal section of RedHat http://people.redhat.com/poros/e6a8cc19d733b1526c2519fbaa1e231d/ is supposed to fix the issue. I haven’t had a chance to test it yet.

My questions are, who decides what packages are current for CentOS when I
“yum upgrade”?
When can version 2.1-18 be released to avoid this problem?

Thanks in advance!

3 thoughts on - Microcode_ctl-2.1-16 Hard Crash On Intel E5 2667 V4 CPUs

  • That’s determined by the repositories defined and enabled in
    /etc/yum.conf and /etc/yum.repos.d/*.repo. To see the repositories enabled by your system, ask yum:

    yum repolist

    Each repository maintains a different set of packages. For any given package, order is determined by

    epoch > version > release

    To see those values for the packages installed on your system:

    rpm -qa –qf ‘%{name}\t\t%{epoch}\t%{version}\t%{release}\n’ | sort

    Epoch is essentially a hack that can override a change in a package’s version numbering. Most packages don’t have an epoch number, but check out the epochs on bind-libs and (32!) and dhclient (12).

    So for each package name, the package with the highest epoch:version:release is “current.” That allows a package in the updates repository to be installed over one currently installed on your system.

  • Thanks for the breakdown Paul – I’ve had to learn all my sysadmin stuff through organic interactions like this.

    Still though – someone manages the default repositories – so my question is, who decides when a package gets an update from whatever CentOS ships with default to a newer version? How does that process take place, and, can I affect it by adding microcode_ctl-2.1-18 ?

  • For the vast majority of CentOS packages, that decision is made by Red Hat, whose Enterprise Linux product is rebuilt pretty much as-is and released as CentOS. As goes RHEL, so goes CentOS.

    That’s considered a feature by CentOS users, not a bug.

    So when Red Hat releases a new microcode_ctl package, a CentOS update will follow quickly.

    The obverse is true too: without a RHEL release, a CentOS update will not follow.

    You can manually download and install Petr Oros’ test package, and you can badger Red Hat, but those are your only realistic options.