urgent: Red Hat distros have an update that renders some systems unbootable
https://access.redhat.com/solutions/5272311 https://arstechnica.com/gadgets/2020/07/red-hat-and-centos-systems-arent-boo... Don't do upgrades to Fedora, RHEL, CentOS until you read those. This seems to have bitten me, making one of my routers (running CentOS 7). I'm still not sure if this is what has happened to my system. The symptoms looked like an SSD failure: nothing past POST on the screen. So I spent a fair bit of time trying to work around the loss. Now that I've seen this error report, I will redirect my efforts
On Sat, Aug 1, 2020 at 12:03 PM D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:
https://access.redhat.com/solutions/5272311
https://arstechnica.com/gadgets/2020/07/red-hat-and-centos-systems-arent-boo...
Don't do upgrades to Fedora, RHEL, CentOS until you read those.
This seems to have bitten me, making one of my routers (running CentOS 7). I'm still not sure if this is what has happened to my system. The symptoms looked like an SSD failure: nothing past POST on the screen.
So I spent a fair bit of time trying to work around the loss. Now that I've seen this error report, I will redirect my efforts
Seems to affect grub2 and secure boot for quite a number of distributions. https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/GRUB2SecureBootBypass?WUw... One fix quote from this link. "solved this by actually copying the grubenv file to /boot/grub2 instead of relying on the symlink to efi." ---
Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
-- Russell
On 2020-08-01 1:26 p.m., Russell Reiter via talk wrote:
On Sat, Aug 1, 2020 at 12:03 PM D. Hugh Redelmeier via talk <talk@gtalug.org <mailto:talk@gtalug.org>> wrote:
https://access.redhat.com/solutions/5272311 https://arstechnica.com/gadgets/2020/07/red-hat-and-centos-systems-arent-boo...
Don't do upgrades to Fedora, RHEL, CentOS until you read those.
I'm not sure if it was necessary or not, but I killed all my dnfdragora-updater processes and also commented out the contents of /etc/xdg/autostart/org.mageia.dnfdragora-updater.desktop so that dnfdragora-updater dies if it tries to run That's for the xfce spin of Fedora 31... Now all I have to do is remember to re-enable it after the bug is fixed (;-)) -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest davecb@spamcop.net | -- Mark Twain
On Sat, Aug 1, 2020 at 2:57 PM David Collier-Brown via talk <talk@gtalug.org> wrote:
On 2020-08-01 1:26 p.m., Russell Reiter via talk wrote:
On Sat, Aug 1, 2020 at 12:03 PM D. Hugh Redelmeier via talk < talk@gtalug.org> wrote:
https://access.redhat.com/solutions/5272311
https://arstechnica.com/gadgets/2020/07/red-hat-and-centos-systems-arent-boo...
Don't do upgrades to Fedora, RHEL, CentOS until you read those.
I'm not sure if it was necessary or not, but I killed all my dnfdragora-updater processes and also commented out the contents of /etc/xdg/autostart/org.mageia.dnfdragora-updater.desktop so that dnfdragora-updater dies if it tries to run
That's for the xfce spin of Fedora 31...
Now all I have to do is remember to re-enable it after the bug is fixed (;-))
I did rpm -qa grub2-\* shim-\* --qf "%{SOURCERPM}\n" | sort | uniq on my Fedora and got grub2-2.02-109.fc31.src.rpm shim-15-8.src.rpm so my version is ok. It looks like this problem was caused by a patch which then allowed a malformed token to cause a buffer overflow.
-- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the restdavecb@spamcop.net | -- Mark Twain
--- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
-- Russell
On Sat, Aug 1, 2020 at 3:50 PM Russell Reiter <rreiter91@gmail.com> wrote: Correction. On Sat, Aug 1, 2020 at 2:57 PM David Collier-Brown via talk <talk@gtalug.org>
wrote:
On 2020-08-01 1:26 p.m., Russell Reiter via talk wrote:
On Sat, Aug 1, 2020 at 12:03 PM D. Hugh Redelmeier via talk < talk@gtalug.org> wrote:
https://access.redhat.com/solutions/5272311
https://arstechnica.com/gadgets/2020/07/red-hat-and-centos-systems-arent-boo...
Don't do upgrades to Fedora, RHEL, CentOS until you read those.
I'm not sure if it was necessary or not, but I killed all my dnfdragora-updater processes and also commented out the contents of /etc/xdg/autostart/org.mageia.dnfdragora-updater.desktop so that dnfdragora-updater dies if it tries to run
That's for the xfce spin of Fedora 31...
Now all I have to do is remember to re-enable it after the bug is fixed (;-))
I did
rpm -qa grub2-\* shim-\* --qf "%{SOURCERPM}\n" | sort | uniq
on my Fedora and got
grub2-2.02-109.fc31.src.rpm shim-15-8.src.rpm
so my version is ok.
It looks like this problem was caused by a patch which then allowed a malformed token to cause a buffer overflow.
Sorry, not a patch but a native flaw in grub's handling of UEFI Secure Boot which is the BootHole. It appears it's the patch which currently borks system booting, which is why downgrading grub and shim is suggested.
-- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the restdavecb@spamcop.net | -- Mark Twain
--- Post to this mailing list talk@gtalug.org Unsubscribe from this mailing list https://gtalug.org/mailman/listinfo/talk
-- Russell
-- Russell
D. Hugh Redelmeier via talk wrote:
https://access.redhat.com/solutions/5272311 https://arstechnica.com/gadgets/2020/07/red-hat-and-centos-systems-arent-boo...
Don't do upgrades to Fedora, RHEL, CentOS until you read those.
Debian released a couple of Grub updates in alarmingly quick succession too. Best keep an eye open regardless of your distro. -- Anthony de Boer
On Sat, Aug 1, 2020 at 11:03 AM D. Hugh Redelmeier via talk <talk@gtalug.org> wrote:
https://access.redhat.com/solutions/5272311 https://arstechnica.com/gadgets/2020/07/red-hat-and-centos-systems-arent-boo...
Don't do upgrades to Fedora, RHEL, CentOS until you read those.
This seems to have bitten me, making one of my routers (running CentOS 7). I'm still not sure if this is what has happened to my system. The symptoms looked like an SSD failure: nothing past POST on the screen.
So I spent a fair bit of time trying to work around the loss. Now that I've seen this error report, I will redirect my efforts
Reading the other reports it seems like, a more than somewhat neophyte, that the fix to the fix compounded with automated upgrades is the sum of the problem. Maybe the fix is to have NO automatic upgrades. The forced automatic upgrades is why I've deprecated Ubuntu here. The latest shiniest new toy isn't always the most useful in my experience - - - - - - especially when it comes to computing! Really do appreciate the heads up!!
| From: D. Hugh Redelmeier via talk <talk@gtalug.org> | https://access.redhat.com/solutions/5272311 The procedure outlined did not work for me on my CentOS 7 box. Here are some additions: 1) networking in rescue environment The link describing how to enable networking is only available to those paying for support. I fumbled about in nmtui (Network Manager Text User Interface) until it worked. 2) the permanent ESP isn't mounted For updating the *.efi files (the main point of the exercise) the ESP must be mounted on /boot/efi. After the chroot: If you have a separate /boot partition: mount /boot (I see no point in a /boot partition but many people have them.) If you have a separate /var partition: mount /var etc... Mount the ESP: mount /boot/efi Check that it is the partition that you want (/dev/sda1 in my case). Only then can you do the yum stuff. ================ Since I didn't do (2), I had to manually move things that landed in /boot/efi (a directory and intended mount-point) to /boot/efi (the filesystem). On the next boot, SELINUX was upset and spent some time relabelling things. Seems to be working now. ================ I expect that this disaster is going to be fixed really quickly. So I'm going to be lazy and not lock down the downgraded versions. Instead, I will refrain from updating things until I hear of fixed packages being available.
participants (5)
-
Anthony de Boer -
D. Hugh Redelmeier -
David Collier-Brown -
o1bigtenor -
Russell Reiter