> 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. Now you know how the Window$ admins suffered all the years :-) > > One thought regularly kept crossing my mind: > > "How on earth could this have passed Q & A ?" Quite simple I guess. It's one of the cases where you can not test so easily like other updates. Here you have to make tests on real hardware, different hardware of all kind and can not do it in the Cloud, a VM or whatever. The only real solution I can think of to prevent this would be to make preview versions of updates available to the public so that a lot of people can test them on their hardware, hopefully spare hardware, and give feedback. I think current business models do not support such a way these days. However one can find strategies to survive. What I do is: * Never update any system directly from what is provided online. Sync to local repositories first to control what is fed to your systems. * Never blindly apply updates. Always do tests on not so important systems or dedicated test systems first. * If all goes well, update important systems. If you have multiple systems, update only one first as another test. Then update others. I have learned my lessons in the past decades but this was a good wake up call to follow above rules even more strictly. Better safe than sorry. Regards, Simon