On 8/1/20 10:21 PM, Alan McRae via CentOS wrote:
This is a quick recovery and fix for the machines rendered unbootable
after the grub2/shim yum update.
It is written for CentOS 8.2.2004 but similar should work for any CentOS
8 or 7 as long as you get the correct shim file,
that is, the one
On Sun, Aug 2, 2020 at 7:14 PM Chris Adams wrote:
> Once upon a time, Jonathan Billings said:
> > On Aug 2, 2020, at 14:43, Pete Biggs wrote:
> > > You don't have to use UEFI secure booting - most machines can fall back
> > > to legacy booting using BIOS settings. If you do that, you won't use
Once upon a time, Jonathan Billings said:
> On Aug 2, 2020, at 14:43, Pete Biggs wrote:
> > You don't have to use UEFI secure booting - most machines can fall back
> > to legacy booting using BIOS settings. If you do that, you won't use
> > any Microsoft signed code.
>
> Back in 2017, Intel
This isn't the problem everyone else has been talking about, but...
I made sure that yum update offered the packages Johnny said it should
then updated. when I rebooted everything looked normal except it was
taking a long time to bring up the login screen.
Flipped over to ALT-F2 and saw a
>
> You just need to reinstall the kernel and it should work.
>
>
Is it possible to bump the kernel version number to make sure the
kernel gets re-installed on automated installs? Or would this break
the compatibility with RHEL?
P.
___
CentOS
On 8/2/20 4:11 PM, John Pierce wrote:
isn't it more that they simply won't work with newer boots that were signed
by the new keys? and the updated BIOS's won't boot older OS versions that
weren't signed by the new keys?
I don't know if the Secure Boot PKI has a publicly documented
Am 02.08.20 um 04:15 schrieb Kay Schenk:
Questions re this statement in the ZDNET article --
"In all cases, users reported that downgrading systems to a previous
release to reverse the BootHole patches usually fixed their problems."
A previous release of what? GRUB2
So that's my first
On Aug 2, 2020, at 14:43, Pete Biggs wrote:
> You don't have to use UEFI secure booting - most machines can fall back
> to legacy booting using BIOS settings. If you do that, you won't use
> any Microsoft signed code.
Back in 2017, Intel said that it was going to deprecate the “Legacy” CSM by
On Sun, Aug 2, 2020 at 3:54 PM Gordon Messmer
wrote:
> On 8/2/20 1:19 PM, John Pierce wrote:
> > One of the things that bugs me about PKI trust chains like this, what
> > happens if the unthinkable happens, and Microsoft's RootCA gets
> compromised
> > and has to be revoked... does that mean
On 8/2/20 1:19 PM, John Pierce wrote:
One of the things that bugs me about PKI trust chains like this, what
happens if the unthinkable happens, and Microsoft's RootCA gets compromised
and has to be revoked... does that mean every single piece of UEFI
hardware out there needs a BIOS upgrade?
On Sun, 2 Aug 2020 at 18:13, Robert G (Doc) Savage via CentOS
wrote:
>
> -Original Message-
> From: Stephen John Smoogen
> Reply-To: CentOS mailing list
> To: CentOS mailing list
> Subject: Re: [CentOS] 8.2.2004 Latest yum update renders machine unbootable
> Date: Sun, 2 Aug 2020
-Original Message-
From: Stephen John Smoogen
Reply-To: CentOS mailing list
To: CentOS mailing list
Subject: Re: [CentOS] 8.2.2004 Latest yum update renders machine unbootable
Date: Sun, 2 Aug 2020 10:57:49 -0400
On Sun, 2 Aug 2020 at 10:20, david wrote:
> >
I agree it is a lot of
Thanks Greg! Very clear!
___
Sent from MzK's phone.
On Sun, Aug 2, 2020, 14:07 Gregory P. Ennis wrote:
> Hello all--
> These instructions are somewhat OK but my messed up box is the only one
> I've got basically to help with this problem.
>
> Where can we find "correction"
Hello all--
These instructions are somewhat OK but my messed up box is the only one
I've got basically to help with this problem.
Where can we find "correction" instructions using a "rescue" CD or flash
drive? I understand RedHat provided detailed instructions to supported
customers.
Thanks.
On Sun, Aug 2, 2020 at 1:01 PM Phil Perry wrote:
> I believe Microsoft signs the shim which then becomes the trusted
> authority and embeds RH (or CentOS) signing cert, so (I believe) every
> release of the shim needs to be signed by Microsoft. So it's not quite
> as efficient as MS signing a
Hello all--
These instructions are somewhat OK but my messed up box is the only one
I've got basically to help with this problem.
Where can we find "correction" instructions using a "rescue" CD or flash
drive? I understand RedHat provided detailed instructions to supported
customers.
Thanks.
On 02/08/2020 19:54, John Pierce wrote:
On Sun, Aug 2, 2020 at 11:45 AM Phil Perry wrote:
On 02/08/2020 16:26, Valeri Galtsev wrote:
On the side note: it is Microsoft that signs one of Linux packages now.
We seem to have made one more step away from “our” computers being _our
computers_.
On Sun, Aug 2, 2020 at 11:45 AM Phil Perry wrote:
> On 02/08/2020 16:26, Valeri Galtsev wrote:
> >
> > On the side note: it is Microsoft that signs one of Linux packages now.
> We seem to have made one more step away from “our” computers being _our
> computers_. Am I wrong?
> >
> > Valeri
> >
>
On 02/08/2020 16:26, Valeri Galtsev wrote:
On the side note: it is Microsoft that signs one of Linux packages now. We seem
to have made one more step away from “our” computers being _our computers_. Am
I wrong?
Valeri
Microsoft are the Certificate Authority for SecureBoot and most
> On the side note: it is Microsoft that signs one of Linux packages
> now. We seem to have made one more step away from “our” computers
> being _our computers_. Am I wrong?
>
Secure booting using UEFI requires that the code is signed - that is
the "secure" bit. Microsoft are the CA for that
On Sun, 2 Aug 2020 at 13:35, Alessandro Baggi
wrote:
>
>
> Il 02/08/20 19:09, Alessandro Baggi ha scritto:
> >
> > Il 02/08/20 18:54, Stephen John Smoogen ha scritto:
> >> On a side note, you keep emphasizing you aren't expecting an SLA.. but
> >> all your questions are what someone asks to have
Il 02/08/20 19:22, Valeri Galtsev ha scritto:
On 8/2/20 12:09 PM, Alessandro Baggi wrote:
Il 02/08/20 18:54, Stephen John Smoogen ha scritto:
On a side note, you keep emphasizing you aren't expecting an SLA.. but
all your questions are what someone asks to have in a defined SLA. I
have
Il 02/08/20 19:09, Alessandro Baggi ha scritto:
Il 02/08/20 18:54, Stephen John Smoogen ha scritto:
On a side note, you keep emphasizing you aren't expecting an SLA.. but
all your questions are what someone asks to have in a defined SLA. I
have done the same thing in the past when things
On 8/2/20 12:09 PM, Alessandro Baggi wrote:
Il 02/08/20 18:54, Stephen John Smoogen ha scritto:
On a side note, you keep emphasizing you aren't expecting an SLA.. but
all your questions are what someone asks to have in a defined SLA. I
have done the same thing in the past when things have
Il 02/08/20 18:54, Stephen John Smoogen ha scritto:
On a side note, you keep emphasizing you aren't expecting an SLA.. but
all your questions are what someone asks to have in a defined SLA. I
have done the same thing in the past when things have gone badly, but
couching it in 'I am not asking'
On Sun, Aug 02, 2020 at 07:16:25AM -0700, david wrote:
>
> >
>
...
>
> >
> > You just need to reinstall the kernel and it should work.
> >
>
> Sorry for being so ignorant, but I don't understand "just reinstall the
> kernel". I don't know how to translate that into a specific yum or rpm
>
Il 02/08/20 15:10, Marc Balmer via CentOS ha scritto:
Thanks for acting quickly, especially on a weekend.
This. +1
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
On Sun, 2 Aug 2020 at 12:08, Alessandro Baggi
wrote:
>
> Hi Johnny,
> thank you for your answer. I always accepted release cycle of CentOS
> without any problem (maybe with EL8 but it is ok).
>
> I don't need SLA and I don't blame anyone for this, errors can occour. For
> example in this story, I
Hi Johnny,
thank you for your answer. I always accepted release cycle of CentOS
without any problem (maybe with EL8 but it is ok).
I don't need SLA and I don't blame anyone for this, errors can occour. For
example in this story, I applied blindly updates without check what and how
so really I ran
> On Aug 2, 2020, at 9:14 AM, Gregory P. Ennis wrote:
>
> On 8/2/20 2:47 AM, Alessandro Baggi wrote:
>>
>> Il 02/08/20 00:42, Mike McCarthy, W1NR ha scritto:
>>> It appears that it is affecting multiple distributions including Debian
>>> and Ubuntu so it looks like the grub2 team messed up.
On Sun, 2 Aug 2020 at 11:06, david wrote:
> > > Sorry for being so ignorant, but I don't
> > > understand "just reinstall the kernel". I don't
> > > know how to translate that into a specific yum or rpm command.
> >
> >I agree it is a lot of shorthand because of expectations. In the end
> >we
> From: david
> Sent: Sunday, August 2, 2020 10:16 AM
> > >> Yes .. it should be on mirror.centos.org now .. you could change the
> > >> repo where your updates come from. OR .. wait for that mirror to get
> > >> updated.
> > >
> > >
> > > I just did
> > > yum clean all
> > > yum update
> > >
>
At 07:57 AM 8/2/2020, you wrote:
On Sun, 2 Aug 2020 at 10:20, david wrote:
>
>
> >
>
>
>
>
> > >> Yes .. it should be on mirror.centos.org now .. you could change the
> > >> repo where your updates come from.Ã OR
.. wait for that mirror to get
> > >> updated.
> > >
> > >
> > > I just did
>
On Sun, 2 Aug 2020 at 10:20, david wrote:
>
>
> >
>
>
>
>
> > >> Yes .. it should be on mirror.centos.org now .. you could change the
> > >> repo where your updates come from. OR .. wait for that mirror to get
> > >> updated.
> > >
> > >
> > > I just did
> > > yum clean all
> > > yum update
> >
>> Yes .. it should be on mirror.centos.org now .. you could change the
>> repo where your updates come from. OR .. wait for that mirror to get
>> updated.
>
>
> I just did
> yum clean all
> yum update
>
> and 15-8 showed up. Maybe the 'clean all'
did it, or maybe just showed up.
>> Yes .. it should be on mirror.centos.org now .. you could change the
>> repo where your updates come from. OR .. wait for that mirror to get
>> updated.
>
>
> I just did
> yum clean all
> yum update
>
> and 15-8 showed up. Maybe the 'clean all'
did it, or maybe just showed up.
> Is the latest update :
> shim-x64 x86_64 15-7.el7_9
No. 15-8 is.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
On 8/2/20 2:47 AM, Alessandro Baggi wrote:
>
> Il 02/08/20 00:42, Mike McCarthy, W1NR ha scritto:
> > It appears that it is affecting multiple distributions including Debian
> > and Ubuntu so it looks like the grub2 team messed up. See
> >
> >
On 8/2/20 8:47 AM, david wrote:
> At 06:37 AM 8/2/2020, Johnny Hughes wrote:
>> On 8/2/20 8:30 AM, david wrote:
>> > At 06:10 AM 8/2/2020, you wrote:
>> >> On 8/2/20 8:04 AM, david wrote:
>> >> >
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> >> > I'll post here again once we have pushed the EL8 and
At 06:37 AM 8/2/2020, Johnny Hughes wrote:
On 8/2/20 8:30 AM, david wrote:
> At 06:10 AM 8/2/2020, you wrote:
>> On 8/2/20 8:04 AM, david wrote:
>> >
>> >>
>> >
>> >
>> >
>> >> > I'll post here again once we have pushed the EL8 and CentOS Stream
>> >> updates.
>> >>
>> >> OK .. I have also now
On 8/2/20 8:30 AM, david wrote:
> At 06:10 AM 8/2/2020, you wrote:
>> On 8/2/20 8:04 AM, david wrote:
>> >
>> >>
>> >
>> >
>> >
>> >> > I'll post here again once we have pushed the EL8 and CentOS Stream
>> >> updates.
>> >>
>> >> OK .. I have also now pushed the CentOS Linux 8 update .. you
>>
At 06:10 AM 8/2/2020, you wrote:
On 8/2/20 8:04 AM, david wrote:
>
>>
>
>
>
>> > I'll post here again once we have pushed the EL8 and CentOS Stream
>> updates.
>>
>> OK .. I have also now pushed the CentOS Linux 8 update .. you should see
>> an update to SHIM .. the new versions are:
>>
>>
On 8/2/20 8:12 AM, Johnny Hughes wrote:
> On 8/2/20 8:10 AM, Marc Balmer via CentOS wrote:
Please report both positive and negative results.
>>>
>>> A previously afftected Aures nino POS-terminal boots just fine with CentOS
>>> 7 and shim 15.8.
>>>
>>> Now I will test an affected
On 8/2/20 8:10 AM, Marc Balmer via CentOS wrote:
>>>
>>> Please report both positive and negative results.
>>
>> A previously afftected Aures nino POS-terminal boots just fine with CentOS 7
>> and shim 15.8.
>>
>> Now I will test an affected machine (Aures Twist POS terminal) that runs
>> CentOS
On 8/2/20 8:04 AM, david wrote:
>
>>
>
>
>
>> > I'll post here again once we have pushed the EL8 and CentOS Stream
>> updates.
>>
>> OK .. I have also now pushed the CentOS Linux 8 update .. you should see
>> an update to SHIM .. the new versions are:
>>
>>
>>
>> Please report both positive and negative results.
>
> A previously afftected Aures nino POS-terminal boots just fine with CentOS 7
> and shim 15.8.
>
> Now I will test an affected machine (Aures Twist POS terminal) that runs
> CentOS 8 (well, usually runs CentOS 8, but not now, since it
> I'll post here again once we have pushed the EL8 and CentOS Stream updates.
OK .. I have also now pushed the CentOS Linux 8 update .. you should see
an update to SHIM .. the new versions are:
PowerTools/x86_64/os/Packages/shim-unsigned-x64-15-8.el8.x86_64.rpm
On 8/2/20 2:47 AM, Alessandro Baggi wrote:
>
> Il 02/08/20 00:42, Mike McCarthy, W1NR ha scritto:
>> It appears that it is affecting multiple distributions including Debian
>> and Ubuntu so it looks like the grub2 team messed up. See
>>
>>
> Am 02.08.2020 um 14:34 schrieb Johnny Hughes :
>
> On 8/2/20 6:59 AM, Johnny Hughes wrote:
>>> On 8/2/20 2:04 AM, Alessandro Baggi wrote:
>>>
>>> Il 01/08/20 22:03, Greg Bailey ha scritto:
On 8/1/20 6:56 AM, david wrote:
> At 02:54 AM 8/1/2020, Alessandro Baggi wrote:
>> Hi
On 8/2/20 6:59 AM, Johnny Hughes wrote:
> On 8/2/20 2:04 AM, Alessandro Baggi wrote:
>>
>> Il 01/08/20 22:03, Greg Bailey ha scritto:
>>> On 8/1/20 6:56 AM, david wrote:
At 02:54 AM 8/1/2020, Alessandro Baggi wrote:
> Hi Johnny,
> thank you very much for clarification.
>
> You
On 8/2/20 7:06 AM, Robert Heller wrote:
> At Sun, 2 Aug 2020 06:59:06 -0500 CentOS mailing list
> wrote:
>
>>
>>
>>
>> On 8/2/20 2:04 AM, Alessandro Baggi wrote:
>>>
>>> Il 01/08/20 22:03, Greg Bailey ha scritto:
On 8/1/20 6:56 AM, david wrote:
> At 02:54 AM 8/1/2020, Alessandro Baggi
At Sun, 2 Aug 2020 06:59:06 -0500 CentOS mailing list wrote:
>
>
>
> On 8/2/20 2:04 AM, Alessandro Baggi wrote:
> >
> > Il 01/08/20 22:03, Greg Bailey ha scritto:
> >> On 8/1/20 6:56 AM, david wrote:
> >>> At 02:54 AM 8/1/2020, Alessandro Baggi wrote:
> Hi Johnny,
> thank you very
On 8/2/20 2:04 AM, Alessandro Baggi wrote:
>
> Il 01/08/20 22:03, Greg Bailey ha scritto:
>> On 8/1/20 6:56 AM, david wrote:
>>> At 02:54 AM 8/1/2020, Alessandro Baggi wrote:
Hi Johnny,
thank you very much for clarification.
You said that in the centos infrastructure only one
Le 02/08/2020 à 09:47, Alessandro Baggi a écrit :
>
> Il 02/08/20 00:42, Mike McCarthy, W1NR ha scritto:
>> It appears that it is affecting multiple distributions including Debian
>> and Ubuntu so it looks like the grub2 team messed up. See
>>
>>
Hi Paride,
I also have a debian 10 on a workstation and some VMs for test purpose.
Probably you updated after the grub-regression update but I noticed
several stories about debian breakage.
Il 02/08/20 01:13, paride desimone ha scritto:
I use debian buster on my old notebook, an asus f3ja
Il 02/08/20 00:42, Mike McCarthy, W1NR ha scritto:
It appears that it is affecting multiple distributions including Debian
and Ubuntu so it looks like the grub2 team messed up. See
https://www.zdnet.com/article/boothole-fixes-causing-boot-problems-across-multiple-linux-distros/
Mike
On
Il 01/08/20 22:03, Greg Bailey ha scritto:
On 8/1/20 6:56 AM, david wrote:
At 02:54 AM 8/1/2020, Alessandro Baggi wrote:
Hi Johnny,
thank you very much for clarification.
You said that in the centos infrastructure only one server got the
problem.
What are the conditions that permit the
57 matches
Mail list logo
