On 2020-08-03 18:43, Gordon Messmer wrote:
On 8/3/20 2:21 AM, Jyrki Tikka wrote:
The boot disks must have an EFI boot partition even though it's not
used in this case.
IIRC, they need a partition at the beginning of the drive to reserve
space for GRUB2. That should be a "BIOS boot
On 8/3/20 2:21 AM, Jyrki Tikka wrote:
The boot disks must have an EFI boot partition even though it's not
used in this case.
IIRC, they need a partition at the beginning of the drive to reserve
space for GRUB2. That should be a "BIOS boot partition" not an "EFI
System partition" for
On 2020-08-03 05:56, John Pierce wrote:
Legacy BIOS has its own set of issues, like no GPT support, MBR disks
are
max 2TB.
I'm booting just fine on an old BIOS system from a pair (mdraid 1) of 3
TB GPT disks.
The MBR compatibility on GPT disks allow the old machine to boot from a
GPT disk
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
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, 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
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, 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.
> 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 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
>>
>>
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
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 question.
Second. I'm assuming the the
My system was happy UNTIL I rebooted. ThenBZZT!!!
On Sat, Aug 1, 2020, 17:02 Schatzi Olsen wrote:
> And for whatever reason, both my centos 7 and 8 survived this apparently
> with flying colors. Actually, this is out of character for how fate has
> been dealing the cards recently.
>
>
And for whatever reason, both my centos 7 and 8 survived this apparently
with flying colors. Actually, this is out of character for how fate has
been dealing the cards recently.
I'm very leary about rebooting either, now, though.
On Sat, Aug 1, 2020 at 12:50 PM Kay Schenk wrote:
> Totally
Mike --
Thanks for the clarification and more information.
___
Sent from MzK's phone.
On Sat, Aug 1, 2020, 15:42 Mike McCarthy, W1NR wrote:
> It appears that it is affecting multiple distributions including Debian
> and Ubuntu so it looks like the grub2 team messed up. See
I use debian buster on my old notebook, an asus f3ja and I have not grub
throuble. I try a virtual mschine with testing and unstable, and both boot
regularly
Il dom 2 ago 2020, 00:42 Mike McCarthy, W1NR ha scritto:
> It appears that it is affecting multiple distributions including Debian
> and
Another ZDNet story on the issue:
https://www.zdnet.com/article/red-hat-enterprise-linux-runs-into-boothole-patch-trouble/
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
who donate their time and energy to
supporting the CentOS project.
Andrea
-Original Message-
From: CentOS On Behalf Of Mike McCarthy, W1NR
Sent: Saturday, August 1, 2020 5:42 PM
To: centos@centos.org
Subject: {EXTERNAL} Re: [CentOS] Boot failed on latest CentOS 7 update
CAUTION:
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 8/1/2020 6:11 PM, Marc Balmer via CentOS wrote:
>
>
>> Am
> Am 01.08.2020 um 23:52 schrieb Leon Fauster via CentOS :
>
> Am 01.08.20 um 23:41 schrieb Kay Schenk:
>> Well misery loves company but still...just truly unfathomable!
>> Time for a change.
>
>
> I can only express my incomprehension for such statements!
>
> Stay and help. Instead running
Am 01.08.20 um 23:41 schrieb Kay Schenk:
Well misery loves company but still...just truly unfathomable!
Time for a change.
I can only express my incomprehension for such statements!
Stay and help. Instead running away or should I say out of the
frying pan and into the fire? :-)
--
Leon
Well misery loves company but still...just truly unfathomable!
Time for a change.
___
Sent from MzK's phone.
On Sat, Aug 1, 2020, 13:04 david wrote:
> At 12:50 PM 8/1/2020, Kay Schenk wrote:
> >Totally and completely on my HP microfiber. Wouldn't get past anything to
>
At 12:50 PM 8/1/2020, Kay Schenk wrote:
Totally and completely on my HP microfiber. Wouldn't get past anything to
even get me into the grub menu. NOT AMUSED!
___
Kay Schenk
I was going to confirm the same, but the system that became
unbootable was my mail system :-(
Totally and completely on my HP microfiber. Wouldn't get past anything to
even get me into the grub menu. NOT AMUSED!
___
Kay Schenk
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
42 matches
Mail list logo
