[ale] News: Red Hat slams into reverse on CPU fix for Spectre design blunder

[Lightner, Jeffrey]

No doubt, but the fact I got it booted into multi-user from old kernel (before my "cleanup") made me wonder if it was really the interrupted update that caused the panic or the updated kernel and microcode combination.   The fact I saw the panic even after the "cleanup" made it seem more likely it was the new kernel and microcode.   The fact I couldn't get into multiuser using the old kernel after the "cleanup" I'm willing to accept was more because of the interrupted update and "cleanup".  

I haven't delved into RedHat's reversal yet but the thing I'd seen even before they did the reversal suggested they already knew the microcode wasn't appropriate for all systems.   Dell on the other hand wasn't offering an update for that generation of server and Intel was saying one would need to get the update from the server manufacturer.   All that was why I asked a question about the catch 22 on this list before I applied anything.

-----Original Message-----
From: Derek Atkins [mailto:derek at ihtfp.com] 
Sent: Thursday, January 18, 2018 9:57 AM
To: Lightner, Jeffrey; DJ-Pfulio; Atlanta Linux Enthusiasts
Subject: Re: [ale] News: Red Hat slams into reverse on CPU fix for Spectre design blunder

My upgrades to 7.4 went smoothly on the two systems I upgraded. An interrupted yum update could definitely cause major issues.

-derek
Sent using my mobile device. Please excuse any typos.



On January 18, 2018 9:54:18 AM "Lightner, Jeffrey via Ale" <ale at ale.org> wrote:

> The first box (RHEL7.4) I attempted to update panic'ed so I had to 
> boot from the older kernel.
>
> However, I'm not sure if that was caused by the new kernel and 
> firmware package or the fact that I accidentally rebooted the box before it finished
> a full "yum update" of all packages I'd run.   The interruption left it 
> with lots of duplicate packages (the old and the updated versions) that I 
> had to clean up.   Even after the cleanup and new completed "yum update" it 
> panic'ed on the next boot.   On trying to boot from the older kernel it 
> left the system at a place where I couldn't get into GUI console, text 
> console or via ssh.   It may be the instability RedHat is now reporting 
> that caused the final state or it might be my fubar (or a combination).
>
> The good news is we already had a replacement for this server planned.  
> Rather than wasting any more time on the old server (I was able to 
> boot into single user on old kernel) I opted to go ahead and install the
> replacement.   It had the then latest updates but had been running fine on 
> those.   Based on RedHat's announcements I intend to run updates on it 
> again so it will do the reversion they're recommending.
>
> The other good news is that working with all that prevented me from 
> being Johnny on the spot with all our other systems.
>
>
> -----Original Message-----
> From: Ale [mailto:ale-bounces at ale.org] On Behalf Of DJ-Pfulio via Ale
> Sent: Thursday, January 18, 2018 8:23 AM
> To: Atlanta Linux Enthusiasts
> Subject: [ale] News: Red Hat slams into reverse on CPU fix for Spectre 
> design blunder
>
> Red Hat slams into reverse on CPU fix for Spectre design blunder
>
> https://www.theregister.co.uk/2018/01/18/red_hat_spectre_firmware_upda
> te_woes/
>
> Be careful out there.
>
> Anyone seen system instabilities from the different layers of patches?
>
> I've delayed patching the last few weeks to let others find most of 
> the issues first. ;) _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at 
> http://mail.ale.org/mailman/listinfo
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at 
> http://mail.ale.org/mailman/listinfo