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?id=1398698 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!
On Wed, 4 Jan 2017, Locane wrote:
My questions are, who decides what packages are current for CentOS when I "yum upgrade"?
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 ?
On Wed, Jan 4, 2017 at 10:00 AM, Paul Heinlein heinlein@madboa.com wrote:
On Wed, 4 Jan 2017, Locane wrote:
My questions are, who decides what packages are current for CentOS when I
"yum upgrade"?
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.
-- Paul Heinlein <> heinlein@madboa.com <> http://www.madboa.com/ _______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
On Wed, 4 Jan 2017, Locane wrote:
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.
-
Locane -
Paul Heinlein