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>
Il 07/08/20 08:22, Johnny Hughes ha scritto:>> "How on earth could this have passed Q & A ?"Hi Johnny, Niki's question is spread, legit, in the thoughts in many and many users so don't see this as an attack. Many and many users,though really "if this was tested before release" and I think that many of us are incredulous at what happened on CentOS and in the upstream (specially in the upstream) but as you said CentOS inherits RHEL bugs. I'm reading about many users that lost their trust in RH with the last 2 problem (microcode and shim). This is bad for CentOS.> 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.Probably many users have not updated their machines between the bug release and the resolution (thanks to your fast apply in the weekend, thank you) and many update their centos machines on a 2 months base (if not worst). I think also that many users of CentOS user base have not proclamed their disappointement/the issue on this list or in other channels. For example I simply updated in the wrong time.> 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?you are right but is not UEFI a standard and it shouldn't work the same on several vendors? I ask this because this patch broken all my uefi workstations. While CentOS team could not have so much resources to run this type of tests would be great to know what happened to RHEL QA (being RH giant) for this release and given the partenership between CentOS and RH if you know something more on this..... Thank you.
Le 07/08/2020 ? 09:40, Alessandro Baggi a ?crit?:> Probably many users have not updated their machines between the bug release and > the resolution (thanks to your fast apply in the weekend, thank you) and many > update their centos machines on a 2 months base (if not worst). I think also > that many users of CentOS user base have not proclamed their > disappointement/the issue on this list or in other channels. For example I > simply updated in the wrong time.I'm using yum-cron to keep all my server updated on a daily basis. And my question "How could this have passed Q & A" was obviously directed at Red Hat... and *not* at Johnny Hughes and the CentOS team who do their best to deliver the best possible downstream system. I raise my morning coffee mug to your health, guys. 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
On 8/7/20 2:40 AM, Alessandro Baggi wrote:> > Il 07/08/20 08:22, Johnny Hughes ha scritto: >>> "How on earth could this have passed Q & A ?" > > Hi Johnny, > Niki's question is spread, legit, in the thoughts in many and many users > so don't see this as an attack. Many and many users,though really "if > this was tested before release" and I think that many of us are > incredulous at what happened on CentOS and in the upstream (specially in > the upstream) but as you said CentOS inherits RHEL bugs. I'm reading > about many users that lost their trust in RH with the last 2 problem > (microcode and shim). This is bad for CentOS. > >> 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. > > Probably many users have not updated their machines between the bug > release and the resolution (thanks to your fast apply in the weekend, > thank you) and many update their centos machines on a 2 months base (if > not worst). I think also that many users of CentOS user base have not > proclamed their disappointement/the issue on this list or in other > channels. For example I simply updated in the wrong time. > >> 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? > > you are right but is not UEFI a standard and it shouldn't work the same > on several vendors? I ask this because this patch broken all my uefi > workstations.It would be nice if it did .. however, this worked on many UEFI/Secureboot machines. It did not work on a small subset of machines.> > While CentOS team could not have so much resources to run this type of > tests would be great to know what happened to RHEL QA (being RH giant) > for this release and given the partenership between CentOS and RH if you > know something more on this..... >I have not seen the full post event account if what actually happened. I do know that many Red Hatters worked many hours over the last weekend to fix it. I am sure a public post will be made (if not already there) .. if someone knows where it is, post a link. If I don't see it posted soon, I'll look for it and post here. -------------- 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/154e7c7b/attachment.sig>
Once upon a time, Alessandro Baggi <alessandro.baggi at gmail.com> said:> you are right but is not UEFI a standard and it shouldn't work the > same on several vendors? I ask this because this patch broken all my > uefi workstations.The great thing about standards is there's so many to choose from! Also relevant: https://xkcd.com/927/ UEFI has gone through a number of revisions over the years, and has optional bits like Secure Boot (which itself has gone through revisions). Almost any set of standards has undefined corners where vendors interpret things differently. Vendors also have bugs in weird places sometimes. The firmware and boot loaders arguably are the least "exercised" parts of a system - both change rarely and there are few implementations. There's not many combinations, and they don't change a lot. I'm interested to read about the cause of this issue - something like this can be a lesson on "hmm, hadn't thought of that before" type things to watch for in other areas. -- Chris Adams <linux at cmadams.net>
Hi Alessandro, Compared to Microsoft , both RH and SuSE are awesome. You always need a patch management strategy with locked repos (spacewalk/pulp) which can be tested on less important systems, prior deployment on Prod. Keep in mind that Secureboot is hard to deploy in Virtual Environments and thus testing is not so easy. Of course, contributing to the community was always welcomed. Best Regards, Strahil Nikolov ?? 7 ?????? 2020 ?. 10:40:01 GMT+03:00, Alessandro Baggi <alessandro.baggi at gmail.com> ??????:> >Il 07/08/20 08:22, Johnny Hughes ha scritto: >>> "How on earth could this have passed Q & A ?" > >Hi Johnny, >Niki's question is spread, legit, in the thoughts in many and many >users >so don't see this as an attack. Many and many users,though really "if >this was tested before release" and I think that many of us are >incredulous at what happened on CentOS and in the upstream (specially >in >the upstream) but as you said CentOS inherits RHEL bugs. I'm reading >about many users that lost their trust in RH with the last 2 problem >(microcode and shim). This is bad for CentOS. > >> 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. > >Probably many users have not updated their machines between the bug >release and the resolution (thanks to your fast apply in the weekend, >thank you) and many update their centos machines on a 2 months base (if > >not worst). I think also that many users of CentOS user base have not >proclamed their disappointement/the issue on this list or in other >channels. For example I simply updated in the wrong time. > >> 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? > >you are right but is not UEFI a standard and it shouldn't work the same > >on several vendors? I ask this because this patch broken all my uefi >workstations. > >While CentOS team could not have so much resources to run this type of >tests would be great to know what happened to RHEL QA (being RH giant) >for this release and given the partenership between CentOS and RH if >you >know something more on this..... > >Thank you. > >_______________________________________________ >CentOS mailing list >CentOS at centos.org >https://lists.centos.org/mailman/listinfo/centos