Difference between revisions of "Grub Boot Hole Crash"
Jump to navigation
Jump to search
Michael.mast (talk | contribs) (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...") |
Michael.mast (talk | contribs) |
||
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.