Difference between revisions of "Grub Boot Hole Crash"

From Michael's Information Zone
Jump to navigation Jump to search
(Created page with "<pre> set root=(hd0,gpt2) linuxefi /vmlinuz-4.18.0-193.14.2.el8_2.x86_64 root=/dev/mapper/OS-root initrdefi /initramfs-4.18.0-193.14.2.el8_2.x86_64.img relabled, rebooted, di...")
 
Line 1: Line 1:
 +
I was hit with the BootHole patch crash<ref>https://arstechnica.com/gadgets/2020/07/red-hat-and-centos-systems-arent-booting-due-to-boothole-patches/</ref> on my personal server. Before I really knew what to do about it I had destroyed my boot partition trying to recover. The official steps from Red Hat<ref>https://access.redhat.com/solutions/5272311</ref> is to downgrade grub, shim, and mkotuil, then exclude them from updates. Though they quickly released a fixed shim file<ref>https://access.redhat.com/errata/RHBA-2020:3262?sc_cid=701600000006NHXAA2</ref>
 +
 
<pre>
 
<pre>
 
set root=(hd0,gpt2)
 
set root=(hd0,gpt2)

Revision as of 08:32, 3 August 2020

I was hit with the BootHole patch crash[1] on my personal server. Before I really knew what to do about it I had destroyed my boot partition trying to recover. The official steps from Red Hat[2] is to downgrade grub, shim, and mkotuil, then exclude them from updates. Though they quickly released a fixed shim file[3]

set root=(hd0,gpt2)
linuxefi /vmlinuz-4.18.0-193.14.2.el8_2.x86_64 root=/dev/mapper/OS-root
initrdefi /initramfs-4.18.0-193.14.2.el8_2.x86_64.img

relabled, rebooted, did again.