CentOS - Jan 2018 - /lib/firmware/microcode.dat update on CentOS 6

On 01/18/2018 09:42 AM, Valeri Galtsev wrote:
> 
> 
> On 01/18/18 03:41, Pete Biggs wrote:
>>
>>> Look at:
>>>
>>> https://t.co/6fT61xgtGH
>>>
>>> Get the latest microcode.dat file from here:
>>>
>>> https://t.co/zPwagbeJFY
>>>
>>> See how to update the microcode from the links at the bottom of
this
>>> page:
>>>
>>> https://t.co/EOgclWdHCw
>>>
>>> An before anyone asks .. I have no idea why Red Hat chose this
path,
>>> they did.? It doesn't matter if I (or anyone else) agrees with
the
>>> decision.? It is what it is.
>>>
>> **I'm not blaming you.**
>>
>> But can I just clarify. We have to *manually* install the microcode
>> update an EL7 in order to be protected against Spectre? EL6 as well?
>>
>> Presumably this is to remove RH from the loop and to stop people
>> blaming them - i.e. this is between Intel and the customer, it's
>> nothing to do with them.
> 
> I bet you are right. I was going to rant about that... then it occurred
> to me that class action against Intel (didn't hear about AMD though) is
> quite likely, so, indeed, RedHat does not want to be even mentioned in
> it, which will be unfair, especially after RedHat putting effort into
> fixing somebody's else crap.
> 
It isn't about washing hands, lawsuits, or soeoen else's stuff.  It is
about broken microcode updates.

The code from intel was broken .. causing several CPUs not to boot after
update.  That (and only that) is why they were pulled.

Users MUST individually QA the microcode for their individual CPUs, OEM
Frimware, chipset etc.

The issue here is that the microcode broke peoples machines .. therefore
it had to be rolled back.  All the other discussion is full and total BS.

It is likely ONCE all the microcode updates are tested and completely
working that Red Hat will again include it in the microcode_ctl RPM ..
but that can't put stuff in there that is breaking machines.

While things are beuing released as QA quality, they are going to have
to be done individually by admins .. that's just how it is.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.centos.org/pipermail/centos/attachments/20180122/a1fce928/attachment-0001.sig>

On 01/22/18 09:08, Johnny Hughes wrote:
> On 01/18/2018 09:42 AM, Valeri Galtsev wrote:
>>
>>
>> On 01/18/18 03:41, Pete Biggs wrote:
>>>
>>>> Look at:
>>>>
>>>> https://t.co/6fT61xgtGH
>>>>
>>>> Get the latest microcode.dat file from here:
>>>>
>>>> https://t.co/zPwagbeJFY
>>>>
>>>> See how to update the microcode from the links at the bottom of
this
>>>> page:
>>>>
>>>> https://t.co/EOgclWdHCw
>>>>
>>>> An before anyone asks .. I have no idea why Red Hat chose this
path,
>>>> they did.? It doesn't matter if I (or anyone else) agrees
with the
>>>> decision.? It is what it is.
>>>>
>>> **I'm not blaming you.**
>>>
>>> But can I just clarify. We have to *manually* install the microcode
>>> update an EL7 in order to be protected against Spectre? EL6 as
well?
>>>
>>> Presumably this is to remove RH from the loop and to stop people
>>> blaming them - i.e. this is between Intel and the customer,
it's
>>> nothing to do with them.
>>
>> I bet you are right. I was going to rant about that... then it occurred
>> to me that class action against Intel (didn't hear about AMD
though) is
>> quite likely, so, indeed, RedHat does not want to be even mentioned in
>> it, which will be unfair, especially after RedHat putting effort into
>> fixing somebody's else crap.
>>
> 
> It isn't about washing hands, lawsuits, or soeoen else's stuff.  It
is
> about broken microcode updates.
> 
> The code from intel was broken .. causing several CPUs not to boot after
> update.  That (and only that) is why they were pulled.
> 
> Users MUST individually QA the microcode for their individual CPUs, OEM
> Frimware, chipset etc.
> 
> The issue here is that the microcode broke peoples machines .. therefore
> it had to be rolled back.  All the other discussion is full and total BS.
> 
> It is likely ONCE all the microcode updates are tested and completely
> working that Red Hat will again include it in the microcode_ctl RPM ..
> but that can't put stuff in there that is breaking machines.
> 
> While things are beuing released as QA quality, they are going to have
> to be done individually by admins .. that's just how it is.
> 
Thanks Johnny, for correcting my wild guess which was wrong, and the 
fact that my guess was wrong I realized after reading your other post!

As with everything else the end user pays one way or another. :-(

Valeri

++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++

On 01/22/2018 10:06 AM, Valeri Galtsev wrote:
> 
> 
> On 01/22/18 09:08, Johnny Hughes wrote:
>> On 01/18/2018 09:42 AM, Valeri Galtsev wrote:
>>>
>>>
>>> On 01/18/18 03:41, Pete Biggs wrote:
>>>>
>>>>> Look at:
>>>>>
>>>>> https://t.co/6fT61xgtGH
>>>>>
>>>>> Get the latest microcode.dat file from here:
>>>>>
>>>>> https://t.co/zPwagbeJFY
>>>>>
>>>>> See how to update the microcode from the links at the
bottom of this
>>>>> page:
>>>>>
>>>>> https://t.co/EOgclWdHCw
>>>>>
>>>>> An before anyone asks .. I have no idea why Red Hat chose
this path,
>>>>> they did.? It doesn't matter if I (or anyone else)
agrees with the
>>>>> decision.? It is what it is.
>>>>>
>>>> **I'm not blaming you.**
>>>>
>>>> But can I just clarify. We have to *manually* install the
microcode
>>>> update an EL7 in order to be protected against Spectre? EL6 as
well?
>>>>
>>>> Presumably this is to remove RH from the loop and to stop
people
>>>> blaming them - i.e. this is between Intel and the customer,
it's
>>>> nothing to do with them.
>>>
>>> I bet you are right. I was going to rant about that... then it
occurred
>>> to me that class action against Intel (didn't hear about AMD
though) is
>>> quite likely, so, indeed, RedHat does not want to be even mentioned
in
>>> it, which will be unfair, especially after RedHat putting effort
into
>>> fixing somebody's else crap.
>>>
>>
>> It isn't about washing hands, lawsuits, or soeoen else's
stuff.? It is
>> about broken microcode updates.
>>
>> The code from intel was broken .. causing several CPUs not to boot
after
>> update.? That (and only that) is why they were pulled.
>>
>> Users MUST individually QA the microcode for their individual CPUs, OEM
>> Frimware, chipset etc.
>>
>> The issue here is that the microcode broke peoples machines ..
therefore
>> it had to be rolled back.? All the other discussion is full and total
BS.
>>
>> It is likely ONCE all the microcode updates are tested and completely
>> working that Red Hat will again include it in the microcode_ctl RPM ..
>> but that can't put stuff in there that is breaking machines.
>>
>> While things are beuing released as QA quality, they are going to have
>> to be done individually by admins .. that's just how it is.
>>
> 
> Thanks Johnny, for correcting my wild guess which was wrong, and the
> fact that my guess was wrong I realized after reading your other post!
> 
> As with everything else the end user pays one way or another. :-(
Here are a couple of posts for our reading pleasure:

Intel recommends not installing the microcode now:
http://intel.ly/2DsL9qz

Linus Torvalds agrees:
http://tcrn.ch/2n2mEcA


So, wait on those microcode updates for a while.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.centos.org/pipermail/centos/attachments/20180123/b406a09b/attachment-0001.sig>