On Wed, Jul 7, 2021 at 8:23 AM Vitaly Zaitsev via devel
wrote:
>
> On 06/07/2021 23:27, Christian Stadelmann wrote:
> > In other words: I think it is too early to drop non-(U)EFI BIOS support.
>
> Btw, the upcoming Windows 11 will require full UEFI support, enabled
> UEFI Secure Boot and TPM 2.0.
On 06/07/2021 23:27, Christian Stadelmann wrote:
In other words: I think it is too early to drop non-(U)EFI BIOS support.
Btw, the upcoming Windows 11 will require full UEFI support, enabled
UEFI Secure Boot and TPM 2.0.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.org)
On Tue, Jul 6, 2021 at 7:05 PM Chris Murphy wrote:
>
> On Tue, Jul 6, 2021 at 3:37 PM Christian Stadelmann
> wrote:
> >
> > > […] and move to uefi only supported boot which
> > > has been available on any common intel based x86 platform since atleast
> > > 2005.
> >
> > (U)EFI was not available
On Tue, Jul 6, 2021 at 3:37 PM Christian Stadelmann
wrote:
>
> > […] and move to uefi only supported boot which
> > has been available on any common intel based x86 platform since atleast
> > 2005.
>
> (U)EFI was not available for the general market in 2005 (except on Apple
> devices maybe). It
> […] and move to uefi only supported boot which
> has been available on any common intel based x86 platform since atleast
> 2005.
(U)EFI was not available for the general market in 2005 (except on Apple
devices maybe). It was introduced around 2011.
I own 2 devices which are booting with
On Wed, Jul 01, 2020 at 12:49:17AM +0200, Kevin Kofler wrote:
> Jóhann B. Guðmundsson wrote:
> > Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes
> > it beg the question if now would not be the time to stop supporting
> > booting in legacy bios mode and move to uefi only
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/T6CKCW64YVWM6LEPO6KDCTZJYSQVUQL4/
The fact of the rejection of the OP to drop BIOS support is difficult to find.
You should therefore have suggested to never again bring up the issue of
dropping BIOS support
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4GFKE56HTECMQ45RMPALBDFPMORQCQKQ/
it came up on ask.fedora and is linked into here.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an
On 2021-05-27 2:28 p.m., Sam Varshavchik wrote:
It a shame if Fedora were to abandon its long-time users. This proposal
was already brough up earlier this year and was described as a
non-starter back then. I haven't paid attention and I hope this is still
a non-starter; otherwise, as I said,
Marius Schwarz writes:
Am 30.06.20 um 15:34 schrieb Jóhann B. Guðmundsson:
Given Hans proposal [1] introduced systemd/grub2/Gnome upstream changes it
beg the question if now would not be the time to stop supporting booting in
legacy bios mode and move to uefi only supported boot which has
On Thu, 2021-05-27 at 09:35 +, eedio wrote:
> well,
>
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QBANCA2UAJ5ZSMDVVARLIYAJE66TYTCD/
>
> suggesting to drop BIOS is a nonstarter.
This thread died over half a year ago (back in October of last year)
On 5/27/21 10:45 AM, Nikolay Nikolov wrote:
That is quite a painful process. And how do you do that on a MBR system that
dual boots Fedora and Windows 10? I really don't want to go through the pain of
reinstalling Windows and all the programs that I have there.
There's no migration path that
On 5/27/21 5:25 PM, Vitaly Zaitsev via devel wrote:
On 27.05.2021 16:17, Marius Schwarz wrote:
Also, a lot of laptops are installed in Legacy Mode, as setting them
up in EFI was impossible.
1. Backup all data.
2. Convert MBR to GPT.
3. Create an ESP partition, add it to the /etc/fstab file
On 27.05.2021 16:17, Marius Schwarz wrote:
Also, a lot of laptops are installed in Legacy Mode, as setting them up
in EFI was impossible.
1. Backup all data.
2. Convert MBR to GPT.
3. Create an ESP partition, add it to the /etc/fstab file and mount.
4. sudo dnf swap grub2 grub2-efi
5. sudo dnf
Am 30.06.20 um 15:34 schrieb Jóhann B. Guðmundsson:
Given Hans proposal [1] introduced systemd/grub2/Gnome upstream
changes it beg the question if now would not be the time to stop
supporting booting in legacy bios mode and move to uefi only supported
boot which has been available on any
well,
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/QBANCA2UAJ5ZSMDVVARLIYAJE66TYTCD/
suggesting to drop BIOS is a nonstarter.
much like Mr Jóhann B. Guðmundsson's argument that UEFI is on sale since 2005
, only 16 years.
A completely weightless
> On Saturday, July 4, 2020 6:44:55 AM MST Solomon Peachy wrote:
>
> There are still new systems built today that only support BIOS, and vendors
> providing systems factory-configured for BIOS boot on hardware that does
> support UEFI. There is no 2TB upper limit on drive sizes as a result of
b
On Tue, Oct 20, 2020 at 8:49 PM Jóhann B. Guðmundsson
wrote:
>
> On 19.10.2020 17:25, Michael Catanzaro wrote:
> > On Mon, Oct 19, 2020 at 8:16 pm, Arnoldas Skinderis
> > wrote:
> >> I'am also have Thikpads and MSI running BIOS and some of those
> >> machines still are the beast in some
On 19.10.2020 17:25, Michael Catanzaro wrote:
On Mon, Oct 19, 2020 at 8:16 pm, Arnoldas Skinderis
wrote:
I'am also have Thikpads and MSI running BIOS and some of those
machines still are the beast in some terms. Dropping BIOS would
pretty much force me to use something else.
I don't want to
Le mardi 20 octobre 2020 à 12:32 +0200, Petr Pisar a écrit :
>
> In my opinion what became slugish (besides web browsers) are desktop
> environments that "accelerated" GUI by a move to OpenGL and
> JavaScript.
> A typical examples are login managers. GDM actually loads full Gnome,
> thus GDM
>
On 10/19/20 6:47 PM, Stephen John Smoogen wrote:
The issue is that while 'moore's' law was no longer doubling every 18months
it was still working and tasks had to be rewritten to work with more
cores/threads/etc. As that happened the software's need for more CPU power
has increased to the point
On Mon, Oct 19, 2020 at 12:47:55PM -0400, Stephen John Smoogen wrote:
>
> The issue is that while 'moore's' law was no longer doubling every 18months
> it was still working and tasks had to be rewritten to work with more
> cores/threads/etc. As that happened the software's need for more CPU power
Am 19.10.20 um 18:47 schrieb Stephen John Smoogen:
> The issue is that while 'moore's' law was no longer doubling every
> 18months it was still working and tasks had to be rewritten to work
> with more cores/threads/etc. As that happened the software's need for
> more CPU power has increased to
Le lundi 19 octobre 2020 à 12:47 -0400, Stephen John Smoogen a écrit :
> It is only after Moore's law 'broke' after 2003 stopped seeing
> doubling cpu speeds every 18 months that trying to keep hardware
> useful longer than 5 years has been possible.
The real turning point is when Microsoft
Arnoldas Skinderis writes:
I'am also have Thikpads and MSI running BIOS and some of those machines
still are the beast in some terms. Dropping BIOS would pretty much force me
to use something else.
I don't want to lose Fedora.
Ditto. My Thinkpad W520 is the best damn Fedora laptop.
On 10/19/20 11:33 AM, Hans de Goede wrote:
I guess those machines are more or less the cut-off point and slower machines
are not worth keeping around. But that means that there still are a ton
of BIOS machines worth keeping around.
Note that even most sandy bridge machines do not support UEFI
Hi,
On 10/19/20 6:47 PM, Stephen John Smoogen wrote:
> The issue is that while 'moore's' law was no longer doubling every 18months
> it was still working and tasks had to be rewritten to work with more
> cores/threads/etc. As that happened the software's need for more CPU power
> has increased
> >> This proposal was soundly rejected, so don't worry about it.
> >
> > That's great news. Thank you!
> I am not thrilled that this has been rejected since efi support is not
> so good on Fedora.
How do you mean, it's supported quite well IMO with support for things
like secure boot and UEFI
On Mon, Oct 19, 2020 at 5:46 PM Damian Ivanov wrote:
>
> >> This proposal was soundly rejected, so don't worry about it.
> >
> > That's great news. Thank you!
> I am not thrilled that this has been rejected since efi support is not
> so good on Fedora.
> Devices that are BIOS can IIRC still use
>> This proposal was soundly rejected, so don't worry about it.
>
> That's great news. Thank you!
I am not thrilled that this has been rejected since efi support is not
so good on Fedora.
Devices that are BIOS can IIRC still use efi using a boot tool
installed to the MBR which emulates EFI
and
On Mon, Oct 19, 2020 at 8:27 PM Michael Catanzaro
wrote:
> On Mon, Oct 19, 2020 at 8:16 pm, Arnoldas Skinderis
> wrote:
> > I'am also have Thikpads and MSI running BIOS and some of those
> > machines still are the beast in some terms. Dropping BIOS would
> > pretty much force me to use
On Mon, Oct 19, 2020 at 8:16 pm, Arnoldas Skinderis
wrote:
I'am also have Thikpads and MSI running BIOS and some of those
machines still are the beast in some terms. Dropping BIOS would
pretty much force me to use something else.
I don't want to lose Fedora.
This proposal was soundly
On Mon, Oct 19, 2020 at 7:48 PM Stephen John Smoogen
wrote:
>
>
> On Mon, 19 Oct 2020 at 02:15, Subsentient
> wrote:
>
>> I figure I'll add my two cents for as little as that's worth.
>>
>> Personally, I use extlinux with a custom, barebones configuration. On my
>> EFI systems, I use syslinux
On Mon, 19 Oct 2020 at 02:15, Subsentient wrote:
> I figure I'll add my two cents for as little as that's worth.
>
> Personally, I use extlinux with a custom, barebones configuration. On my
> EFI systems, I use syslinux EFI. I like the simplicity of syntax for
> syslinux's configuration and how
I figure I'll add my two cents for as little as that's worth.
Personally, I use extlinux with a custom, barebones configuration. On my EFI
systems, I use syslinux EFI. I like the simplicity of syntax for syslinux's
configuration and how small it is, but that's me, and it's not going to be
On Monday, July 13, 2020 7:52:51 AM MST Przemek Klosowski via devel wrote:
> On 7/10/20 5:22 PM, John M. Harris Jr wrote:
> >> Android, actually, is trying to get it right by a) being a platform so
> >> that common security updates are available from the platform owner, and
> >> can be applied to
On 7/10/20 5:22 PM, John M. Harris Jr wrote:
Android, actually, is trying to get it right by a) being a platform so
that common security updates are available from the platform owner, and
can be applied to everyone's system and b) having a secure remote update
method.
The problem with
On Sun, Jul 12, 2020 at 03:35:05AM +1000, Philip Rhoades wrote:
> > Marginal costs are still costs. They add up _very_ quickly.
> >
> > If they can save $0.01 by eliminating a physical button, over a
> > million-unit production run that's a cool $1 million of potantial
> > profit.
> Really?
Solomon,
On 2020-07-11 21:41, Solomon Peachy wrote:
On Sat, Jul 11, 2020 at 10:03:47AM +0200, Nicolas Mailhot via devel
wrote:
The marginal cost of a button is completely marginal, on devices that
already include other buttons, on a assembly line that already builds
a
ton of such things.
On Sat, Jul 11, 2020 at 10:03:47AM +0200, Nicolas Mailhot via devel wrote:
> The marginal cost of a button is completely marginal, on devices that
> already include other buttons, on a assembly line that already builds a
> ton of such things.
Marginal costs are still costs. They add up _very_
On Tue, Jul 7, 2020 at 6:17 AM Gerd Hoffmann wrote:
>
> On Mon, Jul 06, 2020 at 01:26:31PM -0700, John M. Harris Jr wrote:
> > I guess that shows how unfamiliar I am with UEFI boot Fedora. You would
> > encrypt /boot to ensure that your boot images have not been tampered with,
>
> Well, if that
Le vendredi 10 juillet 2020 à 08:55 -0400, Przemek Klosowski a écrit :
>
> The marginal cost of a digital key has got to be smaller than the
> marginal cost of the button
The marginal cost of a button is completely marginal, on devices that
already include other buttons, on a assembly line that
On Friday, July 10, 2020 5:05:51 AM MST Nicolas Mailhot via devel wrote:
> Le vendredi 10 juillet 2020 à 07:51 -0400, Solomon Peachy a écrit :
>
> > On Fri, Jul 10, 2020 at 01:37:14PM +0200, Nicolas Mailhot via devel
> > wrote:
> >
> > > If you remove end users from the loop there is zero zip
On Friday, July 10, 2020 4:12:42 AM MST Przemek Klosowski via devel wrote:
> On 7/10/20 5:06 AM, Nicolas Mailhot wrote:
>
> > The problem IOT side is not the security of the
> > software update chain. The problem is that manufacturers skimp on
> > software updates in the first place
>
>
> Yes,
On 7/10/20 8:25 AM, Nicolas Mailhot wrote:
Le vendredi 10 juillet 2020 à 08:00 -0400, Przemek Klosowski a écrit :
Not quite---as I said in next sentence that you didn't include in
your quote, secure boot also tries to prevent unauthorized
modifications,
That does not work either, because if
Le vendredi 10 juillet 2020 à 08:00 -0400, Przemek Klosowski a écrit :
> >
> Not quite---as I said in next sentence that you didn't include in
> your quote, secure boot also tries to prevent unauthorized
> modifications,
That does not work either, because if your system is remotely
exploitable,
Le vendredi 10 juillet 2020 à 07:51 -0400, Solomon Peachy a écrit :
> On Fri, Jul 10, 2020 at 01:37:14PM +0200, Nicolas Mailhot via devel
> wrote:
> > If you remove end users from the loop there is zero zip nada need
> > for
> > secure boot in the first place. The sole function of secure boot
> >
On 7/10/20 7:37 AM, Nicolas Mailhot wrote:
Le vendredi 10 juillet 2020 à 07:12 -0400, Przemek Klosowski via devel
a écrit :
My point is that however the updates are being produced, they need a
secure remote update method. It's not realistic to expect end users
to be in the loop
If you remove
On Fri, Jul 10, 2020 at 01:37:14PM +0200, Nicolas Mailhot via devel wrote:
> If you remove end users from the loop there is zero zip nada need for
> secure boot in the first place. The sole function of secure boot and
> DRPM is to prevent end users, present in the update loop, from doing
> things
Hello, Faye.
On Saturday, 04 July 2020 at 00:42, Faye C. wrote:
[...]
> Because of the way Windows 10 is, UEFI is the only thing that is
> accepted (no Legacy Boot). If I try any other OS on UEFI my laptop
> can't find the disc image. It somehow seems to be designed only for
> Windows 10. Legacy
Le vendredi 10 juillet 2020 à 07:12 -0400, Przemek Klosowski via devel
a écrit :
>
> My point is that however the updates are being produced, they need a
> secure remote update method. It's not realistic to expect end users
> to be in the loop
If you remove end users from the loop there is zero
On Thu, Jul 9, 2020 at 5:20 PM Chris Adams wrote:
>
> Once upon a time, nick...@gmail.com said:
> > To be honest, I don't know. Do all UEFI secure boot implementations
> > allow you to add your own keys to the list of trusted keys?
>
> I believe that the Microsoft OEM Windows x86_64 distribution
On 7/10/20 5:06 AM, Nicolas Mailhot wrote:
The problem IOT side is not the security of the
software update chain. The problem is that manufacturers skimp on
software updates in the first place
Yes, that's the situation right now: everyone has a custom firmware tied
to a short product
Le jeudi 09 juillet 2020 à 23:58 -0400, Przemek Klosowski via devel a
écrit :
>
> While it's true that a completely secure software chain doesn't
> really exist yet, we are slowly going in that direction, because it
> is just inconceivable otherwise in the world with billions of
> autonomous IOT
On 7/9/20 10:46 AM, John M. Harris Jr wrote:
"Secure Boot" doesn't make root non-uid 0, and can't keep root from
controlling system devices, even uploading unsigned firmware to peripherals.
While it's true that a completely secure software chain doesn't really
exist yet, we are slowly going
Once upon a time, nick...@gmail.com said:
> To be honest, I don't know. Do all UEFI secure boot implementations
> allow you to add your own keys to the list of trusted keys?
I believe that the Microsoft OEM Windows x86_64 distribution
requirements require UEFI, with Scure Boot enabled, and with
On Thu, 09 Jul 2020 23:10:46 +0300
nick...@gmail.com wrote:
> On Thu, 2020-07-09 at 11:17 -0700, stan via devel wrote:
> > That is, isn't this only an issue if the person doing the kernel
> > development hasn't generated their own key, and isn't signing their
> > kernels locally?
>
> To be
On Thu, 2020-07-09 at 23:10 +0300, nick...@gmail.com wrote:
> On Thu, 2020-07-09 at 11:17 -0700, stan via devel wrote:
> > On Thu, 09 Jul 2020 18:07:39 +0300
> > nick...@gmail.com wrote:
> >
> > > Yes, that's why "secure boot" should only be an option and the user
> > > must have the option to
On Thu, 2020-07-09 at 11:17 -0700, stan via devel wrote:
> On Thu, 09 Jul 2020 18:07:39 +0300
> nick...@gmail.com wrote:
>
> > Yes, that's why "secure boot" should only be an option and the user
> > must have the option to turn it off. Otherwise, it wouldn't be
> > possible to do any kernel
On Thu, 09 Jul 2020 18:07:39 +0300
nick...@gmail.com wrote:
> Yes, that's why "secure boot" should only be an option and the user
> must have the option to turn it off. Otherwise, it wouldn't be
> possible to do any kernel development on that computer.
For my edification. I build custom
On Thu, 2020-07-09 at 07:46 -0700, John M. Harris Jr wrote:
> On Thursday, July 9, 2020 3:38:54 AM MST Richard Hughes wrote:
> > On Wed, 8 Jul 2020 at 22:19, John M. Harris Jr <
> > joh...@splentity.com>
> > wrote:
> > > This is not something that's beneficial here, it's only
> > > harming our
On Thu, 2020-07-09 at 07:38 -0700, John M. Harris Jr wrote:
> On Thursday, July 9, 2020 12:26:27 AM MST Daniel P. Berrangé wrote:
> > On Wed, Jul 08, 2020 at 02:17:53PM -0700, John M. Harris Jr wrote:
> >
> > > On Wednesday, July 8, 2020 10:04:01 AM MST Richard Hughes wrote:
> > >
> > > > On
On Thursday, July 9, 2020 3:38:54 AM MST Richard Hughes wrote:
> On Wed, 8 Jul 2020 at 22:19, John M. Harris Jr
> wrote:
> > This is not something that's beneficial here, it's only
> > harming our users.
>
>
> That seems exceedingly myopic to me. I'm guessing you've not been
> following the
On Thursday, July 9, 2020 12:26:27 AM MST Daniel P. Berrangé wrote:
> On Wed, Jul 08, 2020 at 02:17:53PM -0700, John M. Harris Jr wrote:
>
> > On Wednesday, July 8, 2020 10:04:01 AM MST Richard Hughes wrote:
> >
> > > On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr
> > > wrote:
> > >
> > > >
On Wed, 8 Jul 2020 at 22:19, John M. Harris Jr wrote:
> This is not something that's beneficial here, it's only
> harming our users.
That seems exceedingly myopic to me. I'm guessing you've not been
following the last few years of security research, where attacking the
firmware is now the best
On Wed, Jul 08, 2020 at 02:17:53PM -0700, John M. Harris Jr wrote:
> On Wednesday, July 8, 2020 10:04:01 AM MST Richard Hughes wrote:
> > On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr
> > wrote:
> > > needlessly disables a lot of kernel functionality
> >
> >
> > It disables functionality which
On Wednesday, July 8, 2020 10:04:01 AM MST Richard Hughes wrote:
> On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr
> wrote:
> > needlessly disables a lot of kernel functionality
>
>
> It disables functionality which can destroy platform security.
It disables functionality that users need, such
On 7/8/20 10:47 AM, John M. Harris Jr wrote:
On Tuesday, July 7, 2020 3:17:16 AM MST Gerd Hoffmann wrote:
On Mon, Jul 06, 2020 at 01:26:31PM -0700, John M. Harris Jr wrote:
Well, if that is your concern the answer is secure boot. That will not
only prevent tampering with /boot files, but
Once upon a time, Richard Hughes said:
> tl;dr: if you care about platform security at all, enable secure boot.
If you want to use interesting and useful kernel technologies (namely
eBPF), disable secure boot. That's a real killer of secure boot IMHO.
--
Chris Adams
On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr wrote:
> needlessly disables a lot of kernel functionality
It disables functionality which can destroy platform security.
> You cannot load kernel modules you've built
If you can build and insert your own kernel module you can do almost
anything
On Tuesday, July 7, 2020 3:17:16 AM MST Gerd Hoffmann wrote:
> On Mon, Jul 06, 2020 at 01:26:31PM -0700, John M. Harris Jr wrote:
>
> > On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote:
> >
> > > Default fedora disk layout in UEFI mode is partitions for ESP, /boot
> > > and
> > > LVM.
On Mo, 06.07.20 21:58, Peter Robinson (pbrobin...@gmail.com) wrote:
> >
> > Less complexity in the boot chain, mainly. But the EFI drivers would
> > need to be signed by MS, I think? That would massively complicate
> > things.
>
> I believe that to be correct, of could Apply has control over that
Once upon a time, Lennart Poettering said:
> EFI SecureBoot uses PE signed executables.
Secure Boot also triggers the Linux kernel to disable functionality, so
should be avoided as a requirement (except when necessary to boot some
other OSes).
--
Chris Adams
On Mo, 06.07.20 16:34, Neal Gompa (ngomp...@gmail.com) wrote:
> Encryption != integrity/authentication. The only thing encryption
> guarantees is that the data is not visible, not that it hasn't been
> tampered with. Usually, dm-verity or dm-integrity is used for what
> you're asking for. Android
On Tue, Jul 7, 2020 at 11:17 AM Gerd Hoffmann wrote:
>
> On Mon, Jul 06, 2020 at 01:26:31PM -0700, John M. Harris Jr wrote:
> > On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote:
> > > Default fedora disk layout in UEFI mode is partitions for ESP, /boot and
> > > LVM. If you ask for
On Mon, Jul 06, 2020 at 01:26:31PM -0700, John M. Harris Jr wrote:
> On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote:
> > Default fedora disk layout in UEFI mode is partitions for ESP, /boot and
> > LVM. If you ask for full disk encryption LVM is encrypted, ESP + boot
> > are not.
On Monday, July 6, 2020 3:03:05 PM MST Peter Robinson wrote:
> > > It's less complex to maintain one solution for both types of boot, I'd
> > > imagine. I'm not the one that'd be doing the work to support it, so far
> > > be it from me to prevent somebody from doing so, but that's just what
> > >
> > It's less complex to maintain one solution for both types of boot, I'd
> > imagine. I'm not the one that'd be doing the work to support it, so far be
> > it
> > from me to prevent somebody from doing so, but that's just what it sounds
> > like. Right now, we have one solution that works well
On Mon, Jul 6, 2020 at 5:05 PM John M. Harris Jr wrote:
>
> On Monday, July 6, 2020 1:34:05 PM MST Neal Gompa wrote:
> > On Mon, Jul 6, 2020 at 4:26 PM John M. Harris Jr
> > wrote:
> > >
> > >
> > > On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote:
> > >
> > > > Default fedora disk
On Monday, July 6, 2020 1:34:05 PM MST Neal Gompa wrote:
> On Mon, Jul 6, 2020 at 4:26 PM John M. Harris Jr
> wrote:
> >
> >
> > On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote:
> >
> > > Default fedora disk layout in UEFI mode is partitions for ESP, /boot
> > > and
> > > LVM. If you
> > I guess that shows how unfamiliar I am with UEFI boot Fedora. You would
> > encrypt /boot to ensure that your boot images have not been tampered with,
> > or
> > config files haven't been read by somebody other than the end user.
> >
>
> Encryption != integrity/authentication. The only thing
On Mon, Jul 6, 2020 at 4:26 PM John M. Harris Jr wrote:
>
> On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote:
> > Default fedora disk layout in UEFI mode is partitions for ESP, /boot and
> > LVM. If you ask for full disk encryption LVM is encrypted, ESP + boot
> > are not. Which makes
On Monday, July 6, 2020 5:24:32 AM MST Gerd Hoffmann wrote:
> Default fedora disk layout in UEFI mode is partitions for ESP, /boot and
> LVM. If you ask for full disk encryption LVM is encrypted, ESP + boot
> are not. Which makes sense to me. Why would you encrypt /boot? The
> files you can
Hi,
On 7/6/20 9:36 PM, John M. Harris Jr wrote:
On Monday, July 6, 2020 5:51:40 AM MST Gerd Hoffmann wrote:
Image boots in both uefi (sd-boot) and bios (grub2) mode, and the config
file for the latter is so short that I can include it here without
hitting the mailing list size limit ;)
On Monday, July 6, 2020 2:10:18 AM MST Jóhann B. Guðmundsson wrote:
> On 5.7.2020 19:31, Solomon Peachy wrote:
>
> > On Sun, Jul 05, 2020 at 07:18:47PM -, Tom Seewald wrote:
> >
> >> In terms of physical x86 systems, you are right that UEFI is the
> >> overwhelming majority. But as stated
On 6.7.2020 12:07, Tomasz Torcz wrote:
On Mon, Jul 06, 2020 at 01:31:30PM +0200, Gerd Hoffmann wrote:
The BIOS provides block device access at sector level, so the boot
loader has little choice but implementing drivers for all kinds of
stuff. Or use fragile block lists like lilo did in the
On Monday, July 6, 2020 5:51:40 AM MST Gerd Hoffmann wrote:
> Image boots in both uefi (sd-boot) and bios (grub2) mode, and the config
> file for the latter is so short that I can include it here without
> hitting the mailing list size limit ;)
>
> -- cut here
On 6.7.2020 18:39, Javier Martinez Canillas wrote:
On Mon, Jul 6, 2020 at 10:39 AM Jóhann B. Guðmundsson
wrote:
On 5.7.2020 18:34, Javier Martinez Canillas wrote:
On Sat, Jul 4, 2020 at 6:27 PM Lennart Poettering wrote:
[snip]
Please submit additions to the spec as PRs to systemd github.
Out of the 2 computers I own, 2 only boot through legacy BIOS. One claims to
have UEFI support but I haven't managed to get it running with tens of hours of
work over the years.
In other words: I think it is too early to drop support for this legacy
technology.
On Mon, Jul 6, 2020 at 10:39 AM Jóhann B. Guðmundsson
wrote:
>
> On 5.7.2020 18:34, Javier Martinez Canillas wrote:
> > On Sat, Jul 4, 2020 at 6:27 PM Lennart Poettering
> > wrote:
> >
> > [snip]
> >
> >> Please submit additions to the spec as PRs to systemd github. We added
> >> a number of
On Mon, 2020-07-06 at 14:51 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > My real problem with grub2 is not that it's complex, but the fact
> > that
> > it exposes its complexities to the user.
>
> The config file syntax is a mess indeed. The fact that you need a
> config generator tool in the
Le 2020-07-06 16:33, Gerd Hoffmann a écrit :
On Mon, Jul 06, 2020 at 03:45:45PM +0200, Nicolas Mailhot via devel
wrote:
Le lundi 06 juillet 2020 à 15:33 +0200, Gerd Hoffmann a écrit :
> Â Â Hi,
>
> See above. sd-boot allows to edit the kernel command line too. Same
> hotkey ('e') even.
On Mon, Jul 06, 2020 at 03:45:45PM +0200, Nicolas Mailhot via devel wrote:
> Le lundi 06 juillet 2020 à 15:33 +0200, Gerd Hoffmann a écrit :
> > Â Â Hi,
> >
> > See above. sd-boot allows to edit the kernel command line too. Same
> > hotkey ('e') even. And unlike the 'l' and 'w' hotkeys that
On Mon, 2020-07-06 at 15:33 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > default entry highlighted, a few seconds timeout with countdown. Both
> > > support editing boot entries.
> > Anecdata, but I definitely never (maybe once 15 years ago?) had grub
> > install issue, but plenty of dracut
Le lundi 06 juillet 2020 à 15:33 +0200, Gerd Hoffmann a écrit :
> Hi,
>
> > > default entry highlighted, a few seconds timeout with countdown.
> > > Both
> > > support editing boot entries.
>
> > Anecdata, but I definitely never (maybe once 15 years ago?) had
> > grub
> > install issue, but
Hi,
> > default entry highlighted, a few seconds timeout with countdown. Both
> > support editing boot entries.
> Anecdata, but I definitely never (maybe once 15 years ago?) had grub
> install issue, but plenty of dracut reconfiguration/upgrade failures
> over the years and the ability to
Hi,
On Mon, 2020-07-06 at 13:31 +0200, Gerd Hoffmann wrote:
> Hi,
>
> > > btw, sd-boot has a few tricks up its sleeve: if during boot you keep
> > > "w" pressed down it will automatically boot into windows, similar if
> > > you keep "l" pressed down it will automaticall boot into linux, "a"
>
Hi,
> My real problem with grub2 is not that it's complex, but the fact that
> it exposes its complexities to the user.
The config file syntax is a mess indeed. The fact that you need a
config generator tool in the first place speaks volumes ...
But note that grub config files don't have to
On Mon, Jul 06, 2020 at 08:08:48AM -0400, Stephen John Smoogen wrote:
> On Mon, 6 Jul 2020 at 07:38, Gerd Hoffmann wrote:
> >
> > Hi,
> >
> > > > btw, sd-boot has a few tricks up its sleeve: if during boot you keep
> > > > "w" pressed down it will automatically boot into windows, similar if
> >
On Sun, Jul 05, 2020 at 01:11:08AM -0700, John M. Harris Jr wrote:
> On Sunday, July 5, 2020 1:03:34 AM MST Luya Tshimbalanga wrote:
> > It would be great that the installer, Anaconda, enables sd-boot for
> > users running on UEFI system. The method was done before with both LILO
> > and Grub
1 - 100 of 318 matches
Mail list logo
