 |
can you try the method reported at https://bugzilla.redhat.com/show_bug.cgi?id=1861977#c7 ? |
 |
I have a fairly new hardware with Centos 8.2 and I have the same problem. Dmitri. -- |
|
|
I've got hit by this as well. I have Supermicro based system (motherboard X11SSH-F), with Secure boot disabled. UEFI only boot. Resolved by booting latest minimal ISO, chrooting and running yum downgrade grub2* shim mokutil |
|
|
Same issue here with two Centos 8.2 VMs in Microsoft Hyper-V. Both Gen2. One version 5 secure boot disabled on Server 2012r2; the other version 9 secure boot enabled on Server 2019. |
|
|
Same here w/ Intel NUC running CentOS 8.2. The "yum downgrade" workaround doesn't work for me, it says: Package shim-x64 of lowest version already installed, cannot downgrade it. Package grub... (same status) etc. Any other workaround ideas? There's a shimx64.efi file attached to the RH bugzilla, but I don't know if that's specific to RHEL, and my CentOS 8 box (using rescue mode) shows both "shimx86.efi" and "shimx64-centos.efi", and I'm not sure if I can replace either of these with the RHEL bugzilla attachment. |
|
|
If you have your installation USB/CDROM you can do cd /var/run/path_to_USB/CentOS-8-1-1911-x86_64-dvd/BaseOS/Packages/ (adjust the path as appropriate for your case) dnf downgrade ./grub2* ./shim-64* Also, i think, if you do not use secure boot, you can just uninstall shim (at least it worked for me). Dmitri. -- |
|
|
Hello, Can confirm this breaks systems using Supermicro based Motherboards, one client is running x11scz-f and started failing after updates. As well, x11scm-f seems to be affected as well, must be the X11 Series. I am trying to verify on a X11SSL-f and get some debug output to help assist. Checking if the above workaround works as well... |
 |
Today's announcement from Red Hat says, "Red Hat has identified a cause and is working on a resolution to provide to our customers." |
|
|
On 2020-07-30 11:23 ManuelWolfshant wrote: > can you try the method reported at https://bugzilla.redhat.com/show_bug.cgi?id=1861977#c7 ? From https://bugzilla.redhat.com/show_bug.cgi?id=1861977#c7: > solved this by actually copying the grubenv file to /boot/grub2 instead of relying on the symlink to efi. On the old hardware, /boot/grub2/grubenv was a symlink to "../efi/EFI/centos/grubenv" # cd /boot/grub2 # mv grubenv grubenv.old-link # cp -a ../efi/EFI/centos/grubenv ./ (Now, grubenv is a regular file) # chmod 644 grubenv # chown root:root grubenv (duplicated owner and mode from DIFFERENT server with grubenv as a regular file which works with latest mokutil and shim.) # grub2-mkconfig (in case it is needed) # yum update (upgrades to latest mokutil and shim) # reboot Machine becomes unbootable. For broken hardware, a work-around to make bootable again: * Use DRAC with virtual media, remote boot ISO, rescue, shell, "bind" mount {/dev, /proc, /sys, /run to original volume root}, chroot to original volume root, assign IP to interface, configure /etc/resolv.conf, then * (Previously downloaded 2 older RPM with wget found) * rpm --force -U mokutil-15-2.el7.centos.x86_64.rpm shim-x64-15-2.el7.centos.x86_64.rpm * exit chroot, umount all "bind" mounts, reboot server, and once again this older hardware using UEFI can reboot. to CentOS. * reboot * rhel-autorelabel runs on boot, takes a while, then reboots (just like last time after downgrade I reported about in top post) * boots normally, and services running Sorry. That suggestion did not address this specific issue on this older server. Thanks for the idea. :-) The old server boots with the grubenv being a symlink or being a regular file once I downgrade to the older mokutil and shim. With the newest mokutil and shim, neither the grubenv symlink nor regular file allow the older machine to boot. Hope this feedback helps you. |
|
|
1. boot rescue centos CD 2. allow the system to find and mount /mnt/sysimage 3. Mount the needfuls: mount --bind /dev /mnt/sysimage/dev mount -t proc none /mnt/sysimage/proc mount -t sysfs none /mnt/sysimage/sys 4. chroot /mnt/sysimage 5. ifup eno1 6. yum history list (get the first id in the list which would be the latest, the further you go down the further back you go) 7. yum history info <ID> 8. Match and see if grub2, mokutil, and similar were updated -- if it was do: 9. yum history undo <ID> 10. exit 11.reboot now |
|
|
Red Hat published this article: https://access.redhat.com/solutions/5272311 |
|
|
I am closing this bug as the shim packages with the correct fix were pushed to mirrors. Make sure you use shim-x64-15-15.el8_2.x86_64.rpm ( EL8 ) or respectively shim-x64-15-8.el7.x86_64.rpm ( EL7 ) ( or newer ) |
- Anonymous
