On 8/6/20 8:57 AM, Nicolas Kovacs wrote: > Le 04/08/2020 à 08:31, lpeci a écrit : >> I had the same problem with my UEFI bios machine and I fixed it so for Centos 7: >> >> 1) Boot from an rescue linux usb >> >> 2) When the rescue system is running: >> >> 2.1) #chroot /mnt/sysimage >> >> 3) Config network: >> >> 3.1) # ip addr add X.X.X.X/X dev X >> >> 3.2) # ip route add default via X.X.X.X <--- default router >> >> 4) And finally: >> >> #yum downgrade shim\* grub2\* mokutil >> >> #exit >> >> #reboot >> >> I hope you can fix it with these steps. > > Thanks for the detailed suggestion. > > Unfortunately I couldn't recover the installation, and I had to redo everything > from scratch, which cost me the first two days of my holidays. > > One thought regularly kept crossing my mind: > > "How on earth could this have passed Q & A ?" Well, I mean that would be a valid point if it happened for every install. The issue did not happen on every install. There is no way to test every single hardware and firmware combination for every single computer ever built :) It would be great if things like this did not happen, but with the universe of possible combinations, i am surprised it does not happen more often. We do run boot tests of every single kernel for CentOS. The RHEL team runs many more tests for RHEL. But every possible combination from every vendor can't possibly be tested. Right? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20200807/45c00c95/attachment-0004.sig>