Hi all, 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. El 4/8/20 a las 0:56, Nicolas Kovacs escribi?:> Le 03/08/2020 ? 19:24, david a ?crit?: >> After trying several paths, some suggested on this list, here's my results. > Hi, > > Just back from a hiking trip. One of my clients sent me a message that his > CentOS server refuses to boot. So tomorrow I have to drive there to figure out > what's going on. I guess there's a high probability it's the issue discussed in > this thread. > > Simple question: besides a tsunami of mailing list and forum messages, is there > some to-the-point reliable information about this mess ? As well as some > to-the-point reliable information about how to fix it ? > > Thanks, > > Niki >--
> Am 04.08.2020 um 08:31 schrieb lpeci <lpeci at roa.es>: > > Hi all, > > 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\* mokutilAs there are updated and working packages available now, downgrading is no longer needed, another update will also work. # yum makecache # yum upgrade You should see a shim-x64 package with version 15.8 which is the working version (15.7 caused the problem)> > #exit > > #reboot > > I hope you can fix it with these steps.
On 8/4/20 2:31 AM, lpeci wrote:> > 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 >While I appreciate the thoughts behind this step in the instructions, and I thank you for the post that will be useful to those running fairly traditional servers, there are numerous cases where this simply will not work to bring up a network while booted into the rescue mode chroot.? Not all, and maybe not even most, CentOS machines are traditional servers with simple direct ethernet connections that don't require more steps.? I can just off the top of my head think of three cases where the above won't work: Case 1: Virtualization host with a bridge on multiple VLANs over a bond.? Depending upon the type of bond, it may or may not be possible to bring up the host's interface to the network with the commands above.? More than half of my server machines here fall under this case. Case 2: workstation with wired network and 802.1x authentication. Case 3: workstation or laptop with only a wireless interface that requires a supplicant to authenticate.? Yes, workstation and laptop installs of CentOS do exist and are actively used and are just as important to recover as any traditional server. For my laptop I was able to recover thanks to the 'nmtui' text-mode interactive interface to NetworkManager, bringing up any of my WiFi SSIDs with authentication; if any of my virtualization hosts had hit this problem (none did, interestingly enough) nmtui would have allowed me to activate the bridge on the host admin vlan quickly and easily from, again, a nice interactive text interface that is dead-simple to use quickly and accurately, and where you don't have to do any extra steps to get the interface name or any other details; nmtui just takes care of it in an intuitive manner.
On 8/4/20 1:31 AM, lpeci wrote:> Hi all, > > 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. > > El 4/8/20 a las 0:56, Nicolas Kovacs escribi?: >> Le 03/08/2020 ? 19:24, david a ?crit?: >>> After trying several paths, some suggested on this list, here's my >>> results. >> Hi, >> >> Just back from a hiking trip. One of my clients sent me a message that >> his >> CentOS server refuses to boot. So tomorrow I have to drive there to >> figure out >> what's going on. I guess there's a high probability it's the issue >> discussed in >> this thread. >> >> Simple question: besides a tsunami of mailing list and forum messages, >> is there >> some to-the-point reliable information about this mess ? As well as some >> to-the-point reliable information about how to fix it ? >> >> Thanks, >> >> NikiThe issues should now be resolved. If you just mount /mnt/sysimage, set an ip address and upgrade (to get th new shim) .. then: yum reinstall <latest-version> Everything should just work. -------------- 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/20200804/33105184/attachment.sig>
On 8/4/20 9:51 AM, Johnny Hughes wrote:> On 8/4/20 1:31 AM, lpeci wrote: >> Hi all, >> >> 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. >> >> El 4/8/20 a las 0:56, Nicolas Kovacs escribi?: >>> Le 03/08/2020 ? 19:24, david a ?crit?: >>>> After trying several paths, some suggested on this list, here's my >>>> results. >>> Hi, >>> >>> Just back from a hiking trip. One of my clients sent me a message that >>> his >>> CentOS server refuses to boot. So tomorrow I have to drive there to >>> figure out >>> what's going on. I guess there's a high probability it's the issue >>> discussed in >>> this thread. >>> >>> Simple question: besides a tsunami of mailing list and forum messages, >>> is there >>> some to-the-point reliable information about this mess ? As well as some >>> to-the-point reliable information about how to fix it ? >>> >>> Thanks, >>> >>> Niki > > The issues should now be resolved. > > If you just mount /mnt/sysimage, set an ip address and upgrade (to get > th new shim) .. then: > > yum reinstall <latest-version> > > Everything should just work. >sorry .. yum reinstall kernsl-<latest_version> -------------- 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/20200804/870e3276/attachment.sig>
Once upon a time, Johnny Hughes <johnny at centos.org> said:> The issues should now be resolved. > > If you just mount /mnt/sysimage, set an ip address and upgrade (to get > th new shim) .. then: > > yum reinstall <latest-version>I'm curious - why does the kernel need to be reinstalled? The shim-x64 package installs its files directly to the EFI partition where they are needed. -- Chris Adams <linux at cmadams.net>
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 ?" :o) Cheers, Niki -- Microlinux - Solutions informatiques durables 7, place de l'?glise - 30730 Montpezat Site : https://www.microlinux.fr Blog : https://blog.microlinux.fr Mail : info at microlinux.fr T?l. : 04 66 63 10 32 Mob. : 06 51 80 12 12
> 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
On Thu, Aug 06, 2020 at 03:57:56PM +0200, 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:While this worked for me, it might not work for you... My "solution" was to boot the previous kernel, which came up just fine, yum remove kernel.xx.yy.zz yum install kernel.xx.yy.zz which rebuilds the initrd, and voila! Fred> > > > 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 ?" > > :o) > > Cheers, > > Niki > > -- > Microlinux - Solutions informatiques durables > 7, place de l'?glise - 30730 Montpezat > Site : https://www.microlinux.fr > Blog : https://blog.microlinux.fr > Mail : info at microlinux.fr > T?l. : 04 66 63 10 32 > Mob. : 06 51 80 12 12 > _______________________________________________ > CentOS mailing list > CentOS at centos.org > https://lists.centos.org/mailman/listinfo/centos-- ---- Fred Smith -- fredex at fcshome.stoneham.ma.us ----------------------------- The eyes of the Lord are everywhere, keeping watch on the wicked and the good. ----------------------------- Proverbs 15:3 (niv) -----------------------------
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.sig>