8:34 a.m.
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 common intel based x86 platform since atleast
2005.
Now in 2017 Intel's technical marketing engineer Brian Richardson
revealed in a presentation that the company will require UEFI Class 3
and above as in it would remove legacy BIOS support from its client and
datacenter platforms by 2020 and one might expect AMD to follow Intel in
this regard.
So Intel platforms produced this year presumably will be unable to run
32-bit operating systems, unable to use related software (at least
natively), and unable to use older hardware, such as RAID HBAs (and
therefore older hard drives that are connected to those HBAs), network
cards, and even graphics cards that lack UEFI-compatible vBIOS (launched
before 2012 – 2013) etc.
This post is just to gather feed back why Fedora should still continue
to support legacy BIOS boot as opposed to stop supporting it and
potentially drop grub2 and use sd-boot instead.
Share your thoughts and comments on how such move might affect you so
feedback can be collected for the future on why such a change might be
bad, how it might affect the distribution and scope of such change can
be determined for potential system wide proposal.
Regards
Jóhann B.
1.
https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration
8:56 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Tue, 2020-06-30 at 13:34 +0000, 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 supported boot
which
has been available on any common intel based x86 platform since
atleast
2005.
Now in 2017 Intel's technical marketing engineer Brian Richardson
revealed in a presentation that the company will require UEFI Class 3
and above as in it would remove legacy BIOS support from its client
and
datacenter platforms by 2020 and one might expect AMD to follow Intel
in
this regard.
So Intel platforms produced this year presumably will be unable
to run
32-bit operating systems, unable to use related software (at least
natively), and unable to use older hardware, such as RAID HBAs (and
therefore older hard drives that are connected to those HBAs),
network
cards, and even graphics cards that lack UEFI-compatible vBIOS
(launched
before 2012 – 2013) etc.
This post is just to gather feed back why Fedora should still
continue
to support legacy BIOS boot as opposed to stop supporting it and
potentially drop grub2 and use sd-boot instead.
Share your thoughts and comments on how such move might affect you so
feedback can be collected for the future on why such a change might
be
bad, how it might affect the distribution and scope of such change
can
be determined for potential system wide proposal.
I think there are many people still install OS in the legacy mode, but
I don't really have numbers. One thing we should definitely do if we
deprecate legacy BIOS is to properly warn users that still use this
configuration, develop tooling for them if possible for migration and
do not allow upgrades that will simply break their system.
Regards
Jóhann B.
1.
https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
- --
Igor Raits <ignatenkobrain(a)fedoraproject.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl77RJkACgkQEV1auJxc
Hh4+4A//QC8EWxecyBbSWu8uo2dSlFgqcCJ4zn6fkpgsU1PPhcezTPNKBFYdXUag
QMN5d6fawQE7LWRMY6y1Gq4oyANPQyJVshUeOcOBkyDpnZN13uCJSLDXpmHifpOJ
Up27VxVjYRb4kkPyHZqiwOkJP8U/4NfKeWkfew5CFGufKjX1dQVS8CeNWgpl1YsM
aTTLd5CvzDiMN4GBoaSRZmI9YDbrQbElqrk6BZD1wAIVnBbpvCq8wUJFRKIcx6O1
gMxpGV9txZ2HLKqmUYRtQUl5+CKTS45vJszGdlWPPqjiGpgGEDtsAqCPfWiyHUAc
0FZYdYHt3a1/jmNH0WRS2UOmeu5FP8VUOUvywVn3e4A5Dbi3Bdv2xuOGPD+xyti6
TAE3bWnYE1i7T1N6xoD90z2w+iQLFi12ftA7wkajNjf4e0MaawRBKuiG9VhL2xUA
vCDFaL/tqSQDPkWlrQblUjpJEOZOrtxQl48iMTNWmo92AtmuuARNwSsXNxEeP3GP
2DVM69j3CrGPpEBCIt4PdymHTQ2AHalUZwSAxEiT0NjwZ11uS0dAK7ipzwbUr+gt
Kwt202qSB5CZWSYe+VMDDxVyHJAIjpllzejaNBnVFrtpNmAXEjTJY+0sU/JW8o37
2HXm675cbN+X8AvNXMypoVJFcGRvqvaneKn4ywqhVhrRRzc5B38=
=xrlO
-----END PGP SIGNATURE-----
9:18 a.m.
On 30/06/2020 14:56, Igor Raits wrote:
I think there are many people still install OS in the legacy mode,
but
I don't really have numbers. One thing we should definitely do if we
deprecate legacy BIOS is to properly warn users that still use this
configuration, develop tooling for them if possible for migration and
do not allow upgrades that will simply break their system.
Certainly until very recently I have tended to do legacy BIOS installs
even on new machines - it's only really in the last few months that I've
started using UEFI by default instead.
I assume that we're only talking about new installs here anyway. I'm
pretty sure switching an existing install would be something for
advanced users only and might not really be possible in many cases
due to the need to fine space for an EFI system partition.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
10:07 a.m.
On 30.6.2020 14:18, Tom Hughes via devel wrote:
On 30/06/2020 14:56, Igor Raits wrote:
> I think there are many people still install OS in the legacy mode, but
> I don't really have numbers. One thing we should definitely do if we
> deprecate legacy BIOS is to properly warn users that still use this
> configuration, develop tooling for them if possible for migration and
> do not allow upgrades that will simply break their system.
Certainly until very recently I have tended to do legacy BIOS installs
even on new machines - it's only really in the last few months that I've
started using UEFI by default instead.
Well I would urge everyone to switch that know and can switch since
fwupd can only use the UEFI runtime services to schedule system firmware
update when running in UEFI mode.
In legacy BIOS mode it can only do USB type updates of peripherals.
I assume that we're only talking about new installs here anyway.
Right
I'm
pretty sure switching an existing install would be something for
advanced users only and might not really be possible in many cases
due to the need to fine space for an EFI system partition.
Yeps
jBG
10:22 a.m.
On 6/30/20 8:07 AM, Jóhann B. Guðmundsson wrote:
>> I think there are many people still install OS in the legacy
mode, but
>> I don't really have numbers.
I've just started working with Fedora 32 ~ a week ago. Looking at it as a migration
option, for imo a lot of _good_ reasons, from current deployed OS/distro for lots of
boxes.
one end-user data point for consideration:
currently, out of ~1K linux boxes in my ecosystem -- a mix of desktop, developer, int
& ext production & devel servers -- ~40% are still BIOS only, with no EFI support;
others have EFI support in BIOS, but are currently installed in legacy mode.
all are running distro up-to-date kernels, with a majority running Kernel:Stable. desktop
ENVs are up to date with latest KDE, GNOME & XFCE.
those 'legacy' boxes are perfectly serviceable/functional, and will remain in
service, regularly maintained, for possibly years to come.
mv'ing Fedora to EFI-only anytime soon takes it out of consideration, here anyway.
perhaps I'm missing the details, or point, of this.
10:03 a.m.
On 30.6.2020 13:56, Igor Raits wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
On Tue, 2020-06-30 at 13:34 +0000, 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 supported boot
> which
> has been available on any common intel based x86 platform since
> atleast
> 2005.
>
> Now in 2017 Intel's technical marketing engineer Brian Richardson
> revealed in a presentation that the company will require UEFI Class 3
> and above as in it would remove legacy BIOS support from its client
> and
> datacenter platforms by 2020 and one might expect AMD to follow Intel
> in
> this regard.
>
> So Intel platforms produced this year presumably will be unable
> to run
> 32-bit operating systems, unable to use related software (at least
> natively), and unable to use older hardware, such as RAID HBAs (and
> therefore older hard drives that are connected to those HBAs),
> network
> cards, and even graphics cards that lack UEFI-compatible vBIOS
> (launched
> before 2012 – 2013) etc.
>
> This post is just to gather feed back why Fedora should still
> continue
> to support legacy BIOS boot as opposed to stop supporting it and
> potentially drop grub2 and use sd-boot instead.
>
> Share your thoughts and comments on how such move might affect you so
> feedback can be collected for the future on why such a change might
> be
> bad, how it might affect the distribution and scope of such change
> can
> be determined for potential system wide proposal.
I think there are many people still install OS in the legacy mode, but
I don't really have numbers. One thing we should definitely do if we
deprecate legacy BIOS is to properly warn users that still use this
configuration, develop tooling for them if possible for migration and
do not allow upgrades that will simply break their system.
The use of legacy or uefi are changes that users have to manually change
themselves in their bios from manufactures default settings. There is no
tool that can do that for them or migrate those settings however users
should be able to change this for hardware around 2010.
The Installer would have to try to detect and make a choise sd-boot ( If
settings equall UEFI ) or grub2 ( If setting not equals UEFI ) depending
on it's results.
As an example here's the BIOS/UEFI history for Apple hardware.
2012 and older models only support legacy BIOS Mode
2013-2014 models support both EFI and BIOS with the default setting
being set on BIOS
2015 and later models only support EFI
Different manufacturers have different timelines and different default
settings but I think it's safe to presume from this year onwards they
will all drop the legacy support and default to UEFI.
JBG
12:47 p.m.
Jóhann B. Guðmundsson <johannbg(a)gmail.com> writes:
On 30.6.2020 13:56, Igor Raits wrote:
> On Tue, 2020-06-30 at 13:34 +0000, 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
>> supported boot which has been available on any common intel based
>> x86 platform since atleast 2005.
>>
>> Now in 2017 Intel's technical marketing engineer Brian Richardson
>> revealed in a presentation that the company will require UEFI Class
>> 3 and above as in it would remove legacy BIOS support from its
>> client and datacenter platforms by 2020 and one might expect AMD to
>> follow Intel in this regard.
>>
>> So Intel platforms produced this year presumably will be unable to
>> run 32-bit operating systems, unable to use related software (at
>> least natively), and unable to use older hardware, such as RAID HBAs
>> (and therefore older hard drives that are connected to those HBAs),
>> network cards, and even graphics cards that lack UEFI-compatible
>> vBIOS (launched before 2012 – 2013) etc.
>>
>> This post is just to gather feed back why Fedora should still
>> continue to support legacy BIOS boot as opposed to stop supporting
>> it and potentially drop grub2 and use sd-boot instead.
>>
>> Share your thoughts and comments on how such move might affect you
>> so feedback can be collected for the future on why such a change
>> might be bad, how it might affect the distribution and scope of such
>> change can be determined for potential system wide proposal.
>
> I think there are many people still install OS in the legacy mode,
> but I don't really have numbers. One thing we should definitely do if
> we deprecate legacy BIOS is to properly warn users that still use
> this configuration, develop tooling for them if possible for
> migration and do not allow upgrades that will simply break their
> system.
The use of legacy or uefi are changes that users have to manually
change themselves in their bios from manufactures default
settings. There is no tool that can do that for them or migrate those
settings however users should be able to change this for hardware
around 2010.
The Installer would have to try to detect and make a choise sd-boot (
If settings equall UEFI ) or grub2 ( If setting not equals UEFI )
depending on it's results.
As an example here's the BIOS/UEFI history for Apple hardware.
2012 and older models only support legacy BIOS Mode
2013-2014 models support both EFI and BIOS with the default setting
being set on BIOS
2015 and later models only support EFI
Different manufacturers have different timelines and different default
settings but I think it's safe to presume from this year onwards they
will all drop the legacy support and default to UEFI.
I don't think it contradicts your point that "this stuff is really
complicated", but my desktop is a 2009/2010 MacPro 4,1 running Fedora
booted using EFI. (I didn't ask it one way or the other - this is how
anaconda installed it for me.)
Thanks,
--Robbie
1:03 p.m.
On 30.6.2020 17:47, Robbie Harwood wrote:
Jóhann B. Guðmundsson <johannbg(a)gmail.com> writes:
> On 30.6.2020 13:56, Igor Raits wrote:
>> On Tue, 2020-06-30 at 13:34 +0000, 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
>>> supported boot which has been available on any common intel based
>>> x86 platform since atleast 2005.
>>>
>>> Now in 2017 Intel's technical marketing engineer Brian Richardson
>>> revealed in a presentation that the company will require UEFI Class
>>> 3 and above as in it would remove legacy BIOS support from its
>>> client and datacenter platforms by 2020 and one might expect AMD to
>>> follow Intel in this regard.
>>>
>>> So Intel platforms produced this year presumably will be unable to
>>> run 32-bit operating systems, unable to use related software (at
>>> least natively), and unable to use older hardware, such as RAID HBAs
>>> (and therefore older hard drives that are connected to those HBAs),
>>> network cards, and even graphics cards that lack UEFI-compatible
>>> vBIOS (launched before 2012 – 2013) etc.
>>>
>>> This post is just to gather feed back why Fedora should still
>>> continue to support legacy BIOS boot as opposed to stop supporting
>>> it and potentially drop grub2 and use sd-boot instead.
>>>
>>> Share your thoughts and comments on how such move might affect you
>>> so feedback can be collected for the future on why such a change
>>> might be bad, how it might affect the distribution and scope of such
>>> change can be determined for potential system wide proposal.
>> I think there are many people still install OS in the legacy mode,
>> but I don't really have numbers. One thing we should definitely do if
>> we deprecate legacy BIOS is to properly warn users that still use
>> this configuration, develop tooling for them if possible for
>> migration and do not allow upgrades that will simply break their
>> system.
> The use of legacy or uefi are changes that users have to manually
> change themselves in their bios from manufactures default
> settings. There is no tool that can do that for them or migrate those
> settings however users should be able to change this for hardware
> around 2010.
>
> The Installer would have to try to detect and make a choise sd-boot (
> If settings equall UEFI ) or grub2 ( If setting not equals UEFI )
> depending on it's results.
>
> As an example here's the BIOS/UEFI history for Apple hardware.
>
> 2012 and older models only support legacy BIOS Mode
>
> 2013-2014 models support both EFI and BIOS with the default setting
> being set on BIOS
>
> 2015 and later models only support EFI
>
> Different manufacturers have different timelines and different default
> settings but I think it's safe to presume from this year onwards they
> will all drop the legacy support and default to UEFI.
I don't think it contradicts your point that "this stuff is really
complicated", but my desktop is a 2009/2010 MacPro 4,1 running Fedora
booted using EFI. (I didn't ask it one way or the other - this is how
anaconda installed it for me.)
I was bit surprised by this given that I got that EFI Apple integration
timeframe from the OS-X forum but further digging through Apple
documents has revealed that UEFI has been supported since 2006 on Mac
computers with an Intel-based CPU [1]. So Anaconda did the right thing ;)
JBG
1. https://support.apple.com/en-is/guide/security/seced055bcf6/web
12:17 p.m.
The use of legacy or uefi are changes that users have to manually
change
themselves in their bios from manufactures default settings. There is no
tool that can do that for them or migrate those settings however users
should be able to change this for hardware around 2010.
The Installer would have to try to detect and make a choise sd-boot ( If
settings equall UEFI ) or grub2 ( If setting not equals UEFI ) depending
on it's results.
grub2 supports UEFI, doesn't have to be sd-boot
As an example here's the BIOS/UEFI history for Apple hardware.
2012 and older models only support legacy BIOS Mode
2013-2014 models support both EFI and BIOS with the default setting
being set on BIOS
2015 and later models only support EFI
Different manufacturers have different timelines and different default
settings but I think it's safe to presume from this year onwards they
will all drop the legacy support and default to UEFI.
Microsoft has been actively moving requirements to UEFI for some time
to in both server and workstation side of things as well as other
security improvements like the requirements for TPM2
1:26 p.m.
On 1.7.2020 17:17, Peter Robinson wrote:
> The use of legacy or uefi are changes that users have to manually
change
> themselves in their bios from manufactures default settings. There is no
> tool that can do that for them or migrate those settings however users
> should be able to change this for hardware around 2010.
>
> The Installer would have to try to detect and make a choise sd-boot ( If
> settings equall UEFI ) or grub2 ( If setting not equals UEFI ) depending
> on it's results.
grub2 supports UEFI, doesn't have to be sd-boot
Javier already has provide the best path forward for now and that is for Anaconda
to provide an sd-boot option in same/similar manner as extlinux exist today so people will
have the option to chose to use sd-boot instead of GRUB.
Those who want a simple modern bootloader will then have the ability to use it while those
need or prefer a boot manager OS and all it bells and whistles it brings along with it can
continue to use that.
After what one or two releases of Fedora the idea of making sd-boot the default for EFI
installs can be visited and or WG decide that for themselves.
JBG
12:09 a.m.
On Wednesday, July 1, 2020 11:26:48 AM MST Jóhann B. Guðmundsson wrote:
On 1.7.2020 17:17, Peter Robinson wrote:
>> The use of legacy or uefi are changes that users have to manually change
>> themselves in their bios from manufactures default settings. There is no
>> tool that can do that for them or migrate those settings however users
>> should be able to change this for hardware around 2010.
>>
>> The Installer would have to try to detect and make a choise sd-boot ( If
>> settings equall UEFI ) or grub2 ( If setting not equals UEFI ) depending
>> on it's results.
>
> grub2 supports UEFI, doesn't have to be sd-boot
Javier already has provide the best path forward for now and that is for
Anaconda to provide an sd-boot option in same/similar manner as extlinux
exist today so people will have the option to chose to use sd-boot instead
of GRUB.
Those who want a simple modern bootloader will then have the ability to use
it while those need or prefer a boot manager OS and all it bells and
whistles it brings along with it can continue to use that.
After what one or two releases of Fedora the idea of making sd-boot the
default for EFI installs can be visited and or WG decide that for
themselves.
GRUB2 is not a "boot manager OS", it's a fairly simple, but modular, single
threaded boot management application.
GRUB2 supports UEFI well, probably better than systemd-bloat. At the same
time, it's much more flexible in other aspects, providing users with the
ability to boot their system in a number of situations that systemd-bloat
doesn't support, as well as providing a recovery console in the event that
there are issues loading the kernel and initramfs. GRUB2 also supports Secure
Boot. Does systemd-bloat?
--
John M. Harris, Jr.
10:14 a.m.
On Mi, 01.07.20 22:09, John M. Harris Jr (johnmh(a)splentity.com) wrote:
GRUB2 supports UEFI well, probably better than systemd-bloat. At the
same
time, it's much more flexible in other aspects, providing users with the
ability to boot their system in a number of situations that systemd-bloat
doesn't support, as well as providing a recovery console in the event that
there are issues loading the kernel and initramfs. GRUB2 also supports Secure
Boot. Does systemd-bloat?
Man, grow up maybe? "systemd-bloat"?
Of course sd-boot supports Secure Boot.
You are just spreading FUD, and throwing the word "bloat" around on
anything you don't personally love. On most of the recent threads on
this ML you have been everything, but never constructive. Stop being
just a spreader of negative energy, it's not a good look.
Lennart
--
Lennart Poettering, Berlin
12:34 p.m.
Igor Raits <ignatenkobrain(a)fedoraproject.org> writes:
On Tue, 2020-06-30 at 13:34 +0000, 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
> supported boot which has been available on any common intel based x86
> platform since atleast 2005.
>
> Now in 2017 Intel's technical marketing engineer Brian Richardson
> revealed in a presentation that the company will require UEFI Class 3
> and above as in it would remove legacy BIOS support from its client
> and datacenter platforms by 2020 and one might expect AMD to follow
> Intel in this regard.
>
> So Intel platforms produced this year presumably will be unable
> to run 32-bit operating systems, unable to use related software (at
> least natively), and unable to use older hardware, such as RAID HBAs
> (and therefore older hard drives that are connected to those HBAs),
> network cards, and even graphics cards that lack UEFI-compatible
> vBIOS (launched before 2012 – 2013) etc.
>
> This post is just to gather feed back why Fedora should still
> continue to support legacy BIOS boot as opposed to stop supporting it
> and potentially drop grub2 and use sd-boot instead.
>
> Share your thoughts and comments on how such move might affect you so
> feedback can be collected for the future on why such a change might
> be bad, how it might affect the distribution and scope of such change
> can be determined for potential system wide proposal.
I think there are many people still install OS in the legacy mode, but
I don't really have numbers. One thing we should definitely do if we
deprecate legacy BIOS is to properly warn users that still use this
configuration, develop tooling for them if possible for migration and
do not allow upgrades that will simply break their system.
I think this is the only path forward that can actually work. Without
tooling, the only real way to "migrate" from legacy to UEFI is to
reinstall the operating system - much love to anaconda, but that's not
reasonable as a migration path.
Consider the partitioning. A fairly reasonable legacy setup looks like:
/dev/sda
\-> /boot
\-> dm_crypt
\-> LVM
\-> / (FS root)
\-> other partitions if you like to live dangerously
UEFI needs different partitions at the top level, with different size
requirements. So, since we've partitioned the entire disk, that
dm_crypt area needs to shrink... which means the LVM needs to
shrink... which means we need to shrink the filesystems in it. I'm sure
there are people who feel comfortable enough with parted and whatnot to
accomplish this, but I sure don't.[1]
So I like UEFI, but the risk of rendering my systems unbootable by doing
this by hand is too high.
Thanks,
--Robbie
1: The fact that no one agrees on the size of anything doesn't help,
either. 10^2 vs. 2^10, bits vs. bytes, sector and block
sizing... this is begging for a nice UI.
3:57 p.m.
On Tue, Jun 30, 2020 at 01:34:42PM -0400, Robbie Harwood wrote:
Igor Raits <ignatenkobrain(a)fedoraproject.org> writes:
> On Tue, 2020-06-30 at 13:34 +0000, Jóhann B. Guðmundsson wrote:
>
[snip]
> I think there are many people still install OS in the legacy
mode, but
> I don't really have numbers. One thing we should definitely do if we
> deprecate legacy BIOS is to properly warn users that still use this
> configuration, develop tooling for them if possible for migration and
> do not allow upgrades that will simply break their system.
I think this is the only path forward that can actually work. Without
tooling, the only real way to "migrate" from legacy to UEFI is to
reinstall the operating system - much love to anaconda, but that's not
reasonable as a migration path.
Consider the partitioning. A fairly reasonable legacy setup looks like:
/dev/sda
\-> /boot
\-> dm_crypt
\-> LVM
\-> / (FS root)
\-> other partitions if you like to live dangerously
UEFI needs different partitions at the top level, with different size
requirements. So, since we've partitioned the entire disk, that
dm_crypt area needs to shrink... which means the LVM needs to
shrink... which means we need to shrink the filesystems in it. I'm sure
there are people who feel comfortable enough with parted and whatnot to
accomplish this, but I sure don't.[1]
I guess I'll throw my opinion into the ring as well.
BIOS systems are going to be with us for a very long time. Supporting a
single clean bootloader would be wonderful, but that's not the reality
of the systems that are out there, and will continue to be out there for
decades. grub2, for all of its flaws, covers a very wide range of use
cases.
I also don't recommend trying to 'migrate' a perfectly working system to
a new bootloader. It seems like a giant waste of effort for zero gain,
and a high potential for failure.
You can't use parted to change a msdos disk to GPT, you'll have to
re-partition it. And move the partitions around, as well as shift the
data around, add more partitions, etc. It *may* work, but why take the
chance?
If you care that much about your bootloader just backup your system and
reinstall.
Brian
--
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
9:55 a.m.
On Tue, Jun 30, 2020 at 12:35 PM Robbie Harwood <rharwood(a)redhat.com> wrote:
Igor Raits <ignatenkobrain(a)fedoraproject.org> writes:
I think this is the only path forward that can actually work. Without
tooling, the only real way to "migrate" from legacy to UEFI is to
reinstall the operating system - much love to anaconda, but that's not
reasonable as a migration path.
I converted my system from BIOS to UEFI and can confirm that it was a
nightmare. I found problems months later even after it "worked" that had to
be resolved. I don't recommend it.
Thanks,
Richard
9 a.m.
* 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 common intel based x86 platform
since atleast 2005.
Even for virtualization? Not sure if that can be done.
Thanks,
Florian
9:20 a.m.
On 30/06/2020 15:00, Florian Weimer wrote:
* 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 common intel based x86 platform
> since atleast 2005.
Even for virtualization? Not sure if that can be done.
Good point. Certainly libvirt still defaults to legacy BIOS and I don't
think UEFI is even possible without manually editing the XML definition
for the machine.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
9:25 a.m.
W dniu 30.06.2020 o 16:20, Tom Hughes via devel pisze:
On 30/06/2020 15:00, Florian Weimer wrote:
> * 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 common intel based
>> x86 platform since atleast 2005.
>
> Even for virtualization? Not sure if that can be done.
Good point. Certainly libvirt still defaults to legacy BIOS and I
don't think UEFI is even possible without manually editing the XML
definition for the machine.
New installs for x86-64 VM can be BIOS of UEFI for quite some years.
For both i440fx and q35 variants.
Migration from BIOS to UEFI would require edit of instance XML but
should not be needed as you would not throw away working computer just
because OS decided to not support it's method of booting.
9:55 a.m.
On Tue, Jun 30, 2020 at 04:25:58PM +0200, Marcin Juszkiewicz wrote:
W dniu 30.06.2020 o 16:20, Tom Hughes via devel pisze:
> On 30/06/2020 15:00, Florian Weimer wrote:
>> * 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 common intel based
>>> x86 platform since atleast 2005.
>>
>> Even for virtualization? Not sure if that can be done.
>
> Good point. Certainly libvirt still defaults to legacy BIOS and I
> don't think UEFI is even possible without manually editing the XML
> definition for the machine.
New installs for x86-64 VM can be BIOS of UEFI for quite some years.
For both i440fx and q35 variants.
Migration from BIOS to UEFI would require edit of instance XML but
should not be needed as you would not throw away working computer just
because OS decided to not support it's method of booting.
With modern Libvirt switching to EFI is alot easier than it was in the
past. You simply need to change <os> element in the XML to add the
attribute firmware="efi". No need to mess around with OVMF paths
like in the old days - thanks to metadata files defined by QEMU we
can auto-pick the right EFI firmware blob.
Still, as mentioned elsewhere in the thread there's downsides to
EFI, so I wouldn't encourage blindly changing existing guests to
use EFI. If they're happy as they currently are, then leave them
alone with SeaBIOS.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
9:55 a.m.
On 30/06/2020 15:25, Marcin Juszkiewicz wrote:
W dniu 30.06.2020 o 16:20, Tom Hughes via devel pisze:
> On 30/06/2020 15:00, Florian Weimer wrote:
>> * 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 common intel based
>>> x86 platform since atleast 2005.
>>
>> Even for virtualization? Not sure if that can be done.
>
> Good point. Certainly libvirt still defaults to legacy BIOS and I
> don't think UEFI is even possible without manually editing the XML
> definition for the machine.
New installs for x86-64 VM can be BIOS of UEFI for quite some years.
For both i440fx and q35 variants.
I literally did an F31 install to a new instance two days
ago and don't recall being offered any option.
Same for F32 actually - the install failed but I had got as
far as creating the machine without being asked.
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
5:57 a.m.
On Tue, Jun 30, 2020 at 04:25:58PM +0200, Marcin Juszkiewicz wrote:
W dniu 30.06.2020 o 16:20, Tom Hughes via devel pisze:
> On 30/06/2020 15:00, Florian Weimer wrote:
>> * 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 common intel based
>>> x86 platform since atleast 2005.
>>
>> Even for virtualization? Not sure if that can be done.
>
> Good point. Certainly libvirt still defaults to legacy BIOS and I
> don't think UEFI is even possible without manually editing the XML
> definition for the machine.
New installs for x86-64 VM can be BIOS of UEFI for quite some years.
For both i440fx and q35 variants.
Migration from BIOS to UEFI would require edit of instance XML but
should not be needed as you would not throw away working computer just
because OS decided to not support it's method of booting.
If you mean migration of existing guests, then you need to repartition
them and reinstall the bootloader. I doubt anyone has a practical
idea of how to do that either manually or automatically.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
8:32 a.m.
W dniu 01.07.2020 o 12:57, Richard W.M. Jones pisze:
If you mean migration of existing guests, then you need to
repartition
them and reinstall the bootloader. I doubt anyone has a practical
idea of how to do that either manually or automatically.
Add second drive with 32-64MB size. Create ESP partition there. Install
grub-efi. Power off, switch to UEFI mode, power on, boot to grub-efi.
Much easier than with real hardware machines where you indeed need to
play with partitions. On my laptop I have space available in /boot/
partition so could shrink it and create ESP from there. But already have
ESP so no need.
12:14 a.m.
On Wednesday, July 1, 2020 6:32:15 AM MST Marcin Juszkiewicz wrote:
W dniu 01.07.2020 o 12:57, Richard W.M. Jones pisze:
> If you mean migration of existing guests, then you need to repartition
> them and reinstall the bootloader. I doubt anyone has a practical
> idea of how to do that either manually or automatically.
Add second drive with 32-64MB size. Create ESP partition there. Install
grub-efi. Power off, switch to UEFI mode, power on, boot to grub-efi.
Much easier than with real hardware machines where you indeed need to
play with partitions. On my laptop I have space available in /boot/
partition so could shrink it and create ESP from there. But already have
ESP so no need.
It's not that simple, in many cases. For example, both the virtualization
setup I use at work, and my home virtualization setup, employs iSCSI so that I
can migrate VMs between my various virtualization hosts.
In order to create a new drive, I'd have to create a new LUN just for a
32-64MiB block device.. Not impossible by any means, but not as simple as the
above. This would be similarly "more complex" in OpenStack environments.
--
John M. Harris, Jr.
9:23 a.m.
On Tue, Jun 30, 2020 at 4:01 PM Florian Weimer <fweimer(a)redhat.com> wrote:
* 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 common intel based x86 platform
> since atleast 2005.
Even for virtualization? Not sure if that can be done.
It can, but not much :) I recently reverted the GNOME Boxes change
that installed guests with uefi. I wrote a [humorous] commit message
about it with a few details
https://gitlab.gnome.org/GNOME/gnome-boxes/-/commit/c486da262f6566326fbcb...
Long story short, Libvirt/qemu don't seem to be able to perform AND
revert to snapshots of UEFI guests.
Thanks,
Florian
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
10:19 a.m.
On Tue, Jun 30, 2020 at 04:23:59PM +0200, Felipe Borges wrote:
On Tue, Jun 30, 2020 at 4:01 PM Florian Weimer
<fweimer(a)redhat.com> wrote:
>
> * 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 common intel based x86 platform
> > since atleast 2005.
>
> Even for virtualization? Not sure if that can be done.
It can, but not much :) I recently reverted the GNOME Boxes change
that installed guests with uefi. I wrote a [humorous] commit message
about it with a few details
https://gitlab.gnome.org/GNOME/gnome-boxes/-/commit/c486da262f6566326fbcb...
Long story short, Libvirt/qemu don't seem to be able to perform AND
revert to snapshots of UEFI guests.
Yeah, that's a pretty frustrating bug that's been causing pain for countless
years. The main problem is at the QEMU level, because its "savevm" command
does not provide any way to mark certain block devices as skipped/ignored.
Conceptually, fixing that problem is easy, but it has come up against the
fact that "savevm" has a pile of other problems in QEMU. Any suggestion to
fix the easy problem has ended up blocked by requirement to fix the hard
problems. I think this is a mistake on QEMU's part - given that no one
has made any serious proposal to fix the hard problem in 10 years, it is
unreasonable for QEMU to block fixes for the easy problems.
Unfortunately getting someone motivated to fix any of this is hard as the
big mgmt tools like oVirt and OpenStack don't care about internal snapshots,
instead using the more general external snapshots.
It is all rather an unpleasant mess :-(
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
9:27 a.m.
On Tue, Jun 30, 2020 at 04:00:00PM +0200, Florian Weimer wrote:
* 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 common intel based x86 platform
> since atleast 2005.
Even for virtualization? Not sure if that can be done.
KVM virt on aarch64 and x86 can support EFI via AVMF / OVMF firmware
built from the edk2 project from a technical POV.
The first challenge will be that many mgmt tools still default to
using legacy BIOS when deploying guest OS. We've been trying to
make it easier for mgmt apps to "do the right thing" by having
libosinfo record metadata about whether each guest OS supports
legacy BIOS, EFI or both. ie we want the mgmt apps to just pick
EFI if they see the OS doesn't support legacy BIOS, instead of
requiring users to manually tell them to use EFI.
Historically we've tended to discourage use of EFI on virt because,
unless you wanted SecureBoot for your VMs, it hasn't offered much
in the way of compelling benefits to users. The EDK2 project code
is a much higher maint burden for virt than the seabios was, and
there's no sign that situation will improve.
So I can't say I'm thrilled about a future that depends on EFI for
virt, but I'm resigned to the fact this is the direction the world
is taking. So we're not likely to have any choice and will have to
work to mitigate any downsides it brings.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
9:32 a.m.
W dniu 30.06.2020 o 16:27, Daniel P. Berrangé pisze:
KVM virt on aarch64 and x86 can support EFI via AVMF / OVMF firmware
built from the edk2 project from a technical POV.
The first challenge will be that many mgmt tools still default to
using legacy BIOS when deploying guest OS. We've been trying to
make it easier for mgmt apps to "do the right thing" by having
libosinfo record metadata about whether each guest OS supports
legacy BIOS, EFI or both. ie we want the mgmt apps to just pick
EFI if they see the OS doesn't support legacy BIOS, instead of
requiring users to manually tell them to use EFI.
So I can't say I'm thrilled about a future that depends on
EFI for
virt, but I'm resigned to the fact this is the direction the world
is taking. So we're not likely to have any choice and will have to
work to mitigate any downsides it brings.
Can we also default to Q35 and forget that i440fx existed?
Do all the pain in one step.
9:40 a.m.
On Tue, Jun 30, 2020 at 04:32:44PM +0200, Marcin Juszkiewicz wrote:
W dniu 30.06.2020 o 16:27, Daniel P. Berrangé pisze:
> KVM virt on aarch64 and x86 can support EFI via AVMF / OVMF firmware
> built from the edk2 project from a technical POV.
>
> The first challenge will be that many mgmt tools still default to
> using legacy BIOS when deploying guest OS. We've been trying to
> make it easier for mgmt apps to "do the right thing" by having
> libosinfo record metadata about whether each guest OS supports
> legacy BIOS, EFI or both. ie we want the mgmt apps to just pick
> EFI if they see the OS doesn't support legacy BIOS, instead of
> requiring users to manually tell them to use EFI.
> So I can't say I'm thrilled about a future that depends on EFI for
> virt, but I'm resigned to the fact this is the direction the world
> is taking. So we're not likely to have any choice and will have to
> work to mitigate any downsides it brings.
Can we also default to Q35 and forget that i440fx existed?
Do all the pain in one step.
That's upto the various mgmt apps using libvirt to decide. Q35
is *NOT* a drop-in replacement for i440fx. IOW if libvirt flipped
the switch existing mgmt apps would certainly break. For example, you
can't hotplug with Q35, unless the mgmt app pre-populated a bunch of
pcie-root-port devices. If the mgmt app is using IDE (eg for CDROM)
it'll break because Q35 requires SATA. There's various other areas
of pain. So we must let the mgmt apps decide when they are ready
to switch to use Q35 instead of i440fx.
As an example, OpenStack has been trying to switch to Q35 for over
a year, and continues to hit things which are different or broken
in Q35, so has been forced to stick with i440fx still.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
12:42 p.m.
W dniu 30.06.2020 o 16:40, Daniel P. Berrangé pisze:
On Tue, Jun 30, 2020 at 04:32:44PM +0200, Marcin Juszkiewicz wrote:
> Can we also default to Q35 and forget that i440fx existed?
>
> Do all the pain in one step.
That's upto the various mgmt apps using libvirt to decide. Q35
is *NOT* a drop-in replacement for i440fx. IOW if libvirt flipped
the switch existing mgmt apps would certainly break. For example, you
can't hotplug with Q35, unless the mgmt app pre-populated a bunch of
pcie-root-port devices. If the mgmt app is using IDE (eg for CDROM)
it'll break because Q35 requires SATA. There's various other areas
of pain. So we must let the mgmt apps decide when they are ready
to switch to use Q35 instead of i440fx.
I am aware of those issues. AArch64 default mode is like Q35.
Wrote few words about that in past:
https://marcin.juszkiewicz.com.pl/2018/02/01/everyone-loves-90s-pc-hardware/
10:50 a.m.
On 30.6.2020 14:27, Daniel P. Berrangé wrote:
On Tue, Jun 30, 2020 at 04:00:00PM +0200, Florian Weimer wrote:
> * 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 common intel based x86 platform
>> since atleast 2005.
> Even for virtualization? Not sure if that can be done.
KVM virt on aarch64 and x86 can support EFI via AVMF / OVMF firmware
built from the edk2 project from a technical POV.
The first challenge will be that many mgmt tools still default to
using legacy BIOS when deploying guest OS. We've been trying to
make it easier for mgmt apps to "do the right thing" by having
libosinfo record metadata about whether each guest OS supports
legacy BIOS, EFI or both. ie we want the mgmt apps to just pick
EFI if they see the OS doesn't support legacy BIOS, instead of
requiring users to manually tell them to use EFI.
Historically we've tended to discourage use of EFI on virt because,
unless you wanted SecureBoot for your VMs, it hasn't offered much
in the way of compelling benefits to users. The EDK2 project code
is a much higher maint burden for virt than the seabios was, and
there's no sign that situation will improve.
So I can't say I'm thrilled about a future that depends on EFI for
virt, but I'm resigned to the fact this is the direction the world
is taking. So we're not likely to have any choice and will have to
work to mitigate any downsides it brings.
Right.
Preferably the installer should detect and setup the system either with
sd-boot ( if setting equals UEFI ) or grub ( if setting not equals UEFI
) and other tools do the same and all areas deal with any fallout that
is encountered ( bugs ) before a complete removal could be done so a
realistic timeframe for a complete removal of legacy support would be
F36+ I would say but we have to start prepare for the inevitable and
start sometime and now is as good time as any to start looking into this.
JBG
12:15 p.m.
Hi,
> So I can't say I'm thrilled about a future that depends
on EFI for
> virt, but I'm resigned to the fact this is the direction the world
> is taking. So we're not likely to have any choice and will have to
> work to mitigate any downsides it brings.
Right.
Preferably the installer should detect and setup the system either with
sd-boot ( if setting equals UEFI ) or grub ( if setting not equals UEFI )
I have my doubts that building on sd-boot and drop grub2 is going to fly.
One problem with sd-boot is that the kernels must stay on the ESP, which
can be a problem for dual-boot installs (where Fedora has to run with
the existing ESP and can't just create one which is big enouth).
Another problem is that grub2 covers more architectures than sd-boot.
What is the plan for armhfp, ppc64, s390x?
IMHO a better preparation for deprecating BIOS would be to make new
installs bootable with both BIOS and UEFI. Which isn't hard at least
for the "[x] use all space" case where Fedora can partition the disk as
it pleases: Use gpt. Create a bios boot partition, install grun-pc
there. Create a ESP partition, install grub-efi there. Create a
partition for the /boot filesystem. Have both grubs pick up BLS config
from /boot/loader.
take care,
Gerd
12:37 p.m.
On Tue, 2020-06-30 at 19:15 +0200, Gerd Hoffmann wrote:
Hi,
> > So I can't say I'm thrilled about a future that depends on EFI for
> > virt, but I'm resigned to the fact this is the direction the world
> > is taking. So we're not likely to have any choice and will have to
> > work to mitigate any downsides it brings.
>
> Right.
>
> Preferably the installer should detect and setup the system either with
> sd-boot ( if setting equals UEFI ) or grub ( if setting not equals UEFI )
Another problem is that grub2 covers more architectures than sd-boot.
What is the plan for armhfp, ppc64, s390x?
This part wouldn't really be a problem in the scheme Johann suggests
above, because 'sdboot' would just be another bootloader class in
anaconda in this case, along the several we have already.
IMHO a better preparation for deprecating BIOS would be to make new
installs bootable with both BIOS and UEFI. Which isn't hard at least
for the "[x] use all space" case where Fedora can partition the disk as
it pleases: Use gpt. Create a bios boot partition, install grun-pc
there. Create a ESP partition, install grub-efi there. Create a
partition for the /boot filesystem. Have both grubs pick up BLS config
from /boot/loader.
That would have to be implemented as another class too, probably. :)
https://github.com/rhinstaller/anaconda/tree/master/pyanaconda/modules/st...
is where all this is implemented at present (mostly, the classes there
do pull in various bits of config and info from other places). There's
already quite a mess there, anything we add without taking a way any
existing capabilities will make it a slightly bigger mess...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
12:45 p.m.
On 30.6.2020 17:15, Gerd Hoffmann wrote:
Hi,
>> So I can't say I'm thrilled about a future that depends on EFI for
>> virt, but I'm resigned to the fact this is the direction the world
>> is taking. So we're not likely to have any choice and will have to
>> work to mitigate any downsides it brings.
> Right.
>
> Preferably the installer should detect and setup the system either with
> sd-boot ( if setting equals UEFI ) or grub ( if setting not equals UEFI )
I have my doubts that building on sd-boot and drop grub2 is going to fly.
Grub 2 cant be dropped anytime soon.
One problem with sd-boot is that the kernels must stay on the ESP, which
can be a problem for dual-boot installs (where Fedora has to run with
the existing ESP and can't just create one which is big enouth).
Hmm I dont follow people usually use multiple ESP partition for multiple
os installs on the same hw so the size of one esp partion for one OS
should not affect the other and there should nothing be preventing that
from working except maybe some obscure hw bug from manufactures but I'm
not a dual boot person so I would have to test that for myself to figure
out any limitations it might have.
Another problem is that grub2 covers more architectures than sd-boot.
What is the plan for armhfp, ppc64, s390x?
The first step ( change proposal ) would simply be about replace grub2
with sd-boot for UEFI strictly on the x86 architecture and see what
issue are encountered, solve those then consider moving to different
architectures and further integration if relevant.
JBG
4:36 a.m.
On Di, 30.06.20 19:15, Gerd Hoffmann (kraxel(a)redhat.com) wrote:
Hi,
> > So I can't say I'm thrilled about a future that depends on EFI for
> > virt, but I'm resigned to the fact this is the direction the world
> > is taking. So we're not likely to have any choice and will have to
> > work to mitigate any downsides it brings.
>
> Right.
>
> Preferably the installer should detect and setup the system either with
> sd-boot ( if setting equals UEFI ) or grub ( if setting not equals UEFI )
I have my doubts that building on sd-boot and drop grub2 is going to fly.
One problem with sd-boot is that the kernels must stay on the ESP, which
can be a problem for dual-boot installs (where Fedora has to run with
the existing ESP and can't just create one which is big enouth).
Nah, that's not true. Hasn't been for quite a while.
sd-boot checks for kernels in the ESP first, and then on a second
partition we called XBOOTLDR, which also can contain kernels. XBOOTLDR
partition is simply a partition with type UUID
bc13c2ff-59e6-4262-a352-b275fd6f7172.
This means installers have two options:
1. Create a large ESP and just use that. Everything is nice and simple
2. If the ESP already exists and there's no interest in growing it,
just add in an XBOOTLDR partition and use that instead.
Another problem is that grub2 covers more architectures than
sd-boot.
What is the plan for armhfp, ppc64, s390x?
sd-boot is uefi only, but it should work fine with any arch that is
supported by uefi.
IMHO a better preparation for deprecating BIOS would be to make new
installs bootable with both BIOS and UEFI. Which isn't hard at least
for the "[x] use all space" case where Fedora can partition the disk as
it pleases: Use gpt. Create a bios boot partition, install grun-pc
there. Create a ESP partition, install grub-efi there. Create a
partition for the /boot filesystem. Have both grubs pick up BLS config
from /boot/loader.
My suggestion would be: don't standardize on boot loaders, standardize
on the boot loader spec. And I mean, the real boot loader spec, i.e
not this terrible template language that Fedora now supports in Grub,
which is just the same old grub complexity again. They stole the "Boot
Loader Spec" name and turned it into something that is not related at
all to the real thing.
Supporting the boot loader spec has various benefits, including that
systemd's "systemctl kexec" will just work and understand these tiems.
Lennart
--
Lennart Poettering, Berlin
5:45 a.m.
On 1.7.2020 09:36, Lennart Poettering wrote:
On Di, 30.06.20 19:15, Gerd Hoffmann (kraxel(a)redhat.com) wrote:
> Hi,
>
>>> So I can't say I'm thrilled about a future that depends on EFI for
>>> virt, but I'm resigned to the fact this is the direction the world
>>> is taking. So we're not likely to have any choice and will have to
>>> work to mitigate any downsides it brings.
>> Right.
>>
>> Preferably the installer should detect and setup the system either with
>> sd-boot ( if setting equals UEFI ) or grub ( if setting not equals UEFI )
> I have my doubts that building on sd-boot and drop grub2 is going to fly.
>
> One problem with sd-boot is that the kernels must stay on the ESP, which
> can be a problem for dual-boot installs (where Fedora has to run with
> the existing ESP and can't just create one which is big enouth).
Nah, that's not true. Hasn't been for quite a while.
sd-boot checks for kernels in the ESP first, and then on a second
partition we called XBOOTLDR, which also can contain kernels. XBOOTLDR
partition is simply a partition with type UUID
bc13c2ff-59e6-4262-a352-b275fd6f7172.
This means installers have two options:
1. Create a large ESP and just use that. Everything is nice and simple
2. If the ESP already exists and there's no interest in growing it,
just add in an XBOOTLDR partition and use that instead.
The latter (2) is presumably what manufactures would want OS and their
installers to default to.
As in don't destroy or resize ( which could risk destroying it ) the
existing ESP that comes from the factory and may contain manufacturers
specific tools instead keep it as it is and place only the boot manager
( sd-boot ) on the existing ESP while OS specific kernels ( and any
other stuff the OS might want to place on the ESP ) is placed on a
separate XBOOTLDR partition.
The above is probably also the best compatibility scenario for dual boot
or multi boot scenarios.
> Another problem is that grub2 covers more architectures than sd-boot.
> What is the plan for armhfp, ppc64, s390x?
sd-boot is uefi only, but it should work fine with any arch that is
supported by uefi.
> IMHO a better preparation for deprecating BIOS would be to make new
> installs bootable with both BIOS and UEFI. Which isn't hard at least
> for the "[x] use all space" case where Fedora can partition the disk as
> it pleases: Use gpt. Create a bios boot partition, install grun-pc
> there. Create a ESP partition, install grub-efi there. Create a
> partition for the /boot filesystem. Have both grubs pick up BLS config
> from /boot/loader.
My suggestion would be: don't standardize on boot loaders, standardize
on the boot loader spec. And I mean, the real boot loader spec, i.e
not this terrible template language that Fedora now supports in Grub,
which is just the same old grub complexity again. They stole the "Boot
Loader Spec" name and turned it into something that is not related at
all to the real thing.
Supporting the boot loader spec has various benefits, including that
systemd's "systemctl kexec" will just work and understand these tiems.
Yeah I was going to look at that as well ( how far off Fedora is from
the boot loader specification and where it's going off the rails ) while
I'm looking at this.
JBG
6:14 a.m.
On Wed, Jul 1, 2020 at 11:37 AM Lennart Poettering <mzerqung(a)0pointer.de> wrote:
[snip]
My suggestion would be: don't standardize on boot loaders, standardize
on the boot loader spec. And I mean, the real boot loader spec, i.e
Agreed. In part that's already the case for Fedora, since now besides
GRUB the zipl (s390x) and Petitboot (ppc64le OPAL) bootloaders are
also using BLS snippets to populate their boot menu.
I don't see why one bootloader has to be dropped in favour of the
other, and not just allow users to choose what better fits their
needs.
Just like Anaconda currently provides an extlinux option to use as the
bootloader instead of GRUB for legacy BIOS installs, a sd-boot option
could be added to choose using this bootloader for EFI installs.
That way users who want a simple bootloader can use sd-boot and those
needing features like network boot, LUKS support, etc can choose to
use GRUB instead.
not this terrible template language that Fedora now supports in
Grub,
which is just the same old grub complexity again. They stole the "Boot
Yes, not storing the kernel command line options in the BLS snippets
and using a GRUB variable was indeed a mistake that caused more harm
than good.
That has been fixed for F33, but there are other reasons why the GRUB
implementation needed variables. For instance to support
authentication and authorization of boot entries:
https://www.gnu.org/software/grub/manual/grub/html_node/Authentication-an...
But we can look at how the spec could be extended to cover that case
and stop using the templating for GRUB altogether to align with the
spec.
Loader Spec" name and turned it into something that is not
related at
all to the real thing.
I'm not sure if this is completely fair, it's true that GRUB's blscfg
module diverged from the spec by adding support for variables but it
can also parse BLS snippets that follow the spec verbatim.
For example Fedora CoreOS uses it and the BLS snippets created by
OSTree are completely aligned with the spec as far as I can tell.
And since F33 I think that even the BLS snippets created for GRUB
could be parsed by sd-boot (or any other bootloader following the spec
like LinuxBoot)
since the options field doesn't have a variable anymore.
Best regards,
Javier
9:36 a.m.
On Mi, 01.07.20 13:14, Javier Martinez Canillas (javier(a)dowhile0.org) wrote:
I'm not sure if this is completely fair, it's true that
GRUB's blscfg
module diverged from the spec by adding support for variables but it
can also parse BLS snippets that follow the spec verbatim.
You missed the point of the whole spec:
the spec was that every party which interfaces with boot loaders knows
where to find and how to deal with boot loader entries, and to make
them as simple that every party can easily parse them and make sense
of them, and share them. This means that many parties can *read* them
without trouble and *drop-in* them without trouble either.
By turning them into a programming language you broke that contract,
because suddenly your files cannot be read without any embedded
tremplating language interpretor. You own your files, but everyone
else cannot make sense of it.
Note that the spec has extension points (i.e. it's permissible to add
new fields without this breaking the spec), but turning it into a
programming lnaguage is waaaay outside of it...
Lennart
--
Lennart Poettering, Berlin
10:19 a.m.
On Wed, Jul 1, 2020 at 4:36 PM Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Mi, 01.07.20 13:14, Javier Martinez Canillas (javier(a)dowhile0.org) wrote:
> I'm not sure if this is completely fair, it's true that GRUB's blscfg
> module diverged from the spec by adding support for variables but it
> can also parse BLS snippets that follow the spec verbatim.
You missed the point of the whole spec:
the spec was that every party which interfaces with boot loaders knows
where to find and how to deal with boot loader entries, and to make
them as simple that every party can easily parse them and make sense
of them, and share them. This means that many parties can *read* them
without trouble and *drop-in* them without trouble either.
By turning them into a programming language you broke that contract,
because suddenly your files cannot be read without any embedded
tremplating language interpretor. You own your files, but everyone
else cannot make sense of it.
I've already acknowledged that using variables in the options field
was a mistake, since that is a known field according to the spec and
so it broke the contract. And also mentioned that this was already
fixed in F33, other boot loaders should now be able to parse the BLS
snippets (assuming that ignore other fields only relevant to GRUB for
boot entries auth).
Note that the spec has extension points (i.e. it's permissible to
add
new fields without this breaking the spec), but turning it into a
programming lnaguage is waaaay outside of it...
I wouldn't consider adding variable expansion support to turn them
into a programming language. But yes, you are right that we diverged
from the spec and that caused issues to other bootloaders (i.e: I had
this same conversation with the LinuxBoot folks).
But rather than keep pointing out what we got wrong, I would prefer to
figure out how to make the GRUB implementation to align with the spec
while still supporting all the features that are available in a
non-BLS configuration. This could also allow to have a single
kernel-install plugin instead of having specific plugins for
GRUB/Petitboot and zipl.
Best regards,
Javier
11:27 a.m.
On Mi, 01.07.20 17:19, Javier Martinez Canillas (javier(a)dowhile0.org) wrote:
> Note that the spec has extension points (i.e. it's
permissible to add
> new fields without this breaking the spec), but turning it into a
> programming lnaguage is waaaay outside of it...
>
I wouldn't consider adding variable expansion support to turn them
into a programming language. But yes, you are right that we diverged
from the spec and that caused issues to other bootloaders (i.e: I had
this same conversation with the LinuxBoot folks).
But rather than keep pointing out what we got wrong, I would prefer to
figure out how to make the GRUB implementation to align with the spec
while still supporting all the features that are available in a
non-BLS configuration. This could also allow to have a single
kernel-install plugin instead of having specific plugins for
GRUB/Petitboot and zipl.
Please submit additions to the spec as PRs to systemd github. We added
a number of new keys in the past that sd-boot itself doesn't make use
of (devicetree and such), and we'd be delighted to add more if they
make sense and that helps.
i.e. PRs against this file:
https://github.com/systemd/systemd/blob/master/docs/BOOT_LOADER_SPECIFICA...
Thank you,
Lennart
--
Lennart Poettering, Berlin
1:34 p.m.
On Sat, Jul 4, 2020 at 6:27 PM Lennart Poettering <mzerqung(a)0pointer.de> wrote:
[snip]
Please submit additions to the spec as PRs to systemd github. We added
a number of new keys in the past that sd-boot itself doesn't make use
of (devicetree and such), and we'd be delighted to add more if they
make sense and that helps.
Thanks. I'll discuss this with the rest of the bootloader folks and
think how the spec could be extended to cover the remaining cases
where variable expansion is still used for GRUB. The new keys could be
generic and even benefit other bootloaders if they implement these
features at some point (e.g: boot entries protection).
Best regards,
Javier
3:37 a.m.
On 5.7.2020 18:34, Javier Martinez Canillas wrote:
On Sat, Jul 4, 2020 at 6:27 PM Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
[snip]
> Please submit additions to the spec as PRs to systemd github. We added
> a number of new keys in the past that sd-boot itself doesn't make use
> of (devicetree and such), and we'd be delighted to add more if they
> make sense and that helps.
>
Thanks. I'll discuss this with the rest of the bootloader folks and
think how the spec could be extended to cover the remaining cases
where variable expansion is still used for GRUB. The new keys could be
generic and even benefit other bootloaders if they implement these
features at some point (e.g: boot entries protection).
Since you are in contact with and thus presumably you are one of the
"bootloader folks" could you clarify who those individual are and what
role they play and which bootloaders they represent in the distribution
and on which arch etc. and where they can be contacted ( mailinglist )
since I don't find any documentation about any bootloader WG existing
within Fedora yet such a team seems to exist since it's being mentioned.
JBG
1:39 p.m.
On Mon, Jul 6, 2020 at 10:39 AM Jóhann B. Guðmundsson
<johannbg(a)gmail.com> wrote:
On 5.7.2020 18:34, Javier Martinez Canillas wrote:
> On Sat, Jul 4, 2020 at 6:27 PM Lennart Poettering <mzerqung(a)0pointer.de>
wrote:
>
> [snip]
>
>> Please submit additions to the spec as PRs to systemd github. We added
>> a number of new keys in the past that sd-boot itself doesn't make use
>> of (devicetree and such), and we'd be delighted to add more if they
>> make sense and that helps.
>>
> Thanks. I'll discuss this with the rest of the bootloader folks and
> think how the spec could be extended to cover the remaining cases
> where variable expansion is still used for GRUB. The new keys could be
> generic and even benefit other bootloaders if they implement these
> features at some point (e.g: boot entries protection).
Since you are in contact with and thus presumably you are one of the
"bootloader folks" could you clarify who those individual are and what
role they play and which bootloaders they represent in the distribution
and on which arch etc. and where they can be contacted ( mailinglist )
since I don't find any documentation about any bootloader WG existing
within Fedora yet such a team seems to exist since it's being mentioned.
Sure, I meant the members of the Red Hat bootloader team (Peter Jones,
Jan Hlavac and me) and people who are not part of the bootloader team
but work very closely with us and help to improve the boot stack in
general. Mostly Hans de Goede and Christian Kellner but also others.
Peter maintains all the projects in https://github.com/orgs/rhboot and
their respective packages in Fedora. And I help him with that work. We
are also involved in the upstream communities of the bootloaders that
are used in the architectures supported by Fedora. These are:
- GRUB (x86_64 legacy BIOS and EFI, aarch64 EFI and ppc64le OF)
- Petitboot (ppc64le OPAL)
- zipl (s390x)
- u-boot (armv7).
But for the last two most of the work and the package maintenance is
done by Dan Horák (s390utils-base) and Peter Robinson
(uboot-images-armv7).
All these people can be contacted in the Fedora devel mailing list. I
hope this answers your question, please let me know if you need more
details.
Best regards,
Javier
2:30 p.m.
On 6.7.2020 18:39, Javier Martinez Canillas wrote:
On Mon, Jul 6, 2020 at 10:39 AM Jóhann B. Guðmundsson
<johannbg(a)gmail.com> wrote:
> On 5.7.2020 18:34, Javier Martinez Canillas wrote:
>> On Sat, Jul 4, 2020 at 6:27 PM Lennart Poettering <mzerqung(a)0pointer.de>
wrote:
>>
>> [snip]
>>
>>> Please submit additions to the spec as PRs to systemd github. We added
>>> a number of new keys in the past that sd-boot itself doesn't make use
>>> of (devicetree and such), and we'd be delighted to add more if they
>>> make sense and that helps.
>>>
>> Thanks. I'll discuss this with the rest of the bootloader folks and
>> think how the spec could be extended to cover the remaining cases
>> where variable expansion is still used for GRUB. The new keys could be
>> generic and even benefit other bootloaders if they implement these
>> features at some point (e.g: boot entries protection).
> Since you are in contact with and thus presumably you are one of the
> "bootloader folks" could you clarify who those individual are and what
> role they play and which bootloaders they represent in the distribution
> and on which arch etc. and where they can be contacted ( mailinglist )
> since I don't find any documentation about any bootloader WG existing
> within Fedora yet such a team seems to exist since it's being mentioned.
>
Sure, I meant the members of the Red Hat bootloader team (Peter Jones,
Jan Hlavac and me) and people who are not part of the bootloader team
but work very closely with us and help to improve the boot stack in
general. Mostly Hans de Goede and Christian Kellner but also others.
Peter maintains all the projects in https://github.com/orgs/rhboot and
their respective packages in Fedora. And I help him with that work. We
are also involved in the upstream communities of the bootloaders that
are used in the architectures supported by Fedora. These are:
- GRUB (x86_64 legacy BIOS and EFI, aarch64 EFI and ppc64le OF)
- Petitboot (ppc64le OPAL)
- zipl (s390x)
- u-boot (armv7).
But for the last two most of the work and the package maintenance is
done by Dan Horák (s390utils-base) and Peter Robinson
(uboot-images-armv7).
All these people can be contacted in the Fedora devel mailing list. I
hope this answers your question, please let me know if you need more
details.
This was precisely the info I was looking for.
Thanks
JBG
11:31 a.m.
> One problem with sd-boot is that the kernels must stay on the
ESP, which
> can be a problem for dual-boot installs (where Fedora has to run with
> the existing ESP and can't just create one which is big enouth).
Nah, that's not true. Hasn't been for quite a while.
sd-boot checks for kernels in the ESP first, and then on a second
partition we called XBOOTLDR, which also can contain kernels. XBOOTLDR
partition is simply a partition with type UUID
bc13c2ff-59e6-4262-a352-b275fd6f7172.
Ah, this is news to me. XBOOTLDR must be formated with a filesystem the
uefi firmware can read (i.e. vfat in practice) I assume?
> Another problem is that grub2 covers more architectures than
sd-boot.
> What is the plan for armhfp, ppc64, s390x?
sd-boot is uefi only, but it should work fine with any arch that is
supported by uefi.
Seems it isn't built for armhfp in Fedora (/usr/lib/systemd/boot/efi
doesn't exist ...).
> IMHO a better preparation for deprecating BIOS would be to make
new
> installs bootable with both BIOS and UEFI. Which isn't hard at least
> for the "[x] use all space" case where Fedora can partition the disk as
> it pleases: Use gpt. Create a bios boot partition, install grun-pc
> there. Create a ESP partition, install grub-efi there. Create a
> partition for the /boot filesystem. Have both grubs pick up BLS config
> from /boot/loader.
My suggestion would be: don't standardize on boot loaders, standardize
on the boot loader spec.
Using the above partition scheme probably works with sd-boot (instead of
grub-efi) too if you tag /boot as XBOOTLDR.
The point I was tring to make is that you can install fedora in a way
that the disk can be booted in both bios and uefi mode.
take care,
Gerd
12:25 p.m.
On Mi, 01.07.20 18:31, Gerd Hoffmann (kraxel(a)redhat.com) wrote:
> > One problem with sd-boot is that the kernels must stay on
the ESP, which
> > can be a problem for dual-boot installs (where Fedora has to run with
> > the existing ESP and can't just create one which is big enouth).
>
> Nah, that's not true. Hasn't been for quite a while.
>
> sd-boot checks for kernels in the ESP first, and then on a second
> partition we called XBOOTLDR, which also can contain kernels. XBOOTLDR
> partition is simply a partition with type UUID
> bc13c2ff-59e6-4262-a352-b275fd6f7172.
Ah, this is news to me. XBOOTLDR must be formated with a filesystem the
uefi firmware can read (i.e. vfat in practice) I assume?
The spec doesn't strictly mandate that in the general case. I think it
would still be wise to stick to vfat, given that this means all kind
of firmware can easily read it, but if your boot loader/firmware can
read something else that's OK too.
> sd-boot is uefi only, but it should work fine with any arch that
is
> supported by uefi.
Seems it isn't built for armhfp in Fedora (/usr/lib/systemd/boot/efi
doesn't exist ...).
Hmm, I know that people build it on ARM, I guess we could enable that
in Fedora too. I am not an ARM pro myself, not sure what happens there
right now.
Upstream sd-boot has support for UEFI ia32, x64, arm and aa64.
Lennart
--
Lennart Poettering, Berlin
5:59 a.m.
On Tue, Jun 30, 2020 at 03:27:45PM +0100, Daniel P. Berrangé wrote:
On Tue, Jun 30, 2020 at 04:00:00PM +0200, Florian Weimer wrote:
> * 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 common intel based x86 platform
> > since atleast 2005.
>
> Even for virtualization? Not sure if that can be done.
KVM virt on aarch64 and x86 can support EFI via AVMF / OVMF firmware
built from the edk2 project from a technical POV.
The first challenge will be that many mgmt tools still default to
using legacy BIOS when deploying guest OS. We've been trying to
make it easier for mgmt apps to "do the right thing" by having
libosinfo record metadata about whether each guest OS supports
legacy BIOS, EFI or both. ie we want the mgmt apps to just pick
EFI if they see the OS doesn't support legacy BIOS, instead of
requiring users to manually tell them to use EFI.
Historically we've tended to discourage use of EFI on virt because,
unless you wanted SecureBoot for your VMs, it hasn't offered much
in the way of compelling benefits to users. The EDK2 project code
is a much higher maint burden for virt than the seabios was, and
there's no sign that situation will improve.
Also it's considerably slower to boot to the kernel, especially if you
enable debug messages on an emulated serial port which makes it almost
comically slow.
So I can't say I'm thrilled about a future that depends on
EFI for
virt, but I'm resigned to the fact this is the direction the world
is taking. So we're not likely to have any choice and will have to
work to mitigate any downsides it brings.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
12:54 p.m.
On Tuesday, June 30, 2020 7:00:00 AM MST Florian Weimer wrote:
* 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 common intel based x86 platform
> since atleast 2005.
Even for virtualization? Not sure if that can be done.
It's possible, and actually surprisingly simple, but not in virtualization
hosts based on RHEL7. I'm not sure about RHEL8, but in Fedora, you can install
edk2-ovmf, if it's not already installed, to get UEFI support.
--
John M. Harris, Jr.
9:23 a.m.
W dniu 30.06.2020 o 15:34, Jóhann B. Guðmundsson pisze:
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 common intel based x86
platform since atleast 2005.
Will you provide replacement for laptop I bought in 2013? Still has some
use, runs Fedora 31 just fine. BIOS mode only.
My other PC at home is BIOS mode only too. Sure, it is FX-6300 so quite
old but with some hard drives and 16GB of ram it has a use.
10:25 a.m.
On Tue, 2020-06-30 at 16:23 +0200, Marcin Juszkiewicz wrote:
W dniu 30.06.2020 o 15:34, Jóhann B. Guðmundsson pisze:
> 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 common intel based x86
> platform since atleast 2005.
Will you provide replacement for laptop I bought in 2013? Still has some
use, runs Fedora 31 just fine. BIOS mode only.
My other PC at home is BIOS mode only too. Sure, it is FX-6300 so quite
old but with some hard drives and 16GB of ram it has a use.
I'm also still using a laptop from 2010:
https://www.trustedreviews.com/reviews/sony-vaio-z-series-vpc-z11z9e-b-13...
it has outlived one 'replacement' so far, and my 3.5 year old XPS 13
(9360 gen) recently stopped booting so unless I can fix that, it will
have outlived two...
it has no UEFI support either.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
12:20 p.m.
W dniu 30.06.2020 o 17:25, Adam Williamson pisze:
On Tue, 2020-06-30 at 16:23 +0200, Marcin Juszkiewicz wrote:
> W dniu 30.06.2020 o 15:34, Jóhann B. Guðmundsson pisze:
>> 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 common intel based x86
>> platform since atleast 2005.
>
> Will you provide replacement for laptop I bought in 2013? Still has some
> use, runs Fedora 31 just fine. BIOS mode only.
>
> My other PC at home is BIOS mode only too. Sure, it is FX-6300 so quite
> old but with some hard drives and 16GB of ram it has a use.
I'm also still using a laptop from 2010:
https://www.trustedreviews.com/reviews/sony-vaio-z-series-vpc-z11z9e-b-13...
it has outlived one 'replacement' so far, and my 3.5 year old XPS 13
(9360 gen) recently stopped booting so unless I can fix that, it will
have outlived two...
it has no UEFI support either.
I am happily running Fedora on a laptop from 2011 (Clevo P150HM) which
does not support UEFI.
Best regards,
Julian
1:13 p.m.
Adam Williamson píše v Út 30. 06. 2020 v 08:25 -0700:
On Tue, 2020-06-30 at 16:23 +0200, Marcin Juszkiewicz wrote:
> W dniu 30.06.2020 o 15:34, Jóhann B. Guðmundsson pisze:
> > 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 common intel based
> > x86
> > platform since atleast 2005.
>
> Will you provide replacement for laptop I bought in 2013? Still has
> some
> use, runs Fedora 31 just fine. BIOS mode only.
>
> My other PC at home is BIOS mode only too. Sure, it is FX-6300 so
> quite
> old but with some hard drives and 16GB of ram it has a use.
I'm also still using a laptop from 2010:
https://www.trustedreviews.com/reviews/sony-vaio-z-series-vpc-z11z9e-b-13...
it has outlived one 'replacement' so far, and my 3.5 year old XPS 13
(9360 gen) recently stopped booting so unless I can fix that, it will
have outlived two...
it has no UEFI support either.
I maintain the following laptops in our family:
ThinkPad R61
ThinkPad T400s
ThinkPad X201
Macbook Pro 2010
All of them don't support UEFI, but run Fedora 32 just fine and are
still useful to my relatives. I think one of the important roles of
Linux distributions is that they allow you to keep using hardware that
has been obsoleted by its vendors, help you fight the planned
obsolescence.
I know that supporting old hardware comes at a cost and at some point
we just have to make a cut, but doing it for hardware that is 8-10
years old is not much better than the planned obsolescence.
Jiri
1:39 p.m.
On Tue, 30 Jun 2020 at 17:26, Adam Williamson <adamwill(a)fedoraproject.org>
wrote:
On Tue, 2020-06-30 at 16:23 +0200, Marcin Juszkiewicz wrote:
> W dniu 30.06.2020 o 15:34, Jóhann B. Guðmundsson pisze:
> > 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 common intel based x86
> > platform since atleast 2005.
>
> Will you provide replacement for laptop I bought in 2013? Still has some
> use, runs Fedora 31 just fine. BIOS mode only.
>
> My other PC at home is BIOS mode only too. Sure, it is FX-6300 so quite
> old but with some hard drives and 16GB of ram it has a use.
I'm also still using a laptop from 2010:
https://www.trustedreviews.com/reviews/sony-vaio-z-series-vpc-z11z9e-b-13...
it has outlived one 'replacement' so far, and my 3.5 year old XPS 13
(9360 gen) recently stopped booting so unless I can fix that, it will
have outlived two...
it has no UEFI support either.
HP EliteBook 8570p here. A perfectly capable machine, great for coding,
allowing up
to 16GB RAM. I wouldn't just wave off any machine from around
2010-2012, because many are quite sturdy and still useful.
The other thing is virtualization as many have mentioned. It defaults to
BIOS, because it Just Works. I think the idea to get rid of the legacy
"burden" of BIOS is a good one in the long-term, but I don't think the
ecosystem is ready for it yet :(.
10:24 a.m.
On Tue, 2020-06-30 at 13:34 +0000, 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 supported boot
which
has been available on any common intel based x86 platform since
atleast
2005.
Now in 2017 Intel's technical marketing engineer Brian Richardson
revealed in a presentation that the company will require UEFI Class
3
and above as in it would remove legacy BIOS support from its client
and
datacenter platforms by 2020 and one might expect AMD to follow Intel
in
this regard.
So Intel platforms produced this year presumably will be unable
to run
32-bit operating systems, unable to use related software (at least
natively), and unable to use older hardware, such as RAID HBAs (and
therefore older hard drives that are connected to those HBAs),
network
cards, and even graphics cards that lack UEFI-compatible vBIOS
(launched
before 2012 – 2013) etc.
This post is just to gather feed back why Fedora should still
continue
to support legacy BIOS boot as opposed to stop supporting it and
potentially drop grub2 and use sd-boot instead.
Share your thoughts and comments on how such move might affect you
so
feedback can be collected for the future on why such a change might
be
bad, how it might affect the distribution and scope of such change
can
be determined for potential system wide proposal.
Reason 1: I don't see a reason for supporting the planned obsolescence
that hardware companies try to push on users.
Reason 2: I bought my latest laptop in the end of 2019. It's an HP
laptop with a Ryzen quad-core CPU. Yes, it has UEFI, but I bought it
without Windows, so it came preinstalled with FreeDOS, which runs in
legacy mode only. I installed Fedora on it, without switching to UEFI
mode. I believe many users who buy laptops without Windows would be
using Linux in legacy boot mode, just because it's the only way to boot
FreeDOS, and companies such as HP only offer you the option of having
Windows or FreeDOS preinstalled.
Overall, it is pain and breakage for a portion of the users, while I
don't see a particularly strong benefit - testing and maintaining
legacy BIOS boot support should be easy, because every VM out there
supports it, and it's even the default for most of them. In fact, I've
never tried UEFI in a VM, and I have no idea how stable it is. But even
if it's stable, I wouldn't want to have to migrate them to UEFI,
because that would require repartitioning, which could cause loss of
data in case something goes wrong, which leads us to reason 3:
Reason 3: Migration path to UEFI boot mode is difficult even for modern
systems, that were installed in legacy mode. It requires tinkering with
the BIOS settings, which is non-standard and therefore different for
every computer, and also repartitioning and reinstall of all operating
systems on the computer. Even if this is automated, there are many
dangerous scenarios that can cause loss of data. Think about multiboot
scenarios, for example, where a user is multibooting Windows 10 and
Fedora. We simply can't handle the upgrade in this case, without
destroying the Windows 10 installation, even if we are able to upgrade
a Fedora only install (and even that is dangerous).
Best regards,
Nikolay
10:31 a.m.
On 6/30/20 8:24 AM, nickysn(a)gmail.com wrote:
I've never tried UEFI in a VM, and I have no idea how stable it
is.
IME, works well in a variety of hypervisors; atm, my 'exploration' of Fedora32 is
running solely in VirtualBox VMs ... booted UEFI.
That said, their a lots of providers that have the capability, but do not enable/support
UEFI boot.
E.g., Linode hosts KVM (and, iiuc, still some Xen), but does _not_ support UEFI boot; as
of a few weeks ago, there's no plans/commitment for that changing anytime soon.
12:49 p.m.
On Tuesday, June 30, 2020 6:34:27 AM MST 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 supported boot which
has been available on any common intel based x86 platform since atleast
2005.
This is simply false. I'm currently writing this email on a ThinkPad X200
Tablet, which does not support UEFI. I can get dropping x86 support, but
dropping BIOS boot support?
Now in 2017 Intel's technical marketing engineer Brian Richardson
revealed in a presentation that the company will require UEFI Class 3
and above as in it would remove legacy BIOS support from its client and
datacenter platforms by 2020 and one might expect AMD to follow Intel in
this regard.
Good for them. That just means that, on those next-generation systems, once
they're out, people will be using UEFI boot.
So Intel platforms produced this year presumably will be unable to
run
32-bit operating systems, unable to use related software (at least
natively), and unable to use older hardware, such as RAID HBAs (and
therefore older hard drives that are connected to those HBAs), network
cards, and even graphics cards that lack UEFI-compatible vBIOS (launched
before 2012 – 2013) etc.
What does BIOS boot have to do with 32 bit operating systems? RAID HBAs will
also continue to work, though you may not be able to boot from them. Network
cards will *also* continue to work, you just might not be able to PXE.
This post is just to gather feed back why Fedora should still
continue
to support legacy BIOS boot as opposed to stop supporting it and
potentially drop grub2 and use sd-boot instead.
So that people can continue to boot their systems, and so that users and cloud
providers can still boot Fedora VMs. Why in the world would GRUB2 be dropped?
Share your thoughts and comments on how such move might affect you so
feedback can be collected for the future on why such a change might be
bad, how it might affect the distribution and scope of such change can
be determined for potential system wide proposal.
This would mean that every single one of the systems that I own, every system
on Linode, DigitalOcean, and most other cloud providers would cease to be able
to boot Fedora. I'm very much against this proposal.
--
John M. Harris, Jr.
1:29 p.m.
On 30.6.2020 17:49, John M. Harris Jr wrote:
On Tuesday, June 30, 2020 6:34:27 AM MST 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 supported boot which
> has been available on any common intel based x86 platform since atleast
> 2005.
This is simply false. I'm currently writing this email on a ThinkPad X200
Tablet, which does not support UEFI. I can get dropping x86 support, but
dropping BIOS boot support?
Such proposal would never be about stop supporting older hardware that's
just a misconception people are getting
And it's quite evident by the response here that hw that is atleast 2010
and older is still quite happily being used and that hw does not support
UEFI and no one is talking about taking that away anytime soon.
The first step ( The actual change proposal ) would simply be about
replace grub2 with sd-boot for UEFI strictly on the x86 architecture
which has UEFI available and enabled ( is not using legacy bios ) and
see what issue are encountered, solve those then consider moving to
different architectures and further integration if relevant etc. ( baby
steps ) Next I would suggest looking at UEFI supported ARM systems ( but
I personally would have to obtain such hardware before doing so ).
JBG
1:32 p.m.
On Tuesday, June 30, 2020 11:29:13 AM MST Jóhann B. Guðmundsson wrote:
On 30.6.2020 17:49, John M. Harris Jr wrote:
> On Tuesday, June 30, 2020 6:34:27 AM MST 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 supported boot which
>> has been available on any common intel based x86 platform since atleast
>> 2005.
>
> This is simply false. I'm currently writing this email on a ThinkPad X200
> Tablet, which does not support UEFI. I can get dropping x86 support, but
> dropping BIOS boot support?
Such proposal would never be about stop supporting older hardware that's
just a misconception people are getting
And it's quite evident by the response here that hw that is atleast 2010
and older is still quite happily being used and that hw does not support
UEFI and no one is talking about taking that away anytime soon.
The first step ( The actual change proposal ) would simply be about
replace grub2 with sd-boot for UEFI strictly on the x86 architecture
which has UEFI available and enabled ( is not using legacy bios ) and
see what issue are encountered, solve those then consider moving to
different architectures and further integration if relevant etc. ( baby
steps ) Next I would suggest looking at UEFI supported ARM systems ( but
I personally would have to obtain such hardware before doing so ).
JBG
Why do you prefer sd-boot over GRUB2? I don't understand how you'd boot from
an SD card on most x86 hardware. ;)
Jokes aside, what's the call for the preference of even more systemd bloat? Do
we not have enough yet?
--
John M. Harris, Jr.
3:20 p.m.
On 30.6.2020 18:32, John M. Harris Jr wrote:
On Tuesday, June 30, 2020 11:29:13 AM MST Jóhann B. Guðmundsson
wrote:
> On 30.6.2020 17:49, John M. Harris Jr wrote:
>> On Tuesday, June 30, 2020 6:34:27 AM MST 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 supported boot which
>>> has been available on any common intel based x86 platform since atleast
>>> 2005.
>> This is simply false. I'm currently writing this email on a ThinkPad X200
>> Tablet, which does not support UEFI. I can get dropping x86 support, but
>> dropping BIOS boot support?
> Such proposal would never be about stop supporting older hardware that's
> just a misconception people are getting
>
> And it's quite evident by the response here that hw that is atleast 2010
> and older is still quite happily being used and that hw does not support
> UEFI and no one is talking about taking that away anytime soon.
>
> The first step ( The actual change proposal ) would simply be about
> replace grub2 with sd-boot for UEFI strictly on the x86 architecture
> which has UEFI available and enabled ( is not using legacy bios ) and
> see what issue are encountered, solve those then consider moving to
> different architectures and further integration if relevant etc. ( baby
> steps ) Next I would suggest looking at UEFI supported ARM systems ( but
> I personally would have to obtain such hardware before doing so ).
>
> JBG
Why do you prefer sd-boot over GRUB2? I don't understand how you'd boot from
an SD card on most x86 hardware. ;)
Jokes aside, what's the call for the preference of even more systemd bloat? Do
we not have enough yet?
sd-boot is already installed on end users system, is light weight
compared to Grub ( sd-boot only supports uefi,smaller code size, easier
to maintain ).
It already integrates with the service management framework (systemd).
More user friendly than Grub ( has lilo like interface easier to change
kernel entry, which goes nicely with the default editor change )
Gnome related changes such as Hans is proposing might be easier to
integrate for the desktop team ( less work, problem being fixed where it
arguably should be as opposed to systemd,grub and gnome for his feature
to work and more future proof work for the desktop team).
Could help further adapt UEFI and secure boot which the industry is
moving towards which helps keep Fedora moving along with it.
If correctly implemented ( baby steps and without excluding anyone)
should be a win win for Fedora, developers and end users alike.
Grub discourages users who have tried sd-boot from coming/returning to
Fedora [1].
Bottom line I think this will be a good move for the distribution and a
good time to start looking into and make that move.
JBG
1. https://www.reddit.com/r/Fedora/comments/c0f3z5/systemdboot/
5:38 p.m.
Jóhann B. Guðmundsson wrote:
sd-boot is already installed on end users system, is light weight
compared to Grub ( sd-boot only supports uefi,smaller code size, easier
to maintain ).
And that is exactly the problem, systemd-boot has only a small fraction of
the feature set of GRUB. That is what makes it so small. I do not see what
value it would provide over GRUB-EFI.
In addition, as far as I know, systemd-boot is not compatible with the
"Secure Boot" shim.
Kevin Kofler
6:19 p.m.
On 30.6.2020 22:38, Kevin Kofler wrote:
Jóhann B. Guðmundsson wrote:
> sd-boot is already installed on end users system, is light weight
> compared to Grub ( sd-boot only supports uefi,smaller code size, easier
> to maintain ).
And that is exactly the problem, systemd-boot has only a small fraction of
the feature set of GRUB. That is what makes it so small. I do not see what
value it would provide over GRUB-EFI.
In addition, as far as I know, systemd-boot is not compatible with the
"Secure Boot" shim.
sd-boot works fine with secure boot but good point I'll add a test case
for that and check if it's not working.
( This might actually have been one of those case that I might have
forgotten so good catch )
JBG
6:46 a.m.
On Wed, Jul 1, 2020 at 12:19 AM Jóhann B. Guðmundsson
<johannbg(a)gmail.com> wrote:
On 30.6.2020 22:38, Kevin Kofler wrote:
> Jóhann B. Guðmundsson wrote:
>> sd-boot is already installed on end users system, is light weight
>> compared to Grub ( sd-boot only supports uefi,smaller code size, easier
>> to maintain ).
> And that is exactly the problem, systemd-boot has only a small fraction of
> the feature set of GRUB. That is what makes it so small. I do not see what
> value it would provide over GRUB-EFI.
>
> In addition, as far as I know, systemd-boot is not compatible with the
> "Secure Boot" shim.
sd-boot works fine with secure boot but good point I'll add a test case
for that and check if it's not working.
Is that with self enrolled keys or is it now signed with the MS keys
through the official process?
9:57 a.m.
On 7/2/20 4:46 AM, Peter Robinson wrote:
On Wed, Jul 1, 2020 at 12:19 AM Jóhann B. Guðmundsson
<johannbg(a)gmail.com> wrote:
On 30.6.2020 22:38, Kevin Kofler wrote:
>> In addition, as far as I know, systemd-boot is not compatible with the
>> "Secure Boot" shim.
> sd-boot works fine with secure boot but good point I'll add a test case
> for that and check if it's not working.
Is that with self enrolled keys or is it now signed with the MS keys
through the official process?
Correct me if I'm wrong, but I think only shim is signed with the MS
keys and the boot loader that it loads (grub2 or sd-boot) is signed by
Red Hat.
https://docs.fedoraproject.org/en-US/Fedora/18/html/UEFI_Secure_Boot_Guid...
10:21 a.m.
On Do, 02.07.20 12:46, Peter Robinson (pbrobinson(a)gmail.com) wrote:
On Wed, Jul 1, 2020 at 12:19 AM Jóhann B. Guðmundsson
<johannbg(a)gmail.com> wrote:
>
> On 30.6.2020 22:38, Kevin Kofler wrote:
> > Jóhann B. Guðmundsson wrote:
> >> sd-boot is already installed on end users system, is light weight
> >> compared to Grub ( sd-boot only supports uefi,smaller code size, easier
> >> to maintain ).
> > And that is exactly the problem, systemd-boot has only a small fraction of
> > the feature set of GRUB. That is what makes it so small. I do not see what
> > value it would provide over GRUB-EFI.
> >
> > In addition, as far as I know, systemd-boot is not compatible with the
> > "Secure Boot" shim.
>
>
> sd-boot works fine with secure boot but good point I'll add a test case
> for that and check if it's not working.
Is that with self enrolled keys or is it now signed with the MS keys
through the official process?
It's up to the distro to sign it, it supports the shim though.
Lennart
--
Lennart Poettering, Berlin
2:26 a.m.
On Tuesday, June 30, 2020 1:20:18 PM MST Jóhann B. Guðmundsson wrote:
sd-boot is already installed on end users system, is light weight
compared to Grub ( sd-boot only supports uefi,smaller code size, easier
to maintain ).
Sure, gummiboot is more lightweight than GRUB. It also doesn't support a lot
of the features that GRUB does, such as full disk encryption (with stub in
MBR).
It already integrates with the service management framework
(systemd).
That's one of the problems with it. What does an init system have to do with
the bootloader?
More user friendly than Grub ( has lilo like interface easier to
change
kernel entry, which goes nicely with the default editor change )
I'm pretty sure GRUB has a much more user friendly interface than systemd-
boot.. Additionally, you can even drop to a cmdline if needed, in GRUB.
Gnome related changes such as Hans is proposing might be easier to
integrate for the desktop team ( less work, problem being fixed where it
arguably should be as opposed to systemd,grub and gnome for his feature
to work and more future proof work for the desktop team).
GNOME related changes.. to a bootloader? Sorry, I haven't heard of any of
those. Can you point me to a thread or page describing that kind of thing?
That sounds a bit.. odd, to say the least.
Regardless, if that's going to be a thing, it'd be perfectly fine, in my
opinion, for Workstation to use systemd-boot on UEFI by default, and GRUB only
on BIOS boot systems, while the rest of Fedora continues to use the more
powerful bootloader.
Could help further adapt UEFI and secure boot which the industry is
moving towards which helps keep Fedora moving along with it.
GRUB2 supports UEFI, quite well in fact.
Grub discourages users who have tried sd-boot from coming/returning
to
Fedora [1].
How's that? If you mean that users that have used GRUB prefer it over systemd-
boot, I'd be inclined to agree, but I don't see how it'd prevent people from
returning to Fedora.
Bottom line I think this will be a good move for the distribution and
a
good time to start looking into and make that move.
I have to disagree. The more systemd bloat that gets thrown into the mix, the
more concerned I become with this path. We already have a powerful and mature
project in GRUB2, which supports UEFI well, and is known to be stable.
--
John M. Harris, Jr.
6:18 p.m.
Jóhann B. Guðmundsson wrote:
More user friendly than Grub ( has lilo like interface easier to
change
kernel entry, which goes nicely with the default editor change )
This made me go "What?!". I used Lilo back in the day. Its user
interface was nothing but a prompt. You had to know what to type or
you'd be stuck.
Information for others like me who haven't seen Lilo since Grub came
along: Apparently development of Lilo continued until just five years
ago, and it grew a menu at some point. I guess that menu is the image
of user-friendliness that Johann was trying to invoke.
Björn Persson
6:28 p.m.
On Wed, Jul 1, 2020 at 7:19 PM Björn Persson <Bjorn(a)xn--rombobjrn-67a.se> wrote:
Jóhann B. Guðmundsson wrote:
> More user friendly than Grub ( has lilo like interface easier to change
> kernel entry, which goes nicely with the default editor change )
This made me go "What?!". I used Lilo back in the day. Its user
interface was nothing but a prompt. You had to know what to type or
you'd be stuck.
Information for others like me who haven't seen Lilo since Grub came
along: Apparently development of Lilo continued until just five years
ago, and it grew a menu at some point. I guess that menu is the image
of user-friendliness that Johann was trying to invoke.
If I ever wanted to switch to another boot manager, I'd seriously like
us to consider rEFInd: https://www.rodsbooks.com/refind/
It's a very nice boot manager that looks good and doesn't suck. And
purportedly is somewhat (if not fully) compatible with bls.
sd-boot is too barebones and unfriendly to use, which makes sense
since it was designed for non-interactive machines and not humans to
use.
--
真実はいつも一つ！/ Always, there's only one truth!
8:02 p.m.
On 1.7.2020 23:28, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 7:19 PM Björn Persson
<Bjorn(a)xn--rombobjrn-67a.se> wrote:
> Jóhann B. Guðmundsson wrote:
>> More user friendly than Grub ( has lilo like interface easier to change
>> kernel entry, which goes nicely with the default editor change )
> This made me go "What?!". I used Lilo back in the day. Its user
> interface was nothing but a prompt. You had to know what to type or
> you'd be stuck.
>
> Information for others like me who haven't seen Lilo since Grub came
> along: Apparently development of Lilo continued until just five years
> ago, and it grew a menu at some point. I guess that menu is the image
> of user-friendliness that Johann was trying to invoke.
>
If I ever wanted to switch to another boot manager, I'd seriously like
us to consider rEFInd: https://www.rodsbooks.com/refind/
It's a very nice boot manager that looks good and doesn't suck. And
purportedly is somewhat (if not fully) compatible with bls.
sd-boot is too barebones and unfriendly to use, which makes sense
since it was designed for non-interactive machines and not humans to
use.
If there is this general feel that sd-boots configuration syntax is much
harder to read and the ability of not having to run additional command
once the file has been edited or the ability to be able to easily
maintain and manage multiple kernels or multiple operating systems due
those being a drop-in configuration text files, is considered being too
bare bone and *less* user-friendly than grub, then obviously me creating
a change proposal based on what Javier suggested along with other
cleanups to provide as best user experience as can be had with sd-boot
would be doing the distribution a great disservice would it not?
JBG
8:06 p.m.
On Wed, Jul 1, 2020 at 9:03 PM Jóhann B. Guðmundsson <johannbg(a)gmail.com> wrote:
On 1.7.2020 23:28, Neal Gompa wrote:
> On Wed, Jul 1, 2020 at 7:19 PM Björn Persson <Bjorn(a)xn--rombobjrn-67a.se> wrote:
>> Jóhann B. Guðmundsson wrote:
>>> More user friendly than Grub ( has lilo like interface easier to change
>>> kernel entry, which goes nicely with the default editor change )
>> This made me go "What?!". I used Lilo back in the day. Its user
>> interface was nothing but a prompt. You had to know what to type or
>> you'd be stuck.
>>
>> Information for others like me who haven't seen Lilo since Grub came
>> along: Apparently development of Lilo continued until just five years
>> ago, and it grew a menu at some point. I guess that menu is the image
>> of user-friendliness that Johann was trying to invoke.
>>
> If I ever wanted to switch to another boot manager, I'd seriously like
> us to consider rEFInd: https://www.rodsbooks.com/refind/
>
> It's a very nice boot manager that looks good and doesn't suck. And
> purportedly is somewhat (if not fully) compatible with bls.
>
> sd-boot is too barebones and unfriendly to use, which makes sense
> since it was designed for non-interactive machines and not humans to
> use.
If there is this general feel that sd-boots configuration syntax is much
harder to read and the ability of not having to run additional command
once the file has been edited or the ability to be able to easily
maintain and manage multiple kernels or multiple operating systems due
those being a drop-in configuration text files, is considered being too
bare bone and *less* user-friendly than grub, then obviously me creating
a change proposal based on what Javier suggested along with other
cleanups to provide as best user experience as can be had with sd-boot
would be doing the distribution a great disservice would it not?
Oh, I don't care about the configuration syntax. That part would be
the same across grub, refind, and sd-boot anyway.
The user-interactive portion of sd-boot is *awful*. I know our GRUB
looks ugly by default these days too, but it doesn't have to be, and
most distros actually do make it look semi-decent.
But alas, nobody cares about making that part look nice, because they
hope people don't have to go there at all. But even Windows makes
their boot manager not look ugly and relatively easy to navigate. And
obviously Apple has done this forever with macOS.
I honestly don't get why everyone is okay with butt-ugly and user-unfriendly UX.
--
真実はいつも一つ！/ Always, there's only one truth!
8:19 p.m.
On 2.7.2020 01:06, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 9:03 PM Jóhann B. Guðmundsson
<johannbg(a)gmail.com> wrote:
> On 1.7.2020 23:28, Neal Gompa wrote:
>> On Wed, Jul 1, 2020 at 7:19 PM Björn Persson <Bjorn(a)xn--rombobjrn-67a.se> wrote:
>>> Jóhann B. Guðmundsson wrote:
>>>> More user friendly than Grub ( has lilo like interface easier to change
>>>> kernel entry, which goes nicely with the default editor change )
>>> This made me go "What?!". I used Lilo back in the day. Its user
>>> interface was nothing but a prompt. You had to know what to type or
>>> you'd be stuck.
>>>
>>> Information for others like me who haven't seen Lilo since Grub came
>>> along: Apparently development of Lilo continued until just five years
>>> ago, and it grew a menu at some point. I guess that menu is the image
>>> of user-friendliness that Johann was trying to invoke.
>>>
>> If I ever wanted to switch to another boot manager, I'd seriously like
>> us to consider rEFInd: https://www.rodsbooks.com/refind/
>>
>> It's a very nice boot manager that looks good and doesn't suck. And
>> purportedly is somewhat (if not fully) compatible with bls.
>>
>> sd-boot is too barebones and unfriendly to use, which makes sense
>> since it was designed for non-interactive machines and not humans to
>> use.
> If there is this general feel that sd-boots configuration syntax is much
> harder to read and the ability of not having to run additional command
> once the file has been edited or the ability to be able to easily
> maintain and manage multiple kernels or multiple operating systems due
> those being a drop-in configuration text files, is considered being too
> bare bone and *less* user-friendly than grub, then obviously me creating
> a change proposal based on what Javier suggested along with other
> cleanups to provide as best user experience as can be had with sd-boot
> would be doing the distribution a great disservice would it not?
>
Oh, I don't care about the configuration syntax. That part would be
the same across grub, refind, and sd-boot anyway.
The user-interactive portion of sd-boot is *awful*. I know our GRUB
looks ugly by default these days too, but it doesn't have to be, and
most distros actually do make it look semi-decent.
But alas, nobody cares about making that part look nice, because they
hope people don't have to go there at all. But even Windows makes
their boot manager not look ugly and relatively easy to navigate. And
obviously Apple has done this forever with macOS.
I honestly don't get why everyone is okay with butt-ugly and user-unfriendly UX.
Because the end user should never find himself in the boot manager to
begin with that's why no boot manager invest any time in being "pretty".
The end user should find himself ending up in some form of shiny nice
user friendly rescue environment that helps him troubleshoot his problem
would you agree?
JBG
8:42 p.m.
On Wed, Jul 1, 2020 at 9:23 PM Jóhann B. Guðmundsson <johannbg(a)gmail.com> wrote:
On 2.7.2020 01:06, Neal Gompa wrote:
> On Wed, Jul 1, 2020 at 9:03 PM Jóhann B. Guðmundsson <johannbg(a)gmail.com>
wrote:
>> On 1.7.2020 23:28, Neal Gompa wrote:
>>> On Wed, Jul 1, 2020 at 7:19 PM Björn Persson <Bjorn(a)xn--rombobjrn-67a.se>
wrote:
>>>> Jóhann B. Guðmundsson wrote:
>>>>> More user friendly than Grub ( has lilo like interface easier to
change
>>>>> kernel entry, which goes nicely with the default editor change )
>>>> This made me go "What?!". I used Lilo back in the day. Its
user
>>>> interface was nothing but a prompt. You had to know what to type or
>>>> you'd be stuck.
>>>>
>>>> Information for others like me who haven't seen Lilo since Grub
came
>>>> along: Apparently development of Lilo continued until just five years
>>>> ago, and it grew a menu at some point. I guess that menu is the image
>>>> of user-friendliness that Johann was trying to invoke.
>>>>
>>> If I ever wanted to switch to another boot manager, I'd seriously like
>>> us to consider rEFInd: https://www.rodsbooks.com/refind/
>>>
>>> It's a very nice boot manager that looks good and doesn't suck. And
>>> purportedly is somewhat (if not fully) compatible with bls.
>>>
>>> sd-boot is too barebones and unfriendly to use, which makes sense
>>> since it was designed for non-interactive machines and not humans to
>>> use.
>> If there is this general feel that sd-boots configuration syntax is much
>> harder to read and the ability of not having to run additional command
>> once the file has been edited or the ability to be able to easily
>> maintain and manage multiple kernels or multiple operating systems due
>> those being a drop-in configuration text files, is considered being too
>> bare bone and *less* user-friendly than grub, then obviously me creating
>> a change proposal based on what Javier suggested along with other
>> cleanups to provide as best user experience as can be had with sd-boot
>> would be doing the distribution a great disservice would it not?
>>
> Oh, I don't care about the configuration syntax. That part would be
> the same across grub, refind, and sd-boot anyway.
>
> The user-interactive portion of sd-boot is *awful*. I know our GRUB
> looks ugly by default these days too, but it doesn't have to be, and
> most distros actually do make it look semi-decent.
>
> But alas, nobody cares about making that part look nice, because they
> hope people don't have to go there at all. But even Windows makes
> their boot manager not look ugly and relatively easy to navigate. And
> obviously Apple has done this forever with macOS.
>
> I honestly don't get why everyone is okay with butt-ugly and user-unfriendly
UX.
Because the end user should never find himself in the boot manager to
begin with that's why no boot manager invest any time in being "pretty".
The end user should find himself ending up in some form of shiny nice
user friendly rescue environment that helps him troubleshoot his problem
would you agree?
I would, except, we can't have that either, because nobody cares to
make that either.
In the Windows and macOS world, these two things are paramount and
they're combined with a more solid boot manager experience. We have
none of that on the Linux side because all the incentives are wrong in
the Linux world: we're driven exclusively by people who know what
they're doing and don't like change.
We have less of this problem in Fedora, but all the *money* in Linux
is pushed for *not changing*, so that makes life very difficult. The
server world uses automation and APIs as a substitute for making good
user experiences. And it shows.
That's why we get more dumb services further stratifying the landscape
of interfaces needed to do something meaningful rather than actually
*changing* things to be better.
That's why GUI tools keep getting retired for complex web applications.
That's why we can't have nice things. Because nobody with power cares enough.
--
真実はいつも一つ！/ Always, there's only one truth!
9:08 p.m.
On 2.7.2020 01:42, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 9:23 PM Jóhann B. Guðmundsson
<johannbg(a)gmail.com> wrote:
> On 2.7.2020 01:06, Neal Gompa wrote:
>> On Wed, Jul 1, 2020 at 9:03 PM Jóhann B. Guðmundsson <johannbg(a)gmail.com>
wrote:
>>> On 1.7.2020 23:28, Neal Gompa wrote:
>>>> On Wed, Jul 1, 2020 at 7:19 PM Björn Persson <Bjorn(a)xn--rombobjrn-67a.se>
wrote:
>>>>> Jóhann B. Guðmundsson wrote:
>>>>>> More user friendly than Grub ( has lilo like interface easier to
change
>>>>>> kernel entry, which goes nicely with the default editor change )
>>>>> This made me go "What?!". I used Lilo back in the day. Its
user
>>>>> interface was nothing but a prompt. You had to know what to type or
>>>>> you'd be stuck.
>>>>>
>>>>> Information for others like me who haven't seen Lilo since Grub
came
>>>>> along: Apparently development of Lilo continued until just five
years
>>>>> ago, and it grew a menu at some point. I guess that menu is the
image
>>>>> of user-friendliness that Johann was trying to invoke.
>>>>>
>>>> If I ever wanted to switch to another boot manager, I'd seriously
like
>>>> us to consider rEFInd: https://www.rodsbooks.com/refind/
>>>>
>>>> It's a very nice boot manager that looks good and doesn't suck.
And
>>>> purportedly is somewhat (if not fully) compatible with bls.
>>>>
>>>> sd-boot is too barebones and unfriendly to use, which makes sense
>>>> since it was designed for non-interactive machines and not humans to
>>>> use.
>>> If there is this general feel that sd-boots configuration syntax is much
>>> harder to read and the ability of not having to run additional command
>>> once the file has been edited or the ability to be able to easily
>>> maintain and manage multiple kernels or multiple operating systems due
>>> those being a drop-in configuration text files, is considered being too
>>> bare bone and *less* user-friendly than grub, then obviously me creating
>>> a change proposal based on what Javier suggested along with other
>>> cleanups to provide as best user experience as can be had with sd-boot
>>> would be doing the distribution a great disservice would it not?
>>>
>> Oh, I don't care about the configuration syntax. That part would be
>> the same across grub, refind, and sd-boot anyway.
>>
>> The user-interactive portion of sd-boot is *awful*. I know our GRUB
>> looks ugly by default these days too, but it doesn't have to be, and
>> most distros actually do make it look semi-decent.
>>
>> But alas, nobody cares about making that part look nice, because they
>> hope people don't have to go there at all. But even Windows makes
>> their boot manager not look ugly and relatively easy to navigate. And
>> obviously Apple has done this forever with macOS.
>>
>> I honestly don't get why everyone is okay with butt-ugly and user-unfriendly
UX.
> Because the end user should never find himself in the boot manager to
> begin with that's why no boot manager invest any time in being
"pretty".
>
> The end user should find himself ending up in some form of shiny nice
> user friendly rescue environment that helps him troubleshoot his problem
> would you agree?
>
I would, except, we can't have that either, because nobody cares to
make that either.
Well if anything I would have expected atleast the Gnome community to
care deeply about that and build a a rescue environment consistent with
the overall Gnome experience.
If we implement sd-boot in conjunction with the automatic boot
assessment we should be able to boot into such environment if the end
users boot fails but if people oppose sd-boot and see that as unusable
root of all evil or there is no interest within the Workstation WG and
or Gnome community ( Team Anaconda might be the right place for such
work? ) working on to provide such an rescue environment then obviously
nothing will change.
JBG
<snip>
9:10 p.m.
On Wed, Jul 1, 2020 at 10:08 PM Jóhann B. Guðmundsson
<johannbg(a)gmail.com> wrote:
On 2.7.2020 01:42, Neal Gompa wrote:
> On Wed, Jul 1, 2020 at 9:23 PM Jóhann B. Guðmundsson <johannbg(a)gmail.com>
wrote:
>> On 2.7.2020 01:06, Neal Gompa wrote:
>>> On Wed, Jul 1, 2020 at 9:03 PM Jóhann B. Guðmundsson
<johannbg(a)gmail.com> wrote:
>>>> On 1.7.2020 23:28, Neal Gompa wrote:
>>>>> On Wed, Jul 1, 2020 at 7:19 PM Björn Persson
<Bjorn(a)xn--rombobjrn-67a.se> wrote:
>>>>>> Jóhann B. Guðmundsson wrote:
>>>>>>> More user friendly than Grub ( has lilo like interface
easier to change
>>>>>>> kernel entry, which goes nicely with the default editor
change )
>>>>>> This made me go "What?!". I used Lilo back in the day.
Its user
>>>>>> interface was nothing but a prompt. You had to know what to type
or
>>>>>> you'd be stuck.
>>>>>>
>>>>>> Information for others like me who haven't seen Lilo since
Grub came
>>>>>> along: Apparently development of Lilo continued until just five
years
>>>>>> ago, and it grew a menu at some point. I guess that menu is the
image
>>>>>> of user-friendliness that Johann was trying to invoke.
>>>>>>
>>>>> If I ever wanted to switch to another boot manager, I'd
seriously like
>>>>> us to consider rEFInd: https://www.rodsbooks.com/refind/
>>>>>
>>>>> It's a very nice boot manager that looks good and doesn't
suck. And
>>>>> purportedly is somewhat (if not fully) compatible with bls.
>>>>>
>>>>> sd-boot is too barebones and unfriendly to use, which makes sense
>>>>> since it was designed for non-interactive machines and not humans
to
>>>>> use.
>>>> If there is this general feel that sd-boots configuration syntax is
much
>>>> harder to read and the ability of not having to run additional command
>>>> once the file has been edited or the ability to be able to easily
>>>> maintain and manage multiple kernels or multiple operating systems due
>>>> those being a drop-in configuration text files, is considered being too
>>>> bare bone and *less* user-friendly than grub, then obviously me
creating
>>>> a change proposal based on what Javier suggested along with other
>>>> cleanups to provide as best user experience as can be had with sd-boot
>>>> would be doing the distribution a great disservice would it not?
>>>>
>>> Oh, I don't care about the configuration syntax. That part would be
>>> the same across grub, refind, and sd-boot anyway.
>>>
>>> The user-interactive portion of sd-boot is *awful*. I know our GRUB
>>> looks ugly by default these days too, but it doesn't have to be, and
>>> most distros actually do make it look semi-decent.
>>>
>>> But alas, nobody cares about making that part look nice, because they
>>> hope people don't have to go there at all. But even Windows makes
>>> their boot manager not look ugly and relatively easy to navigate. And
>>> obviously Apple has done this forever with macOS.
>>>
>>> I honestly don't get why everyone is okay with butt-ugly and
user-unfriendly UX.
>> Because the end user should never find himself in the boot manager to
>> begin with that's why no boot manager invest any time in being
"pretty".
>>
>> The end user should find himself ending up in some form of shiny nice
>> user friendly rescue environment that helps him troubleshoot his problem
>> would you agree?
>>
> I would, except, we can't have that either, because nobody cares to
> make that either.
Well if anything I would have expected atleast the Gnome community to
care deeply about that and build a a rescue environment consistent with
the overall Gnome experience.
This is the first time I'm hearing of GNOME being interested in
preboot environments.
If we implement sd-boot in conjunction with the automatic boot
assessment we should be able to boot into such environment if the end
users boot fails but if people oppose sd-boot and see that as unusable
root of all evil or there is no interest within the Workstation WG and
or Gnome community ( Team Anaconda might be the right place for such
work? ) working on to provide such an rescue environment then obviously
nothing will change.
This could still work. But you really shouldn't accept butt-ugliness
from any user-facing technology, even sd-boot.
--
真実はいつも一つ！/ Always, there's only one truth!
10:30 a.m.
On Mi, 01.07.20 22:10, Neal Gompa (ngompa13(a)gmail.com) wrote:
This could still work. But you really shouldn't accept
butt-ugliness
from any user-facing technology, even sd-boot.
Dude, maybe what is "butt-ugly" and what isn't is in the eye of the
beholder, and maybe if you want to spend the day watching at your
pretty boot loader then you have a somewhat exotic desire.
sd-boot is really designed to stay out of the view as much as
possible. It's UI (which was proposed by some GNOME designers back in
the day, as mentioned) is supposed to never show except when it really
has to. It's not a UI you spend time in.
sd-boot is designed so that it passed as much information to the OS
about its context, about boot menu items and such as possible, and it
takes commands from the OS too. it does this, so that OS UIs (and not
boot loader UIs) are the primary way to choose what to boot
into. i.e. a pre-boot UI for selecting if you want to boot into
Windows, MacOS, or some Linux version is always going to be terrible,
and being able to pick where to boot into from the desktop UI is a
always a much better UI (with mouse, with touch, with pretty graphics)
then the pre-boot UI could ever have.
It's a substantially diffrent focus: Grub wants to be an OS itself,
have fs drivers, have a UI, have modules, drivers what not. It's Grub
in the center of everything, that is in control and decides what to
do. sd-boot tries hard to not be all that, it has little UI, has a lot
of automatism, little configuration, and a lot of integration, so that
you drive it from the OS, and as little possible have to interface
with its own UI as you can. If you want to reboot into Windows then
you tell sd-boot so when shutting down, i.e. in the OS UI.
Lennart
--
Lennart Poettering, Berlin
10:39 a.m.
On Sat, Jul 4, 2020 at 11:30 AM Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Mi, 01.07.20 22:10, Neal Gompa (ngompa13(a)gmail.com) wrote:
> This could still work. But you really shouldn't accept butt-ugliness
> from any user-facing technology, even sd-boot.
Dude, maybe what is "butt-ugly" and what isn't is in the eye of the
beholder, and maybe if you want to spend the day watching at your
pretty boot loader then you have a somewhat exotic desire.
sd-boot is really designed to stay out of the view as much as
possible. It's UI (which was proposed by some GNOME designers back in
the day, as mentioned) is supposed to never show except when it really
has to. It's not a UI you spend time in.
sd-boot is designed so that it passed as much information to the OS
about its context, about boot menu items and such as possible, and it
takes commands from the OS too. it does this, so that OS UIs (and not
boot loader UIs) are the primary way to choose what to boot
into. i.e. a pre-boot UI for selecting if you want to boot into
Windows, MacOS, or some Linux version is always going to be terrible,
So, sd-boot would only support some Linux OS as it relies on the OS UI?
> and being able to pick where to boot into from the desktop UI is a
> always a much better UI (with mouse, with touch, with pretty graphics)
> then the pre-boot UI could ever have.
>
> It's a substantially diffrent focus: Grub wants to be an OS itself,
> have fs drivers, have a UI, have modules, drivers what not. It's Grub
> in the center of everything, that is in control and decides what to
> do. sd-boot tries hard to not be all that, it has little UI, has a lot
> of automatism, little configuration, and a lot of integration, so that
> you drive it from the OS, and as little possible have to interface
> with its own UI as you can. If you want to reboot into Windows then
> you tell sd-boot so when shutting down, i.e. in the OS UI.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
10:59 a.m.
On Sa, 04.07.20 11:39, Mauricio Tavares (raubvogel(a)gmail.com) wrote:
On Sat, Jul 4, 2020 at 11:30 AM Lennart Poettering
<mzerqung(a)0pointer.de> wrote:
>
> On Mi, 01.07.20 22:10, Neal Gompa (ngompa13(a)gmail.com) wrote:
>
> > This could still work. But you really shouldn't accept butt-ugliness
> > from any user-facing technology, even sd-boot.
>
> Dude, maybe what is "butt-ugly" and what isn't is in the eye of the
> beholder, and maybe if you want to spend the day watching at your
> pretty boot loader then you have a somewhat exotic desire.
>
> sd-boot is really designed to stay out of the view as much as
> possible. It's UI (which was proposed by some GNOME designers back in
> the day, as mentioned) is supposed to never show except when it really
> has to. It's not a UI you spend time in.
>
> sd-boot is designed so that it passed as much information to the OS
> about its context, about boot menu items and such as possible, and it
> takes commands from the OS too. it does this, so that OS UIs (and not
> boot loader UIs) are the primary way to choose what to boot
> into. i.e. a pre-boot UI for selecting if you want to boot into
> Windows, MacOS, or some Linux version is always going to be terrible,
So, sd-boot would only support some Linux OS as it relies on the OS UI?
You can always enter its UI if you like, which is useful if the OS you
come from doesn't support the interfaces as well as Linux does.
BTW, I think the best UI for sd-boot would be if gdm would simply show
the boot entries discovered in some menu accessible from the login
screen, so that the primary boot menu people would interface with is
actually GNOME itself.
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"
will boot into macos, all without showing any UI at all. This means
the boot menu can be hidden entirely during boot with a zero timeout,
but you can still boot into a specific boot entry.
Oh, and did I mention that sd-boot discovers Windows and MacOS X
installations at boot automatically, so that this all is really robust
and requires no writing out of turing complete scripts from any
installer or OS environment?
Lennart
--
Lennart Poettering, Berlin
11:20 a.m.
On 04.07.20 17:59, Lennart Poettering wrote:
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"
will boot into macos, all without showing any UI at all.
I didn't know that (although I've used sd-boot since when it was still
called gummiboot) - that's pretty cool.
8:20 p.m.
On Saturday, July 4, 2020 8:59:09 AM MST Lennart Poettering wrote:
You can always enter its UI if you like, which is useful if the OS
you
come from doesn't support the interfaces as well as Linux does.
That should really be the default, as with the default, sane, bootloader..
BTW, I think the best UI for sd-boot would be if gdm would simply
show
the boot entries discovered in some menu accessible from the login
screen, so that the primary boot menu people would interface with is
actually GNOME itself.
What's the plan for non-GNOME systems? Has this plan been discussed with gdm
developers? How would this be implemented for hardened systems, such as those
using the `ncp` security profile, where the option to reboot or shutdown is
removed from the GDM screen?
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"
will boot into macos, all without showing any UI at all. This means
the boot menu can be hidden entirely during boot with a zero timeout,
but you can still boot into a specific boot entry.
That's actually awful, in my opinion, and objectively undiscoverable.. If
you'd like to see how it should be done, boot a VM with GRUB2 as the
bootloader. For a short period of time, you'll see a list of options, with the
default option highlighted. If you don't pick something different, or don't
need to enter a prompt to recover your device, it'll automatically boot. GRUB2
is nice in that it's powerful enough for those that need it, but simple enough
for those who don't want the complex features.
--
John M. Harris, Jr.
6:31 a.m.
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"
> will boot into macos, all without showing any UI at all. This means
> the boot menu can be hidden entirely during boot with a zero timeout,
> but you can still boot into a specific boot entry.
That's actually awful, in my opinion,
Why? It's nice to have them and I can't see any downsides.
and objectively undiscoverable..
Indeed. Would be nice to show these hotkeys somewhere. Extend the
help line which is shown when you press '?' for example.
If you'd like to see how it should be done, boot a VM with GRUB2
as
the bootloader. For a short period of time, you'll see a list of
options, with the default option highlighted. If you don't pick
something different, or don't need to enter a prompt to recover your
device, it'll automatically boot.
Well, seems you have never actually used sd-boot ...
There actually isn't much of a difference between grub2 and systemd-boot
here. Both can be configured to show or not show a menu. The menu
screen doesn't look fundamentally different either: List of boot
entries for the kernels installed, entry to boot into firmware setup,
default entry highlighted, a few seconds timeout with countdown. Both
support editing boot entries.
Yes, unlike grub2 sd-boot has no command prompt. I have not missed that
so far. The vast majority of cases where I've actually needed the grub2
prompt have been grub2 install problems, like grub2 failing to find its
config file for some reason. That is clearly not something I account in
favor of grub2 ...
GRUB2 is nice in that it's powerful enough for those that need
it, but
simple enough for those who don't want the complex features.
Well, alot of the complex grub features are dragged forward from the
BIOS world to the UEFI world and are somewhat awkward there.
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 last century.
With UEFI much more functionality is provided by the firmware and there
is little reason for a bootloader to have tons of drivers. With the
exception of filesystem drivers in case you want boot from something !=
vfat. But even that should ideally be implemented as uefi driver not as
grub2 module.
If you insist on comparing bloat it will be grub2 which is bloated,
and it comes from being stuck in its own world and carrying its own
implementation for everything instead of using firmware services.
-rwxr-xr-x. 1 root root 93803 Jun 2 08:19 systemd-bootx64.efi
-rwx------. 1 root root 2513224 Jun 19 18:24 grubx64.efi
(binaries as shipped by fedora 32).
take care,
Gerd
7:07 a.m.
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 last century.
With UEFI much more functionality is provided by the firmware and there
is little reason for a bootloader to have tons of drivers. With the
exception of filesystem drivers in case you want boot from something !=
vfat. But even that should ideally be implemented as uefi driver not as
grub2 module.
FWIW, there seem to be UEFI driver for btrfs, ZFS, XFS and others:
https://efi.akeo.ie/
--
Tomasz Torcz “Never underestimate the bandwidth of a station
tomek(a)pipebreaker.pl wagon filled with backup tapes.” — Jim Gray
2:39 p.m.
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 last century.
>
> With UEFI much more functionality is provided by the firmware and there
> is little reason for a bootloader to have tons of drivers. With the
> exception of filesystem drivers in case you want boot from something !=
> vfat. But even that should ideally be implemented as uefi driver not as
> grub2 module.
FWIW, there seem to be UEFI driver for btrfs, ZFS, XFS and others:
https://efi.akeo.ie/
Thanks this was very helpful.
JBG
7:08 a.m.
On Mon, 6 Jul 2020 at 07:38, Gerd Hoffmann <kraxel(a)redhat.com> 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"
> > will boot into macos, all without showing any UI at all. This means
> > the boot menu can be hidden entirely during boot with a zero timeout,
> > but you can still boot into a specific boot entry.
>
> That's actually awful, in my opinion,
Why? It's nice to have them and I can't see any downsides.
It isn't that you put the keyboard strokes, it is that you are saying
you can do a zero-timeout without problems. The assumption being that
you are saying this is what should be a default.. and now you say
there are no downsides. I assume that people are talking past each
other, but in case not, there are always problems
1. Various systems blank out keyboard strokes in case of stuck key. I
have seen this on a lot of servers, workstations and some laptops.
Basically hold a key too short and it gets cleared, hold a key too
long and the system assumes stuck key and ignores keyboard for 30
seconds.
2. Other systems blank out keyboard strokes from before the beginning
of OS boot sections and expect that your OS will give you time to
press some keystrokes before booting. My parents 2 laptops with
different vendors (Dell and ASUS) do that. [They wanted to try what
their son works on... and I found this out while trying to debug
things remotely over the years. We push out bad kernels every now and
then]
3. Some hardware is controlled by things like Serial over LAN (SOL)
which a lot of mgmt ports use. That puts a limit on repeated character
strokes and will break a connection and such. I have spent way too
long this last week dealing with Fedora 30+ systems with short boot
menus over serial over lan and having to power cycle the server (a 3
to 5 minute wait) to get back to the boot menu for one more attempt of
a 2 second keyboard section which SOL may scrub. Trying to debug a
problem over a phone with a parent is similar.
4. Screen flickering and paused screens. The lenovos I have do weird
things when attached to external monitors. Screens will stick on
monitors during the boot up sequence sometimes.. or they will do sync
tests which drop the entire video for 3-5 seconds at a time.
I can see where a zero timeout is a good thing on hardware which
allows it and if the person is ok with it. It is a complete nightmare
on hardware or remote support.
> and objectively undiscoverable..
Indeed. Would be nice to show these hotkeys somewhere. Extend the
help line which is shown when you press '?' for example.
Again, in a zero boot timeout how would hotkeys be seen? A lot of
systems (even new ones :( ) are still recovering from hardware video
tests with screens flashing and such. If I have an external monitor
hooked up to my laptop, I rarely see the grub menu with a default
timeout.. the screen steadies only by the time the system has reached
the enter a password to decrypt drive.
My issues here are not with sd-boot or grub. It is with assuming that
a fast seen by menu is a good thing by default. I think it would be
great as a config option to shoot yourself in the foot by choice.. but
I spend too much time debugging other people's problems to like it by
default :).
--
Stephen J Smoogen.
7:38 a.m.
On Mon, Jul 06, 2020 at 08:08:48AM -0400, Stephen John Smoogen wrote:
On Mon, 6 Jul 2020 at 07:38, Gerd Hoffmann <kraxel(a)redhat.com>
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"
> > > will boot into macos, all without showing any UI at all. This means
> > > the boot menu can be hidden entirely during boot with a zero timeout,
> > > but you can still boot into a specific boot entry.
> >
> > That's actually awful, in my opinion,
>
> Why? It's nice to have them and I can't see any downsides.
>
It isn't that you put the keyboard strokes, it is that you are saying
you can do a zero-timeout without problems.
Ah, ok. I meant specifically the hotkey existing.
I clearly can see that hiding the boot menu has its downsides and in
fact most of my machines are configured to show it (and I think server
actually defaults to menu=on, only workstatiion has menu=off by
default). That is doesn't matter much for the uefi/bios and
grub2/sd-boot discussion though, both boot loaders can be configured
to whatever timeout you like.
4. Screen flickering and paused screens. The lenovos I have do weird
things when attached to external monitors. Screens will stick on
monitors during the boot up sequence sometimes.. or they will do sync
tests which drop the entire video for 3-5 seconds at a time.
I have a 4k monitor connected to a intel nuc, and grub has a 30s timeout
there because it takes *ages* for the screen to sync. And even with the
30s timeout I don't see the menu now and then.
The other extreme are laptop panels which typically sync within the
fraction of a second where all this is not a problem at all.
take care,
Gerd
7:17 a.m.
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"
> > will boot into macos, all without showing any UI at all. This
> > means
> > the boot menu can be hidden entirely during boot with a zero
> > timeout,
> > but you can still boot into a specific boot entry.
>
> That's actually awful, in my opinion,
Why? It's nice to have them and I can't see any downsides.
> and objectively undiscoverable..
Indeed. Would be nice to show these hotkeys somewhere. Extend the
help line which is shown when you press '?' for example.
> If you'd like to see how it should be done, boot a VM with GRUB2 as
> the bootloader. For a short period of time, you'll see a list of
> options, with the default option highlighted. If you don't pick
> something different, or don't need to enter a prompt to recover
> your
> device, it'll automatically boot.
Well, seems you have never actually used sd-boot ...
There actually isn't much of a difference between grub2 and systemd-
boot
here. Both can be configured to show or not show a menu. The menu
screen doesn't look fundamentally different either: List of boot
entries for the kernels installed, entry to boot into firmware setup,
default entry highlighted, a few seconds timeout with
countdown. Both
support editing boot entries.
Yes, unlike grub2 sd-boot has no command prompt. I have not missed
that
so far. The vast majority of cases where I've actually needed the
grub2
prompt have been grub2 install problems, like grub2 failing to find
its
config file for some reason. That is clearly not something I account
in
favor of grub2 ...
> GRUB2 is nice in that it's powerful enough for those that need it,
> but
> simple enough for those who don't want the complex features.
Well, alot of the complex grub features are dragged forward from the
BIOS world to the UEFI world and are somewhat awkward there.
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 last century.
With UEFI much more functionality is provided by the firmware and
there
is little reason for a bootloader to have tons of drivers. With the
exception of filesystem drivers in case you want boot from something
!=
vfat. But even that should ideally be implemented as uefi driver not
as
grub2 module.
If you insist on comparing bloat it will be grub2 which is bloated,
and it comes from being stuck in its own world and carrying its own
implementation for everything instead of using firmware services.
-rwxr-xr-x. 1 root root 93803 Jun 2 08:19 systemd-bootx64.efi
-rwx------. 1 root root 2513224 Jun 19 18:24 grubx64.efi
(binaries as shipped by fedora 32).
You're right, and that's yet another reason it's not a good idea to use
childish names as "systemd-bloat". I agree that grub2 is more bloated
and that it doesn't make sense to bring all the complexities of BIOS
boot to UEFI. However, the real question is, why does it matter? It's
only a boot loader. It does its job in a fraction of a second and then
it's all done, and the kernel takes it up from there. None of the
"bloated" bootloader code stays in memory. And wasting 2.5 MB instead
of 94 KB of disk space would only matter if we lived in the times when
hard drives were 10 MB or 20 MB :) It's true that the extra complexity
means it's more prone to bugs, but it has already been debugged fairly
well and does its job just fine, so what's the problem?
My real problem with grub2 is not that it's complex, but the fact that
it exposes its complexities to the user. I wish it had an "easy" mode,
where you could configure it easily for the common things that 99% of
the users would do, such as:
1. setting the boot menu timeout
2. choosing the default boot option - e.g. always Fedora, or always
Windows, or always a single entry, or, alternatively, as an option,
remember the last chosen option, and just repeat it, if the timeout
expires - this is invaluable when you dual boot Windows and have to
install Windows updates, because they are notorious for rebooting the
system several times, and you can't always sit in front the computer
for hours, so that you can catch the 5 seconds when the boot menu
appears, so you can choose Windows again. :)
3. changing the kernel boot options
4. adding passwords to certain menu entries
These are common things, that I'm reluctant to do, because I'm put off
by the complexities of grub2 configuration. I wish it had an easy mode
that just covers these common scenarios. I don't want to remove
features from it, I think it's great to have extra features for those
that want them, but I see no reason why simple things have to be
complicated also.
IMHO, all this talk about bloat is just distracting us from the real
issues, which is bootloader configuration difficulties.
I'm willing to try systemd-boot on a virtual machine, to see if it
makes things easier, but the fact it doesn't support BIOS makes it not
very usable for me. There are systems, where I can't use it, and there
are systems where I can use it, but I don't want to repartition and
reinstall both Windows 10 and Fedora, because they are dual boot
systems. And no, I wouldn't trust Microsoft's MBR to GPT upgrade tool
on a dual boot system. :)
Best regards,
Nikolay
7:51 a.m.
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 be as complex as the
grub2-mkconfig generated ones.
I'm willing to try systemd-boot on a virtual machine, to see if
it
makes things easier, but the fact it doesn't support BIOS makes it not
very usable for me.
https://www.kraxel.org/repos/images/fedora-31-efi-systemd-x86_64.qcow2.xz
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 ------------------------------
function load_video {
insmod all_video
}
insmod part_gpt
insmod fat
insmod serial
insmod terminal
insmod blscfg
serial --unit=0 --speed=115200
terminal_output console serial
terminal_input console serial
set boot='hd0,gpt2'
set timeout=3
blscfg
------------------------------ cut here ------------------------------
take care,
Gerd
10:43 a.m.
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 first place speaks volumes ...
But note that grub config files don't have to be as complex as the
grub2-mkconfig generated ones.
> I'm willing to try systemd-boot on a virtual machine, to see if it
> makes things easier, but the fact it doesn't support BIOS makes it
> not
> very usable for me.
https://www.kraxel.org/repos/images/fedora-31-efi-systemd-x86_64.qcow2.xz
Thanks! I downloaded the image and will check it out as soon as I find
some free time... :)
Best regards,
Nikolay
2:36 p.m.
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 ------------------------------
function load_video {
insmod all_video
}
insmod part_gpt
insmod fat
insmod serial
insmod terminal
insmod blscfg
serial --unit=0 --speed=115200
terminal_output console serial
terminal_input console serial
set boot='hd0,gpt2'
set timeout=3
blscfg
------------------------------ cut here ------------------------------
Does that actually include the drivers necessary to use your keyboard?
Somebody pointed out to me, in private, that the drivers for their keyboard
weren't loaded in the current Workstation GRUB2 config.
--
John M. Harris, Jr.
3:25 p.m.
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 ;)
>
> ------------------------------ cut here ------------------------------
> function load_video {
> insmod all_video
> }
>
> insmod part_gpt
> insmod fat
> insmod serial
> insmod terminal
> insmod blscfg
>
> serial --unit=0 --speed=115200
> terminal_output console serial
> terminal_input console serial
>
> set boot='hd0,gpt2'
> set timeout=3
> blscfg
> ------------------------------ cut here ------------------------------
Does that actually include the drivers necessary to use your keyboard?
Somebody pointed out to me, in private, that the drivers for their keyboard
weren't loaded in the current Workstation GRUB2 config.
UEFI grub uses the EFI provided keyboard drivers, if the keyboard
does not work in grub then that someone likely has "fastboot" enabled
in his BIOS and he has a BIOS which skips all USB device setup when
this is enabled.
UEFI firmware which supports some form of fastboot is supposed to delay
scanning the USB bus until we ask for input (and we currently always
ask for input) but many BIOS-es do not delay, but instead entirely skip,
scanning the USB bus when their fastboot or equivalent option is on.
Regards,
Hans
8:16 a.m.
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"
> > will boot into macos, all without showing any UI at all. This means
> > the boot menu can be hidden entirely during boot with a zero timeout,
> > but you can still boot into a specific boot entry.
>
> That's actually awful, in my opinion,
Why? It's nice to have them and I can't see any downsides.
I have lots of machines that fail to show the exact time boot happens
(external monitor still powering up or blanking out) and will
disable/ignore keys if you press too early.
You won't see this with laptops as they are integrated machines and
manufacturers pay a lot more attention to having a smooth display
experience, but with workstations or servers the boot time is not the
best experience ...
> and objectively undiscoverable..
Indeed. Would be nice to show these hotkeys somewhere. Extend the
help line which is shown when you press '?' for example.
> If you'd like to see how it should be done, boot a VM with GRUB2 as
> the bootloader. For a short period of time, you'll see a list of
> options, with the default option highlighted. If you don't pick
> something different, or don't need to enter a prompt to recover your
> device, it'll automatically boot.
Well, seems you have never actually used sd-boot ...
There actually isn't much of a difference between grub2 and systemd-boot
here. Both can be configured to show or not show a menu. The menu
screen doesn't look fundamentally different either: List of boot
entries for the kernels installed, entry to boot into firmware setup,
default entry highlighted, a few seconds timeout with countdown. Both
support editing boot entries.
Yes, unlike grub2 sd-boot has no command prompt. I have not missed that
so far. The vast majority of cases where I've actually needed the grub2
prompt have been grub2 install problems, like grub2 failing to find its
config file for some reason. That is clearly not something I account in
favor of grub2 ...
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 edit the command line has been a life
sacver.
It is kind of a must have feature to do development on kernels so you
can quickly change something w/o breaking your written down
configuration for good if you make a mistake.
Definitely not a fan of having to try a rescue disk, when you are 1000
miles from a server that you can access only via a remote console.
That said I do not love grub, but being able to change the boot line is
really a basic required feature for a developer OS.
> GRUB2 is nice in that it's powerful enough for those that
need it, but
> simple enough for those who don't want the complex features.
Well, alot of the complex grub features are dragged forward from the
BIOS world to the UEFI world and are somewhat awkward there.
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 last century.
With UEFI much more functionality is provided by the firmware and there
is little reason for a bootloader to have tons of drivers. With the
exception of filesystem drivers in case you want boot from something !=
vfat. But even that should ideally be implemented as uefi driver not as
grub2 module.
If you insist on comparing bloat it will be grub2 which is bloated,
and it comes from being stuck in its own world and carrying its own
implementation for everything instead of using firmware services.
-rwxr-xr-x. 1 root root 93803 Jun 2 08:19 systemd-bootx64.efi
-rwx------. 1 root root 2513224 Jun 19 18:24 grubx64.efi
(binaries as shipped by fedora 32).
take care,
Gerd
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
8:33 a.m.
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 edit the command line has been a life
sacver.
See above. sd-boot allows to edit the kernel command line too. Same
hotkey ('e') even. And unlike the 'l' and 'w' hotkeys that one
is
actually listed if you hit '?' or 'h'.
take care,
Gerd
8:45 a.m.
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 plenty of dracut reconfiguration/upgrade
> failures
> over the years and the ability to edit the command line has been a
> life
> sacver.
See above. sd-boot allows to edit the kernel command line too. Same
hotkey ('e') even. And unlike the 'l' and 'w' hotkeys that one
is
actually listed if you hit '?' or 'h'.
Given the mess boot input and display are on a lot of systems, any
keypress should pause the boot and display boot options (including
editing the boot CLI).
Otherwise you end up in keypress & display timing hell (not to mention
that non-qwerty users have the additional hurdle of guessing where keys
are mapped, which is why using anything except escape/space and
function keys will break hard in the field).
Regards,
--
Nicolas Mailhot
9:33 a.m.
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
one is
> actually listed if you hit '?' or 'h'.
Given the mess boot input and display are on a lot of systems, any
keypress should pause the boot and display boot options (including
editing the boot CLI).
Sure. All bootloaders I have seen in recent years (including sd-boot)
behave that way. Even if a key has no specific function attached
pressing it will at least stop the timeout countdown. So I'm not sure
why you are bringing that up and what you are trying to say ...
take care,
Gerd
9:48 a.m.
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. And unlike the 'l' and 'w' hotkeys
that one is
> > actually listed if you hit '?' or 'h'.
>
> Given the mess boot input and display are on a lot of systems, any
> keypress should pause the boot and display boot options (including
> editing the boot CLI).
Sure. All bootloaders I have seen in recent years (including sd-boot)
behave that way.
I was mostly reacting to
And unlike the 'l' and 'w' hotkeys that one is
actually listed if you
hit '?' or 'h'.
Regards,
--
Nicolas Mailhot
8:47 a.m.
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 reconfiguration/upgrade failures
> over the years and the ability to edit the command line has been a life
> sacver.
See above. sd-boot allows to edit the kernel command line too. Same
hotkey ('e') even. And unlike the 'l' and 'w' hotkeys that one
is
actually listed if you hit '?' or 'h'.
Ah this is good, sorry I must have misunderstood what you were saying.
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
10:20 a.m.
On Mi, 01.07.20 21:06, Neal Gompa (ngompa13(a)gmail.com) wrote:
The user-interactive portion of sd-boot is *awful*. I know our GRUB
looks ugly by default these days too, but it doesn't have to be, and
most distros actually do make it look semi-decent.
BTW, the current look of systemd-boot was proposed by some GNOME
designers back in the day. We just implemented what they wanted.
Lennart
--
Lennart Poettering, Berlin
10:24 a.m.
On Sat, Jul 4, 2020 at 11:20 AM Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Mi, 01.07.20 21:06, Neal Gompa (ngompa13(a)gmail.com) wrote:
> The user-interactive portion of sd-boot is *awful*. I know our GRUB
> looks ugly by default these days too, but it doesn't have to be, and
> most distros actually do make it look semi-decent.
BTW, the current look of systemd-boot was proposed by some GNOME
designers back in the day. We just implemented what they wanted.
Now I'm even less surprised. It was probably designed with the idea
that it would never be seen. If any designer people actually wanted to
make a good boot manager experience, they should take cues from
Windows, macOS, or even rEFInd.
--
真実はいつも一つ！/ Always, there's only one truth!
9:27 a.m.
On Sat, 4 Jul 2020 at 11:34, Neal Gompa <ngompa13(a)gmail.com> wrote:
On Sat, Jul 4, 2020 at 11:20 AM Lennart Poettering <mzerqung(a)0pointer.de> wrote:
>
> On Mi, 01.07.20 21:06, Neal Gompa (ngompa13(a)gmail.com) wrote:
>
> > The user-interactive portion of sd-boot is *awful*. I know our GRUB
> > looks ugly by default these days too, but it doesn't have to be, and
> > most distros actually do make it look semi-decent.
>
> BTW, the current look of systemd-boot was proposed by some GNOME
> designers back in the day. We just implemented what they wanted.
>
Now I'm even less surprised. It was probably designed with the idea
that it would never be seen. If any designer people actually wanted to
make a good boot manager experience, they should take cues from
Windows, macOS, or even rEFInd.
It was probably designed on that idea by people who don't spend as
much time staring at bootloaders as they do operating systems. For the
overwhelming majority of people using computers they are not going to
spend a lot of time making choices in a bootloader or things like
that. For system administrators and operating system developers.. that
is not the case. For most of the computers I manage, I never actually
log onto them UNLESS I am going to be dealing with the boot loader. So
of course the UI is going to be very important to me and I want it to
do a lot of things it probably shouldn't. Mainly because if I have
been called to deal with said computer, something has gone very wrong
and I am going to be trying to make it right.
There is a very different car from what a gear head will design from a
person who wants to enjoy driving their car. A gear head will want an
easy to fix car with very few things hard to get to. The problem is
that usually makes the vehicle noisy, uncomfortable and ugly. The
majority of car drivers want something where all those parts are
nicely hidden because they like a quiet smooth ride. The same is with
computers.. If we want to be able to work on the computers we want a
lot of places we can get into the deep internals and mess around. If
we want to use the computer day to day without needing to spend 10
years learning how to take it apart and put it together.. We want
something completely different. In the end, the vast majority of
people want things which are hidden away and just do the thing they
are supposed to do.. we computer grease monkeys just need to charge
more to work on them.
--
Stephen J Smoogen.
10:12 a.m.
On 5 July 2020 16:27:07 CEST, Stephen John Smoogen <smooge(a)gmail.com> wrote:
On Sat, 4 Jul 2020 at 11:34, Neal Gompa <ngompa13(a)gmail.com>
wrote:
>
> On Sat, Jul 4, 2020 at 11:20 AM Lennart Poettering <mzerqung(a)0pointer.de>
wrote:
> >
> > On Mi, 01.07.20 21:06, Neal Gompa (ngompa13(a)gmail.com) wrote:
> >
> > > The user-interactive portion of sd-boot is *awful*. I know our GRUB
> > > looks ugly by default these days too, but it doesn't have to be, and
> > > most distros actually do make it look semi-decent.
> >
> > BTW, the current look of systemd-boot was proposed by some GNOME
> > designers back in the day. We just implemented what they wanted.
> >
>
> Now I'm even less surprised. It was probably designed with the idea
> that it would never be seen. If any designer people actually wanted to
> make a good boot manager experience, they should take cues from
> Windows, macOS, or even rEFInd.
>
>
It was probably designed on that idea by people who don't spend as
much time staring at bootloaders as they do operating systems. For the
overwhelming majority of people using computers they are not going to
spend a lot of time making choices in a bootloader or things like
that. For system administrators and operating system developers.. that
is not the case. For most of the computers I manage, I never actually
log onto them UNLESS I am going to be dealing with the boot loader. So
of course the UI is going to be very important to me and I want it to
do a lot of things it probably shouldn't. Mainly because if I have
been called to deal with said computer, something has gone very wrong
and I am going to be trying to make it right.
I have no problem with GRUB2 or sd-boot. I have much more problems with refind and their
ilk. While things can look pretty, that's fine, as soon as it gets in my way when I
try to get things done it stops being fine.
There is a very different car from what a gear head will design from a
person who wants to enjoy driving their car. A gear head will want an
easy to fix car with very few things hard to get to. The problem is
that usually makes the vehicle noisy, uncomfortable and ugly. The
majority of car drivers want something where all those parts are
nicely hidden because they like a quiet smooth ride. The same is with
computers.. If we want to be able to work on the computers we want a
lot of places we can get into the deep internals and mess around. If
we want to use the computer day to day without needing to spend 10
years learning how to take it apart and put it together.. We want
something completely different. In the end, the vast majority of
people want things which are hidden away and just do the thing they
are supposed to do.. we computer grease monkeys just need to charge
more to work on them.
There's no reason there can't be a glossy front hiding what techs really wants.
Just look at the bootsplash. Looks pretty but just push a button and you will get actual
useful data instead, everybody wins.
That said, I don't think you are wrong per se. I just think there can we can coexist
with the help of smart solutions.
As I said earlier, I have no problems with sd-boot or the looks of it (it seems that is
what we are discussing now). I see no real problems with using it as default for EFI
systems. That's just an opinion though. It does what it does and shows what is
needed.
As for keeping BIOS, yes of course but that seems settled 100 mails ago :)
I generally argue that I want Fedora to run on as much different things as possible and
devices and motherboards with defective UEFI or no UEFI will be here for a while.
M
>
>
11:33 a.m.
On Sun, 5 Jul 2020 at 11:23, Markus Larsson <qrsbrwn(a)uidzero.se> wrote:
On 5 July 2020 16:27:07 CEST, Stephen John Smoogen <smooge(a)gmail.com> wrote:
>On Sat, 4 Jul 2020 at 11:34, Neal Gompa <ngompa13(a)gmail.com> wrote:
>>
>> On Sat, Jul 4, 2020 at 11:20 AM Lennart Poettering <mzerqung(a)0pointer.de>
wrote:
>> >
>> > On Mi, 01.07.20 21:06, Neal Gompa (ngompa13(a)gmail.com) wrote:
>> >
>
>There is a very different car from what a gear head will design from a
>person who wants to enjoy driving their car. A gear head will want an
>easy to fix car with very few things hard to get to. The problem is
>that usually makes the vehicle noisy, uncomfortable and ugly. The
>majority of car drivers want something where all those parts are
>nicely hidden because they like a quiet smooth ride. The same is with
>computers.. If we want to be able to work on the computers we want a
>lot of places we can get into the deep internals and mess around. If
>we want to use the computer day to day without needing to spend 10
>years learning how to take it apart and put it together.. We want
>something completely different. In the end, the vast majority of
>people want things which are hidden away and just do the thing they
>are supposed to do.. we computer grease monkeys just need to charge
>more to work on them.
There's no reason there can't be a glossy front hiding what techs really wants.
Just look at the bootsplash. Looks pretty but just push a button and you will get actual
useful data instead, everybody wins.
That said, I don't think you are wrong per se. I just think there can we can coexist
with the help of smart solutions.
Usually the only time I deal with the bootsplash is when the system is
broken in a way that hitting a key won't remove it... so I end up
removing rhgb/quiet and other things. The fact that I can do that is
all I care about.. I get grumpy when proposals want to make that
impossible to be done for whatever reasons. Especially since I will
somehow have to fix it when it breaks but have to get an arc welder to
cut open parts first.
That said, I am not against sd-boot, btrfs, nano or a bunch of other
changes which seem to have gotten every 'stop the change' advocate out
there. I understand a little of where they are coming from... fixing
things are hard enough at times. I also understand what it is like to
be overloaded with everything going on these days and just want things
to stop for a bit. The problem is that doesn't happen, and it
definitely doesn't happen in Fedora. If people need a slower or
stopped OS, there is CentOS or Debian Stable. Fedora isn't as bleeding
edge as other Linux distributions... but it is constantly moving and
it is always going to be a bumpy road.
As I said earlier, I have no problems with sd-boot or the looks of it
(it seems that is what we are discussing now). I see no real problems with using it as
default for EFI systems. That's just an opinion though. It does what it does and shows
what is needed.
As for keeping BIOS, yes of course but that seems settled 100 mails ago :)
I generally argue that I want Fedora to run on as much different things as possible and
devices and motherboards with defective UEFI or no UEFI will be here for a while.
M
>
>
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Stephen J Smoogen.
12:39 p.m.
On Sunday, July 5, 2020 8:12:33 AM MST Markus Larsson wrote:
I have no problem with GRUB2 or sd-boot. I have much more problems
with
refind and their ilk. While things can look pretty, that's fine, as soon as
it gets in my way when I try to get things done it stops being fine.
I don't think there's anything visually wrong with systemd-boot, so long as
it's showing a menu like gummiboot did.
As I said earlier, I have no problems with sd-boot or the looks of it
(it
seems that is what we are discussing now). I see no real problems with
using it as default for EFI systems. That's just an opinion though. It does
what it does and shows what is needed.
Actually, it doesn't do enough to be able to actually boot Fedora systems.
Please note that full disk encryption is a supported scenario in Fedora, as is
encrypted /boot or /boot on Btrfs. systemd-boot is not capable of getting
bootloader configuration files in this case, so your system will never boot.
As for making it the default, I can't see any reason to do that. Standardizing
on the best bootloader seems like the safe bet, i.e. use GRUB2 everywhere
possible, and support boot from u-boot, zipl, petitboot, etc. where it's not
available.
--
John M. Harris, Jr.
6:41 a.m.
Hi,
I have no problem with GRUB2 or sd-boot. I have much more problems
with refind and their ilk. While things can look pretty, that's fine,
as soon as it gets in my way when I try to get things done it stops
being fine.
"getting into the way" IMO includes "doesn't show up on the serial
console".
Both sd-boot and grub2 are doing fine here, the standard uefi text
console works on both vga and serial line. Anything doing something
fancy on the framebuffer is problematic here ...
take care,
Gerd
PS: yes, you can configure grub2 to do fancy graphics, but fedora
doesn't do that by default.
7:53 p.m.
On 1.7.2020 23:18, Björn Persson wrote:
Jóhann B. Guðmundsson wrote:
> More user friendly than Grub ( has lilo like interface easier to change
> kernel entry, which goes nicely with the default editor change )
This made me go "What?!". I used Lilo back in the day. Its user
interface was nothing but a prompt. You had to know what to type or
you'd be stuck.
Information for others like me who haven't seen Lilo since Grub came
along: Apparently development of Lilo continued until just five years
ago, and it grew a menu at some point. I guess that menu is the image
of user-friendliness that Johann was trying to invoke.
What I was referring to was that systemd uses split configuration text
files which can easily be copy or edited like lilo.conf was but OK.
JBG
2:22 p.m.
Jóhann B. Guðmundsson <johannbg(a)gmail.com> writes:
On 30.6.2020 17:49, John M. Harris Jr wrote:
> On Tuesday, June 30, 2020 6:34:27 AM MST 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 supported boot which
>> has been available on any common intel based x86 platform since atleast
>> 2005.
> This is simply false. I'm currently writing this email on a ThinkPad X200
> Tablet, which does not support UEFI. I can get dropping x86 support, but
> dropping BIOS boot support?
>
Such proposal would never be about stop supporting older hardware that's
just a misconception people are getting
And it's quite evident by the response here that hw that is atleast 2010
and older is still quite happily being used and that hw does not support
UEFI and no one is talking about taking that away anytime soon.
The first step ( The actual change proposal ) would simply be about
replace grub2 with sd-boot for UEFI strictly on the x86 architecture
which has UEFI available and enabled ( is not using legacy bios ) and
see what issue are encountered, solve those then consider moving to
different architectures and further integration if relevant etc. (
baby steps ) Next I would suggest looking at UEFI supported ARM
systems ( but I personally would have to obtain such hardware before
doing so ).
But... why? It's not like grub2 doesn't work for booting UEFI. Doesn't
seem like there's a point in running through all the issues that grub2
already solved again.
Thanks,
--Robbie
3:32 p.m.
On 30.6.2020 19:22, Robbie Harwood wrote:
Jóhann B. Guðmundsson <johannbg(a)gmail.com> writes:
> On 30.6.2020 17:49, John M. Harris Jr wrote:
>> On Tuesday, June 30, 2020 6:34:27 AM MST 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 supported boot which
>>> has been available on any common intel based x86 platform since atleast
>>> 2005.
>> This is simply false. I'm currently writing this email on a ThinkPad X200
>> Tablet, which does not support UEFI. I can get dropping x86 support, but
>> dropping BIOS boot support?
>>
> Such proposal would never be about stop supporting older hardware that's
> just a misconception people are getting
>
> And it's quite evident by the response here that hw that is atleast 2010
> and older is still quite happily being used and that hw does not support
> UEFI and no one is talking about taking that away anytime soon.
>
> The first step ( The actual change proposal ) would simply be about
> replace grub2 with sd-boot for UEFI strictly on the x86 architecture
> which has UEFI available and enabled ( is not using legacy bios ) and
> see what issue are encountered, solve those then consider moving to
> different architectures and further integration if relevant etc. (
> baby steps ) Next I would suggest looking at UEFI supported ARM
> systems ( but I personally would have to obtain such hardware before
> doing so ).
But... why? It's not like grub2 doesn't work for booting UEFI. Doesn't
seem like there's a point in running through all the issues that grub2
already solved again.
I think we put different meaning in maintainance,usability and issues if
you think grub solves anything but I mentioned this elsewhere in the
thread and justification/selling points usually end up on the change
proposals but I'll repeat it here ;)
sd-boot is already installed on end users system, is light weight
compared to Grub ( sd-boot only supports uefi,smaller code size, easier
to maintain ).
It already integrates with the service management framework (systemd).
More user friendly than Grub ( has lilo like interface easier to change
kernel entry, which goes nicely with the default editor change )
Gnome related changes such as Hans is proposing might be easier to
integrate for the desktop team ( less work, problem being fixed where it
arguably should be as opposed to systemd,grub and gnome for his feature
to work and more future proof work for the desktop team).
Could help further adapt UEFI and secure boot which the industry is
moving towards which helps keep Fedora moving along with it.
If correctly implemented ( baby steps and without excluding anyone)
should be a win win for Fedora, developers and end users alike.
Grub discourages users who have tried sd-boot from coming/returning to
Fedora [1].
Bottom line I think this will be a good move for the distribution and a
good time to start looking into and make that move.
JBG
1. https://www.reddit.com/r/Fedora/comments/c0f3z5/systemdboot/
4:14 p.m.
On Tue, 2020-06-30 at 20:32 +0000, Jóhann B. Guðmundsson wrote:
Grub discourages users who have tried sd-boot from coming/returning
to
Fedora [1].
Bottom line I think this will be a good move for the distribution and
a
good time to start looking into and make that move.
JBG
1. https://www.reddit.com/r/Fedora/comments/c0f3z5/systemdboot/
I read the whole reddit link, but I couldn't understand what's wrong
with grub. The poster admits to having an obsession with keeping the
number of packages to a minimum (I don't know what that has to do with
grub), and doesn't like grub for some unexplained reason. Note that I
have never used sd-boot. So far, I've used LILO (starting with Red Hat
Linux 5.0), grub1 and grub2. These days, I don't even notice the boot
loader. This means it's doing its job properly. :)
Maybe I should try sd-boot in a UEFI VM and see for myself, but can
someone explain what's the difference?
I have one system where I run Fedora Server in UEFI mode and I haven't
ever had the need to mess with the bootloader. It just shows its menu
for 5 seconds and that's all that it does. I don't understand how can
something like that discourage a user from using Fedora? :)
Best regards,
Nikolay
4:55 p.m.
On 30.6.2020 21:14, nickysn(a)gmail.com wrote:
On Tue, 2020-06-30 at 20:32 +0000, Jóhann B. Guðmundsson wrote:
>
> Grub discourages users who have tried sd-boot from coming/returning
> to
> Fedora [1].
>
> Bottom line I think this will be a good move for the distribution and
> a
> good time to start looking into and make that move.
>
> JBG
>
> 1. https://www.reddit.com/r/Fedora/comments/c0f3z5/systemdboot/
I read the whole reddit link, but I couldn't understand what's wrong
with grub. The poster admits to having an obsession with keeping the
number of packages to a minimum (I don't know what that has to do with
grub), and doesn't like grub for some unexplained reason. Note that I
have never used sd-boot. So far, I've used LILO (starting with Red Hat
Linux 5.0), grub1 and grub2. These days, I don't even notice the boot
loader. This means it's doing its job properly. :)
Maybe I should try sd-boot in a UEFI VM and see for myself, but can
someone explain what's the difference?
I have one system where I run Fedora Server in UEFI mode and I haven't
ever had the need to mess with the bootloader. It just shows its menu
for 5 seconds and that's all that it does. I don't understand how can
something like that discourage a user from using Fedora? :)
Given that you have not changed an entry in your boot loader for quite
sometime or perhaps ever it would actually be better that you yourself
setup Fedora using sd-boot as the boot manager and compare changing an
configuration entry in sd-boot with doing the exact same thing in Grub2
and share your feedback and experience of doing so with the rest of the
community rather then someone provide you with an answer.
Thanks
JBG
5:31 p.m.
On Tue, 2020-06-30 at 21:55 +0000, Jóhann B. Guðmundsson wrote:
On 30.6.2020 21:14, nickysn(a)gmail.com wrote:
> On Tue, 2020-06-30 at 20:32 +0000, Jóhann B. Guðmundsson wrote:
> > Grub discourages users who have tried sd-boot from
> > coming/returning
> > to
> > Fedora [1].
> >
> > Bottom line I think this will be a good move for the distribution
> > and
> > a
> > good time to start looking into and make that move.
> >
> > JBG
> >
> > 1. https://www.reddit.com/r/Fedora/comments/c0f3z5/systemdboot/
> I read the whole reddit link, but I couldn't understand what's
> wrong
> with grub. The poster admits to having an obsession with keeping
> the
> number of packages to a minimum (I don't know what that has to do
> with
> grub), and doesn't like grub for some unexplained reason. Note that
> I
> have never used sd-boot. So far, I've used LILO (starting with Red
> Hat
> Linux 5.0), grub1 and grub2. These days, I don't even notice the
> boot
> loader. This means it's doing its job properly. :)
>
> Maybe I should try sd-boot in a UEFI VM and see for myself, but can
> someone explain what's the difference?
>
> I have one system where I run Fedora Server in UEFI mode and I
> haven't
> ever had the need to mess with the bootloader. It just shows its
> menu
> for 5 seconds and that's all that it does. I don't understand how
> can
> something like that discourage a user from using Fedora? :)
Given that you have not changed an entry in your boot loader for
quite
sometime or perhaps ever it would actually be better that you
yourself
setup Fedora using sd-boot as the boot manager and compare changing
an
configuration entry in sd-boot with doing the exact same thing in
Grub2
and share your feedback and experience of doing so with the rest of
the
community rather then someone provide you with an answer.
I would try it, but I don't know how, since Fedora uses GRUB2. Should I
install ArchLinux in a VM or is there a way to try it with Fedora? Is
there any documentation for how to install it and how to use it?
Best regards,
Nikolay
5:40 p.m.
On 30.6.2020 22:31, nickysn(a)gmail.com wrote:
On Tue, 2020-06-30 at 21:55 +0000, Jóhann B. Guðmundsson wrote:
> On 30.6.2020 21:14, nickysn(a)gmail.com wrote:
>> On Tue, 2020-06-30 at 20:32 +0000, Jóhann B. Guðmundsson wrote:
>>> Grub discourages users who have tried sd-boot from
>>> coming/returning
>>> to
>>> Fedora [1].
>>>
>>> Bottom line I think this will be a good move for the distribution
>>> and
>>> a
>>> good time to start looking into and make that move.
>>>
>>> JBG
>>>
>>> 1. https://www.reddit.com/r/Fedora/comments/c0f3z5/systemdboot/
>> I read the whole reddit link, but I couldn't understand what's
>> wrong
>> with grub. The poster admits to having an obsession with keeping
>> the
>> number of packages to a minimum (I don't know what that has to do
>> with
>> grub), and doesn't like grub for some unexplained reason. Note that
>> I
>> have never used sd-boot. So far, I've used LILO (starting with Red
>> Hat
>> Linux 5.0), grub1 and grub2. These days, I don't even notice the
>> boot
>> loader. This means it's doing its job properly. :)
>>
>> Maybe I should try sd-boot in a UEFI VM and see for myself, but can
>> someone explain what's the difference?
>>
>> I have one system where I run Fedora Server in UEFI mode and I
>> haven't
>> ever had the need to mess with the bootloader. It just shows its
>> menu
>> for 5 seconds and that's all that it does. I don't understand how
>> can
>> something like that discourage a user from using Fedora? :)
> Given that you have not changed an entry in your boot loader for
> quite
> sometime or perhaps ever it would actually be better that you
> yourself
> setup Fedora using sd-boot as the boot manager and compare changing
> an
> configuration entry in sd-boot with doing the exact same thing in
> Grub2
> and share your feedback and experience of doing so with the rest of
> the
> community rather then someone provide you with an answer.
I would try it, but I don't know how, since Fedora uses GRUB2. Should I
install ArchLinux in a VM or is there a way to try it with Fedora? Is
there any documentation for how to install it and how to use it?
Good point
I was not planning on doing that until I had some feedback on how big of
scope this could turn out to be but I see if I cant setup a minimal test
image you can build locally with mkosi and write some documentation.
It's almost 23:00 here so it wont be until tomorrow.
JBG
2:33 a.m.
On Tuesday, June 30, 2020 2:55:42 PM MST Jóhann B. Guðmundsson wrote:
On 30.6.2020 21:14, nickysn(a)gmail.com wrote:
> On Tue, 2020-06-30 at 20:32 +0000, Jóhann B. Guðmundsson wrote:
>
>>
>>
>> Grub discourages users who have tried sd-boot from coming/returning
>> to
>> Fedora [1].
>>
>>
>>
>> Bottom line I think this will be a good move for the distribution and
>> a
>> good time to start looking into and make that move.
>>
>>
>>
>> JBG
>>
>>
>>
>> 1. https://www.reddit.com/r/Fedora/comments/c0f3z5/systemdboot/
>
> I read the whole reddit link, but I couldn't understand what's wrong
> with grub. The poster admits to having an obsession with keeping the
> number of packages to a minimum (I don't know what that has to do with
> grub), and doesn't like grub for some unexplained reason. Note that I
> have never used sd-boot. So far, I've used LILO (starting with Red Hat
> Linux 5.0), grub1 and grub2. These days, I don't even notice the boot
> loader. This means it's doing its job properly. :)
>
>
>
> Maybe I should try sd-boot in a UEFI VM and see for myself, but can
> someone explain what's the difference?
>
>
>
> I have one system where I run Fedora Server in UEFI mode and I haven't
> ever had the need to mess with the bootloader. It just shows its menu
> for 5 seconds and that's all that it does. I don't understand how can
> something like that discourage a user from using Fedora? :)
Given that you have not changed an entry in your boot loader for quite
sometime or perhaps ever it would actually be better that you yourself
setup Fedora using sd-boot as the boot manager and compare changing an
configuration entry in sd-boot with doing the exact same thing in Grub2
and share your feedback and experience of doing so with the rest of the
community rather then someone provide you with an answer.
It's really simple with GRUB. You just alter /etc/default/grub, and then
rebuild your config. With systemd-bloat, you do.. what?
--
John M. Harris, Jr.
7:45 a.m.
Hi,
On 6/30/20 8:29 PM, Jóhann B. Guðmundsson wrote:
On 30.6.2020 17:49, John M. Harris Jr wrote:
> On Tuesday, June 30, 2020 6:34:27 AM MST 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 supported boot which
>> has been available on any common intel based x86 platform since atleast
>> 2005.
> This is simply false. I'm currently writing this email on a ThinkPad X200
> Tablet, which does not support UEFI. I can get dropping x86 support, but
> dropping BIOS boot support?
>
Such proposal would never be about stop supporting older hardware that's just a
misconception people are getting
And it's quite evident by the response here that hw that is atleast 2010 and older is
still quite happily being used and that hw does not support UEFI and no one is talking
about taking that away anytime soon.
The first step ( The actual change proposal ) would simply be about replace grub2 with
sd-boot for UEFI strictly on the x86 architecture which has UEFI available and enabled (
is not using legacy bios ) and see what issue are encountered, solve those then consider
moving to different architectures and further integration if relevant etc. ( baby steps )
Next I would suggest looking at UEFI supported ARM systems ( but I personally would have
to obtain such hardware before doing so ).
So instead of replacing grub2 you are suggesting adding sd-boot to the
list of supported boot-loaders and using it as the default bootloader
on x86_64 UEFI installs, correct ?
I'm not in the bootloader-team, but I do work very closely with them,
so I have only one question: who is going to pick up the extra
maintenance load this is going to cause ?
Note this might sound like me being a bit snarky, but that is not
my intention here. This is a serious question and without a good
answer to that question I believe that any proposal to add sd-boot
to the list of supported bootloaders is pretty much dead in the
water.
Also note that this entails a lot more work then just maintaining sd-boot,
anaconda will need to be adjusted, kernel-install scripts will need to
be adjusted, etc. And what about upgrades, if upgrades stick with using grub2
then now we have 3 bootloader configs, including things like documentation on
how to change kernel commandline options, to maintain instead of 2.
Also I wonder, if you are not proposing to completely drop grub2 on x86_64
what does offering sd-boot in addition to grub2 actually offer as advantages?
sd-boot is simpler and a bit tighter integrated with systemd, which would
mean it is less work to maintain if we use it instead of grub, but if we
use it next to grub then all those advantages fall away. IOW if we use
it next to grub then all I see is a whole lot of extra work, with very
little gain.
AFAIK this (lot of extra work, very little gain) is exactly why we have
been sticking with grub2 so far. We need to maintain it anyway, at which
point we want to use it in as much cases as possible so that we can have
unified code and documentation for dealing with the bootloader.
Regards,
Hans
9:30 a.m.
On Mi, 01.07.20 14:45, Hans de Goede (hdegoede(a)redhat.com) wrote:
I'm not in the bootloader-team, but I do work very closely with
them,
so I have only one question: who is going to pick up the extra
maintenance load this is going to cause ?
There are distros already using it. And so far we have been pretty OK
with supporting it upstream and downstream. At least upstream I am not
aware of any big issues left open.
Note that sd-boot is a lot simpler than grub, i.e. it doesn't contain
Turing complete programming languages, module loaders, file system
drivers, storage stacks and such. There's simply not that much to
maintain!
Also note that this entails a lot more work then just maintaining
sd-boot,
anaconda will need to be adjusted, kernel-install scripts will need to
be adjusted, etc.
kernel-install itself is actually maintained in the same repo as
sd-boot: systemd upstream. They are developed along the same lines
already.
Also I wonder, if you are not proposing to completely drop grub2 on
x86_64 what does offering sd-boot in addition to grub2 actually
offer as advantages?
Primarily simplicity, and that it implements the boot loader spec
correctly.
it automatically discovers windows and Macos installations at each
boot, without any userspace involvement. You can talk to it very
nicely, i.e. implement trivially "boot-into-windows" buttons and such
in GNOME and so on. It makes things very robust, since you don't need
a script that generates a script that generates a script (yeah, that's
how grub is hooked up). it just works on its own. You drop in boot
menu items, and that's it. You don't need to regenerate stuff, and you
never have to run an interpretor for a turing complete language.
By using sd-boot, you can do stuff like "systemctl reboot
--boot-loader-entry=windows", you can do "systemctl reboot
--boot-loader-menu=0", you can do "systemctl kexec" and it boots the
right thing, and so on.
It also implements boot time assessement that is simple and just works
(i.e. automatic revert to previous boot menu choice when the one
selected doesn't work).
Oh, and it as support for seeding the Linux random seed pre-boot
already, in a safe and simple fashion.
Moreover, it communicates which ESP is used to the host OS, so that
the host can automatically discover what other partitions to mount.
And the list goes on and on and on.
All these features are very simple individually, but put together they
are just a much nicer and expose a much more integrated behaviour
than Grub ever did.
sd-boot is simpler and a bit tighter integrated with systemd, which
would
mean it is less work to maintain if we use it instead of grub, but if we
use it next to grub then all those advantages fall away. IOW if we use
it next to grub then all I see is a whole lot of extra work, with very
little gain.
Well, you appear to believe in the race to the bottom, i.e. that the
lowest common denominator should be where the future is. I am pretty
sure it's the wrong approach: pick the simple contender that can do
all the nice things, and has the nice integration, and use it as a
blueprint for the other archs where Grub is still needed, and make
them catch up.
I mean, I understand you are interested in exotic platforms that lack
modern things like UEFI, but it kinda sucks to hold the boot loader
hostage due to that, and just stick to the terrible ways of yesteryear
because of it.
AFAIK this (lot of extra work, very little gain) is exactly why we
have
been sticking with grub2 so far. We need to maintain it anyway, at which
point we want to use it in as much cases as possible so that we can have
unified code and documentation for dealing with the bootloader.
I don't see "very little gain". I see a lot of gain, and all while
things become simpler. Much simpler.
Lennart
--
Lennart Poettering, Berlin
11:55 a.m.
On Wed, 2020-07-01 at 16:30 +0200, Lennart Poettering wrote:
On Mi, 01.07.20 14:45, Hans de Goede (hdegoede(a)redhat.com) wrote:
> I'm not in the bootloader-team, but I do work very closely with
> them,
> so I have only one question: who is going to pick up the extra
> maintenance load this is going to cause ?
There are distros already using it. And so far we have been pretty OK
with supporting it upstream and downstream. At least upstream I am
not
aware of any big issues left open.
Note that sd-boot is a lot simpler than grub, i.e. it doesn't contain
Turing complete programming languages, module loaders, file system
drivers, storage stacks and such. There's simply not that much to
maintain!
> Also note that this entails a lot more work then just maintaining
> sd-boot,
> anaconda will need to be adjusted, kernel-install scripts will need
> to
> be adjusted, etc.
kernel-install itself is actually maintained in the same repo as
sd-boot: systemd upstream. They are developed along the same lines
already.
> Also I wonder, if you are not proposing to completely drop grub2 on
> x86_64 what does offering sd-boot in addition to grub2 actually
> offer as advantages?
Primarily simplicity, and that it implements the boot loader spec
correctly.
it automatically discovers windows and Macos installations at each
boot, without any userspace involvement. You can talk to it very
nicely, i.e. implement trivially "boot-into-windows" buttons and such
in GNOME and so on. It makes things very robust, since you don't need
a script that generates a script that generates a script (yeah,
that's
how grub is hooked up). it just works on its own. You drop in boot
menu items, and that's it. You don't need to regenerate stuff, and
you
never have to run an interpretor for a turing complete language.
By using sd-boot, you can do stuff like "systemctl reboot
--boot-loader-entry=windows", you can do "systemctl reboot
--boot-loader-menu=0", you can do "systemctl kexec" and it boots the
right thing, and so on.
It also implements boot time assessement that is simple and just
works
(i.e. automatic revert to previous boot menu choice when the one
selected doesn't work).
Oh, and it as support for seeding the Linux random seed pre-boot
already, in a safe and simple fashion.
Moreover, it communicates which ESP is used to the host OS, so that
the host can automatically discover what other partitions to mount.
And the list goes on and on and on.
All these features are very simple individually, but put together
they
are just a much nicer and expose a much more integrated behaviour
than Grub ever did.
> sd-boot is simpler and a bit tighter integrated with systemd, which
> would
> mean it is less work to maintain if we use it instead of grub, but
> if we
> use it next to grub then all those advantages fall away. IOW if we
> use
> it next to grub then all I see is a whole lot of extra work, with
> very
> little gain.
Well, you appear to believe in the race to the bottom, i.e. that the
lowest common denominator should be where the future is. I am pretty
sure it's the wrong approach: pick the simple contender that can do
all the nice things, and has the nice integration, and use it as a
blueprint for the other archs where Grub is still needed, and make
them catch up.
I mean, I understand you are interested in exotic platforms that lack
modern things like UEFI, but it kinda sucks to hold the boot loader
hostage due to that, and just stick to the terrible ways of
yesteryear
because of it.
Note that this is not only about exotic platforms. I can give you
examples with:
1. My 2019 HP laptop with an AMD Ryzen CPU. Purchased without Windows,
so it came with FreeDOS preinstalled. Obviously, FreeDOS only runs in
legacy mode. I just booted from an USB flash drive and installed Fedora
on it, without changing the BIOS settings.
2. A 2017 Dell laptop, purchased also without Windows. Came with Ubuntu
preinstalled, also in legacy mode. I installed Fedora on it, also
without changing the BIOS settings.
It's not unrealistic to expect that a lot of people would buy laptops
such as these, if they specifically want to run Linux. And it's not
unrealistic to expect many users to just install Fedora without
changing any BIOS settings, related to legacy vs UEFI boot mode. In
fact, most users wouldn't probably know anything about these settings.
Both of these computers are very far away from being considered legacy
or exotic. They can be switched to UEFI mode, but that requires
repartitioning and an OS reinstall (and that gets very complicated when
you consider multiboot scenarios with Windows 10 as well). Upgrading
these systems without reinstall is possible, but *very* difficult and
can't be automated, because, even if in the single OS scenario, it
requires the user to change the BIOS settings to disable legacy boot.
Note that I don't disagree with the general idea of simplifying
bootloader configuration. But it's not at all realistic to drop legacy
BIOS support anytime soon, and it isn't about legacy and exotic
systems.
Best regards,
Nikolay
12:55 a.m.
On Wednesday, July 1, 2020 7:30:37 AM MST Lennart Poettering wrote:
On Mi, 01.07.20 14:45, Hans de Goede (hdegoede(a)redhat.com) wrote:
> I'm not in the bootloader-team, but I do work very closely with them,
> so I have only one question: who is going to pick up the extra
> maintenance load this is going to cause ?
There are distros already using it. And so far we have been pretty OK
with supporting it upstream and downstream. At least upstream I am not
aware of any big issues left open.
Note that sd-boot is a lot simpler than grub, i.e. it doesn't contain
Turing complete programming languages, module loaders, file system
drivers, storage stacks and such. There's simply not that much to
maintain!
> Also note that this entails a lot more work then just maintaining
> sd-boot,
> anaconda will need to be adjusted, kernel-install scripts will need to
> be adjusted, etc.
kernel-install itself is actually maintained in the same repo as
sd-boot: systemd upstream. They are developed along the same lines
already.
> Also I wonder, if you are not proposing to completely drop grub2 on
> x86_64 what does offering sd-boot in addition to grub2 actually
> offer as advantages?
Primarily simplicity, and that it implements the boot loader spec
correctly.
it automatically discovers windows and Macos installations at each
boot, without any userspace involvement. You can talk to it very
nicely, i.e. implement trivially "boot-into-windows" buttons and such
in GNOME and so on. It makes things very robust, since you don't need
a script that generates a script that generates a script (yeah, that's
how grub is hooked up). it just works on its own. You drop in boot
menu items, and that's it. You don't need to regenerate stuff, and you
never have to run an interpretor for a turing complete language.
By using sd-boot, you can do stuff like "systemctl reboot
--boot-loader-entry=windows", you can do "systemctl reboot
--boot-loader-menu=0", you can do "systemctl kexec" and it boots the
right thing, and so on.
It also implements boot time assessement that is simple and just works
(i.e. automatic revert to previous boot menu choice when the one
selected doesn't work).
Oh, and it as support for seeding the Linux random seed pre-boot
already, in a safe and simple fashion.
Moreover, it communicates which ESP is used to the host OS, so that
the host can automatically discover what other partitions to mount.
And the list goes on and on and on.
All these features are very simple individually, but put together they
are just a much nicer and expose a much more integrated behaviour
than Grub ever did.
> sd-boot is simpler and a bit tighter integrated with systemd, which would
> mean it is less work to maintain if we use it instead of grub, but if we
> use it next to grub then all those advantages fall away. IOW if we use
> it next to grub then all I see is a whole lot of extra work, with very
> little gain.
Well, you appear to believe in the race to the bottom, i.e. that the
lowest common denominator should be where the future is. I am pretty
sure it's the wrong approach: pick the simple contender that can do
all the nice things, and has the nice integration, and use it as a
blueprint for the other archs where Grub is still needed, and make
them catch up.
I mean, I understand you are interested in exotic platforms that lack
modern things like UEFI, but it kinda sucks to hold the boot loader
hostage due to that, and just stick to the terrible ways of yesteryear
because of it.
> AFAIK this (lot of extra work, very little gain) is exactly why we have
> been sticking with grub2 so far. We need to maintain it anyway, at which
> point we want to use it in as much cases as possible so that we can have
> unified code and documentation for dealing with the bootloader.
I don't see "very little gain". I see a lot of gain, and all while
things become simpler. Much simpler.
Lennart
--
Lennart Poettering, Berlin
Lennart,
We don't need more systemd-bloat just to boot our systems. However your
bootloader works, it doesn't really matter if it's not up to snuff with GRUB2.
When it supports LUKS, LVM, LUKS+LVM, a recovery console and several
filesystems, then it'll be more of a viable option, and I still wouldn't
recommend having yet another systemd component as a core part of our systems.
At what point is systemd large enough that you'll stop adding more cruft?
--
John M. Harris, Jr.
6 a.m.
On Thu, Jul 2, 2020 at 1:55 AM John M. Harris Jr <johnmh(a)splentity.com> wrote:
On Wednesday, July 1, 2020 7:30:37 AM MST Lennart Poettering wrote:
> On Mi, 01.07.20 14:45, Hans de Goede (hdegoede(a)redhat.com) wrote:
>
>
> > I'm not in the bootloader-team, but I do work very closely with them,
> > so I have only one question: who is going to pick up the extra
> > maintenance load this is going to cause ?
>
>
> There are distros already using it. And so far we have been pretty OK
> with supporting it upstream and downstream. At least upstream I am not
> aware of any big issues left open.
>
> Note that sd-boot is a lot simpler than grub, i.e. it doesn't contain
> Turing complete programming languages, module loaders, file system
> drivers, storage stacks and such. There's simply not that much to
> maintain!
>
>
> > Also note that this entails a lot more work then just maintaining
> > sd-boot,
> > anaconda will need to be adjusted, kernel-install scripts will need to
> > be adjusted, etc.
>
>
> kernel-install itself is actually maintained in the same repo as
> sd-boot: systemd upstream. They are developed along the same lines
> already.
>
>
> > Also I wonder, if you are not proposing to completely drop grub2 on
> > x86_64 what does offering sd-boot in addition to grub2 actually
> > offer as advantages?
>
>
> Primarily simplicity, and that it implements the boot loader spec
> correctly.
>
> it automatically discovers windows and Macos installations at each
> boot, without any userspace involvement. You can talk to it very
> nicely, i.e. implement trivially "boot-into-windows" buttons and such
> in GNOME and so on. It makes things very robust, since you don't need
> a script that generates a script that generates a script (yeah, that's
> how grub is hooked up). it just works on its own. You drop in boot
> menu items, and that's it. You don't need to regenerate stuff, and you
> never have to run an interpretor for a turing complete language.
>
> By using sd-boot, you can do stuff like "systemctl reboot
> --boot-loader-entry=windows", you can do "systemctl reboot
> --boot-loader-menu=0", you can do "systemctl kexec" and it boots the
> right thing, and so on.
>
> It also implements boot time assessement that is simple and just works
> (i.e. automatic revert to previous boot menu choice when the one
> selected doesn't work).
>
> Oh, and it as support for seeding the Linux random seed pre-boot
> already, in a safe and simple fashion.
>
> Moreover, it communicates which ESP is used to the host OS, so that
> the host can automatically discover what other partitions to mount.
>
> And the list goes on and on and on.
>
> All these features are very simple individually, but put together they
> are just a much nicer and expose a much more integrated behaviour
> than Grub ever did.
>
>
> > sd-boot is simpler and a bit tighter integrated with systemd, which would
> > mean it is less work to maintain if we use it instead of grub, but if we
> > use it next to grub then all those advantages fall away. IOW if we use
> > it next to grub then all I see is a whole lot of extra work, with very
> > little gain.
>
>
> Well, you appear to believe in the race to the bottom, i.e. that the
> lowest common denominator should be where the future is. I am pretty
> sure it's the wrong approach: pick the simple contender that can do
> all the nice things, and has the nice integration, and use it as a
> blueprint for the other archs where Grub is still needed, and make
> them catch up.
>
> I mean, I understand you are interested in exotic platforms that lack
> modern things like UEFI, but it kinda sucks to hold the boot loader
> hostage due to that, and just stick to the terrible ways of yesteryear
> because of it.
>
>
> > AFAIK this (lot of extra work, very little gain) is exactly why we have
> > been sticking with grub2 so far. We need to maintain it anyway, at which
> > point we want to use it in as much cases as possible so that we can have
> > unified code and documentation for dealing with the bootloader.
>
>
> I don't see "very little gain". I see a lot of gain, and all while
> things become simpler. Much simpler.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
Lennart,
We don't need more systemd-bloat just to boot our systems. However your
bootloader works, it doesn't really matter if it's not up to snuff with GRUB2.
When it supports LUKS, LVM, LUKS+LVM, a recovery console and several
filesystems, then it'll be more of a viable option, and I still wouldn't
recommend having yet another systemd component as a core part of our systems.
At what point is systemd large enough that you'll stop adding more cruft?
Hardly. I completely disagree with your entire statement, so stop using "we".
Here's the thing: systemd-boot is very good at what it does. The
Gummiboot project was a great demonstration of a nice, simple boot
manager. Kay decided to fold it into the systemd project, which is
fine. It has benefited from the tighter integration with tools like
systemctl.
I have two problems with sd-boot:
1. It is absolutely butt-ugly.
2. It is absolutely horrible for people who need to navigate this "by
surprise".
Neither the Windows Boot Manager nor the Apple "Option Boot" menus are
this bad. I literally do not care about anything else about it except
for those two things.
I've used sd-boot before and it's more than sufficient as long as the
UEFI firmware isn't broken. Nowadays, it's more common to have UEFI
firmware that does the right thing than the wrong thing, which is
great.
--
真実はいつも一つ！/ Always, there's only one truth!
4:08 p.m.
New subject: sd-boot vs. grub (WAS: The future of legacy BIOS support in Fedora.)
On Thu, Jul 2, 2020 at 6:01 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
Here's the thing: systemd-boot is very good at what it does. The
Gummiboot project was a great demonstration of a nice, simple boot
manager. Kay decided to fold it into the systemd project, which is
fine. It has benefited from the tighter integration with tools like
systemctl.
I have two problems with sd-boot:
1. It is absolutely butt-ugly.
2. It is absolutely horrible for people who need to navigate this "by
surprise".
I don't disagree with either of those points, but I'm frustrated with grub
due to this:
grub2-editenv: Error: Environment-Block is too small
https://bugzilla.redhat.com/show_bug.cgi?id=1625124
It should be trivial for a decent C programmer to come up with some logic
to fix this. Something like:
if < 1024 bytes but the last character is a # (after excluding white space
or newlines) -> Adjust (pad) to 1024 bytes.
If > 1024 bytes and the 1024th bit is a #, then truncate to the correct
length.
But this BZ has been open since 2018.
I like the simplicity of sd-boot and it was the only way I could get my MS
Surface GO to boot Fedora. For whatever reason it refuses to cooperate with
grub2.
I opted for a 1GB vfat partition and used it as /boot.
Thanks,
Richard
7:08 a.m.
On 7/2/20 12:55 AM, John M. Harris Jr wrote:
<Snip>
Lennart,
We don't need more systemd-bloat just to boot our systems. However your
bootloader works, it doesn't really matter if it's not up to snuff with GRUB2.
When it supports LUKS, LVM, LUKS+LVM, a recovery console and several
filesystems, then it'll be more of a viable option, and I still wouldn't
recommend having yet another systemd component as a core part of our systems.
At what point is systemd large enough that you'll stop adding more cruft?
Can you please stop calling features of systemd you don't like
"systemd-bloat" at every given opportunity? It is not being respectful
to those who work on the project and doesn't help your argument.
2:56 p.m.
On Thursday, July 2, 2020 5:08:14 AM MST Brandon Nielsen wrote:
On 7/2/20 12:55 AM, John M. Harris Jr wrote:
<Snip>
>
> Lennart,
>
> We don't need more systemd-bloat just to boot our systems. However your
> bootloader works, it doesn't really matter if it's not up to snuff with
> GRUB2. When it supports LUKS, LVM, LUKS+LVM, a recovery console and
> several filesystems, then it'll be more of a viable option, and I still
> wouldn't recommend having yet another systemd component as a core part of
> our systems. At what point is systemd large enough that you'll stop
> adding more cruft?
Can you please stop calling features of systemd you don't like
"systemd-bloat" at every given opportunity? It is not being respectful
to those who work on the project and doesn't help your argument.
It works well with this one. It's part of systemd, for some reason. It's
bloat. It's one letter off from the actual name of the software.
It doesn't need to be part of systemd to integrate with it. We don't need to
make our system more exclusive to make use of some systemd features, we can
just use the more powerful bootloader, GRUB2, and implement what it needs to
make use of these systemd "features".
--
John M. Harris, Jr.
3:07 p.m.
On 7/2/20 2:56 PM, John M. Harris Jr wrote:
On Thursday, July 2, 2020 5:08:14 AM MST Brandon Nielsen wrote:
> On 7/2/20 12:55 AM, John M. Harris Jr wrote:
>
> <Snip>
>
>
>>
>> Lennart,
>>
>> We don't need more systemd-bloat just to boot our systems. However your
>> bootloader works, it doesn't really matter if it's not up to snuff with
>> GRUB2. When it supports LUKS, LVM, LUKS+LVM, a recovery console and
>> several filesystems, then it'll be more of a viable option, and I still
>> wouldn't recommend having yet another systemd component as a core part of
>> our systems. At what point is systemd large enough that you'll stop
>> adding more cruft?
>
>
> Can you please stop calling features of systemd you don't like
> "systemd-bloat" at every given opportunity? It is not being respectful
> to those who work on the project and doesn't help your argument.
It works well with this one. It's part of systemd, for some reason. It's
bloat. It's one letter off from the actual name of the software.
It doesn't need to be part of systemd to integrate with it. We don't need to
make our system more exclusive to make use of some systemd features, we can
just use the more powerful bootloader, GRUB2, and implement what it needs to
make use of these systemd "features".
If your issue is with the architecture of systemd, I recommend taking an
objective argument to the systemd development list.
If your issue is with Fedora making use of features already implemented
in systemd, I recommend making an objective argument detailing why those
features shouldn't be used. If there are better alternatives that can
enable Gnome is easily integrate with the bootloader (to enable say, a
"Reboot to Windows" or "Reboot to UEFI" option), I would love to hear
about them.
I'm also interested in how further modifying GRUB2 to to enable features
(that were previously bloat?) that systemd-boot supports today is better
for the future of Fedora's UEFI support. Especially in regards to
testing and maintenance burden.
4:14 p.m.
On 02/07/20 07:08 -0500, Brandon Nielsen wrote:
On 7/2/20 12:55 AM, John M. Harris Jr wrote:
<Snip>
>
>Lennart,
>
>We don't need more systemd-bloat just to boot our systems. However your
>bootloader works, it doesn't really matter if it's not up to snuff with
GRUB2.
>When it supports LUKS, LVM, LUKS+LVM, a recovery console and several
>filesystems, then it'll be more of a viable option, and I still wouldn't
>recommend having yet another systemd component as a core part of our systems.
>At what point is systemd large enough that you'll stop adding more cruft?
>
Can you please stop calling features of systemd you don't like
"systemd-bloat" at every given opportunity? It is not being respectful
to those who work on the project and doesn't help your argument.
Seconded. Please stop it.
10:53 a.m.
On Mi, 01.07.20 22:55, John M. Harris Jr (johnmh(a)splentity.com) wrote:
Lennart,
We don't need more systemd-bloat just to boot our systems. However your
bootloader works, it doesn't really matter if it's not up to snuff with GRUB2.
When it supports LUKS, LVM, LUKS+LVM, a recovery console and several
filesystems, then it'll be more of a viable option, and I still wouldn't
recommend having yet another systemd component as a core part of our systems.
At what point is systemd large enough that you'll stop adding more cruft?
John,
sd-boot is tiny precisely *because* it doesn't implement storage
stacks, file systems, and drivers. I think it's the big problem of
Grub that it goes down that road even on EFI, as all that is a
redundant reimplementation on EFI where the firmware *itself* already
implements a basic storage stack you *have* to rely on, and you cannot
escape from. So booting Linux via Grub on EFI means you have a chain
of three storage stacks: the without doubt crappy EFI one, the
questionnable one in Grub and finally the pretty OK one in Linux. To
boot a reasonable system on EFI you cannot really escape the storage
stack on Linux, and the storage stack of EFI. However, why would you
plug a third one in the middle? sd-boot just says: no, let's not do
that. Loading a kernel and an initrd off disk is not hard, if we have
to use the EFI firmware to load the boot loader off disk anyway, then
it's OK to also load these two files off disk as well with it.
This makes sd-boot tiny, and simply the entire opposite of "bloat".
If you want to talk about "bloat": grub is a more or less complete OS
these days, it slowly but surely reimplements a major section of the
Linux OS, with complex storage and file systems, including write
access. All that even with little sympathy from the Linux fs
developers who made clear in the past they have little interest in
supporting alternative implementations of their fs (see this very
mailing list's discussion about xfs support in grub for more info).
And yes, EFI is an OS too, it also implements drivers and file systems
(much fewer though). Key here though is that the OS it implements is
an OS you *cannot* escape: if grub is used it's that EFI OS that will
load your grub binary. sd-boot just goes one step further and says: oh
well, instead of loading just the boot loader of disk via EFI, let's
load the kernel/initrd off disk with it too. If loading the EFI
loader like this worked, then loading the kernel/initrd off disk via
the very same APIs hsa the best chance to work.
You know, Grub made some sense back in the old days before EFI was in
the mix, because the old MBR boot protocol was such a simplistic
scheme that it only had sector access and not even the most basic file
system support, but you almost always want basic fs support, even if
all you want to do is show a boot menu. Hence back then adding some
basic fs support to Grub definitely made sense.
But now we live in a world where firmware can do that anyway, and you
cannot avoid it, and hence you might as well use it for two more files
than just the boot loader itself, and remove a redundant
reimplementation of a full pretend-Linux-compatible storage stack out
of your boot loader.
TLDR: boot loader should be simpler and not needlessly reimplement LVM
and xfs. If there's "bloat" here anywhere, it's probably these
reimplementations of LVM and xfs, but not in sd-boot that avoids all
that.
Lennart
--
Lennart Poettering, Berlin
11:58 a.m.
Hi,
Also note that this entails a lot more work then just maintaining
sd-boot,
anaconda will need to be adjusted, kernel-install scripts will need to
be adjusted, etc. And what about upgrades, if upgrades stick with using grub2
then now we have 3 bootloader configs, including things like documentation on
how to change kernel commandline options, to maintain instead of 2.
It is all there and working, except for the anaconda bits (as far I know
there is no way to ask anaconda install sd-boot instead of grub2).
If you wanna play with it qemu images (f31 only, no time yet for f32)
are here: https://www.kraxel.org/repos/images/
The '-systemd' variants use sd-boot.
take care,
Gerd
6:17 p.m.
Jóhann B. Guðmundsson wrote:
Such proposal would never be about stop supporting older hardware
that's
just a misconception people are getting
When you write "stop supporting booting in legacy bios mode and move to
uefi only supported boot", then you shouldn't be too surprised if people
believe that you're proposing to stop supporting BIOS and support only
UEFI.
Björn Persson
1:38 p.m.
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 common intel based x86 platform since atleast
2005.
Now in 2017 Intel's technical marketing engineer Brian Richardson
revealed in a presentation that the company will require UEFI Class 3
and above as in it would remove legacy BIOS support from its client and
datacenter platforms by 2020 and one might expect AMD to follow Intel in
this regard.
So Intel platforms produced this year presumably will be unable to run
32-bit operating systems, unable to use related software (at least
natively), and unable to use older hardware, such as RAID HBAs (and
therefore older hard drives that are connected to those HBAs), network
cards, and even graphics cards that lack UEFI-compatible vBIOS (launched
before 2012 – 2013) etc.
This post is just to gather feed back why Fedora should still continue
to support legacy BIOS boot as opposed to stop supporting it and
potentially drop grub2 and use sd-boot instead.
Share your thoughts and comments on how such move might affect you so
feedback can be collected for the future on why such a change might be
bad, how it might affect the distribution and scope of such change can
be determined for potential system wide proposal.
Regards
Jóhann B.
1.
https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration
The primary areas of concern I have about Fedora dropping grub2 and BIOS boot support
are:
1. Users that are on systems that do not support UEFI, or that knowingly (or unknowingly)
use BIOS boot on UEFI-capable systems.
These people are likely to form a lasting negative impression of Fedora, as removing BIOS
boot support would ostensibly mean that Fedora no longer runs on their systems (at least
as configured). I have heard that the UEFI implementations on some (typically older)
motherboards can be buggy, so many users may have a legitimate reason to still use BIOS
boot on boards that advertise support for both.
2. How would dropping grub2 affect users that boot multiple operating systems?
What manual steps, if any, would users need to take if they were previously using grub2 to
support booting multiple operating systems. Would this change break existing multi-boot
setups?
3. Virtual machines typically default to BIOS boot.
It's my understanding that libvirt, Virtual Box, Hyper-V (gen1 VMs only?), and many
cloud providers default to using BIOS boot when creating virtual machines. If Fedora no
longer works *by default* with common virtualization stacks I'd imagine many users
will simply choose to no longer run or recommend Fedora.
4. Support documentation for sd-boot
Would this result in changes to how users access the boot menu, select a boot entry, or
edit the kernel command line, etc? These actions of course aren't expected to be
common but when they are needed it tends to be when a user is already experiencing
problems and is under stress. Therefore if there are changes, hopefully these will be
clearly documented to avoid confusion.
5. What does Fedora gain by dropping BIOS boot support?
Perhaps it is obvious to others, but I think it is worth fully spelling out what the
expected benefits are. This would help everyone more clearly see the trade-offs of this
change.
1:59 p.m.
On Tue, Jun 30, 2020 at 2:39 PM Tom Seewald <tseewald(a)gmail.com> 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 supported boot which
> has been available on any common intel based x86 platform since atleast
> 2005.
>
> Now in 2017 Intel's technical marketing engineer Brian Richardson
> revealed in a presentation that the company will require UEFI Class 3
> and above as in it would remove legacy BIOS support from its client and
> datacenter platforms by 2020 and one might expect AMD to follow Intel in
> this regard.
>
> So Intel platforms produced this year presumably will be unable to run
> 32-bit operating systems, unable to use related software (at least
> natively), and unable to use older hardware, such as RAID HBAs (and
> therefore older hard drives that are connected to those HBAs), network
> cards, and even graphics cards that lack UEFI-compatible vBIOS (launched
> before 2012 – 2013) etc.
>
> This post is just to gather feed back why Fedora should still continue
> to support legacy BIOS boot as opposed to stop supporting it and
> potentially drop grub2 and use sd-boot instead.
>
> Share your thoughts and comments on how such move might affect you so
> feedback can be collected for the future on why such a change might be
> bad, how it might affect the distribution and scope of such change can
> be determined for potential system wide proposal.
>
>
> Regards
>
> Jóhann B.
>
>
> 1.
> https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration
The primary areas of concern I have about Fedora dropping grub2 and BIOS boot support
are:
1. Users that are on systems that do not support UEFI, or that knowingly (or unknowingly)
use BIOS boot on UEFI-capable systems.
These people are likely to form a lasting negative impression of Fedora, as removing BIOS
boot support would ostensibly mean that Fedora no longer runs on their systems (at least
as configured). I have heard that the UEFI implementations on some (typically older)
motherboards can be buggy, so many users may have a legitimate reason to still use BIOS
boot on boards that advertise support for both.
2. How would dropping grub2 affect users that boot multiple operating systems?
What manual steps, if any, would users need to take if they were previously using grub2
to support booting multiple operating systems. Would this change break existing multi-boot
setups?
What would happen if some of those multiple operating systems do
not support UEFI for whatever reason?
3. Virtual machines typically default to BIOS boot.
It's my understanding that libvirt, Virtual Box, Hyper-V (gen1 VMs only?), and many
cloud providers default to using BIOS boot when creating virtual machines. If Fedora no
longer works *by default* with common virtualization stacks I'd imagine many users
will simply choose to no longer run or recommend Fedora.
I think this is a place to handhold user, not to tell, say,
libvirt it should drop BIOS boot altogether like others in this thread
suggested.
> 4. Support documentation for sd-boot
>
> Would this result in changes to how users access the boot menu, select a boot entry,
or edit the kernel command line, etc? These actions of course aren't expected to be
common but when they are needed it tends to be when a user is already experiencing
problems and is under stress. Therefore if there are changes, hopefully these will be
clearly documented to avoid confusion.
>
> 5. What does Fedora gain by dropping BIOS boot support?
>
> Perhaps it is obvious to others, but I think it is worth fully spelling out what the
expected benefits are. This would help everyone more clearly see the trade-offs of this
change.
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
1:59 p.m.
On 6/30/20 11:38 AM, Tom Seewald wrote:
The primary areas of concern I have about Fedora dropping grub2 and
BIOS boot support are:
nicely summarized.
4. Support documentation for sd-boot
Would this result in changes to how users access the boot menu, select a boot entry, or
edit the kernel command line, etc? These actions of course aren't expected to be
common but when they are needed it tends to be when a user is already experiencing
problems and is under stress. Therefore if there are changes, hopefully these will be
clearly documented to avoid confusion.
Is this proposed dropping of grub only for 'desktop' Fedora?
iiuc, server/workstation instances share the same underpinnings?
For server/workstation, "access the boot menu, select a boot entry, or edit the
kernel command line" are certainly NOT _uncommon_.
Very often, particularly when tracking closely with upstream latest releases, they're
very often _necessary_.
re: sd-boot docs, grub -- for both BIOS & UEFI -- has available encyclopedic &
thorough documentation.
its configs are also wonderfully portable. including/across the countless other distros
that (will) continue to use/support it.
*dropping* grub for the next bright-n-shiny seems to make little sense. *adding*
"sd-boot" (tbh, i've never come across an instance of it in use. anywhere.),
and support *both* -- whether or not it's 'bloat -- doesn't make much sense
either.
5:49 p.m.
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 supported boot which
has been available on any common intel based x86 platform since atleast
2005.
No, it would not.
It would mean desupporting a wide range of existing hardware and some VM
environments (even with QEMU/KVM, I found the SeaBIOS legacy BIOS to be much
less quirky than the OVMF UEFI implementation, and other VM environments
might not support UEFI at all, including older QEMU versions that may still
be in use as hosts for modern Fedora guests). And for what gain?
I do not think switching from GRUB-EFI to systemd-boot as you propose would
be of any benefit for UEFI users. (It would actually mean fewer features for
no tangible benefit.) Hence, we are dealing with GRUB in both enviroments.
So I do not see the maintenance burden of continued BIOS support, also
considering that, in my experience, the environment that keeps causing
problems is actually UEFI, not BIOS.
This post is just to gather feed back why Fedora should still
continue
to support legacy BIOS boot as opposed to stop supporting it and
potentially drop grub2 and use sd-boot instead.
Fedora should still continue to support legacy BIOS boot.
Kevin Kofler
3:43 a.m.
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 supported boot which
> has been available on any common intel based x86 platform since atleast
> 2005.
No, it would not.
It would mean desupporting a wide range of existing hardware and some VM
environments (even with QEMU/KVM, I found the SeaBIOS legacy BIOS to be much
less quirky than the OVMF UEFI implementation, and other VM environments
might not support UEFI at all, including older QEMU versions that may still
be in use as hosts for modern Fedora guests). And for what gain?
Also SeaBIOS boot is much faster than OVMF, and that matters in many
cases (libguestfs for one).
Rich.
I do not think switching from GRUB-EFI to systemd-boot as you propose
would
be of any benefit for UEFI users. (It would actually mean fewer features for
no tangible benefit.) Hence, we are dealing with GRUB in both enviroments.
So I do not see the maintenance burden of continued BIOS support, also
considering that, in my experience, the environment that keeps causing
problems is actually UEFI, not BIOS.
> This post is just to gather feed back why Fedora should still continue
> to support legacy BIOS boot as opposed to stop supporting it and
> potentially drop grub2 and use sd-boot instead.
Fedora should still continue to support legacy BIOS boot.
Kevin Kofler
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
3:13 a.m.
Yes...Dropping support for BIOS will enable us to switch to
systemd-boot, which is the benefit. But just out of curiosity, what is
the benefit of switching from GRUB to systemd-boot.
Dropping support for 32-bit x86 surely can make maintainers be free
from one old platform (and less package to compile... etc.). But
supporting BIOS is just work for GRUB (and anaconda, not system-wide)
and when system is booted, BIOS or UEFI won't show such a significant
difference, not so great work is put into this.
Jóhann B. Guðmundsson <johannbg(a)gmail.com> 于2020年6月30日周二 下午9:34写道：
>
> 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 common intel based x86 platform since atleast
> 2005.
>
> Now in 2017 Intel's technical marketing engineer Brian Richardson
> revealed in a presentation that the company will require UEFI Class 3
> and above as in it would remove legacy BIOS support from its client and
> datacenter platforms by 2020 and one might expect AMD to follow Intel in
> this regard.
>
> So Intel platforms produced this year presumably will be unable to run
> 32-bit operating systems, unable to use related software (at least
> natively), and unable to use older hardware, such as RAID HBAs (and
> therefore older hard drives that are connected to those HBAs), network
> cards, and even graphics cards that lack UEFI-compatible vBIOS (launched
> before 2012 – 2013) etc.
>
> This post is just to gather feed back why Fedora should still continue
> to support legacy BIOS boot as opposed to stop supporting it and
> potentially drop grub2 and use sd-boot instead.
>
> Share your thoughts and comments on how such move might affect you so
> feedback can be collected for the future on why such a change might be
> bad, how it might affect the distribution and scope of such change can
> be determined for potential system wide proposal.
>
>
> Regards
>
> Jóhann B.
>
>
> 1.
> https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
4:23 a.m.
Has UEFI support improved in the last 2 - 3 years?
My last experience with it was so poor on a multi-boot system I switched to legacy and
haven't bothered trying it since.
4:28 a.m.
legacy BIOS
Stop using the L-word, please: BIOS is not "legacy", it's just alternative
way (one of many). All my laptops use BIOS, by the way.
ср, 1 июл. 2020 г. в 18:26, Leigh Scott <leigh123linux(a)gmail.com>:
Has UEFI support improved in the last 2 - 3 years?
My last experience with it was so poor on a multi-boot system I switched
to legacy and haven't bothered trying it since.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
5:01 a.m.
On 01.07.2020 11:28, Alexey A. wrote:
Stop using the L-word, please: BIOS is not "legacy",
it's just
alternative way (one of many).
Using BIOS boot on UEFI-compatible systems is a legacy, because it works
under the CSM compatibly layer.
More information about CSM you can find here:
https://www.rodsbooks.com/efi-bootloaders/csm-good-bad-ugly.html
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
5:08 a.m.
On Wed, Jul 01, 2020 at 12:01:08PM +0200, Vitaly Zaitsev via devel wrote:
On 01.07.2020 11:28, Alexey A. wrote:
> Stop using the L-word, please: BIOS is not "legacy", it's just
> alternative way (one of many).
Using BIOS boot on UEFI-compatible systems is a legacy, because it works
under the CSM compatibly layer.
More information about CSM you can find here:
https://www.rodsbooks.com/efi-bootloaders/csm-good-bad-ugly.html
NB, with the OVMF UEFI firmware for KVM, there is *NO* CSM layer
provided.
IOW, If KVM is configured for UEFI, the guest OS must use UEFI boot;
if KVM is configured for legacy BIOS, the guest OS must use legacy BIOS.
Just something to be aware of if you're testing OS using KVM - it won't
replicate behaviour of bare metal UEFI setups with CSM.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
9:27 a.m.
On 2020-06-30 14:34, Jóhann B. Guðmundsson wrote:
Share your thoughts and comments on how such move might affect you so
feedback can be collected for the future on why such a change might be
bad, how it might affect the distribution and scope of such change can
be determined for potential system wide proposal.
Just in case if someone is not aware: syslinux (pxe, ext) shipped with
Fedora is in very good state - form about 2016 I am using the package
for all my booting needs (grub2 is too complex for me):
* PXE/Legacy,UEFI
* Physical (partition) Legacy, ESP-UEFI
* VM Legacy - for VMs (and USB sticks) usually it is not even needed
to partition the VM disk, just extlinux the VM FS volume.
I do not tried VM/UEFI so far.
so (in my experience) any instance will have easy switchable
UEFI/Non-UEFI boot option even if the other bootloaders discontinue
legacy mode support.
I do not know if syslinux/extlinux have support in Anaconda, since I am
not using Anaconda for my imaging needs.
Kind Regards,
Alek
7:08 a.m.
On Wed, Jul 1, 2020 at 3:29 PM Alek Paunov <alex(a)declera.com> wrote:
On 2020-06-30 14:34, Jóhann B. Guðmundsson wrote:
> Share your thoughts and comments on how such move might affect you so
> feedback can be collected for the future on why such a change might be
> bad, how it might affect the distribution and scope of such change can
> be determined for potential system wide proposal.
>
Just in case if someone is not aware: syslinux (pxe, ext) shipped with
Fedora is in very good state - form about 2016 I am using the package
I suppose "very good state" is a relative term, upstream hasn't seen a
release since 2016 so is essentially "unmaintained", not sure it
supports secure boot, probably has a bunch of CVEs (see point about
maintenance). I think it only lives on in Fedora is because I think
it's used for some (.iso?) install method, AFIACT it's eventually
glued back together when it fails to build and is generally ignored.
> for all my booting needs (grub2 is too complex for me):
>
> * PXE/Legacy,UEFI
> * Physical (partition) Legacy, ESP-UEFI
> * VM Legacy - for VMs (and USB sticks) usually it is not even needed
> to partition the VM disk, just extlinux the VM FS volume.
> I do not tried VM/UEFI so far.
>
> so (in my experience) any instance will have easy switchable
> UEFI/Non-UEFI boot option even if the other bootloaders discontinue
> legacy mode support.
>
> I do not know if syslinux/extlinux have support in Anaconda, since I am
> not using Anaconda for my imaging needs.
>
> Kind Regards,
> Alek
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
2:59 p.m.
On Thursday, July 2, 2020 5:08:31 AM MST Peter Robinson wrote:
On Wed, Jul 1, 2020 at 3:29 PM Alek Paunov <alex(a)declera.com>
wrote:
>
>
> On 2020-06-30 14:34, Jóhann B. Guðmundsson wrote:
>
> > Share your thoughts and comments on how such move might affect you so
> > feedback can be collected for the future on why such a change might be
> > bad, how it might affect the distribution and scope of such change can
> > be determined for potential system wide proposal.
> >
> >
>
>
>
> Just in case if someone is not aware: syslinux (pxe, ext) shipped with
> Fedora is in very good state - form about 2016 I am using the package
I suppose "very good state" is a relative term, upstream hasn't seen a
release since 2016 so is essentially "unmaintained", not sure it
supports secure boot, probably has a bunch of CVEs (see point about
maintenance). I think it only lives on in Fedora is because I think
it's used for some (.iso?) install method, AFIACT it's eventually
glued back together when it fails to build and is generally ignored.
It's used for ISO boot by Fedora itself, and is the preferred PXE method, the
alternative being GRUB. It's a powerful bootloader, I don't see anything that
needs changing in it.
--
John M. Harris, Jr.
8:34 p.m.
On 2020-07-02 13:08, Peter Robinson wrote:
I suppose "very good state" is a relative term, upstream
hasn't seen a
release since 2016 so is essentially "unmaintained", not sure it
supports secure boot, probably has a bunch of CVEs (see point about
maintenance). I think it only lives on in Fedora is because I think
it's used for some (.iso?) install method, AFIACT it's eventually
glued back together when it fails to build and is generally ignored.
As "very good state" I meant that the subpackages contain everything
needed, and the binaries work flawlessly for the above use cases.
Before, in some cases I was forced to use binaries from the upstream
tarball.
I started to collect the sources (the upstream repo, various branches
like [1]), Fedora patchset, the "dist-gits" from other distributions
listed in Repology [2], bug trackers), and will try to give more
informed answer to your questions once I manage to asemble something ala
src-git with pair of branches (patches/applied) per distribution.
Kind Regards,
Alek
[1] https://github.com/awalls-cx18/syslinux/commits/master
[2] https://repology.org/project/syslinux/versions
10:19 a.m.
On 2020-06-30 15:34, Jóhann B. Guðmundsson wrote:
Share your thoughts and comments on how such move might affect you so
feedback can be collected for the future on why such a change might be bad, how it might
affect the distribution and scope of such change can be determined for potential system
wide proposal.
I've never really seen any reason to switch to UEFI since it
appeared years ago.
It just looked much more complicated (and buggy at the time), for no reasonable
gain.
I'm currently using BIOS, grub, grub2 basically everywhere, even on fresh new
machines,
for the simple reason that grub2 is really flexible; recently with GPT and code-EF02 bios
boot partition.
(GPT scheme 21686148-6449-6E6F-744E-656564454649: "Hah!IdontNeedEFI")
In some cases I have complex setups where grub2 is installed two times, with the first one
offering
some entries, including chainloading the second one for additional entries (possibly on a
different
drive not always connected and which each operating system having their own grub2 and
/boot).
These things are either impossible with UEFI or would require learning everything again.
I've seen lilo, grub and grub2, which has matured for years; we have finally started
to understand it
fully, we got the new blscfg thing too, and now... everything reinvented again?
IMHO the firmware (BIOS/UEFI/something) should just be able to run a bootloader,
everything else
added is not an advantage.
Regards.
--
Roberto Ragusa mail at robertoragusa.it
11:10 a.m.
On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:
I'm currently using BIOS, grub, grub2 basically everywhere, even
on
fresh new machines,
This won't be the case for much longer; Intel will finally drop CSM
("BIOS") support this year.
Even putting that aside, for the past several years CSM/BIOS has been
slowly bitrotting due to a lack of real testing, as the last few Windows
releases have mandated use of UEFI for preinstalled systems, plus the
EOLing of Windows 7 and (especially) XP.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org (email&xmpp)
@pizza:shaftnet dot org (matrix)
High Springs, FL speachy (freenode)
11:32 a.m.
On 1.7.2020 16:10, Solomon Peachy wrote:
On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:
> I'm currently using BIOS, grub, grub2 basically everywhere, even on
> fresh new machines,
This won't be the case for much longer; Intel will finally drop CSM
("BIOS") support this year.
Even putting that aside, for the past several years CSM/BIOS has been
slowly bitrotting due to a lack of real testing, as the last few Windows
releases have mandated use of UEFI for preinstalled systems, plus the
EOLing of Windows 7 and (especially) XP.
AMD is "strongly" recommending UEFI for the windows [1]
So Apple dropped CSM in 2006
Intel in 2020
AMD is against it's use
Windows has moved on with the curve...
JBG
1. https://www.amd.com/en/support/kb/faq/cpu-uefi-mode
12:30 p.m.
On Wed, 2020-07-01 at 16:32 +0000, Jóhann B. Guðmundsson wrote:
On 1.7.2020 16:10, Solomon Peachy wrote:
> On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:
> > I'm currently using BIOS, grub, grub2 basically everywhere, even
> > on
> > fresh new machines,
> This won't be the case for much longer; Intel will finally drop CSM
> ("BIOS") support this year.
>
> Even putting that aside, for the past several years CSM/BIOS has
> been
> slowly bitrotting due to a lack of real testing, as the last few
> Windows
> releases have mandated use of UEFI for preinstalled systems, plus
> the
> EOLing of Windows 7 and (especially) XP.
AMD is "strongly" recommending UEFI for the windows [1]
So Apple dropped CSM in 2006
And Apple makes what percentage of the computers, used by Fedora users?
:)
Intel in 2020
Which will only apply to new computers. Existing installs from 2017-
2019 will need to be supported for a long time. Like I said in a
different email, top tier PC manufacturers such as Dell and HP have
been selling PCs without Windows, configured in legacy mode by default
and that's probably what most people, who purchased them, use.
AMD is against it's use
Only a recommendation, they aren't mandating it. What matters is what
PC manufacturers will actually ship. AMD doesn't have much control over
that, compared to Intel. But I suspect PC manufacturers will follow
Intel and move to UEFI only as well. But, once again, this is for new
systems. Systems, purchased in 2017-2019 aren't "legacy" and you can't
force people to reinstall their operating systems or risk losing their
data.
Windows has moved on with the curve...
Only for new computers, sold with Windows preinstalled. Existing
Windows 10 installs are still supported. In fact, Fedora has dropped
i686 support before Windows. You can download the latest Windows 10 for
32-bit computers. They've only dropped 32-bit support for OEMs. But
anyhow 32-bit vs 64-bit is a whole different story, this is about the
bootloader.
Best regards,
Nikolay
4 p.m.
On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
<johannbg(a)gmail.com> wrote:
On 1.7.2020 16:10, Solomon Peachy wrote:
> On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:
>> I'm currently using BIOS, grub, grub2 basically everywhere, even on
>> fresh new machines,
> This won't be the case for much longer; Intel will finally drop CSM
> ("BIOS") support this year.
>
> Even putting that aside, for the past several years CSM/BIOS has been
> slowly bitrotting due to a lack of real testing, as the last few Windows
> releases have mandated use of UEFI for preinstalled systems, plus the
> EOLing of Windows 7 and (especially) XP.
AMD is "strongly" recommending UEFI for the windows [1]
So Apple dropped CSM in 2006
Intel in 2020
AMD is against it's use
Windows has moved on with the curve...
That's great and all, but of all the cloud providers, only Microsoft's
Azure / Hyper-V platform actually requires UEFI support. Nobody else
even supports it! Okay, AWS only supports it for AArch64, but not x86.
KVM guys here are still recommending BIOS.
We still can't use NVIDIA proprietary drivers on UEFI because Fedora's
kernel configuration is too strict for that. I personally consider it
a good thing, but that's a problem for others.
Fix all the other problems we have with UEFI environments before
suggesting we drop "legacy BIOS".
It's absolutely shameful that despite us being first to the UEFI
Secure Boot support, we *still* can't get things working fully in that
environment. And frankly, from what I can tell from all the people
involved: nobody cares except for the couple of people who ask every
few months why we can't have the NVIDIA driver signed and auto-trusted
so it works. I know every time I ask, people respond with "it's not
that simple" and more mumbles of Koji architecture problems.
At this point, I personally don't want to see this proposal *ever*
come up again unless somebody cares about fixing the user experience
with UEFI.
--
真実はいつも一つ！/ Always, there's only one truth!
4:28 p.m.
On 1.7.2020 21:00, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
<johannbg(a)gmail.com> wrote:
> On 1.7.2020 16:10, Solomon Peachy wrote:
>> On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:
>>> I'm currently using BIOS, grub, grub2 basically everywhere, even on
>>> fresh new machines,
>> This won't be the case for much longer; Intel will finally drop CSM
>> ("BIOS") support this year.
>>
>> Even putting that aside, for the past several years CSM/BIOS has been
>> slowly bitrotting due to a lack of real testing, as the last few Windows
>> releases have mandated use of UEFI for preinstalled systems, plus the
>> EOLing of Windows 7 and (especially) XP.
> AMD is "strongly" recommending UEFI for the windows [1]
>
> So Apple dropped CSM in 2006
>
> Intel in 2020
>
> AMD is against it's use
>
> Windows has moved on with the curve...
>
That's great and all, but of all the cloud providers, only Microsoft's
Azure / Hyper-V platform actually requires UEFI support. Nobody else
even supports it! Okay, AWS only supports it for AArch64, but not x86.
KVM guys here are still recommending BIOS.
We still can't use NVIDIA proprietary drivers on UEFI because Fedora's
kernel configuration is too strict for that. I personally consider it
a good thing, but that's a problem for others.
Fix all the other problems we have with UEFI environments before
suggesting we drop "legacy BIOS".
It's absolutely shameful that despite us being first to the UEFI
Secure Boot support, we *still* can't get things working fully in that
environment. And frankly, from what I can tell from all the people
involved: nobody cares except for the couple of people who ask every
few months why we can't have the NVIDIA driver signed and auto-trusted
so it works. I know every time I ask, people respond with "it's not
that simple" and more mumbles of Koji architecture problems.
At this point, I personally don't want to see this proposal *ever*
come up again unless somebody cares about fixing the user experience
with UEFI.
Based on the feedback here there are atleast 5 - 10 years before we can
even consider removing it so no worries this wont come up again for a
looong time but hopefully there are other areas we can improve upon
which helps us improve the overall UEFI experience in Fedora etc.
Perhaps it's not that people dont care and more that they are unaware of
those problems I mean I personally was unaware of those problem and
probably whole lot of other people here as well so could you list in
more detail what exactly those user experience problems with UEFI are
that you are aware of and we can try to compile a todo list to work with.
JBG
4:50 p.m.
On Wed, Jul 1, 2020 at 5:29 PM Jóhann B. Guðmundsson <johannbg(a)gmail.com> wrote:
On 1.7.2020 21:00, Neal Gompa wrote:
> On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
> <johannbg(a)gmail.com> wrote:
>> On 1.7.2020 16:10, Solomon Peachy wrote:
>>> On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:
>>>> I'm currently using BIOS, grub, grub2 basically everywhere, even on
>>>> fresh new machines,
>>> This won't be the case for much longer; Intel will finally drop CSM
>>> ("BIOS") support this year.
>>>
>>> Even putting that aside, for the past several years CSM/BIOS has been
>>> slowly bitrotting due to a lack of real testing, as the last few Windows
>>> releases have mandated use of UEFI for preinstalled systems, plus the
>>> EOLing of Windows 7 and (especially) XP.
>> AMD is "strongly" recommending UEFI for the windows [1]
>>
>> So Apple dropped CSM in 2006
>>
>> Intel in 2020
>>
>> AMD is against it's use
>>
>> Windows has moved on with the curve...
>>
> That's great and all, but of all the cloud providers, only Microsoft's
> Azure / Hyper-V platform actually requires UEFI support. Nobody else
> even supports it! Okay, AWS only supports it for AArch64, but not x86.
>
> KVM guys here are still recommending BIOS.
>
> We still can't use NVIDIA proprietary drivers on UEFI because Fedora's
> kernel configuration is too strict for that. I personally consider it
> a good thing, but that's a problem for others.
>
> Fix all the other problems we have with UEFI environments before
> suggesting we drop "legacy BIOS".
>
> It's absolutely shameful that despite us being first to the UEFI
> Secure Boot support, we *still* can't get things working fully in that
> environment. And frankly, from what I can tell from all the people
> involved: nobody cares except for the couple of people who ask every
> few months why we can't have the NVIDIA driver signed and auto-trusted
> so it works. I know every time I ask, people respond with "it's not
> that simple" and more mumbles of Koji architecture problems.
>
> At this point, I personally don't want to see this proposal *ever*
> come up again unless somebody cares about fixing the user experience
> with UEFI.
Based on the feedback here there are atleast 5 - 10 years before we can
even consider removing it so no worries this wont come up again for a
looong time but hopefully there are other areas we can improve upon
which helps us improve the overall UEFI experience in Fedora etc.
Perhaps it's not that people dont care and more that they are unaware of
those problems I mean I personally was unaware of those problem and
probably whole lot of other people here as well so could you list in
more detail what exactly those user experience problems with UEFI are
that you are aware of and we can try to compile a todo list to work with.
I suspect you may not be aware because nobody ever bothered to bubble
it up to you.
I think most people are satisfied with the situation, but I'm not. I
despise NVIDIA, but guess what, there's no choice in the marketplace
anymore. Everyone ships NVIDIA GPUs, even with AMD CPUs on laptops.
And no laptop lets you swap GPUs like you can on desktops.
Red Hat probably doesn't care because most server users are not using
UEFI yet. That proportion goes down a lot as people transition from on
premises to AWS. So this doesn't hurt their partnership with NVIDIA
where they tacitly encourage proprietary kernel module usage at scale.
Since KVM in RHEL doesn't support UEFI properly either, nobody is
seriously looking at the issues caused by multiplexing NVIDIA GPUs and
exposing them into virtual machines running in UEFI Secure Boot,
because this just doesn't happen there. I've tried it on my Fedora
systems, they don't work.
On the desktop side, most PC makers shipping Linux are turning UEFI or
UEFI Secure Boot off, which lets the NVIDIA driver work. But if you're
shipping Secure Boot on by default, as I suspect Lenovo will with
their Linux laptops, then the NVIDIA drivers will simply fail to
function.
Nouveau obviously works (for some definition of works...), but because
NVIDIA is awful, it is not a useful driver like amdgpu is.
The Fedora Koji Build System is not capable of building kernel module
packages and signing them so that they are trusted. The Koji Build
System *itself* does not make it easy to offer this functionality in
the same way that other build systems (like SUSE's OBS) do. Moreover,
we rely on RPM Fusion to build the driver package, which is fine,
except nobody can get RPM Fusion's Koji system to sign the driver
correctly and have the Fedora kernel trust the RPM Fusion certificate
automatically. Nor is there a straightforward way for packages to get
installed and have their signatures trusted so that kernel modules
that are properly signed will work.
The core of it is that nobody cares. It comes up at least once or
twice every development cycle in the Workstation Working Group
meetings, but there's nothing we can do. Sometimes I'll get bullshit
answers from people. Sometimes they'll just say stuff about security.
Sometimes they'll say something about it being NVIDIA's problem.
Nobody wants to say it, so I will: nobody cares. All of these problems
are fixable, just nobody with power wants to fix them.
--
真実はいつも一つ！/ Always, there's only one truth!
4:59 p.m.
On Wed, Jul 1, 2020 at 5:51 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
The core of it is that nobody cares. It comes up at least once or
twice every development cycle in the Workstation Working Group
meetings, but there's nothing we can do. Sometimes I'll get bullshit
answers from people. Sometimes they'll just say stuff about security.
Sometimes they'll say something about it being NVIDIA's problem.
Is there a bug filed for this that I can follow? I didn't see one
from a quick search.
Personally, I use my own Secure Boot keys and sign the modules from
akmods with that. It works fine with the cert in db since that gets
it loaded into the platform keyring. I'd like to see the
extract-vmlinux and/or insert-sys-cert kernel programs learn how to
repack vmlinux back into an existing vmlinuz so that
CONFIG_SYSTEM_EXTRA_CERTIFICATE can be useful with UEFI, and I could
have a separate module signing key and Secure Boot key.
Thanks.
David
5:45 p.m.
On 1.7.2020 21:50, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 5:29 PM Jóhann B. Guðmundsson
<johannbg(a)gmail.com> wrote:
> On 1.7.2020 21:00, Neal Gompa wrote:
>> On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
>> <johannbg(a)gmail.com> wrote:
>>> On 1.7.2020 16:10, Solomon Peachy wrote:
>>>> On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:
>>>>> I'm currently using BIOS, grub, grub2 basically everywhere, even
on
>>>>> fresh new machines,
>>>> This won't be the case for much longer; Intel will finally drop CSM
>>>> ("BIOS") support this year.
>>>>
>>>> Even putting that aside, for the past several years CSM/BIOS has been
>>>> slowly bitrotting due to a lack of real testing, as the last few Windows
>>>> releases have mandated use of UEFI for preinstalled systems, plus the
>>>> EOLing of Windows 7 and (especially) XP.
>>> AMD is "strongly" recommending UEFI for the windows [1]
>>>
>>> So Apple dropped CSM in 2006
>>>
>>> Intel in 2020
>>>
>>> AMD is against it's use
>>>
>>> Windows has moved on with the curve...
>>>
>> That's great and all, but of all the cloud providers, only Microsoft's
>> Azure / Hyper-V platform actually requires UEFI support. Nobody else
>> even supports it! Okay, AWS only supports it for AArch64, but not x86.
>>
>> KVM guys here are still recommending BIOS.
>>
>> We still can't use NVIDIA proprietary drivers on UEFI because Fedora's
>> kernel configuration is too strict for that. I personally consider it
>> a good thing, but that's a problem for others.
>>
>> Fix all the other problems we have with UEFI environments before
>> suggesting we drop "legacy BIOS".
>>
>> It's absolutely shameful that despite us being first to the UEFI
>> Secure Boot support, we *still* can't get things working fully in that
>> environment. And frankly, from what I can tell from all the people
>> involved: nobody cares except for the couple of people who ask every
>> few months why we can't have the NVIDIA driver signed and auto-trusted
>> so it works. I know every time I ask, people respond with "it's not
>> that simple" and more mumbles of Koji architecture problems.
>>
>> At this point, I personally don't want to see this proposal *ever*
>> come up again unless somebody cares about fixing the user experience
>> with UEFI.
> Based on the feedback here there are atleast 5 - 10 years before we can
> even consider removing it so no worries this wont come up again for a
> looong time but hopefully there are other areas we can improve upon
> which helps us improve the overall UEFI experience in Fedora etc.
>
> Perhaps it's not that people dont care and more that they are unaware of
> those problems I mean I personally was unaware of those problem and
> probably whole lot of other people here as well so could you list in
> more detail what exactly those user experience problems with UEFI are
> that you are aware of and we can try to compile a todo list to work with.
>
I suspect you may not be aware because nobody ever bothered to bubble
it up to you.
I think most people are satisfied with the situation, but I'm not. I
despise NVIDIA, but guess what, there's no choice in the marketplace
anymore. Everyone ships NVIDIA GPUs, even with AMD CPUs on laptops.
And no laptop lets you swap GPUs like you can on desktops.
Red Hat probably doesn't care because most server users are not using
UEFI yet. That proportion goes down a lot as people transition from on
premises to AWS. So this doesn't hurt their partnership with NVIDIA
where they tacitly encourage proprietary kernel module usage at scale.
Since KVM in RHEL doesn't support UEFI properly either, nobody is
seriously looking at the issues caused by multiplexing NVIDIA GPUs and
exposing them into virtual machines running in UEFI Secure Boot,
because this just doesn't happen there. I've tried it on my Fedora
systems, they don't work.
On the desktop side, most PC makers shipping Linux are turning UEFI or
UEFI Secure Boot off, which lets the NVIDIA driver work. But if you're
shipping Secure Boot on by default, as I suspect Lenovo will with
their Linux laptops, then the NVIDIA drivers will simply fail to
function.
Nouveau obviously works (for some definition of works...), but because
NVIDIA is awful, it is not a useful driver like amdgpu is.
The Fedora Koji Build System is not capable of building kernel module
packages and signing them so that they are trusted. The Koji Build
System *itself* does not make it easy to offer this functionality in
the same way that other build systems (like SUSE's OBS) do. Moreover,
we rely on RPM Fusion to build the driver package, which is fine,
except nobody can get RPM Fusion's Koji system to sign the driver
correctly and have the Fedora kernel trust the RPM Fusion certificate
automatically. Nor is there a straightforward way for packages to get
installed and have their signatures trusted so that kernel modules
that are properly signed will work.
The core of it is that nobody cares. It comes up at least once or
twice every development cycle in the Workstation Working Group
meetings, but there's nothing we can do. Sometimes I'll get bullshit
answers from people. Sometimes they'll just say stuff about security.
Sometimes they'll say something about it being NVIDIA's problem.
Nobody wants to say it, so I will: nobody cares. All of these problems
are fixable, just nobody with power wants to fix them.
Well I whole heartily agree with you assessment that we need fix all
problems that we can with UEFI environments and up to this point we have
done piss poor job of it and based on the feedback on this thread I
suspect there are other usability issues that we are unaware of, other
than the one you are pointing out.
I mean there is one thing that PC makers are shipping hardware which
seemingly have this turned on or off at random and novice end user just
use it since they dont know any better and another when *experience*
users deliberately go into their bios to disable UEFI and as I said I
suspect there is something more going on than it's all due to nvidia GPU.
JBG
5:47 p.m.
On Wed, Jul 1, 2020 at 6:45 PM Jóhann B. Guðmundsson <johannbg(a)gmail.com> wrote:
On 1.7.2020 21:50, Neal Gompa wrote:
> On Wed, Jul 1, 2020 at 5:29 PM Jóhann B. Guðmundsson <johannbg(a)gmail.com>
wrote:
>> On 1.7.2020 21:00, Neal Gompa wrote:
>>> On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
>>> <johannbg(a)gmail.com> wrote:
>>>> On 1.7.2020 16:10, Solomon Peachy wrote:
>>>>> On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:
>>>>>> I'm currently using BIOS, grub, grub2 basically everywhere,
even on
>>>>>> fresh new machines,
>>>>> This won't be the case for much longer; Intel will finally drop
CSM
>>>>> ("BIOS") support this year.
>>>>>
>>>>> Even putting that aside, for the past several years CSM/BIOS has
been
>>>>> slowly bitrotting due to a lack of real testing, as the last few
Windows
>>>>> releases have mandated use of UEFI for preinstalled systems, plus
the
>>>>> EOLing of Windows 7 and (especially) XP.
>>>> AMD is "strongly" recommending UEFI for the windows [1]
>>>>
>>>> So Apple dropped CSM in 2006
>>>>
>>>> Intel in 2020
>>>>
>>>> AMD is against it's use
>>>>
>>>> Windows has moved on with the curve...
>>>>
>>> That's great and all, but of all the cloud providers, only
Microsoft's
>>> Azure / Hyper-V platform actually requires UEFI support. Nobody else
>>> even supports it! Okay, AWS only supports it for AArch64, but not x86.
>>>
>>> KVM guys here are still recommending BIOS.
>>>
>>> We still can't use NVIDIA proprietary drivers on UEFI because
Fedora's
>>> kernel configuration is too strict for that. I personally consider it
>>> a good thing, but that's a problem for others.
>>>
>>> Fix all the other problems we have with UEFI environments before
>>> suggesting we drop "legacy BIOS".
>>>
>>> It's absolutely shameful that despite us being first to the UEFI
>>> Secure Boot support, we *still* can't get things working fully in that
>>> environment. And frankly, from what I can tell from all the people
>>> involved: nobody cares except for the couple of people who ask every
>>> few months why we can't have the NVIDIA driver signed and auto-trusted
>>> so it works. I know every time I ask, people respond with "it's
not
>>> that simple" and more mumbles of Koji architecture problems.
>>>
>>> At this point, I personally don't want to see this proposal *ever*
>>> come up again unless somebody cares about fixing the user experience
>>> with UEFI.
>> Based on the feedback here there are atleast 5 - 10 years before we can
>> even consider removing it so no worries this wont come up again for a
>> looong time but hopefully there are other areas we can improve upon
>> which helps us improve the overall UEFI experience in Fedora etc.
>>
>> Perhaps it's not that people dont care and more that they are unaware of
>> those problems I mean I personally was unaware of those problem and
>> probably whole lot of other people here as well so could you list in
>> more detail what exactly those user experience problems with UEFI are
>> that you are aware of and we can try to compile a todo list to work with.
>>
> I suspect you may not be aware because nobody ever bothered to bubble
> it up to you.
>
> I think most people are satisfied with the situation, but I'm not. I
> despise NVIDIA, but guess what, there's no choice in the marketplace
> anymore. Everyone ships NVIDIA GPUs, even with AMD CPUs on laptops.
> And no laptop lets you swap GPUs like you can on desktops.
>
> Red Hat probably doesn't care because most server users are not using
> UEFI yet. That proportion goes down a lot as people transition from on
> premises to AWS. So this doesn't hurt their partnership with NVIDIA
> where they tacitly encourage proprietary kernel module usage at scale.
>
> Since KVM in RHEL doesn't support UEFI properly either, nobody is
> seriously looking at the issues caused by multiplexing NVIDIA GPUs and
> exposing them into virtual machines running in UEFI Secure Boot,
> because this just doesn't happen there. I've tried it on my Fedora
> systems, they don't work.
>
> On the desktop side, most PC makers shipping Linux are turning UEFI or
> UEFI Secure Boot off, which lets the NVIDIA driver work. But if you're
> shipping Secure Boot on by default, as I suspect Lenovo will with
> their Linux laptops, then the NVIDIA drivers will simply fail to
> function.
>
> Nouveau obviously works (for some definition of works...), but because
> NVIDIA is awful, it is not a useful driver like amdgpu is.
>
> The Fedora Koji Build System is not capable of building kernel module
> packages and signing them so that they are trusted. The Koji Build
> System *itself* does not make it easy to offer this functionality in
> the same way that other build systems (like SUSE's OBS) do. Moreover,
> we rely on RPM Fusion to build the driver package, which is fine,
> except nobody can get RPM Fusion's Koji system to sign the driver
> correctly and have the Fedora kernel trust the RPM Fusion certificate
> automatically. Nor is there a straightforward way for packages to get
> installed and have their signatures trusted so that kernel modules
> that are properly signed will work.
>
> The core of it is that nobody cares. It comes up at least once or
> twice every development cycle in the Workstation Working Group
> meetings, but there's nothing we can do. Sometimes I'll get bullshit
> answers from people. Sometimes they'll just say stuff about security.
> Sometimes they'll say something about it being NVIDIA's problem.
>
> Nobody wants to say it, so I will: nobody cares. All of these problems
> are fixable, just nobody with power wants to fix them.
>
>
Well I whole heartily agree with you assessment that we need fix all
problems that we can with UEFI environments and up to this point we have
done piss poor job of it and based on the feedback on this thread I
suspect there are other usability issues that we are unaware of, other
than the one you are pointing out.
I mean there is one thing that PC makers are shipping hardware which
seemingly have this turned on or off at random and novice end user just
use it since they dont know any better and another when *experience*
users deliberately go into their bios to disable UEFI and as I said I
suspect there is something more going on than it's all due to nvidia GPU.
I'm fairly certain there are other issues, but that's the most popular
one that gets brought up, so it remains at the forefront of my
attention.
--
真実はいつも一つ！/ Always, there's only one truth!
3:35 a.m.
On Wed, Jul 01, 2020 at 05:50:05PM -0400, Neal Gompa wrote:
Red Hat probably doesn't care because most server users are not
using
UEFI yet.
That statement is false. UEFI is absolutely important to server users.
That proportion goes down a lot as people transition from
on
premises to AWS. So this doesn't hurt their partnership with NVIDIA
where they tacitly encourage proprietary kernel module usage at scale.
Since KVM in RHEL doesn't support UEFI properly either, nobody is
seriously looking at the issues caused by multiplexing NVIDIA GPUs and
exposing them into virtual machines running in UEFI Secure Boot,
because this just doesn't happen there. I've tried it on my Fedora
systems, they don't work.
KVM in RHEL does support UEFI. That's not the say it everything is
bug-free, but it is supported as it is clearly the direction the
industry is going and new security features in particular increasingly
rely on UEFI.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
3:05 p.m.
On Wednesday, July 1, 2020 2:28:39 PM MST Jóhann B. Guðmundsson wrote:
On 1.7.2020 21:00, Neal Gompa wrote:
> On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
> <johannbg(a)gmail.com> wrote:
>
>> On 1.7.2020 16:10, Solomon Peachy wrote:
>>
>>> On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:
>>>
>>>> I'm currently using BIOS, grub, grub2 basically everywhere, even on
>>>> fresh new machines,
>>>
>>> This won't be the case for much longer; Intel will finally drop CSM
>>> ("BIOS") support this year.
>>>
>>>
>>>
>>> Even putting that aside, for the past several years CSM/BIOS has been
>>> slowly bitrotting due to a lack of real testing, as the last few
>>> Windows
>>> releases have mandated use of UEFI for preinstalled systems, plus the
>>> EOLing of Windows 7 and (especially) XP.
>>
>> AMD is "strongly" recommending UEFI for the windows [1]
>>
>>
>>
>> So Apple dropped CSM in 2006
>>
>>
>>
>> Intel in 2020
>>
>>
>>
>> AMD is against it's use
>>
>>
>>
>> Windows has moved on with the curve...
>>
>>
>>
> That's great and all, but of all the cloud providers, only Microsoft's
> Azure / Hyper-V platform actually requires UEFI support. Nobody else
> even supports it! Okay, AWS only supports it for AArch64, but not x86.
>
>
>
> KVM guys here are still recommending BIOS.
>
>
>
> We still can't use NVIDIA proprietary drivers on UEFI because Fedora's
> kernel configuration is too strict for that. I personally consider it
> a good thing, but that's a problem for others.
>
>
>
> Fix all the other problems we have with UEFI environments before
> suggesting we drop "legacy BIOS".
>
>
>
> It's absolutely shameful that despite us being first to the UEFI
> Secure Boot support, we *still* can't get things working fully in that
> environment. And frankly, from what I can tell from all the people
> involved: nobody cares except for the couple of people who ask every
> few months why we can't have the NVIDIA driver signed and auto-trusted
> so it works. I know every time I ask, people respond with "it's not
> that simple" and more mumbles of Koji architecture problems.
>
>
>
> At this point, I personally don't want to see this proposal *ever*
> come up again unless somebody cares about fixing the user experience
> with UEFI.
Based on the feedback here there are atleast 5 - 10 years before we can
even consider removing it so no worries this wont come up again for a
looong time but hopefully there are other areas we can improve upon
which helps us improve the overall UEFI experience in Fedora etc.
Perhaps it's not that people dont care and more that they are unaware of
those problems I mean I personally was unaware of those problem and
probably whole lot of other people here as well so could you list in
more detail what exactly those user experience problems with UEFI are
that you are aware of and we can try to compile a todo list to work with.
5-10 years? A better estimate would be 15-20 years. People aren't going to
throw away perfectly fine systems and jump to new "cloud" platforms just
because the OS they were using dropped BIOS support. They'll just stop
updating, and likely move to something that is still supporting BIOS, if they
don't write their own installer and just continue using Fedora, given that
this is an entirely artificial limitation.
--
John M. Harris, Jr.
3:19 p.m.
5-10 years? A better estimate would be 15-20 years. People aren't
going to
throw away perfectly fine systems and jump to new "cloud" platforms just
because the OS they were using dropped BIOS support. They'll just stop
updating, and likely move to something that is still supporting BIOS, if they
don't write their own installer and just continue using Fedora, given that
this is an entirely artificial limitation.
While I completely hear you on the fact that people will often sweat
assets for years longer than accounting schedules suggest they should,
do you really think they're going to write custom installers??? I think
it's far more likely that they would move to other distros more amenable
to supporting the hardware they have.
There are many distros that cater to this kind of market already, some
by design and some by inclination.?? I don't think we want to drive them
there.
For what it's worth, I do not think that removing legacy BIOS support
from Fedora is the right thing to do.?? I don't see significant benefit,
and I see lots of potential harm.
Thanks,
Marty
3:30 p.m.
On 7/2/20 3:19 PM, Martin Jackson wrote:
> 5-10 years? A better estimate would be 15-20 years. People aren't
> going to
> throw away perfectly fine systems and jump to new "cloud" platforms just
> because the OS they were using dropped BIOS support. They'll just stop
> updating, and likely move to something that is still supporting BIOS,
> if they
> don't write their own installer and just continue using Fedora, given
> that
> this is an entirely artificial limitation.
>
While I completely hear you on the fact that people will often sweat
assets for years longer than accounting schedules suggest they should,
do you really think they're going to write custom installers??? I think
it's far more likely that they would move to other distros more amenable
to supporting the hardware they have.
There are many distros that cater to this kind of market already, some
by design and some by inclination.?? I don't think we want to drive them
there.
For what it's worth, I do not think that removing legacy BIOS support
from Fedora is the right thing to do.?? I don't see significant benefit,
and I see lots of potential harm.
Thanks,
Marty
I don't think removing BIOS support _today_ is the right answer either.
I have BIOS only hardware kicking around, and quite a bit of my UEFI
hardware still supports legacy BIOS booting as well (though I don't use it).
However, I'm concerned about UEFI feature development / quality
assurance being held hostage by BIOS support for, based on above
comments, 5 to 20 years? Surely as a somewhat leading-edge distribution,
we need to start thinking about some kind of post-BIOS world.
Perhaps one small step toward that future would be enabling systemd-boot
on new UEFI installs, relegating GRUB2 to BIOS and upgrade installs
only? This split configuration could hang around until support for GRUB2
/ BIOS wanes to the point it can no longer stand under its own weight
(much like 32bit install media).
3:42 p.m.
On Thursday, July 2, 2020 1:30:41 PM MST Brandon Nielsen wrote:
On 7/2/20 3:19 PM, Martin Jackson wrote:
>
>
>> 5-10 years? A better estimate would be 15-20 years. People aren't
>> going to
>> throw away perfectly fine systems and jump to new "cloud" platforms
just
>> because the OS they were using dropped BIOS support. They'll just stop
>> updating, and likely move to something that is still supporting BIOS,
>> if they
>> don't write their own installer and just continue using Fedora, given
>> that
>> this is an entirely artificial limitation.
>>
>>
>>
> While I completely hear you on the fact that people will often sweat
> assets for years longer than accounting schedules suggest they should,
> do you really think they're going to write custom installers??? I think
> it's far more likely that they would move to other distros more amenable
> to supporting the hardware they have.
>
> There are many distros that cater to this kind of market already, some
> by design and some by inclination.?? I don't think we want to drive them
> there.
>
> For what it's worth, I do not think that removing legacy BIOS support
> from Fedora is the right thing to do.?? I don't see significant benefit,
> and I see lots of potential harm.
>
> Thanks,
>
> Marty
I don't think removing BIOS support _today_ is the right answer either.
I have BIOS only hardware kicking around, and quite a bit of my UEFI
hardware still supports legacy BIOS booting as well (though I don't use
it).
However, I'm concerned about UEFI feature development / quality
assurance being held hostage by BIOS support for, based on above
comments, 5 to 20 years? Surely as a somewhat leading-edge distribution,
we need to start thinking about some kind of post-BIOS world.
Perhaps one small step toward that future would be enabling systemd-boot
on new UEFI installs, relegating GRUB2 to BIOS and upgrade installs
only? This split configuration could hang around until support for GRUB2
/ BIOS wanes to the point it can no longer stand under its own weight
(much like 32bit install media).
GRUB2, which is a UEFI bootloader as well, is a far superior bootloader to
systemd-bloat, and it supports usecases that are supported by Anaconda (the
Fedora installer framework) that systemd-bloat doesn't, as addressed elsewhere
in this thread by myself and several others. There is no way that supporting
BIOS can be a cause for UEFI feature development being "held back". It's got
nothing to do with UEFI stuff.
--
John M. Harris, Jr.
4:32 p.m.
On 7/2/20 3:42 PM, John M. Harris Jr wrote:
<Snip>
GRUB2, which is a UEFI bootloader as well, is a far superior bootloader to
systemd-bloat, and it supports usecases that are supported by Anaconda (the
Fedora installer framework) that systemd-bloat doesn't, as addressed elsewhere
in this thread by myself and several others. There is no way that supporting
BIOS can be a cause for UEFI feature development being "held back". It's
got
nothing to do with UEFI stuff.
Again with "systemd-bloat"... I guess I don't see how something that is
responsible for booting the system, taking on more responsibility for
booting the system, could ever be argued to be bloat?
How is GRUB2 superior? I would like to see a list of pros, or
alternatively, a list of things systemd-boot doesn't do. I see plenty of
discussion in this thread about things not supporting UEFI, but not
things that only GRUB2 can do (except boot both UEFI and BIOS machines).
As for systemd-boot advantages:
1) It is simpler to configure and interact with from a running system
than GRUB2
2) Supports seeding entropy generation before the Linux boot process
proceeds
3) Can integrate easily with Gnome, other DEs
4) Has boot assessment, which could potentially integrate nicely with
the ability to boot into a read-only recovery type mode that's been
proposed[0]
5) Has hooks for automatically booting a newly installed kernel
systemd-boot disadvantages:
1) No BIOS support
2) Ugly
3) Boot counting support doesn't seem real configurable? It only reverts
to a previous kernel.
4) Additional testing / maintenance burden until BIOS is dropped completely
5) Limited boot entry templating ability
0 -
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
11:19 a.m.
On Do, 02.07.20 15:30, Brandon Nielsen (nielsenb(a)jetfuse.net) wrote:
I don't think removing BIOS support _today_ is the right answer
either. I
have BIOS only hardware kicking around, and quite a bit of my UEFI hardware
still supports legacy BIOS booting as well (though I don't use it).
However, I'm concerned about UEFI feature development / quality assurance
being held hostage by BIOS support for, based on above comments, 5 to 20
years? Surely as a somewhat leading-edge distribution, we need to start
thinking about some kind of post-BIOS world.
Perhaps one small step toward that future would be enabling systemd-boot on
new UEFI installs, relegating GRUB2 to BIOS and upgrade installs only? This
split configuration could hang around until support for GRUB2 / BIOS wanes
to the point it can no longer stand under its own weight (much like 32bit
install media).
If it way my decision I'd propose the following as the path to the
future:
1. Unify/standardize on the boot loader spec, not the boot loader
2. Let's use UEFI as model and make MBR boots more alike UEFI then the
other way round (right now, UEFI boots in grub are considered a
special case, and booting on UEFI is attempted to be as close as
possible to MBR). i.e this is a race-to-the-bottom
vs. race-to-the-top issue: make the stuff that doesn't work like
today's industry standard work like it, and don't make today's hw
work like the industry standard of yesteryear.
Specifically this means:
a. Teach grub proper boot loader spec support (and maybe boot loader
interface support too,
i.e. https://systemd.io/BOOT_LOADER_SPECIFICATION +
https://systemd.io/BOOT_LOADER_INTERFACE)
b. Prepare a static no-module build of Grub that reimplements roughly
how booting on EFI works: i.e. support only VFAT file systems, then
search for suitable partitions (ESP/XBOOTLDR), and retrieve boot
loader spec entries from them, and populate the menu by it, and
that's it. Do this the same way on all archs we support, regardless
if MBR or ARM or EFI boot protocols.
As I understand a good chunk of a/b already exists.
With these changes it doesn't matter too much which boot loader is
used, it can be sd-boot or Grub. Or it could even be the native boot
loader spec support in firmware (i.e. LinuxBoot). It doesn't matter
anymore.
but the effect of this approach would be great: suddenly "systemctl
kexec" and "systemctl reboot --boot-loader-entry=" would jus twork for
all these boot loaders, and installers could all understand each
other's drop-ins and logic, on all archs... And you could switch boot
loaders any day and there's a major chance things would just work. You
could multi-boot between Linux distros without having the boot loaders
overwrite each others data all the time.
Note that I personally would actually prefer if the firmware would
natively implement the boot loader spec and we wouldn't have to have
sd-boot around at all. Such a scheme would be fantastic actually, as
it would remove so many variables from the stack.
sd-boot exists only to add the minimum on top of EFI to make the above
work, i.e. something that in an ideal world would just be subsumed by
the firmware itself.
Lennart
--
Lennart Poettering, Berlin
1:49 p.m.
On Sat, Jul 4, 2020 at 10:19 AM Lennart Poettering <mzerqung(a)0pointer.de> wrote:
If it way my decision I'd propose the following as the path to
the
future:
1. Unify/standardize on the boot loader spec, not the boot loader
2. Let's use UEFI as model and make MBR boots more alike UEFI then the
other way round (right now, UEFI boots in grub are considered a
special case, and booting on UEFI is attempted to be as close as
possible to MBR). i.e this is a race-to-the-bottom
vs. race-to-the-top issue: make the stuff that doesn't work like
today's industry standard work like it, and don't make today's hw
work like the industry standard of yesteryear.
Specifically this means:
a. Teach grub proper boot loader spec support (and maybe boot loader
interface support too,
i.e. https://systemd.io/BOOT_LOADER_SPECIFICATION +
https://systemd.io/BOOT_LOADER_INTERFACE)
b. Prepare a static no-module build of Grub that reimplements roughly
how booting on EFI works: i.e. support only VFAT file systems, then
search for suitable partitions (ESP/XBOOTLDR), and retrieve boot
loader spec entries from them, and populate the menu by it, and
that's it. Do this the same way on all archs we support, regardless
if MBR or ARM or EFI boot protocols.
As I understand a good chunk of a/b already exists.
I agree with all of this. But multiple projects (distros but also
project within even Fedora) boot differently and put pressure on
bootloader folks. GRUB is simultaneously unwieldy and indispensable.
The cost of abandoning it, or reorganizing either the upstream
approach or Fedora's approach to it, is incredible to imagine let
alone implement. And thus far upstream GRUB seems intractable on
Bootloaderspec, or giving sufficient feedback on modifications to make
it viable. It's a sand trap.
Why do the security folks want POSIX and SELinux labels on the
contents of /boot? I've never really gotten a straight answer on this,
but I know it's considered important and a sticking point for why some
folks do not want the kernel and initramfs and bootloader
configuration files on FAT. And can it be mitigated some other way?
Maybe not persistently mounting /boot and /boot/efi or mounting them
on-demand elsewhere only when they need to be modified?
There are other use cases folks are interested in. Here's one:
https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Boot_on_Btrfs
That aims to make it possible to support a snapshot/rollback regime.
There needs to be a way to pair the states of /boot and / so that the
kernel we're using to boot a rollback, has modules available on the
rolledback /usr. That does not need to be done with Btrfs, even though
it's probably easier, since we have examples of this already from
(open)SUSE that we know work very reliably. It's a solved problem that
is also well understood. The unsolved component to that though is how
to do it with Bootloaderspec. Is it possible at the same time we
figure out a way to not require /boot to be Btrfs? I'm open to the
idea even though I'm not sure what it looks like. Hence why this is an
option in the proposal, not part of the base proposal.
Everyone wants out of the sand trap, but we're also more comfortable
sticking with the problems we know rather than jumping into problems
we don't know. And then also RH/Fedora bootloader folks are busy
enough as it is holding up the fort, with few cycles to look at
planning and implementing a new design.
--
Chris Murphy
5:23 a.m.
On Sa, 04.07.20 12:49, Chris Murphy (lists(a)colorremedies.com) wrote:
Why do the security folks want POSIX and SELinux labels on the
contents of /boot? I've never really gotten a straight answer on this,
but I know it's considered important and a sticking point for why some
folks do not want the kernel and initramfs and bootloader
configuration files on FAT. And can it be mitigated some other way?
Maybe not persistently mounting /boot and /boot/efi or mounting them
on-demand elsewhere only when they need to be modified?
You can assign an SELinux label onto a whole file system at mount time
via the context= mount option and related ones. Hence the question is
why it is supposedly so essential to be able to label the initrd
differently than the kernel itself...
Note that systemd can automatically mount the ESP and XBOOTLDR
partition for you if you let it. If done so it will set it up via
automounts, so that the file systems are:
1) automatically fsck'ed on first mount
2) only mounted when actually accessed
3) very quickly after the last access unmounted again
This should provide the best data integrity guarantees on those file
systems as the file system is almost always unmounted, and thus in a
clean state, and automatically fixed in the unlikely case that the
system was turned off right at the moment the fs was accessed.
Note that this mechanism is independent of the boot loader spec, or
sd-boot or anything like that. It's automatically used if /boot or
/efi are not listed in /etc/fstab and if partitions of the right type
are found in the partition table.
(Note that this automatism doesn't support /boot/efi/, first of al
because it's weird, but mostly because in order to establish the
second automount point we'd have to activate the first one, which
defeats the whole excercise of having file systems that are never
mounted, except if they are accessed)
Hence, a couple of changes independent of the sd-boot/grub/boot loader spec
situation would make a lot of sense for Fedora:
1) Use the XBOOTLDR uuid for /boot
2) Mount ESP to /efi instead of /boot/efi (you can keep a symlink in
/boot/efi/ if you like)
3) Drop generation of ESP and /boot entries in /etc/fstab in the
installer, and let the automatic logic do its thing.
There are other use cases folks are interested in. Here's one:
https://fedoraproject.org/wiki/Changes/BtrfsByDefault#Boot_on_Btrfs
You know using a journalling file system on /boot means means you
drastically complicate things if you want to implement boot counting,
because then you need a writable fs, and then things become complex
because you need a ful fs implementation in grub.
Do the btrfs upstream folks commit to support an alternative writable
btrfs implementation in grub? I doubt so?
That aims to make it possible to support a snapshot/rollback regime.
There needs to be a way to pair the states of /boot and / so that the
kernel we're using to boot a rollback, has modules available on the
rolledback /usr. That does not need to be done with Btrfs, even
though
You are just reimplementing OSTree/Atomic/FedoraCoreOS with that...
Lennart
--
Lennart Poettering, Berlin
8:11 p.m.
On Saturday, July 4, 2020 9:19:34 AM MST Lennart Poettering wrote:
If it way my decision I'd propose the following as the path to
the
future:
1. Unify/standardize on the boot loader spec, not the boot loader
2. Let's use UEFI as model and make MBR boots more alike UEFI then the
other way round (right now, UEFI boots in grub are considered a
special case, and booting on UEFI is attempted to be as close as
possible to MBR). i.e this is a race-to-the-bottom
vs. race-to-the-top issue: make the stuff that doesn't work like
today's industry standard work like it, and don't make today's hw
work like the industry standard of yesteryear.
GRUB2 + BIOS boot is currently the best way to boot a system, as it actually
supports situations such as full disk encryption, boot from btrfs or ZFS,
including ZFS with native encryption.
Specifically this means:
a. Teach grub proper boot loader spec support (and maybe boot loader
interface support too,
i.e. https://systemd.io/BOOT_LOADER_SPECIFICATION +
https://systemd.io/BOOT_LOADER_INTERFACE)
That systemd throws some crap out doesn't make it a standard. There's no
reason for GRUB to adopt this, or for anyone else to use this.
b. Prepare a static no-module build of Grub that reimplements
roughly
how booting on EFI works: i.e. support only VFAT file systems, then
search for suitable partitions (ESP/XBOOTLDR), and retrieve boot
loader spec entries from them, and populate the menu by it, and
that's it. Do this the same way on all archs we support, regardless
if MBR or ARM or EFI boot protocols.
There is even less reason to *remove* features from GRUB, to make up for the
alternative bootloaders having less.
As I understand a good chunk of a/b already exists.
With these changes it doesn't matter too much which boot loader is
used, it can be sd-boot or Grub. Or it could even be the native boot
loader spec support in firmware (i.e. LinuxBoot). It doesn't matter
anymore.
Please note that projects such as Libreboot (blobless coreboot with GRUB as
the payload) currently assume that the installed system either uses GRUB2 or
syslinux/isolinux.
but the effect of this approach would be great: suddenly
"systemctl
kexec" and "systemctl reboot --boot-loader-entry=" would jus twork for
all these boot loaders, and installers could all understand each
other's drop-ins and logic, on all archs... And you could switch boot
loaders any day and there's a major chance things would just work. You
could multi-boot between Linux distros without having the boot loaders
overwrite each others data all the time.
How does `systemctl kexec` differ from `kexec`? Can it not simply use `kexec`
under the hood? What's the benefit of supporting `--boot-loader-entry=`?
You can already multiboot between Linux distros, and we've been able to do so,
as well as between other families of OS, for about two decades now.
Note that I personally would actually prefer if the firmware would
natively implement the boot loader spec and we wouldn't have to have
sd-boot around at all. Such a scheme would be fantastic actually, as
it would remove so many variables from the stack.
sd-boot exists only to add the minimum on top of EFI to make the above
work, i.e. something that in an ideal world would just be subsumed by
the firmware itself.
We don't need more bloat in the UEFI stack. It's already painfully specific to
Windows based platforms, and it's a complete hack that it works for our
systems now. Do you remember the state of UEFI in the RHEL6 days?
--
John M. Harris, Jr.
5:07 a.m.
On Sa, 04.07.20 18:11, John M. Harris Jr (johnmh(a)splentity.com) wrote:
That systemd throws some crap out doesn't make it a standard.
There's no
reason for GRUB to adopt this, or for anyone else to use this.
"bloat", "crap", …
I am sorry, but you are apparently just a troll and this is the point
where I will now ignore you.
Just stop being so awful and dismissive, this is not constructive.
Thank you,
Lennart
--
Lennart Poettering, Berlin
12:25 p.m.
On Sunday, July 5, 2020 3:07:44 AM MST Lennart Poettering wrote:
On Sa, 04.07.20 18:11, John M. Harris Jr (johnmh(a)splentity.com)
wrote:
> That systemd throws some crap out doesn't make it a standard. There's no
> reason for GRUB to adopt this, or for anyone else to use this.
"bloat", "crap", …
I am sorry, but you are apparently just a troll and this is the point
where I will now ignore you.
Just stop being so awful and dismissive, this is not constructive.
Lennart,
This behavior, which is identical to what has drawn attention to your handling
of GitHub issues recently, simply dismissing them as trolls or conspiracy
theorists, is why I'm saying that. systemd is not a standards body. It's an
init system.
--
John M. Harris, Jr.
1:21 p.m.
On Sun, Jul 5, 2020 at 11:26 AM John M. Harris Jr <johnmh(a)splentity.com> wrote:
On Sunday, July 5, 2020 3:07:44 AM MST Lennart Poettering wrote:
> On Sa, 04.07.20 18:11, John M. Harris Jr (johnmh(a)splentity.com) wrote:
>
>
> > That systemd throws some crap out doesn't make it a standard. There's
no
> > reason for GRUB to adopt this, or for anyone else to use this.
>
>
> "bloat", "crap", …
>
> I am sorry, but you are apparently just a troll and this is the point
> where I will now ignore you.
>
> Just stop being so awful and dismissive, this is not constructive.
Lennart,
This behavior, which is identical to what has drawn attention to your handling
of GitHub issues recently, simply dismissing them as trolls or conspiracy
theorists, is why I'm saying that. systemd is not a standards body. It's an
init system.
specification != standard
You're calling it something it doesn't claim to be and then criticizing it.
--
Chris Murphy
1:41 p.m.
Le dimanche 05 juillet 2020 à 12:21 -0600, Chris Murphy a écrit :
specification != standard
I, for one, am very happy that the systemd project makes the effort of
documenting its formats so others can write competing implementations
or write software that interacts with the systemd implementation.
That’s several orders of magnitude better than the usual my code is the
best, copy whatever undocumented thing I did by accident in my last
commit, this is the reference implementation, I won’t commit to
anything and I will change it at will without notification in the
future.
Thank you Lennart for understanding what we meant when we asked you to
engage with standards like the FHS years ago, and for not embarking
upon blackbox unspecified coding.
We all hate writing documentation and formal specifications are among
the most exhausting documentation one may write.
And, nothing wrong with writing a spec for things not specified yet,
quite the countrary.
Regards,
--
Nicolas Mailhot
2:05 p.m.
On Sun, Jul 5, 2020 at 12:41 PM Nicolas Mailhot via devel
<devel(a)lists.fedoraproject.org> wrote:
Le dimanche 05 juillet 2020 à 12:21 -0600, Chris Murphy a écrit :
>
> specification != standard
I, for one, am very happy that the systemd project makes the effort of
documenting its formats so others can write competing implementations
or write software that interacts with the systemd implementation.
That’s several orders of magnitude better than the usual my code is the
best, copy whatever undocumented thing I did by accident in my last
commit, this is the reference implementation, I won’t commit to
anything and I will change it at will without notification in the
future.
Thank you Lennart for understanding what we meant when we asked you to
engage with standards like the FHS years ago, and for not embarking
upon blackbox unspecified coding.
We all hate writing documentation and formal specifications are among
the most exhausting documentation one may write.
And, nothing wrong with writing a spec for things not specified yet,
quite the countrary.
Agreed. This is a better response.
Thanks Lennart!
--
Chris Murphy
3:42 p.m.
On Thursday, July 2, 2020 1:19:22 PM MST Martin Jackson wrote:
> 5-10 years? A better estimate would be 15-20 years. People
aren't going
> to
> throw away perfectly fine systems and jump to new "cloud" platforms just
> because the OS they were using dropped BIOS support. They'll just stop
> updating, and likely move to something that is still supporting BIOS, if
> they don't write their own installer and just continue using Fedora,
> given that this is an entirely artificial limitation.
>
>
While I completely hear you on the fact that people will often sweat
assets for years longer than accounting schedules suggest they should,
do you really think they're going to write custom installers??? I think
it's far more likely that they would move to other distros more amenable
to supporting the hardware they have.
There are many distros that cater to this kind of market already, some
by design and some by inclination.?? I don't think we want to drive them
there.
For what it's worth, I do not think that removing legacy BIOS support
from Fedora is the right thing to do.?? I don't see significant benefit,
and I see lots of potential harm.
Considering that a custom installer for Fedora could just be a bash script
that partitions disks, then runs `dnf`, then grub2-install.. It's not out of
the question. I've considered it myself, so that I could install to root on
ZFS without hacky kickstarts, for example.
--
John M. Harris, Jr.
2:15 a.m.
Le jeudi 02 juillet 2020 à 15:19 -0500, Martin Jackson a écrit :
> 5-10 years? A better estimate would be 15-20 years. People
aren't
> going to
> throw away perfectly fine systems and jump to new "cloud" platforms
> just
> because the OS they were using dropped BIOS support. They'll just
> stop
> updating, and likely move to something that is still supporting
> BIOS, if they
> don't write their own installer and just continue using Fedora,
> given that
> this is an entirely artificial limitation.
>
While I completely hear you on the fact that people will often sweat
assets for years longer than accounting schedules suggest they
should, do you really think they're going to write custom
installers???
They’re going to move to forks of Fedora downstreams (as AWS and others
already did).
(this is not an endorsement of any other position in this thread, I
hate all our bootloaders equally, they’ve been a lost cause since
someone decided to hide the bootloader menu in the default install,
making it something that does not exist… till you need it an realize
the state it’s in).
Regards,
--
Nicolas Mailhot
3:26 p.m.
On Friday, July 3, 2020 12:15:03 AM MST Nicolas Mailhot via devel wrote:
Le jeudi 02 juillet 2020 à 15:19 -0500, Martin Jackson a écrit :
> > 5-10 years? A better estimate would be 15-20 years. People aren't
> > going to
> > throw away perfectly fine systems and jump to new "cloud" platforms
> > just
> > because the OS they were using dropped BIOS support. They'll just
> > stop
> > updating, and likely move to something that is still supporting
> > BIOS, if they
> > don't write their own installer and just continue using Fedora,
> > given that
> > this is an entirely artificial limitation.
> >
>
> While I completely hear you on the fact that people will often sweat
> assets for years longer than accounting schedules suggest they
> should, do you really think they're going to write custom
> installers???
They’re going to move to forks of Fedora downstreams (as AWS and others
already did).
(this is not an endorsement of any other position in this thread, I
hate all our bootloaders equally, they’ve been a lost cause since
someone decided to hide the bootloader menu in the default install,
making it something that does not exist… till you need it an realize
the state it’s in).
Wait, what? I somehow never noticed that the bootloader menu has been hidden.
It's not on my system, so maybe it didn't change upgraded systems?
https://fedoraproject.org/wiki/Changes/HiddenGrubMenu
This is really wild. How in the world did this Change get approved?
"The grub menu with its kernel versions is another example of showing too
technical info to end-users and on non multi-boot systems it normally is not
necessary, so it is better to hide it." has to be the most GNOME thing I've
read today.
Oh, it's just Workstation. That'd explain how I never noticed, and how it got
approved. This would explain the Discourse threads that popped up, asking how
to rescue a system.
--
John M. Harris, Jr.
3:05 a.m.
On 01.07.2020 23:00, Neal Gompa wrote:
We still can't use NVIDIA proprietary drivers on UEFI because
Fedora's
kernel configuration is too strict for that. I personally consider it
a good thing, but that's a problem for others.
NVIDIA proprietary drivers from RPM Fusion repository works absolutely
fine on UEFI configurations (even KMS).
If you need Secure Boot feature to be enabled, you must sign the
compiled kmod packages with your own CA.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
5:56 a.m.
On Thu, Jul 2, 2020 at 4:06 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
On 01.07.2020 23:00, Neal Gompa wrote:
> We still can't use NVIDIA proprietary drivers on UEFI because Fedora's
> kernel configuration is too strict for that. I personally consider it
> a good thing, but that's a problem for others.
NVIDIA proprietary drivers from RPM Fusion repository works absolutely
fine on UEFI configurations (even KMS).
If you need Secure Boot feature to be enabled, you must sign the
compiled kmod packages with your own CA.
This is what's wrong with everything. *This is not okay*. This is
intentionally a poisonous user experience because we provide no
automatic or easy way for this to be done. I understand and agree with
the reasons for why it is this way, but you can't have it both ways if
you want an easy user experience.
Either you sign the drivers server side and auto-trust that
certificate (prebuilt kmods), or you sign the drivers device-side
(akmods) and auto-trust that certificate.
Pick your poison, and drink it. Stop hand-waving around it.
--
真実はいつも一つ！/ Always, there's only one truth!
9:11 a.m.
> If you need Secure Boot feature to be enabled, you must sign
the
> compiled kmod packages with your own CA.
>
This is what's wrong with everything. *This is not okay*. This is
intentionally a poisonous user experience because we provide no
automatic or easy way for this to be done. I understand and agree with
the reasons for why it is this way, but you can't have it both ways if
you want an easy user experience.
So you expect Fedora to provide a signing service using the Fedora
keys for anyone to abuse just so you can run UEFI with secure boot
enabled with your Nvidia GPU. I mean that's like locking the front
door right before you blow the entire back of the building off! I
strongly suspect that would be a violation of the MS secure boot
agreement (I have no idea if this actually is, just widely guessing).
Either you sign the drivers server side and auto-trust that
certificate (prebuilt kmods), or you sign the drivers device-side
(akmods) and auto-trust that certificate.
Or see my other reply for the third option which nvidia could do themselves.
8:47 a.m.
On Wed, Jul 1, 2020 at 10:01 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
<johannbg(a)gmail.com> wrote:
>
> On 1.7.2020 16:10, Solomon Peachy wrote:
> > On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:
> >> I'm currently using BIOS, grub, grub2 basically everywhere, even on
> >> fresh new machines,
> > This won't be the case for much longer; Intel will finally drop CSM
> > ("BIOS") support this year.
> >
> > Even putting that aside, for the past several years CSM/BIOS has been
> > slowly bitrotting due to a lack of real testing, as the last few Windows
> > releases have mandated use of UEFI for preinstalled systems, plus the
> > EOLing of Windows 7 and (especially) XP.
>
> AMD is "strongly" recommending UEFI for the windows [1]
>
> So Apple dropped CSM in 2006
>
> Intel in 2020
>
> AMD is against it's use
>
> Windows has moved on with the curve...
>
That's great and all, but of all the cloud providers, only Microsoft's
Azure / Hyper-V platform actually requires UEFI support. Nobody else
even supports it! Okay, AWS only supports it for AArch64, but not x86.
Google Compute does as well I believe.
KVM guys here are still recommending BIOS.
We still can't use NVIDIA proprietary drivers on UEFI because Fedora's
kernel configuration is too strict for that. I personally consider it
a good thing, but that's a problem for others.
I believe you need to disable secure-boot and it should work, I don't
believe the issue is actual UEFI in this case, of course BIOS boot
doesn't have any form of boot security.
Fix all the other problems we have with UEFI environments before
suggesting we drop "legacy BIOS".
That's a very grand sweeping gesture with no details, I suspect most
of the "problems" (what ever that means) are shity firmware
implementations of the UEFI spec, we use to have that with BIOS all
the time too, I suspect the reason we have it less so is that all the
vendors have long left that code well alone and are only "enhancing"
UEFI
It's absolutely shameful that despite us being first to the UEFI
Secure Boot support, we *still* can't get things working fully in that
environment. And frankly, from what I can tell from all the people
involved: nobody cares except for the couple of people who ask every
few months why we can't have the NVIDIA driver signed and auto-trusted
so it works. I know every time I ask, people respond with "it's not
that simple" and more mumbles of Koji architecture problems.
Is that a Fedora specific problem? Are other distros allowing the
loading of unsigned kernel modules to work around the problem while
potentially compromising user's security? I feel this is a Linux wide
issue with a single vendor, and not specific to Fedora at all.
Well there's lots of "reasons" I can think of but experience in the
Fedora community and my experience in IoT fields and related security
over the last few years the big ones IMO tend to be:
* A lot of people would be opposed to Fedora keys signing closed
source binary drivers, community, Red Hatters, probably legal (but I'm
not legal) and it may even affect the ability to sign shim and hence
use secure-boot at all (I've zero insight into this as I'm to lazy too
even begin to look for how I'd do that) to name but a few.
* Nvidia could sign their binary kernel modules, and the public key
could be enrolled into the kernel using mokutil likely even
automatically using some hook, the user would get a prompt each boot
with a new kernel but it wouldn't be a completely terrible experience.
You'd have to ask nvidia why this isn't possible
At this point, I personally don't want to see this proposal
*ever*
come up again unless somebody cares about fixing the user experience
with UEFI.
I think you're being very harsh and short sighted here TBH, like
things like AVX2 it's useful to have these conversations in a civil
manner, even if the original proposal was short sighted and missed a
lot of details and won't happen for years to come.
When aarch64 came along I made the decision that the only way Fedora
would ever support SBCs (like the Pine64, 96boards 410c the first
early boards we supported) was to use UEFI, and one of the SUSE people
agreed, most of the rest of the distros followed along. It makes
things a *LOT* easier for support because we have *one* boot option,
*one* installer path in anaconda so on and so forth. We could have
bodged up extlinux support like armv7 uses, and I got a lot of
pressure to do that. The little extra time it took has overwhelmingly
worth while and actually changed, and continues to, the arm eco-system
(watch the Fedora Arm space over the the next 6+ months for even more
examples of this).
From a Fedora IoT PoV we only support UEFI on any arch we support, the
reason for that is functionality IoT requires to be actually useful in
the field, and for security. While I believe BIOS boot works on x86_64
it's AFAICT it's purely by chance and I won't say this won't break in
the future if we needed to ensure the OS can remain secure. IoT is
lucky in that, like aarch64, we're quite new and don't have "legacy"
users, we may have users that are playing with IoT on legacy HW but I
don't know and all the users/customers/partners I'm speaking with are
using UEFI.
9:44 a.m.
On Thu, Jul 2, 2020 at 9:49 AM Peter Robinson <pbrobinson(a)gmail.com> wrote:
On Wed, Jul 1, 2020 at 10:01 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>
> On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson
> <johannbg(a)gmail.com> wrote:
> >
> > On 1.7.2020 16:10, Solomon Peachy wrote:
> > > On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:
> > >> I'm currently using BIOS, grub, grub2 basically everywhere, even
on
> > >> fresh new machines,
> > > This won't be the case for much longer; Intel will finally drop CSM
> > > ("BIOS") support this year.
> > >
> > > Even putting that aside, for the past several years CSM/BIOS has been
> > > slowly bitrotting due to a lack of real testing, as the last few Windows
> > > releases have mandated use of UEFI for preinstalled systems, plus the
> > > EOLing of Windows 7 and (especially) XP.
> >
> > AMD is "strongly" recommending UEFI for the windows [1]
> >
> > So Apple dropped CSM in 2006
> >
> > Intel in 2020
> >
> > AMD is against it's use
> >
> > Windows has moved on with the curve...
> >
>
> That's great and all, but of all the cloud providers, only Microsoft's
> Azure / Hyper-V platform actually requires UEFI support. Nobody else
> even supports it! Okay, AWS only supports it for AArch64, but not x86.
Google Compute does as well I believe.
> KVM guys here are still recommending BIOS.
>
> We still can't use NVIDIA proprietary drivers on UEFI because Fedora's
> kernel configuration is too strict for that. I personally consider it
> a good thing, but that's a problem for others.
I believe you need to disable secure-boot and it should work, I don't
believe the issue is actual UEFI in this case, of course BIOS boot
doesn't have any form of boot security.
> Fix all the other problems we have with UEFI environments before
> suggesting we drop "legacy BIOS".
That's a very grand sweeping gesture with no details, I suspect most
of the "problems" (what ever that means) are shity firmware
implementations of the UEFI spec, we use to have that with BIOS all
the time too, I suspect the reason we have it less so is that all the
vendors have long left that code well alone and are only "enhancing"
UEFI
> It's absolutely shameful that despite us being first to the UEFI
> Secure Boot support, we *still* can't get things working fully in that
> environment. And frankly, from what I can tell from all the people
> involved: nobody cares except for the couple of people who ask every
> few months why we can't have the NVIDIA driver signed and auto-trusted
> so it works. I know every time I ask, people respond with "it's not
> that simple" and more mumbles of Koji architecture problems.
Is that a Fedora specific problem? Are other distros allowing the
loading of unsigned kernel modules to work around the problem while
potentially compromising user's security? I feel this is a Linux wide
issue with a single vendor, and not specific to Fedora at all.
It is Fedora-specific. Neither Ubuntu nor openSUSE mandate that all
kmods need to be signed to load. They *warn* on it, but they don't
*block*.
Even with that, openSUSE makes it easy for kernel module packages to
include signed kernel modules. I think openSUSE will eventually switch
to blocking because the reason for not doing it doesn't apply these
days.
Well there's lots of "reasons" I can think of but
experience in the
Fedora community and my experience in IoT fields and related security
over the last few years the big ones IMO tend to be:
* A lot of people would be opposed to Fedora keys signing closed
source binary drivers, community, Red Hatters, probably legal (but I'm
not legal) and it may even affect the ability to sign shim and hence
use secure-boot at all (I've zero insight into this as I'm to lazy too
even begin to look for how I'd do that) to name but a few.
This is false. The openSUSE builds of the nvidia driver are
auto-signed properly too, because their build system actually
*supports* signing kernel modules.
Use a secondary key instead of the primary one if you want. If I
remember correctly, that's what openSUSE does.
* Nvidia could sign their binary kernel modules, and the public key
could be enrolled into the kernel using mokutil likely even
automatically using some hook, the user would get a prompt each boot
with a new kernel but it wouldn't be a completely terrible experience.
You'd have to ask nvidia why this isn't possible
They *do* sign it. Their installer actually autogenerates the cert,
signs the kernel modules, and enrolls the cert for you.
So our experience is strictly *worse* than nvidia's.
> At this point, I personally don't want to see this proposal
*ever*
> come up again unless somebody cares about fixing the user experience
> with UEFI.
I think you're being very harsh and short sighted here TBH, like
things like AVX2 it's useful to have these conversations in a civil
manner, even if the original proposal was short sighted and missed a
lot of details and won't happen for years to come.
When aarch64 came along I made the decision that the only way Fedora
would ever support SBCs (like the Pine64, 96boards 410c the first
early boards we supported) was to use UEFI, and one of the SUSE people
agreed, most of the rest of the distros followed along. It makes
things a *LOT* easier for support because we have *one* boot option,
*one* installer path in anaconda so on and so forth. We could have
bodged up extlinux support like armv7 uses, and I got a lot of
pressure to do that. The little extra time it took has overwhelmingly
worth while and actually changed, and continues to, the arm eco-system
(watch the Fedora Arm space over the the next 6+ months for even more
examples of this).
From a Fedora IoT PoV we only support UEFI on any arch we support, the
reason for that is functionality IoT requires to be actually useful in
the field, and for security. While I believe BIOS boot works on x86_64
it's AFAICT it's purely by chance and I won't say this won't break in
the future if we needed to ensure the OS can remain secure. IoT is
lucky in that, like aarch64, we're quite new and don't have "legacy"
users, we may have users that are playing with IoT on legacy HW but I
don't know and all the users/customers/partners I'm speaking with are
using UEFI.
I feel like I wasn't harsh enough when this stuff first landed years
ago. I didn't say anything then because I hoped that it would mean
we'd be able to push more drivers into the kernel. Obviously that was
a failure.
Heck, we now have tacit support for non-free kernel module drivers by
all the commercial Linux companies. Oh well.
--
真実はいつも一つ！/ Always, there's only one truth!
3:33 p.m.
On 7/1/20 6:10 PM, Solomon Peachy wrote:
On Wed, Jul 01, 2020 at 05:19:01PM +0200, Roberto Ragusa wrote:
> I'm currently using BIOS, grub, grub2 basically everywhere, even on
> fresh new machines,
This won't be the case for much longer; Intel will finally drop CSM
("BIOS") support this year.
Even putting that aside, for the past several years CSM/BIOS has been
slowly bitrotting due to a lack of real testing, as the last few Windows
releases have mandated use of UEFI for preinstalled systems, plus the
EOLing of Windows 7 and (especially) XP.
Win 10 still runs on BIOS systems and (Unlike Fedora) on 32bit systems.
Ralf
8:14 p.m.
Solomon Peachy writes:
Even putting that aside, for the past several years CSM/BIOS has
been
slowly bitrotting due to a lack of real testing, as the last few Windows
releases have mandated use of UEFI for preinstalled systems, plus the
EOLing of Windows 7 and (especially) XP.
That's only because it's Microsoft.
I have ten year old hardware that runs just fine, and boots Fedora just
fine. It's built like a tank, it's just as zippy as the day it was new, and
this old Thinkpad will probably outlive me.
It will be a sad day when I can continue to order minor replacement parts
off Amazon, to replace the few worn out ones, but I can't install Fedora on
it.
5:16 a.m.
On Wed, 2020-07-01 at 21:14 -0400, Sam Varshavchik wrote:
Solomon Peachy writes:
> Even putting that aside, for the past several years CSM/BIOS has
> been
> slowly bitrotting due to a lack of real testing, as the last few
> Windows
> releases have mandated use of UEFI for preinstalled systems, plus
> the
> EOLing of Windows 7 and (especially) XP.
That's only because it's Microsoft.
Note that, even though Microsoft is pushing for UEFI on new systems in
the OEM version of Windows, they still support booting in legacy BIOS
mode in the latest Windows 10 version and they even support a 32-bit
version of Windows 10, which Fedora no longer does, so you can install
and run it on even older hardware than Fedora. Even the latest May 2020
update of Windows 10 has a 32-bit retail version that is directly
downloadable from their website:
https://www.microsoft.com/en-us/software-download/windows10ISO
The only Windows that no longer supports 32-bit systems is Windows
Server. So the obsolescence of Windows 7 and XP is irrelevant.
I'm by no means a Microsoft fan, but these are facts. Fedora is pushing
for hardware obsolescence faster than Microsoft in this regard. :(
To be completely fair, I must say that Fedora runs on first generation
AMD64 hardware, while the 64-bit version of Windows no longer does, but
the 32-bit Windows 10 still works on them, and on even earlier CPUs
that are 32-bit only, which Fedora no longer supports.
Best regards,
Nikolay
6:12 a.m.
On 2.7.2020 10:16, nickysn(a)gmail.com wrote:
On Wed, 2020-07-01 at 21:14 -0400, Sam Varshavchik wrote:
> Solomon Peachy writes:
>
>> Even putting that aside, for the past several years CSM/BIOS has
>> been
>> slowly bitrotting due to a lack of real testing, as the last few
>> Windows
>> releases have mandated use of UEFI for preinstalled systems, plus
>> the
>> EOLing of Windows 7 and (especially) XP.
> That's only because it's Microsoft.
Note that, even though Microsoft is pushing for UEFI on new systems in
the OEM version of Windows, they still support booting in legacy BIOS
mode in the latest Windows 10 version and they even support a 32-bit
version of Windows 10, which Fedora no longer does, so you can install
and run it on even older hardware than Fedora. Even the latest May 2020
update of Windows 10 has a 32-bit retail version that is directly
downloadable from their website:
https://www.microsoft.com/en-us/software-download/windows10ISO
The only Windows that no longer supports 32-bit systems is Windows
Server. So the obsolescence of Windows 7 and XP is irrelevant.
I'm by no means a Microsoft fan, but these are facts. Fedora is pushing
for hardware obsolescence faster than Microsoft in this regard. :(
To be completely fair, I must say that Fedora runs on first generation
AMD64 hardware, while the 64-bit version of Windows no longer does, but
the 32-bit Windows 10 still works on them, and on even earlier CPUs
that are 32-bit only, which Fedora no longer supports.
I think linux distribution started to drop 32bit back in 2015 so Fedora
has just been following that trend and Microsoft is seemingly dropping
32bit [1] ( probably no wants to pay for that support anymore supply and
demand).
"** Beginning with Windows 10, version 2004, all new Windows 10 systems
will be required to use 64-bit builds and Microsoft will no longer
release 32-bit builds for OEM distribution."
At one point or another Fedora needs to reach consensus on how old
hardware should be considered "supported" to set realistic end users
expectations accordingly as well as not to find it in a situation in
which an old hw blocks the progress of the distribution or a change of a
primary architecture ( everything seems to be moving to arm these days )
and visa versa ensure that older hw is "supported" for the duration of
that time that it's promised but that's a topic for an entirely
different thread.
JBG
1.
https://docs.microsoft.com/en-us/windows-hardware/design/minimum/minimum-...
7:18 a.m.
On Thu, Jul 02, 2020 at 01:16:43PM +0300, nickysn(a)gmail.com wrote:
The only Windows that no longer supports 32-bit systems is Windows
Server. So the obsolescence of Windows 7 and XP is irrelevant.
I'm not talking about *old* hardware here, which obviously works as well
now as it did before. I'm talking about *new* hardware, which is
vanishingly unlikely to have been tested with anything other than the
current Win10 release.
As Win10 certification does not mandate testing of BIOS/CSM modes, and
all Windows versions that did require that have been completely EOL'd,
new hardware purchased today is likely to only have had the most cursory
testing in BIOS/CSM mode.. if it has BIOS/CSM support at all. (see:
"Intel Dropping BIOS mode by 2020")
So, yes, BIOS/CSM mode works fine for older hardware, but the simple
fact of the matter is that it is going away for new hardware, so it is
no longer something that can be assumed to be there or be more
functionally stable than UEFI.
In other words, if there are bugs/quirks/UX flaws/whatever in the
Fedora's UEFI boot flow, we can no longer just say "oh, just switch to
BIOS/CSM booting instead" as a functionally-acceptible workaround.
But take away BIOS/CSM, and the massive complexity of grub2 becomes
simply unnecessary. Simpler alternatives _should_ be considered.
(Of course, Fedora will need to continue supporting BIOS-based systems
for some time into the future. Speaking for myseelf, I still have two
running systems that that lack UEFI; both are AMD-platform server
boards, and the newer of the two was first made in 2007 and was EOL'd
in 2011. Plus a small pile of VMs..)
- Solomon
--
Solomon Peachy pizza at shaftnet dot org (email&xmpp)
@pizza:shaftnet dot org (matrix)
High Springs, FL speachy (freenode)
10:24 a.m.
On 7/2/20 3:16 AM, nickysn(a)gmail.com wrote:
Note that, even though Microsoft is pushing for UEFI on new systems
in
the OEM version of Windows, they still support booting in legacy BIOS
mode in the latest Windows 10 version and they even support a 32-bit
version of Windows 10, which Fedora no longer does
...
I'm by no means a Microsoft fan, but these are facts. Fedora is pushing
for hardware obsolescence faster than Microsoft in this regard.:(
I think that as far as 32-bit support is concerned, the issue was less
that Fedora pushed for "hardware obsolescence" and more that no one
"pushed" for support. Fedora is a collection of the work of volunteers,
and supporting 32-bit hardware requires more than simply sending SRPMs
through the build pipeline. Things break, and over time there were
fewer volunteers willing and able to fix those problems. The way I
remember it, there were plenty of statements to the effect that as long
as someone was willing to do that work, Fedora would continue to publish
a 32-bit release.
That doesn't strictly apply to discussions about dropping BIOS boot
support, but that doesn't look like it will happen any time soon.
3:35 p.m.
On Thu, 2020-07-02 at 08:24 -0700, Gordon Messmer wrote:
On 7/2/20 3:16 AM, nickysn(a)gmail.com wrote:
> Note that, even though Microsoft is pushing for UEFI on new systems
> in
> the OEM version of Windows, they still support booting in legacy
> BIOS
> mode in the latest Windows 10 version and they even support a 32-
> bit
> version of Windows 10, which Fedora no longer does
> ...
> I'm by no means a Microsoft fan, but these are facts. Fedora is
> pushing
> for hardware obsolescence faster than Microsoft in this regard.:(
I think that as far as 32-bit support is concerned, the issue was
less
that Fedora pushed for "hardware obsolescence" and more that no one
"pushed" for support. Fedora is a collection of the work of
volunteers,
and supporting 32-bit hardware requires more than simply sending
SRPMs
through the build pipeline. Things break, and over time there were
fewer volunteers willing and able to fix those problems. The way Im
remember it, there were plenty of statements to the effect that as
long
as someone was willing to do that work, Fedora would continue to
publish
a 32-bit release.
Yes, I understand the complexities of the issue and the extra
maintenance work. I was just correcting something I perceived as
misinformation or misunderstanding of what Microsoft supports. They've
only disallowed PC vendors such as HP, Dell, Lenovo, etc. from selling
*new* computers with the 32-bit version of Windows preinstalled, but
they continue to support and update the 32-bit version of Windows 10,
even though they've dropped support for Windows 7 and Windows XP.
I, personally, am happy with what Fedora supports - the oldest computer
I still use regularly is a 2004-2006 Socket 939 desktop with an AMD
Athlon 64 X2 4800+ dual core CPU with 4 GB of DDR1 RAM, a PCI Express
graphics card, a SATA hard drive and 2 floppies - a 3.5-inch and a
5.25-inch (I've added them just for fun, just because the motherboard
has a floppy controller, I don't seriously use them :) ). The x86_64
version of Fedora runs just fine on this computer. And so does the 32-
bit of Windows 10, but the 64-bit version has dropped support for it,
because it doesn't support a single instruction, that was added later
to the AMD64 architecture. Luckily, 64-bit Fedora doesn't require it,
so I'm a happy Fedora user! :)
And yes, I know it's high time that I upgrade, but this is my last
desktop computer (all my newer and more powerful computers have been
laptops), and it's just more convenient to use the desktop, while
sitting on my desk at home. :)
And if I had a 32-bit system still in use, I'd probably have
volunteered to help keep the 32-bit x86 Fedora alive, but since the 64-
bit version works for me, I don't have much incentive to do it. :)
That doesn't strictly apply to discussions about dropping BIOS boot
support, but that doesn't look like it will happen any time soon.
Yes, these are separate issues and the legacy BIOS support affects much
newer systems. And it is also less work to maintain legacy BIOS
support, compared to an entire 32-bit version of the operating system.
And btw, I generally agree that grub2 is a little overengineered and
difficult to configure and I think it would benefit if it supported
something like a simpler configuration mode. I like how powerful it is,
but I think the main problem is that it exposes too much complexity in
its configuration file.
Best regards,
Nikolay
3:53 p.m.
On Thursday, July 2, 2020 8:24:49 AM MST Gordon Messmer wrote:
On 7/2/20 3:16 AM, nickysn(a)gmail.com wrote:
> Note that, even though Microsoft is pushing for UEFI on new systems in
> the OEM version of Windows, they still support booting in legacy BIOS
> mode in the latest Windows 10 version and they even support a 32-bit
> version of Windows 10, which Fedora no longer does
> ...
> I'm by no means a Microsoft fan, but these are facts. Fedora is pushing
> for hardware obsolescence faster than Microsoft in this regard.:(
I think that as far as 32-bit support is concerned, the issue was less
that Fedora pushed for "hardware obsolescence" and more that no one
"pushed" for support. Fedora is a collection of the work of volunteers,
and supporting 32-bit hardware requires more than simply sending SRPMs
through the build pipeline. Things break, and over time there were
fewer volunteers willing and able to fix those problems. The way I
remember it, there were plenty of statements to the effect that as long
as someone was willing to do that work, Fedora would continue to publish
a 32-bit release.
That doesn't strictly apply to discussions about dropping BIOS boot
support, but that doesn't look like it will happen any time soon.
That's not really true. When it came down to it, it was dropped while 32 bit
Fedora still worked perfectly. I'm left with 5 systems that will never be
updated as a result. I asked for a list of issues that warranted ending 32 bit
support while it still worked, and got nothing. Two weeks after the proposal,
the announcement was made, and support was dropped.
--
John M. Harris, Jr.
4:12 p.m.
HI
On Thu, Jul 2, 2020 at 4:54 PM John M. Harris Jr
That's not really true. When it came down to it, it was dropped
while 32
bit
Fedora still worked perfectly. I'm left with 5 systems that will never be
updated as a result. I asked for a list of issues that warranted ending 32
bit
support while it still worked, and got nothing. Two weeks after the
proposal,
the announcement was made, and support was dropped.
This is just not true at all. 32-bit was bitrotting and community support
didn't pan out
https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Kernels
"This was last proposed with Fedora 27, but it was deferred as an i686 SIG
was to be created to handle issues going forward. That SIG has been largely
unresponsive."
Rahul
5:09 p.m.
On Thu, Jul 2, 2020 at 10:54 PM John M. Harris Jr <johnmh(a)splentity.com> wrote:
On Thursday, July 2, 2020 8:24:49 AM MST Gordon Messmer wrote:
> On 7/2/20 3:16 AM, nickysn(a)gmail.com wrote:
>
> > Note that, even though Microsoft is pushing for UEFI on new systems in
> > the OEM version of Windows, they still support booting in legacy BIOS
> > mode in the latest Windows 10 version and they even support a 32-bit
> > version of Windows 10, which Fedora no longer does
> > ...
> > I'm by no means a Microsoft fan, but these are facts. Fedora is pushing
> > for hardware obsolescence faster than Microsoft in this regard.:(
>
>
>
> I think that as far as 32-bit support is concerned, the issue was less
> that Fedora pushed for "hardware obsolescence" and more that no one
> "pushed" for support. Fedora is a collection of the work of volunteers,
> and supporting 32-bit hardware requires more than simply sending SRPMs
> through the build pipeline. Things break, and over time there were
> fewer volunteers willing and able to fix those problems. The way I
> remember it, there were plenty of statements to the effect that as long
> as someone was willing to do that work, Fedora would continue to publish
> a 32-bit release.
>
> That doesn't strictly apply to discussions about dropping BIOS boot
> support, but that doesn't look like it will happen any time soon.
That's not really true. When it came down to it, it was dropped while 32 bit
Fedora still worked perfectly. I'm left with 5 systems that will never be
updated as a result. I asked for a list of issues that warranted ending 32 bit
support while it still worked, and got nothing.
That's certainly not true:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
5:22 p.m.
On Thursday, July 2, 2020 3:09:14 PM MST Alexander Ploumistos wrote:
On Thu, Jul 2, 2020 at 10:54 PM John M. Harris Jr
<johnmh(a)splentity.com>
wrote:
>
>
> On Thursday, July 2, 2020 8:24:49 AM MST Gordon Messmer wrote:
>
> > On 7/2/20 3:16 AM, nickysn(a)gmail.com wrote:
> >
> >
> >
> > > Note that, even though Microsoft is pushing for UEFI on new systems
> > > in
> > > the OEM version of Windows, they still support booting in legacy BIOS
> > > mode in the latest Windows 10 version and they even support a 32-bit
> > > version of Windows 10, which Fedora no longer does
> > > ...
> > > I'm by no means a Microsoft fan, but these are facts. Fedora is
> > > pushing
> > > for hardware obsolescence faster than Microsoft in this regard.:(
> >
> >
> >
> >
> >
> > I think that as far as 32-bit support is concerned, the issue was less
> > that Fedora pushed for "hardware obsolescence" and more that no one
> > "pushed" for support. Fedora is a collection of the work of
> > volunteers,
> > and supporting 32-bit hardware requires more than simply sending SRPMs
> > through the build pipeline. Things break, and over time there were
> > fewer volunteers willing and able to fix those problems. The way I
> > remember it, there were plenty of statements to the effect that as long
> > as someone was willing to do that work, Fedora would continue to
> > publish
> > a 32-bit release.
> >
> >
> >
> > That doesn't strictly apply to discussions about dropping BIOS boot
> > support, but that doesn't look like it will happen any time soon.
>
>
>
> That's not really true. When it came down to it, it was dropped while 32
> bit Fedora still worked perfectly. I'm left with 5 systems that will
> never be updated as a result. I asked for a list of issues that warranted
> ending 32 bit support while it still worked, and got nothing.
That's certainly not true:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/
thread/MVOBCE4G7DKZ56CQXF3B53WXF7LXHYXJ/
That's a link to the release announcement. If you follow the thread, you'll
find that I was provided a link to two bugzilla links are to meta links to
blockers, where the items that are blocking are not issues preventing x86
systems from actually functioning. Source: My 5 remaining, functional, F30 x86
systems.
--
John M. Harris, Jr.
5:47 p.m.
On Fri, Jul 3, 2020 at 12:22 AM John M. Harris Jr <johnmh(a)splentity.com> wrote:
That's a link to the release announcement. If you follow the thread, you'll
find that I was provided a link to two bugzilla links are to meta links to
blockers, where the items that are blocking are not issues preventing x86
systems from actually functioning. Source: My 5 remaining, functional, F30 x86
systems.
I had told you then what went wrong with the i686 SIG and since you
had asked for open issues to work on in your free time, I gave you the
links to the two trackers. I guess you haven't found the time to
spare.
5:48 p.m.
On Thursday, July 2, 2020 3:47:00 PM MST Alexander Ploumistos wrote:
On Fri, Jul 3, 2020 at 12:22 AM John M. Harris Jr
<johnmh(a)splentity.com>
wrote:
>
>
> That's a link to the release announcement. If you follow the thread,
> you'll find that I was provided a link to two bugzilla links are to meta
> links to blockers, where the items that are blocking are not issues
> preventing x86 systems from actually functioning. Source: My 5 remaining,
> functional, F30 x86 systems.
I had told you then what went wrong with the i686 SIG and since you
had asked for open issues to work on in your free time, I gave you the
links to the two trackers. I guess you haven't found the time to
spare.
None of the linked blockers are core packages, and some of them are outright
not designed to work on anything other than 64 bit. I really don't understand
how you can see that as justification.
--
John M. Harris, Jr.
6:06 p.m.
Hi
On Thu, Jul 2, 2020 at 6:49 PM John M. Harris Jr wrote:
That's a link to the release announcement.
Hardly the first time it was announced. It refers to x86_32 sig that was
formed much earlier which itself was a response to an earlier warning that
x86_32 support is going away unless people stepped up to support it. Feel
free to look up the threads on that and read up on that history. There was
plenty of time and opportunity for people to step in. Noone was interested
enough AND had the time/skills to do it.
What you earlier claimed was -> I asked for a list of issues that warranted
> ending 32 bit support while it still worked, and got nothing.
This isn't true. You did get a response with links to bugs and your other
claim that these systems worked perfectly isn't correct objectively.
Rahul
1:12 a.m.
On Thursday, July 2, 2020 4:06:07 PM MST Rahul Sundaram wrote:
Hi
On Thu, Jul 2, 2020 at 6:49 PM John M. Harris Jr wrote:
>That's a link to the release announcement.
Hardly the first time it was announced. It refers to x86_32 sig that was
formed much earlier which itself was a response to an earlier warning that
x86_32 support is going away unless people stepped up to support it. Feel
free to look up the threads on that and read up on that history. There was
plenty of time and opportunity for people to step in. Noone was interested
enough AND had the time/skills to do it.
There were less than 13 outstanding issues, and none of them were release
blocking. Not one.
What you earlier claimed was -> I asked for a list of issues that
warranted
> > ending 32 bit support while it still worked, and got nothing.
This isn't true. You did get a response with links to bugs and your other
claim that these systems worked perfectly isn't correct objectively.
None of those bugs were release blocking, and none of them meant that x86
wouldn't boot, or that core packages didn't work. I have 5 Fedora 30 systems
that STILL work with no issues. One of them is running my PBX, in fact. :)
--
John M. Harris, Jr.
5:37 a.m.
Hi
On Fri, Jul 3, 2020 at 2:14 AM John M. Harris wrote:
None of those bugs were release blocking, and none of them meant that x86
wouldn't boot, or that core packages didn't work
When you add so many qualifiers, you are now admitting a) you did get a
response b) that things weren't perfect as you claimed. Those were merely
examples anyway. You can find plenty more in past discussions long before
the decision was made. You cannot possibly believe that an architecture
maintenance only involves a handful of bugs. It requires substantial
resources which aren't free. If you want to reduce your claim to the "many
bugs that did exist and added additional maintenance burden didn't affect
me personally therefore I disagree with the decision made", now that would
be a more reasonable statement if one didn't keep bringing it up in
unrelated discussions.
Rahul
3:31 p.m.
On Friday, July 3, 2020 3:37:34 AM MST Rahul Sundaram wrote:
Hi
On Fri, Jul 3, 2020 at 2:14 AM John M. Harris wrote:
> None of those bugs were release blocking, and none of them meant that x86
> wouldn't boot, or that core packages didn't work
When you add so many qualifiers, you are now admitting a) you did get a
response b) that things weren't perfect as you claimed. Those were merely
examples anyway. You can find plenty more in past discussions long before
the decision was made. You cannot possibly believe that an architecture
maintenance only involves a handful of bugs. It requires substantial
resources which aren't free. If you want to reduce your claim to the "many
bugs that did exist and added additional maintenance burden didn't affect
me personally therefore I disagree with the decision made", now that would
be a more reasonable statement if one didn't keep bringing it up in
unrelated discussions.
These "qualifiers" are important.
1) Yes, I did get a response, as I said in the first email. The response
showed that there weren't any issues with the kernel or core packages at the
time it was dropped.
2) I never said it was perfect, nothing ever is.
I was involved in those past discussions. The bugs in these packages had no
effect on the majority of x86 users, they could still install Fedora, download
a DE of their choice, compile software, open a web browser, etc. There are
currently bugs filed against x64, does that mean we should drop support for
it? For a while, Firefox wasn't compiling on ARM. Does that mean we should
drop that arch?
It's very much related, because the same arguments that were used against x86
have been used here. See:
- It's "legacy"
- It has bugs filed against it
--
John M. Harris, Jr.
11:40 p.m.
Hi
On Fri, Jul 3, 2020 at 4:32 PM John M. Harris Jr wrote:
These "qualifiers" are important.
1) Yes, I did get a response, as I said in the first email. The response
showed that there weren't any issues with the kernel or core packages at
the
time it was dropped.
What you originally said - "I asked for a list of issues that warranted
ending 32 bit
support while it still worked, and got nothing"
2) I never said it was perfect, nothing ever is.
What you originally said - ". When it came down to it, it was dropped while
32 bit
Fedora still worked perfectly."
We are done here
Rahul
12:02 a.m.
On Friday, July 3, 2020 9:40:34 PM MST Rahul Sundaram wrote:
Hi
On Fri, Jul 3, 2020 at 4:32 PM John M. Harris Jr wrote:
> These "qualifiers" are important.
>
> 1) Yes, I did get a response, as I said in the first email. The response
> showed that there weren't any issues with the kernel or core packages at
> the
> time it was dropped.
What you originally said - "I asked for a list of issues that warranted
ending 32 bit
support while it still worked, and got nothing"
There was nothing. Every single bug filed against it was in a package outside
of the default sets for every Spin, including the GNOME Spin.
> 2) I never said it was perfect, nothing ever is.
What you originally said - ". When it came down to it, it was dropped while
32 bit
Fedora still worked perfectly."
It does "work perfectly". That's not the same as saying anything is perfect,
it's a phrase for "Everything works". Every package that is installed in
every
single spin's default packages works. I confirmed this before I tried to join
the x86 SIG at the last minute, as it seemed to be the only way to keep x86
from getting dropped, but it wasn't enough. I pointed out that the issues
filed against x86 were mostly the same as those filed against ARMv7, and that
still didn't matter. Here we are, with x86 dropped while it still works, while
ARMv7 is still kicking around.
--
John M. Harris, Jr.
6:06 p.m.
On Fri, Jul 3, 2020 at 12:49 AM John M. Harris Jr <johnmh(a)splentity.com> wrote:
On Thursday, July 2, 2020 3:47:00 PM MST Alexander Ploumistos wrote:
> On Fri, Jul 3, 2020 at 12:22 AM John M. Harris Jr <johnmh(a)splentity.com>
> wrote:
> >
> >
> > That's a link to the release announcement. If you follow the thread,
> > you'll find that I was provided a link to two bugzilla links are to meta
> > links to blockers, where the items that are blocking are not issues
> > preventing x86 systems from actually functioning. Source: My 5 remaining,
> > functional, F30 x86 systems.
>
>
> I had told you then what went wrong with the i686 SIG and since you
> had asked for open issues to work on in your free time, I gave you the
> links to the two trackers. I guess you haven't found the time to
> spare.
None of the linked blockers are core packages, and some of them are outright
not designed to work on anything other than 64 bit. I really don't understand
how you can see that as justification.
Even though both trackers still receive reports, many packagers just
stopped bothering with i686, because there was little response and
there were long-lasting breakages in rawhide. A distro arch is more
than the kernel; what good is having a 32-bit kernel and nothing to
run on it? See how many i686 bugs are closed as WONTFIX or
INSUFFICIENT_DATA.
1:14 a.m.
On Thursday, July 2, 2020 4:06:55 PM MST Alexander Ploumistos wrote:
On Fri, Jul 3, 2020 at 12:49 AM John M. Harris Jr
<johnmh(a)splentity.com>
> None of the linked blockers are core packages, and some of them are
> outright not designed to work on anything other than 64 bit. I really
> don't understand how you can see that as justification.
Even though both trackers still receive reports, many packagers just
stopped bothering with i686, because there was little response and
there were long-lasting breakages in rawhide. A distro arch is more
than the kernel; what good is having a 32-bit kernel and nothing to
run on it? See how many i686 bugs are closed as WONTFIX or
INSUFFICIENT_DATA.
There's more to core packages than just the kernel. There were no bugs in the
default install of Fedora Server or Fedora KDE Spin or GNOME Spin.
--
John M. Harris, Jr.
1:45 a.m.
Can we maybe not restart this entire debate? i686 in Fedora has run down
the curtain and joined the choir invisible. Whether we think that was
the correct decision or not, there is absolutely no point in rehashing
all the original arguments, let alone in a thread about BIOS support.
Christopher
On 03.07.20 08:14, John M. Harris Jr wrote:
On Thursday, July 2, 2020 4:06:55 PM MST Alexander Ploumistos wrote:
> On Fri, Jul 3, 2020 at 12:49 AM John M. Harris Jr <johnmh(a)splentity.com>
>> None of the linked blockers are core packages, and some of them are
>> outright not designed to work on anything other than 64 bit. I really
>> don't understand how you can see that as justification.
>
> Even though both trackers still receive reports, many packagers just
> stopped bothering with i686, because there was little response and
> there were long-lasting breakages in rawhide. A distro arch is more
> than the kernel; what good is having a 32-bit kernel and nothing to
> run on it? See how many i686 bugs are closed as WONTFIX or
> INSUFFICIENT_DATA.
There's more to core packages than just the kernel. There were no bugs in the
default install of Fedora Server or Fedora KDE Spin or GNOME Spin.
1:53 a.m.
On Thursday, July 2, 2020 11:45:09 PM MST Christopher Engelhard wrote:
Can we maybe not restart this entire debate? i686 in Fedora has run
down
the curtain and joined the choir invisible. Whether we think that was
the correct decision or not, there is absolutely no point in rehashing
all the original arguments, let alone in a thread about BIOS support.
Well, it's a very similar issue. Let's not break what works, needlessly, as
was done with i686.
--
John M. Harris, Jr.
5:24 p.m.
Question about systemd-boot vs GRUB2.
One of the current stumbling blocks is the lack of LUKS2 support in
GRUB2. Does sytemd-boot support LUKS2?
5:33 p.m.
On Thu, Jul 2, 2020 at 6:24 PM Alex Thomas <karlthane(a)gmail.com> wrote:
Question about systemd-boot vs GRUB2.
One of the current stumbling blocks is the lack of LUKS2 support in
GRUB2. Does sytemd-boot support LUKS2?
GRUB2 supports LUKS2 in v2.06. sd-boot does not support it.
--
真実はいつも一つ！/ Always, there's only one truth!
5:38 p.m.
Ok thought I had read somewhere that is was in the pipeline but had
not merged. Must be old data.
On Thu, Jul 2, 2020 at 5:34 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>
> On Thu, Jul 2, 2020 at 6:24 PM Alex Thomas <karlthane(a)gmail.com> wrote:
> >
> > Question about systemd-boot vs GRUB2.
> > One of the current stumbling blocks is the lack of LUKS2 support in
> > GRUB2. Does sytemd-boot support LUKS2?
>
> GRUB2 supports LUKS2 in v2.06. sd-boot does not support it.
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
11:23 a.m.
On Do, 02.07.20 17:24, Alex Thomas (karlthane(a)gmail.com) wrote:
Question about systemd-boot vs GRUB2.
One of the current stumbling blocks is the lack of LUKS2 support in
GRUB2. Does sytemd-boot support LUKS2?
No it does not. Why would you encrypt your kernel/initrd?
On UEFI you have to have an unencrypted partition anyway, because
that's what the UEFI firmware boots from. Even if you boot with Grub:
the first step is always a VFAT file system (the ESP), without
encryption or anything.
sd-boot simply decides that the VFAT support in the firmware is OK to
load kernels/initrds from too, to make things simple, i.e. reuse the
existing storage stack you cannot avoid anyway.
Lennart
--
Lennart Poettering, Berlin
2:10 p.m.
On Tue, Jun 30, 2020, at 9:34 AM, 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
Among other clouds, AWS doesn't support it and has no plans to do so. So...yeah,
we're not going to be removing BIOS support from Fedora CoreOS at least.
(GCP does support UEFI and even has a virtual TPM, which is pretty cool)
3:31 p.m.
On 6/30/20 3:34 PM, 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 supported boot which
has been available on any common intel based x86 platform since atleast
2005.
This statement is simply not true - With all due respect, I for one
consider this statement of yours to be close to a blatant cheat and a lie.
I definitely own BIOS-only systems, which have been sold long after 2005
and which are still in everyday use.
Now in 2017 Intel's technical marketing engineer Brian Richardson
revealed in a presentation that the company will require UEFI Class 3
and above as in it would remove legacy BIOS support from its client and
datacenter platforms by 2020 and one might expect AMD to follow Intel in
this regard.
Fedora should not care Intel's plans, but about the systems users use.
IMNSHO, this inevitably must comprise to continueg supporting
BIOS-systems for at least another decade.
This post is just to gather feed back why Fedora should still
continue
to support legacy BIOS boot as opposed to stop supporting it and
potentially drop grub2 and use sd-boot instead.
Definitely the former.
Share your thoughts and comments on how such move might affect you so
feedback can be collected for the future on why such a change might be
bad, how it might affect the distribution and scope of such change can
be determined for potential system wide proposal.
Dropping BIOS would render Fedora entire unsuitable for me and will like
cause me to stop supporting Fedora.
Ralf
4 p.m.
On Wed, Jul 1, 2020 at 10:31 pm, Ralf Corsepius <rc040203(a)freenet.de>
wrote:
I definitely own BIOS-only systems, which have been sold long after
2005
and which are still in everyday use.
If we're looking for more data points, my System76 laptop is from 2015
(still just under five years old!) and only supports legacy BIOS.
4:39 p.m.
I second your point.
I don't see any upside to discontinue support of legacy BIOS. Even my latest machine
support legacy BIOS. UEFI caused more headache to me than bringing in any real positive
user experiences.
Fix all your bugs not even securities bugs before you concern the securities features
brought by UEFI.
4:42 p.m.
On 1.7.2020 21:39, Ricky Zhang wrote:
I second your point.
I don't see any upside to discontinue support of legacy BIOS. Even my latest machine
support legacy BIOS. UEFI caused more headache to me than bringing in any real positive
user experiences.
What headache exactly? You had bad user experience with UEFI because ?
JBG
4:40 p.m.
On 1.7.2020 20:31, Ralf Corsepius wrote:
On 6/30/20 3:34 PM, 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
> supported boot which has been available on any common intel based x86
> platform since atleast 2005.
This statement is simply not true - With all due respect, I for one
consider this statement of yours to be close to a blatant cheat and a
lie.
Well I got this from the internet it was not as I intentionally meant to
cheat or lie. Obviously I did not do a proper research or enough digging
on Intel website to obtain correct information or this simply was some
form of marketing speak from Intel, I mean what is "common intel based
x86 platform"?
JBG
4:36 p.m.
No, I strongly disagree your proposal.
Don't break something that works. I have several home machines installing in legacy
BIOS way.
I have followed upgrade path **SMOOTHLY** from Fedora Core 14 up to Fedora 32 today.
Your change will break my dual-boot / multi-boot machines.
Please don't.
5:17 p.m.
I've got a pair of admittedly old desktop machines that are BIOS-only that run Fedora
32 just fine. No reason they can't continue to run Fedora into the future - unless
BIOS boot is eliminated.
9:07 a.m.
Dropping the "legacy BIOS" support is a horrible idea:
Not just there are a lot of "legacy BIOS" PCs, especially in a corporate world
where the upgrades are slower than in the domestic environments.
There are also a lot of really modern PCs running a coreboot firmware with a SeaBIOS
payload - which is a modern "legacy BIOS" written in C.
SeaBIOS has just 50k code lines: infinitely slimmer and much more efficient than a bloated
UEFI abomination, even a Tianocore opensource one.
UEFI is a "SystemD of a BIOS world", in a horrible way.
Well, if you'd drop a Legacy BIOS support, more of the coreboot opensource BIOS people
will move to the other distros,
hopefully those which don't have a SystemD security-vulnerable bloatware - for
example, Artix Linux, great user-friendly Arch without SystemD.
So please go ahead and drop "legacy BIOS" support, so there would be one more
reason for us to abandon Fedora with a SystemD hardcoded into it.
9:50 a.m.
On Thu, Jul 02, 2020 at 02:07:17PM -0000, Ivan Ivanov wrote:
hopefully those which don't have a SystemD security-vulnerable
bloatware
Oh, FFS.
In this comparison, grub2 is the _highly_ bloated,
everything-AND-the-kitchen-sink solution with multiple CVEs under its
belt, and systemd-boot is the lean, tightly-focused do-only-one-thing
tool without any reported CVEs.
(seriously, the most recent systemd tarball is over 2.5MB smaller than
the most recent grub2 tarball)
- Solomon
--
Solomon Peachy pizza at shaftnet dot org (email&xmpp)
@pizza:shaftnet dot org (matrix)
High Springs, FL speachy (freenode)
4 p.m.
On Thursday, July 2, 2020 7:50:25 AM MST Solomon Peachy wrote:
On Thu, Jul 02, 2020 at 02:07:17PM -0000, Ivan Ivanov wrote:
> hopefully those which don't have a SystemD security-vulnerable
> bloatware
Oh, FFS.
In this comparison, grub2 is the _highly_ bloated,
everything-AND-the-kitchen-sink solution with multiple CVEs under its
belt, and systemd-boot is the lean, tightly-focused do-only-one-thing
tool without any reported CVEs.
(seriously, the most recent systemd tarball is over 2.5MB smaller than
the most recent grub2 tarball)
- Solomon
If it doesn't have any reported CVEs, that's because nobody uses it.
--
John M. Harris, Jr.
8:56 p.m.
On Thu, Jul 02, 2020 at 02:00:16PM -0700, John M. Harris Jr wrote:
If it doesn't have any reported CVEs, that's because nobody
uses it.
You may be right, but one can't have vulnerabilies in functionality that
doesn't exist.
(I find it hilarious that "small, simple, single-purpose" is suddenly a
bad thing when it's in systemd's favor..)
- Solomon
--
Solomon Peachy pizza at shaftnet dot org (email&xmpp)
@pizza:shaftnet dot org (matrix)
High Springs, FL speachy (freenode)
1:15 a.m.
On Thursday, July 2, 2020 6:56:03 PM MST Solomon Peachy wrote:
On Thu, Jul 02, 2020 at 02:00:16PM -0700, John M. Harris Jr wrote:
> If it doesn't have any reported CVEs, that's because nobody uses it.
You may be right, but one can't have vulnerabilies in functionality that
doesn't exist.
(I find it hilarious that "small, simple, single-purpose" is suddenly a
bad thing when it's in systemd's favor..)
It's a bad thing when it can't boot Fedora systems. A bootloader's job is to
load the kernel and initramfs, then execute. If it can't do that, it's not
usable.
--
John M. Harris, Jr.
5:42 p.m.
I just came from Windows 10 not too long ago, and it was the worst computer experience
that I've ever had. Had it since the first week it came out, so glad that I don't
see it anymore. Hope I never see it again. It was really rough getting my laptop
downgraded to Windows 7, since my pc was being remote controlled to stop me from leaving
10. Had to shut my pc off and lock the BIOS with a password until I could install Windows
7. While I'm familiar with Windows 7, I would like to leave Windows behind completely.
Currently have a dual booted system.
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 Boot is the only way that I can run a
different OS. Despite factory reseting it and doing a clean install of Windows 7, I still
can't use UEFI at all. My laptop isn't that old either, (about a year and a half)
in fact it was really hard to get my intel drivers working since Intel doesn't support
downgrading with newer hardware that's designed for Windows 10 from what I can see.
I'm new to Linux and have only recently gotten used to Fedora, but if it goes to where
only UEFI is supported I will have to unfortunately go elsewhere.
While my laptop is 64 bit, I know of a lot of computers that are 32 bit and as cool as the
newest software is not everyone switches over. Some people like to stay with the same
configuration for years. I do feel that large companies want people to make the switch to
the newer stuff, but it just isn't always practical for some. I don't know any
computer programming languages, so I don't really know if there are inconvieniences to
keep Legacy Boot. Anyway, this is just my take on it.
6:46 a.m.
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 Boot is the only way that I can run a different OS.
Despite factory reseting it and doing a clean install of Windows 7, I
still can't use UEFI at all. My laptop isn't that old either, (about a
year and a half) in fact it was really hard to get my intel drivers
working since Intel doesn't support downgrading with newer hardware
that's designed for Windows 10 from what I can see. I'm new to Linux
and have only recently gotten used to Fedora, but if it goes to where
only UEFI is supported I will have to unfortunately go elsewhere.
That sadly happens when vendors modify the reference UEFI firmware to
support booting Windows only. For example, one of my machines has
"Windows Boot Manager" hard-coded as the only boot entry it can boot,
so I was able to boot Fedora with UEFI and SecureBoot enabled only by
renaming the Fedora boot entry to "Windows Boot Manager". :)
Regards,
Dominik
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
8:24 a.m.
This post is just to gather feed back why Fedora should still
continue
to support legacy BIOS boot as opposed to stop supporting it
Fedora should absolutely CONTINUE supporting BIOS boot (sometimes wrongly labeled
"legacy BIOS").
Some of the finest hardware around uses trusty BIOS and we already have enough planned
obsolescence in other areas for invalid reasons.
BIOS will be cherished for decades to come!
Fedora does not want to lose out in the huge BIOS based market.
8:44 a.m.
On Sat, Jul 04, 2020 at 01:24:46PM -0000, ziba wrote:
Fedora should absolutely CONTINUE supporting BIOS boot (sometimes
wrongly
labeled "legacy BIOS").
Yep, Fedora should continue supporting BIOS boot at least for the next
few years. This question will surely be revisited after the remaining
x86 CPU makers join Intel in formally droping BIOS support (and quite
possibly the 16-bit CPU modes needed to boot via BIOS!)
And yes, "legacy BIOS" is an accurate term. It is an obelete, long
deprecated, and soon-to-be-retired system with insurmountable technical
limitations including a hard 2TB upper limit on drive sizes that we've
been running into for more than a decade.
(2TB SATA drives have been available since at least mid-2009.
Meanwhile, folks with hardware RAID controllers have been running into
this problem even longer)
BIOS will be cherished for decades to come!
s/cherished/despised/
Fortunately, decades from now, BIOS systems will only exist in museums
and emulators.
Fedora does not want to lose out in the huge BIOS based market.
BIOS-based systems make up a miniscule minority of the current market.
Pretending otherwise is delusional, and delusions are no basis for
technical decisions.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org (email&xmpp)
@pizza:shaftnet dot org (matrix)
High Springs, FL speachy (freenode)
11:08 a.m.
On Sat, 2020-07-04 at 09:44 -0400, Solomon Peachy wrote:
On Sat, Jul 04, 2020 at 01:24:46PM -0000, ziba wrote:
> Fedora should absolutely CONTINUE supporting BIOS boot (sometimes
> wrongly
> labeled "legacy BIOS").
Yep, Fedora should continue supporting BIOS boot at least for the
next
few years. This question will surely be revisited after the
remaining
x86 CPU makers join Intel in formally droping BIOS support (and
quite
possibly the 16-bit CPU modes needed to boot via BIOS!)
While the former will probably happen, I consider the latter to be
quite unlikely, considering the fact that the CPU can execute 16-bit
instructions even in long mode, so they can never be dropped
completely. Yes, even in x86_64 code (although, a subset of them has
been removed from there). But here's an example of some gcc generated
code:
int main()
{
short a = 5;
short b = 7;
short c = a + b;
}
compiled with: gcc gcc_16bit_example.c
happily produces 16-bit instructions, such as:
40110a: 66 c7 45 fe 05 00 movw $0x5,-0x2(%rbp)
401110: 66 c7 45 fc 07 00 movw $0x7,-0x4(%rbp)
401120: 66 89 45 fa mov %ax,-0x6(%rbp)
(disassembly produced by 'objdump -d a.out')
And for 32-bit code, the CPU needs to support the entire 16-bit
instruction set anyway, because it's a proper subset.
The CPU could probably safely drop real mode if BIOS support is
completely dropped, but since it still needs to maintain support for
the entire 16-bit instruction set, in order to run 32-bit and 64-bit
code, it's unlikely this will save a lot of transistors. And it will
mess up with virtualization hosts, because AFAIK modern Intel CPUs have
hardware virtualization support for real mode as well.
And yes, "legacy BIOS" is an accurate term. It is an obelete, long
deprecated, and soon-to-be-retired system with insurmountable
technical
limitations including a hard 2TB upper limit on drive sizes that
we've
been running into for more than a decade.
(2TB SATA drives have been available since at least mid-2009.
Meanwhile, folks with hardware RAID controllers have been running
into
this problem even longer)
Yes, it's one of the reasons I didn't use legacy mode on my server. But
currently, it's a tradeoff - laptops and desktops, for example, rarely
have hard drives larger than 2TB, and quite often UEFI mode is less
stable, due to firmware bugs, etc. Also, there are programs such as
memtest86+ which don't support UEFI yet, so even smart users may
sometimes prefer to use legacy mode, because it simply and objectively
works better for them.
> BIOS will be cherished for decades to come!
s/cherished/despised/
Both are emotional words, that shouldn't be part of an objective and
rational discussion. Despise it how much you want, it hasn't gone away,
and still needs to be supported. Cherish it as much as you want, one
day it will no longer need to be supported. I love old 8-bit and 16-bit
computers, but don't expect Fedora to be able to work on them. :)
Fortunately, decades from now, BIOS systems will only exist in
museums
and emulators.
Nobody knows what would happen decades from now. x86 might be obsolete
by them. Or it might still be alive. Let's not worry about that far in
the future. To put things into perspective, I remember when in 1998 my
friends were telling me x86 would be dead in a couple of years, because
Intel's next gen ISA (I think it had the code name Merced at the time,
which later became Itanium) was significantly different. 22 years
later, we're discussing in how many years it's going to be safe to drop
legacy BIOS support, and my 2019 laptop can still boot MS-DOS 6.22, if
I'm crazy enough to try it (and yes, I have tried it, just for fun, it
works, as long as you allocate a primary partition for it in the first
8 GB of the hard drive! :) )
> Fedora does not want to lose out in the huge BIOS based market.
BIOS-based systems make up a miniscule minority of the current
market.
Pretending otherwise is delusional, and delusions are no basis for
technical decisions.
I think the discussion is swaying too much in the direction of a
religious war, with increasingly polarizing opinions on both sides.
Yes, BIOS is legacy, but I find UEFI users to be living in a bubble as
well. Dropping BIOS support entirely is not realistic in the next 5-10
years and the number of users using legacy mode on UEFI is probably
surprisingly high. Behind these are probably a huge number of bugs,
hidden in the current UEFI implementations in computers, that aren't
considered "obsolete". Microsoft's alleged dropping of BIOS support is
also extremely exaggerated - it only applies to the OEM version for new
systems, for existing systems they even support a fully 32-bit version
of Windows 10 and the 64-bit version supports BIOS without any
problems.
I think, if we have to be objective, the maintainenance burden of
supporting BIOS is relatively small, compared to e.g. i686 support, the
number of users that use it is quite high, compared to the i686 users.
And it's perfectly testable even on new computers that don't have
legacy mode, thanks to virtual machines and SeaBIOS. And operating
system installers and bootloaders should be tested in virtual machines
first, anyway :)
Best regards,
Nikolay
7:24 p.m.
On Saturday, July 4, 2020 6:44:55 AM MST Solomon Peachy wrote:
On Sat, Jul 04, 2020 at 01:24:46PM -0000, ziba wrote:
> Fedora should absolutely CONTINUE supporting BIOS boot (sometimes wrongly
> labeled "legacy BIOS").
Yep, Fedora should continue supporting BIOS boot at least for the next
few years. This question will surely be revisited after the remaining
x86 CPU makers join Intel in formally droping BIOS support (and quite
possibly the 16-bit CPU modes needed to boot via BIOS!)
And yes, "legacy BIOS" is an accurate term. It is an obelete, long
deprecated, and soon-to-be-retired system with insurmountable technical
limitations including a hard 2TB upper limit on drive sizes that we've
been running into for more than a decade.
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
booting from BIOS.
(2TB SATA drives have been available since at least mid-2009.
Meanwhile, folks with hardware RAID controllers have been running into
this problem even longer)
I don't know where you got this, but that's completely false. You can use GPT
partition tables on systems with BIOS boot. Whoever told you otherwise is
misinformed at best.
> BIOS will be cherished for decades to come!
s/cherished/despised/
Why do you "despise" BIOS boot?
Fortunately, decades from now, BIOS systems will only exist in
museums
and emulators.
I highly doubt that, but time will tell.
> Fedora does not want to lose out in the huge BIOS based market.
BIOS-based systems make up a miniscule minority of the current market.
Pretending otherwise is delusional, and delusions are no basis for
technical decisions.
That's absolutely false, as demonstrated elsewhere in this thread. Pretending
otherwise is delusional, and delusions are no basis for technical decisions.
--
John M. Harris, Jr.
10:10 p.m.
On Sat, Jul 04, 2020 at 05:24:05PM -0700, John M. Harris Jr 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.
Lots of hardware has a very long tail -- For example, Intel didn't
actually stop making the 80386 and 80486 until late 2007, yet Fedora
never ran on anything older than the original Pentium, which was a full
decade old when FC1 landed in 2003.
There is no 2TB upper limit on drive sizes as a result of booting
from
BIOS.
I still have two BIOS-only systems in production that can't handle a
_boot_ drive over 2TB in size. (They also can't boot off of USB sticks)
I don't know where you got this, but that's completely false.
You can use GPT
partition tables on systems with BIOS boot. Whoever told you otherwise is
misinformed at best.
Of course folks can use use GPT partitioning with BIOS; they just can't
boot off of it.
Why do you "despise" BIOS boot?
There are better, simpler booting mechanisms that don't require
emulating the behavior (and working around the limitations) of the
40-year-old original IBM PC and the even-older i8086.
No matter how you or I feel about legacy BIOS booting, Intel has ended
support for it, so Fedora *must* be ready for a UEFI-only future. We
can no longer tell folks "just revert to BIOS boot to fix problem X"
(But at the same time Fedora has to continue to support BIOS booting for
the forseable future, because there's still a considerable install base
of BIOS-boot systems)
> BIOS-based systems make up a miniscule minority of the current
market.
> Pretending otherwise is delusional, and delusions are no basis for
> technical decisions.
That's absolutely false, as demonstrated elsewhere in this thread.
Pretending otherwise is delusional, and delusions are no basis for
technical decisions.
I have hard data to back up my assertions. What do you have?
Fine, I'll show my work.
There were 260-odd-million "PCs" shipped in 2019, and about another 12
million physical servers, according to IDC. (Note this explicitly
excludes Chromebooks) For simplicty's sake, let's assume all servers run
Linux, along with a generous 2% of the desktop market. This leaves
Apple and Windows with about 94% of the 2019 market.
Every one of those shipped Apple and Windows-based systems boots using
UEFI. Even if we (falsely) assume that every single linux system boots
using BIOS instead of UEFI, that means that in 2019, BIOS-booting
systems make up *at most* 6% of the market.
Mind you, that's BIOS-booting, not BIOS-only. The actual BIOS-only
numbers will be *much* smaller, for the simple reason that OEMs
generally need to have their hardware able to pass Windows
Certification, which means the presence of full UEFI, even on servers.
The ones that don't care about Windows certification are boutique OEMs
like System76 and folks that make very long-lifecycle industrial systems
meant to run generally ancient software, neither of which ship in any
appreciable volume compared to general-purpose desktops and laptops.
(System76 in particular is a private company, but the public data I've
found caps their annual revenues at about $50M, which, assuming an
average price of $1000/system, gives them only 50,000 units/year.
That's less than 0.02% market share)
So yes, BIOS-only systems represent a *miniscule* portion of the market
today, and that will only decrease further. Pretending otherwise is
delusional.
I stand by what I've written, and I've backed it up with actual numbers
and only a minor amount of conjecture.
Please, prove me wrong.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org (email&xmpp)
@pizza:shaftnet dot org (matrix)
High Springs, FL speachy (freenode)
11:51 p.m.
On Saturday, July 4, 2020 8:10:49 PM MST Solomon Peachy wrote:
On Sat, Jul 04, 2020 at 05:24:05PM -0700, John M. Harris Jr 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.
Lots of hardware has a very long tail -- For example, Intel didn't
actually stop making the 80386 and 80486 until late 2007, yet Fedora
never ran on anything older than the original Pentium, which was a full
decade old when FC1 landed in 2003.
Many people on this very thread are still using BIOS boot systems, and one
person provided a source for a NEW system they're using which is BIOS boot,
while another provided factory-default BIOS configurations on hardware
supporting UEFI. That's hardly similar the case you're referencing.
> There is no 2TB upper limit on drive sizes as a result of
booting from
> BIOS.
I still have two BIOS-only systems in production that can't handle a
_boot_ drive over 2TB in size. (They also can't boot off of USB sticks)
It can actually do both, I can dig up the solution that was provided to me,
using GRUB2, from the thread where they tried to kill off optical media.
> I don't know where you got this, but that's completely
false. You can use
> GPT partition tables on systems with BIOS boot. Whoever told you
> otherwise is misinformed at best.
Of course folks can use use GPT partitioning with BIOS; they just can't
boot off of it.
You can boot off of it, so long as you're using GRUB2. GRUB2 loads from MBR,
parses the GPT, and boom, 2TB or larger partitions on BIOS.
> Why do you "despise" BIOS boot?
There are better, simpler booting mechanisms that don't require
emulating the behavior (and working around the limitations) of the
40-year-old original IBM PC and the even-older i8086.
No matter how you or I feel about legacy BIOS booting, Intel has
ended
support for it, so Fedora *must* be ready for a UEFI-only future. We
can no longer tell folks "just revert to BIOS boot to fix problem X"
Intel has NOT ended support for it. Anyone claiming as much is delusional at
best. We can continue to tell people "just revert to BIOS boot to fix problem
X" or "Disable Secure Boot to fix problem Y". Fedora is already fine on
systems that only support UEFI, using GRUB2 UEFI.
(But at the same time Fedora has to continue to support BIOS booting
for
the forseable future, because there's still a considerable install base
of BIOS-boot systems)
Yes, and there will be for decades to come. BIOS isn't going away any time
soon, just like broken EFI implementations aren't going away.
> > BIOS-based systems make up a miniscule minority of the
current market.
> > Pretending otherwise is delusional, and delusions are no basis for
> > technical decisions.
>
> That's absolutely false, as demonstrated elsewhere in this thread.
> Pretending otherwise is delusional, and delusions are no basis for
> technical decisions.
I have hard data to back up my assertions. What do you have?
Please read this thread before replying. I've had to repeat myself on this
several times now, as have others.
Fine, I'll show my work.
There were 260-odd-million "PCs" shipped in 2019, and about another 12
million physical servers, according to IDC. (Note this explicitly
excludes Chromebooks) For simplicty's sake, let's assume all servers run
Linux, along with a generous 2% of the desktop market. This leaves
Apple and Windows with about 94% of the 2019 market.
Every one of those shipped Apple and Windows-based systems boots using
UEFI.
That's not the case, as cited earlier in this thread.
Even if we (falsely) assume that every single linux system boots
using BIOS instead of UEFI, that means that in 2019, BIOS-booting
systems make up *at most* 6% of the market.
Based on what? Are you assuming Linux is only on servers? As cited elsewhere
in this thread, most servers, in fact, do have better BIOS support than UEFI
support, with some weird quirks. If you're interested, I could give you some
interesting stories about Dell's current generation PowerEdge servers, which
have some BIOS/UEFI weirdness going on. They're BIOS boot by default, and will
*then* load the EFI framework if you've enabled EFI, or try to load one of the
vendor apps.
Mind you, that's BIOS-booting, not BIOS-only. The actual
BIOS-only
numbers will be *much* smaller, for the simple reason that OEMs
generally need to have their hardware able to pass Windows
Certification, which means the presence of full UEFI, even on servers.
The ones that don't care about Windows certification are boutique OEMs
like System76 and folks that make very long-lifecycle industrial systems
meant to run generally ancient software, neither of which ship in any
appreciable volume compared to general-purpose desktops and laptops.
As well as any small to medium OEM. Most OEMs don't actually care about
Windows Certification.
(System76 in particular is a private company, but the public data
I've
found caps their annual revenues at about $50M, which, assuming an
average price of $1000/system, gives them only 50,000 units/year.
That's less than 0.02% market share)
So yes, BIOS-only systems represent a *miniscule* portion of the market
today, and that will only decrease further. Pretending otherwise is
delusional.
You do realize that people use the systems they've already got? We don't trash
our current, working systems every Fedora release and buy a new one.
I stand by what I've written, and I've backed it up with
actual numbers
and only a minor amount of conjecture.
Let's be honest, neither my numbers nor yours even matter in this, beyond
subjective arguments. If we want to make objective claims based on numbers,
we'd need to figure out how many Fedora users have systems 1) supporting UEFI
2) using UEFI.
--
John M. Harris, Jr.
2:18 p.m.
On Sat, Jul 04, 2020 at 09:51:30PM -0700, John M. Harris Jr wrote:
Many people on this very thread are still using BIOS boot systems,
and one
person provided a source for a NEW system they're using which is BIOS boot,
while another provided factory-default BIOS configurations on hardware
supporting UEFI. That's hardly similar the case you're referencing.
When have I ever said those systems don't exist? All I've ever said is
that those systems represent a miniscule (and ever-shrinking) portion of
the market.
I'd wager that more 32-bit-only x86 systems are still sold than
BIOS-boot-only ones, and Fedora already dropped support for the former.
(btw, You keep mixing up "bios-boot-only" and "bios-boot-capable" --
please pick one and stick with it; it'll make your arguments more
coherent)
It can actually do both, I can dig up the solution that was provided
to me,
using GRUB2, from the thread where they tried to kill off optical media.
Does the Fedora installer actually do this, or is it a brittle
manually-applied hack that could get trashed by anything that wants to
manipulate the MBR? (eg gparted)
(What I did to get around this the last time was to use a small
IDE-attached CF card for /boot. That system used mdraid so it also
made for a vastly simpler partitioning layout)
Intel has NOT ended support for it. Anyone claiming as much is
delusional at
best.
I'm sorry, I'm going to trust Intel's word over yours.
(Now if Intel has backtracked or changed their plans to "require UEFI
class 3 on all client and datacenter platforms by 2020", they've not
seemed to have publicly stated that anywhere)
> Every one of those shipped Apple and Windows-based systems boots
using
> UEFI.
That's not the case, as cited earlier in this thread.
Please actually *read* what I am writing. That 94% market share
represents *new systems* *shipped* with Apple or Microsoft operating
systems.
Macs have been UEFI-only since 2007, and since 2012 Microsoft has
required UEFI for systems shipping with Windows 8 (or newer) Thus, every
one of the 253 million Windows and Mac systems shipped in 2019 were
booting with UEFI. Furthermore, starting in November 2016 Microsoft
disallowed new system sales with Windows 7 (ie the last of the
non-EFI-required-for-preinstalls version) -- so every system shipped
with Windows or MacOS in the past *four years* has required use of UEFI.
(That's more than a *billion* systems!)
...Seriously, these are hard facts, and not something up for debate.
Based on what? Are you assuming Linux is only on servers?
No, as I wrote, I assumed Linux is on all servers and 2% of non-server
PCs, for a combined total of aobut 6% of 2019 shipped units. The real
numbers are less than this, as not all servers are shipped with/for
Linux, and that 2% desktop linux represents the estimated install base
rather than shipping market share.
As cited elsewhere in this thread, most servers, in fact, do have
better BIOS support than UEFI support, with some weird quirks.
You act like there have never been "wierd quirks" with BIOS-based
systems, especially in the takes-five-minutes-to-get-to-grub server
realm.
Vendor firmware bugs are a fact of life. Some get fixed; most others
have to be worked around one way or another.
As well as any small to medium OEM. Most OEMs don't actually care
about
Windows Certification.
Anyone selling systems with Windows preinstalled will care, which means
their suppliers and OEMs will care, because they don't want to get
locked out of the massive market that Windows represents.
(Small Boutique OEMs and embedded/industrial niches notwithstanding, of
course. There's a _very_ long tail of stuff like that. FFS, look at
the diehard Amiga folks..)
Let's be honest, neither my numbers nor yours even matter in
this,
beyond subjective arguments. If we want to make objective claims based
on numbers, we'd need to figure out how many Fedora users have systems
1) supporting UEFI 2) using UEFI.
Of course. We need actual numbers if we're to make informed decisions.
Anectdotally, of the sxiteen physical Fedora/CentOS x86 systems I'm
directly responsible for, all but two support (and also boot from) UEFI.
I hope to finally re-retire the older of the two in a few weeks,
replacing it with a machine only half its age.
(There's also a small pile of VMs too, generally used as build hosts or
for QA-type work. Nearly all are considered disposable and can be easily
recreated)
For the record, I think any notion of auto-migrating systems from BIOS
to UEFI booting is insane. And any talk of retiring BIOS support in
Fedora should probably be put off until the F40 timeframe.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org (email&xmpp)
@pizza:shaftnet dot org (matrix)
High Springs, FL speachy (freenode)
2:37 p.m.
On Sunday, July 5, 2020 12:18:46 PM MST Solomon Peachy wrote:
On Sat, Jul 04, 2020 at 09:51:30PM -0700, John M. Harris Jr wrote:
> Many people on this very thread are still using BIOS boot systems, and one
> person provided a source for a NEW system they're using which is BIOS
> boot,
> while another provided factory-default BIOS configurations on hardware
> supporting UEFI. That's hardly similar the case you're referencing.
When have I ever said those systems don't exist? All I've ever said is
that those systems represent a miniscule (and ever-shrinking) portion of
the market.
I'd wager that more 32-bit-only x86 systems are still sold than
BIOS-boot-only ones, and Fedora already dropped support for the former.
(btw, You keep mixing up "bios-boot-only" and "bios-boot-capable" --
please pick one and stick with it; it'll make your arguments more
coherent)
I don't keep mixing them up, but they're similar cases. As mentioned elsewhere
in the thread, if the vendor disabled UEFI on UEFI-capable systems, the end
user is likely to leave it that way.
> It can actually do both, I can dig up the solution that was
provided to
> me,
> using GRUB2, from the thread where they tried to kill off optical media.
Does the Fedora installer actually do this, or is it a brittle
manually-applied hack that could get trashed by anything that wants to
manipulate the MBR? (eg gparted)
No, the Fedora installer doesn't create a USB boot entry.. Why would it? It
was used to chainload the Fedora installer on systems that don't support USB
boot. Also, it's not a hack. This is just one of the many things GRUB2
supports. It's a very powerful bootloader.
(What I did to get around this the last time was to use a small
IDE-attached CF card for /boot. That system used mdraid so it also
made for a vastly simpler partitioning layout)
> Intel has NOT ended support for it. Anyone claiming as much is delusional
> at best.
I'm sorry, I'm going to trust Intel's word over yours.
Where has Intel actually published anything saying BIOS boot will no longer be
available? I can only find articles from 2017, where it was proposed in a
presentation.
> > Every one of those shipped Apple and Windows-based systems
boots using
> > UEFI.
>
> That's not the case, as cited earlier in this thread.
Please actually *read* what I am writing. That 94% market share
represents *new systems* *shipped* with Apple or Microsoft operating
systems.
Macs have been UEFI-only since 2007, and since 2012 Microsoft has
required UEFI for systems shipping with Windows 8 (or newer) Thus, every
one of the 253 million Windows and Mac systems shipped in 2019 were
booting with UEFI. Furthermore, starting in November 2016 Microsoft
disallowed new system sales with Windows 7 (ie the last of the
non-EFI-required-for-preinstalls version) -- so every system shipped
with Windows or MacOS in the past *four years* has required use of UEFI.
(That's more than a *billion* systems!)
That's simply false, that "every system shipped with Windows or MacOS in the
past *four years* has required use of UEFI." Whether you want to accept it or
not, vendors are still selling systems with Windows installed with BIOS boot.
It may be true for MacOS, but that's its own little walled garden. I can't say
when they started using UEFI, and it doesn't really matter. When a proprietary
software vendor started using something doesn't have any bearing on what we
should support in the Fedora project.
...Seriously, these are hard facts, and not something up for debate.
See above.
> Based on what? Are you assuming Linux is only on servers?
No, as I wrote, I assumed Linux is on all servers and 2% of non-server
PCs, for a combined total of aobut 6% of 2019 shipped units. The real
numbers are less than this, as not all servers are shipped with/for
Linux, and that 2% desktop linux represents the estimated install base
rather than shipping market share.
> As cited elsewhere in this thread, most servers, in fact, do have
> better BIOS support than UEFI support, with some weird quirks.
You act like there have never been "wierd quirks" with BIOS-based
systems, especially in the takes-five-minutes-to-get-to-grub server
realm.
That's not a bug or quirk, some servers just take a long time to do checks
with their BMC and other internals. It doesn't take 5 minutes, however.
Vendor firmware bugs are a fact of life. Some get fixed; most
others
have to be worked around one way or another.
I've not run into a case where using GRUB didn't work around vendor firmware
bugs related to booting a given system.
> As well as any small to medium OEM. Most OEMs don't actually
care about
> Windows Certification.
Anyone selling systems with Windows preinstalled will care, which means
their suppliers and OEMs will care, because they don't want to get
locked out of the massive market that Windows represents.
No, that's not true, at all. OEMs don't get "locked out of the massive market
that Windows represents" by selling systems pre-installed with Windows without
a "Windows Certification" on that hardware.
(Small Boutique OEMs and embedded/industrial niches notwithstanding,
of
course. There's a _very_ long tail of stuff like that. FFS, look at
the diehard Amiga folks..)
> Let's be honest, neither my numbers nor yours even matter in this,
> beyond subjective arguments. If we want to make objective claims based
> on numbers, we'd need to figure out how many Fedora users have systems
> 1) supporting UEFI 2) using UEFI.
Of course. We need actual numbers if we're to make informed decisions.
Anectdotally, of the sxiteen physical Fedora/CentOS x86 systems I'm
directly responsible for, all but two support (and also boot from) UEFI.
I hope to finally re-retire the older of the two in a few weeks,
replacing it with a machine only half its age.
Is the hardware failing? If not, what's the reason for replacing perfectly
good hardware?
(There's also a small pile of VMs too, generally used as build
hosts or
for QA-type work. Nearly all are considered disposable and can be easily
recreated)
For the record, I think any notion of auto-migrating systems from BIOS
to UEFI booting is insane. And any talk of retiring BIOS support in
Fedora should probably be put off until the F40 timeframe.
F40?! That's only 4 years away! You mean more like F72, right? That's two
decades down the road, if not further.
--
John M. Harris, Jr.
1:41 a.m.
Le samedi 04 juillet 2020 à 23:10 -0400, Solomon Peachy a écrit :
folks that make very long-lifecycle industrial systems
meant to run generally ancient software
Those things are not meant to run ancient software. They are meant to
run a very long time. And yes at the end of this time the software is
ancient. That does not mean it is ancient at the start of the system
lifecycle (I’ve seen crazy people building such systems from a Fedora
image, because they knew they would accumulate enough technical debt
during the system lifecycle, without taking the centos debt from the
start up)
Regards,
--
Nicolas Mailhot
8:48 a.m.
On Sun, Jul 05, 2020 at 08:41:16AM +0200, Nicolas Mailhot via devel wrote:
Those things are not meant to run ancient software. They are meant
to
run a very long time. And yes at the end of this time the software is
ancient.
Of course.
That does not mean it is ancient at the start of the system lifecycle
If the new embeded or industrial-type system being deployed is BIOS-only
(you know, the entire point of this silly thread) then its underlying
hardware platform (and the software running on top of it) is nowhere
near the start of its lifecycle, ie it's relatively "ancient".
(See my ealier point about Intel continuing to produce 80386 and 80486
CPUs until 2007)
(In 2011 the folks I worked for purchased a brand-new bit of kit for
their PCB production line. The system booted up into Windows NT4,
which had been completely EOL'd in 2004, because it used custom
hardware that relied on drivers that didn't run on anything newer. This
same line had a reflow oven powered by a 386 running DOS..)
- Solomon
--
Solomon Peachy pizza at shaftnet dot org (email&xmpp)
@pizza:shaftnet dot org (matrix)
High Springs, FL speachy (freenode)
1:52 a.m.
Le samedi 04 juillet 2020 à 23:10 -0400, Solomon Peachy a écrit :
(Note this explicitly excludes Chromebooks)
So you want to discuss Linux desktop deployments, excluding the only
sucessful mass Linux desktop deployment to date? Why?
Also your data conflates systems sold in XXXX with systems in use in
XXXX. That’s a very misleading assumption to make, computer systems
have matured a lot, and hardware lifetime has gone up with this
maturing (much to manufacturer’s despair, the maturing is starting to
affect smartphones now).
It’s no longer early days when you replaced last year’s experimental
system with current year’s experimentalk system because nothing had
settled yet.
Regards,
--
Nicolas Mailhot
8:18 a.m.
On Sun, Jul 05, 2020 at 08:52:12AM +0200, Nicolas Mailhot via devel wrote:
So you want to discuss Linux desktop deployments, excluding the only
sucessful mass Linux desktop deployment to date? Why?
Because the raw data I had access to excludes chromebooks, only listing
"traditional" PCs and servers. They lumped chromebooks in with tablets
and other such things, and I'm not going to spend several thousand
dollars to buy market reports just for a stupid thread on fedora-devel.
Additionally, all chromebooks boot with u-boot on top of a UEFI/GPT disk
layout. The x86 ones supposedly use coreboot to load u-boot:
https://www.chromium.org/chromium-os/chromiumos-design-docs/disk-format
Needless to say, this actually *helps* my argument, as including
ChromeOS systems into those numbers will further decrease the overall
BIOS-capable (and thus, BIOS-only) market share.
Also your data conflates systems sold in XXXX with systems in use in
XXXX.
No, it does not; these commercial market report previews I used cover
revenue and units shipped in 2019, not total install base. (those are
also available, but I'm not going to fork over several thousand dollars
over a stupid fedora-devel thread)
That said, I did deliberately conflate the two in one place -- I used
the "2%" linux desktop install base as a proxy for "market share", but
acknowledged that, and assigned those numbers to the "BIOS" side.
If someone has numbers that show the actual install base of in-use
BIOS-boot and BIOS-only systems, I'd love to see them. And I'll gladly
donate the contents of my wallet to the EFF if the BIOS numbers are
still growing in absolute terms -- ie new systems being deployed faster
than old ones are retired.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org (email&xmpp)
@pizza:shaftnet dot org (matrix)
High Springs, FL speachy (freenode)
12:20 p.m.
On Sunday, July 5, 2020 6:18:50 AM MST Solomon Peachy wrote:
On Sun, Jul 05, 2020 at 08:52:12AM +0200, Nicolas Mailhot via devel
wrote:
> So you want to discuss Linux desktop deployments, excluding the only
> sucessful mass Linux desktop deployment to date? Why?
Because the raw data I had access to excludes chromebooks, only listing
"traditional" PCs and servers. They lumped chromebooks in with tablets
and other such things, and I'm not going to spend several thousand
dollars to buy market reports just for a stupid thread on fedora-devel.
Additionally, all chromebooks boot with u-boot on top of a UEFI/GPT disk
layout. The x86 ones supposedly use coreboot to load u-boot:
https://www.chromium.org/chromium-os/chromiumos-design-docs/disk-format
Needless to say, this actually *helps* my argument, as including
ChromeOS systems into those numbers will further decrease the overall
BIOS-capable (and thus, BIOS-only) market share.
Chromebook devices are neither UEFI nor BIOS. You can use GPT disk layout
while still booting BIOS, which they also don't do. Chromebook devices either
boot with uboot -> depthcharge or Coreboot -> uboot -> depthcharge. I don't
see how this helps your argument.
--
John M. Harris, Jr.
1:31 p.m.
On Sun, Jul 05, 2020 at 10:20:01AM -0700, John M. Harris Jr wrote:
Chromebook devices are neither UEFI nor BIOS. You can use GPT disk
layout
while still booting BIOS, which they also don't do. Chromebook devices either
boot with uboot -> depthcharge or Coreboot -> uboot -> depthcharge. I don't
see how this helps your argument.
If one adds ChromeOS devices into the numbers I posted, then the
proportion of BIOS-boot-capable, BIOS-boot-enabled, and/or BIOS-only
devices on the market (and their portion of the total install base) goes
down, not up.
So using the absense of chromebooks in the numbers I referenced actually
boosts, rather than undermines, my argument. Oh, there were supposedly
17 million chromebooks shipped in 2019, versus 261 million "PCs" and
12-ish million "servers".
...Is this horse sufficiently dead yet?
- Solomon
--
Solomon Peachy pizza at shaftnet dot org (email&xmpp)
@pizza:shaftnet dot org (matrix)
High Springs, FL speachy (freenode)
1:50 p.m.
On Sunday, July 5, 2020 11:31:41 AM MST Solomon Peachy wrote:
On Sun, Jul 05, 2020 at 10:20:01AM -0700, John M. Harris Jr wrote:
> Chromebook devices are neither UEFI nor BIOS. You can use GPT disk layout
> while still booting BIOS, which they also don't do. Chromebook devices
> either boot with uboot -> depthcharge or Coreboot -> uboot ->
> depthcharge. I don't see how this helps your argument.
If one adds ChromeOS devices into the numbers I posted, then the
proportion of BIOS-boot-capable, BIOS-boot-enabled, and/or BIOS-only
devices on the market (and their portion of the total install base) goes
down, not up.
So using the absense of chromebooks in the numbers I referenced actually
boosts, rather than undermines, my argument. Oh, there were supposedly
17 million chromebooks shipped in 2019, versus 261 million "PCs" and
12-ish million "servers".
...Is this horse sufficiently dead yet?
- Solomon
Actually, Coreboot has a SeaBIOS payload as well, so the x86_64 Chromebooks
are "BIOS-boot-capable" systems. (Coreboot also has a GRUB payload, which is
used by early Purism devices, before they switched to SeaBIOS, and is used by
all x86_64 Libreboot systems).
People are still using systems from before 2019. More importantly, people are
still using systems from 2010-2012 in Fedora, as demonstrated by this thread.
--
John M. Harris, Jr.
2:40 p.m.
On Sun, 2020-07-05 at 11:50 -0700, John M. Harris Jr wrote:
On Sunday, July 5, 2020 11:31:41 AM MST Solomon Peachy wrote:
> On Sun, Jul 05, 2020 at 10:20:01AM -0700, John M. Harris Jr wrote:
> > Chromebook devices are neither UEFI nor BIOS. You can use GPT
> > disk layout
> > while still booting BIOS, which they also don't do. Chromebook
> > devices
> > either boot with uboot -> depthcharge or Coreboot -> uboot ->
> > depthcharge. I don't see how this helps your argument.
>
> If one adds ChromeOS devices into the numbers I posted, then the
> proportion of BIOS-boot-capable, BIOS-boot-enabled, and/or BIOS-
> only
> devices on the market (and their portion of the total install base)
> goes
> down, not up.
>
> So using the absense of chromebooks in the numbers I referenced
> actually
> boosts, rather than undermines, my argument. Oh, there were
> supposedly
> 17 million chromebooks shipped in 2019, versus 261 million "PCs"
> and
> 12-ish million "servers".
>
> ...Is this horse sufficiently dead yet?
>
> - Solomon
Actually, Coreboot has a SeaBIOS payload as well, so the x86_64
Chromebooks
are "BIOS-boot-capable" systems. (Coreboot also has a GRUB payload,
which is
used by early Purism devices, before they switched to SeaBIOS, and is
used by
all x86_64 Libreboot systems).
I can also confirm that my Acer C720 Chromebook has a SeaBIOS payload,
which is the only way to go, if you want to boot something other than
ChromeOS:
https://www.chromium.org/a/chromium.org/dev/chromium-os/developer-informa...
The default boot method that ChromeOS uses requires the OS to be signed
by Google's private key, which is a secret, so you can't boot Fedora or
any other distro with it. And AFAIK, you can't install other keys,
you're just supposed to use SeaBIOS for other operating systems.
I don't know much about newer chromebooks, though. But I wouldn't be
surprised if they are the same, since Google doesn't have much reason
to adopt UEFI, provided that they control both the software and the
hardware and that they have already developed a system that works.
Btw, this machine is from 2013. I use it for Coreboot+SeaBIOS
experiments.
Best regards,
Nikolay
2:18 p.m.
BIOS-based systems make up a miniscule minority of the current
market.
Pretending otherwise is delusional, and delusions are no basis for
technical decisions.
- Solomon
In terms of physical x86 systems, you are right that UEFI is the overwhelming majority.
But as stated elsewhere in this thread, a lot of cloud providers and virtualization
software default to using BIOS. So I think Fedora should only start considering dropping
BIOS support once the default is UEFI on most virtualization platforms.
2:31 p.m.
On Sun, Jul 05, 2020 at 07:18:47PM -0000, Tom Seewald wrote:
In terms of physical x86 systems, you are right that UEFI is the
overwhelming majority. But as stated elsewhere in this thread, a lot
of cloud providers and virtualization software default to using BIOS.
So I think Fedora should only start considering dropping BIOS support
once the default is UEFI on most virtualization platforms.
FWIW, I completely agree with this.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org (email&xmpp)
@pizza:shaftnet dot org (matrix)
High Springs, FL speachy (freenode)
4:10 a.m.
On 5.7.2020 19:31, Solomon Peachy wrote:
On Sun, Jul 05, 2020 at 07:18:47PM -0000, Tom Seewald wrote:
> In terms of physical x86 systems, you are right that UEFI is the
> overwhelming majority. But as stated elsewhere in this thread, a lot
> of cloud providers and virtualization software default to using BIOS.
> So I think Fedora should only start considering dropping BIOS support
> once the default is UEFI on most virtualization platforms.
FWIW, I completely agree with this.
As do I.
Hopefully Daniel's response of the poor state those tools are in, will
raise some red flags within Red Hat in which it starts throwing some
resources ( money,workforce) to have this addressed before RHEL 9 gets
released.
Atleast that is what I would do if I was a person in power within Red
Hat ( or a company that provides or relies on a solution based on those
tools) and had read his response which described quite the "alarming
situation" for products within the company in relation where the
industry is heading.
JBG
2:42 p.m.
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 -0000, Tom Seewald wrote:
>
>> In terms of physical x86 systems, you are right that UEFI is the
>> overwhelming majority. But as stated elsewhere in this thread, a lot
>> of cloud providers and virtualization software default to using BIOS.
>> So I think Fedora should only start considering dropping BIOS support
>> once the default is UEFI on most virtualization platforms.
>
> FWIW, I completely agree with this.
As do I.
Hopefully Daniel's response of the poor state those tools are in, will
raise some red flags within Red Hat in which it starts throwing some
resources ( money,workforce) to have this addressed before RHEL 9 gets
released.
Atleast that is what I would do if I was a person in power within Red
Hat ( or a company that provides or relies on a solution based on those
tools) and had read his response which described quite the "alarming
situation" for products within the company in relation where the
industry is heading.
I don't understand why you're trying to light fires for no reason. What we
have now works on all platforms already, including UEFI. If every existing
system dropped BIOS support *today*, we'd still be fine.
Please don't exaggerate the importance of these issues. We have a working UEFI
solution with GRUB2, which also works well for BIOS. There is no reason for
RHEL to drop BIOS either, in fact, they have more reason to support it than
Fedora: So their customers can continue to use their product.
--
John M. Harris, Jr.
3:03 a.m.
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 decades ago and it was very surprising very few thought of that
process especially for a distribution aiming to use latest technology.
The question is for contributors running on legacy BIOS if they are
willing to maintain it while the installer can focus to effectively use
sd-boot.
--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
3:11 a.m.
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 decades ago and it was very surprising very few thought of that
process especially for a distribution aiming to use latest technology.
The question is for contributors running on legacy BIOS if they are
willing to maintain it while the installer can focus to effectively use
sd-boot.
systemd-boot isn't really an option. It doesn't have the features that are
necessary for Fedora systems to actually be able to boot. It'd work on
Workstation, maybe, if they think their users will never need to know they're
even using a bootloader, and won't put /boot on LVM or LUKs encrypt it.
Additionally, the theoretical proposal discussed earlier in the thread was to
add it as an alternate option, which users could ELECT to trying out, not to
make it the default bootloader. Probably because it doesn't meet the needs of
actually being able to boot Fedora systems.
--
John M. Harris, Jr.
8:20 a.m.
I don't know about how important EFI and reducing the bootloader technical debt is for
the project, but at least for me personally, it will be a straight way out. My hard disk
has a traditional MBR based structure with about a TB of very important data. I don't
know of a 100% reliable way of converting it to GPT. While I do have backup for most
important files, not everything is backed up nor do I have means to do so.
The system works perfectly fine for me and I see no reason why I should opt for EFI. What
is the value add for me, at least till I don't upgrade to a newer system? which I
won't be at least for next 2 years. So forcing such a no-value-add change to existing
user will drive them away. At least I would opt for a different distro in such case even
though it's not something I want to do.
I feel the better approach would be to use it as default for new installations, if the
disks are appropriately formatted or are empty at the time of installation. Else a fall
back to grub should be transparently done.
Just my 2 cents from a user's perspective.
7:24 a.m.
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 decades ago and it was very surprising very few thought of that
> process especially for a distribution aiming to use latest technology.
>
> The question is for contributors running on legacy BIOS if they are
> willing to maintain it while the installer can focus to effectively use
> sd-boot.
systemd-boot isn't really an option. It doesn't have the features that are
necessary for Fedora systems to actually be able to boot. It'd work on
Workstation, maybe, if they think their users will never need to know they're
even using a bootloader, and won't put /boot on LVM or LUKs encrypt it.
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 find there are public anyway, you can download them from
the fedora servers. Encrypting /boot would make the boot process more
fragile for no benefit.
sd-boot still wouldn't work out-of-the-box though, due to /boot being
xfs not vfat and firmware typically not shipping with xfs drivers.
We could that by using vfat for /boot. Or by shipping & using xfs.efi,
simliar to how apple ships & uses apfs.efi to boot macOS from apfs
filesystems.
take care,
Gerd
3:26 p.m.
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 find there are public anyway, you can download them from
the fedora servers. Encrypting /boot would make the boot process more
fragile for no benefit.
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.
sd-boot still wouldn't work out-of-the-box though, due to /boot
being
xfs not vfat and firmware typically not shipping with xfs drivers.
If I'm not mistaken, XFS is the default used on RHEL, but ext4 is still used
for /boot in Fedora, by default.
We could that by using vfat for /boot. Or by shipping & using
xfs.efi,
simliar to how apple ships & uses apfs.efi to boot macOS from apfs
filesystems.
Is there a notable benefit to using that over GRUB2, which already has support
on both UEFI and BIOS?
--
John M. Harris, Jr.
3:34 p.m.
On Mon, Jul 6, 2020 at 4:26 PM John M. Harris Jr <johnmh(a)splentity.com> 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 sense to me. Why would you encrypt /boot? The
> files you can find there are public anyway, you can download them from
> the fedora servers. Encrypting /boot would make the boot process more
> fragile for no benefit.
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 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 uses dm-verity, if I remember correctly.
> sd-boot still wouldn't work out-of-the-box though, due to /boot being
> xfs not vfat and firmware typically not shipping with xfs drivers.
If I'm not mistaken, XFS is the default used on RHEL, but ext4 is still used
for /boot in Fedora, by default.
> We could that by using vfat for /boot. Or by shipping & using xfs.efi,
> simliar to how apple ships & uses apfs.efi to boot macOS from apfs
> filesystems.
Is there a notable benefit to using that over GRUB2, which already has support
on both UEFI and BIOS?
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.
--
真実はいつも一つ！/ Always, there's only one truth!
3:58 p.m.
> 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 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 uses dm-verity, if I remember correctly.
Or measurement and attestation via TPM2.
> > sd-boot still wouldn't work out-of-the-box though, due
to /boot being
> > xfs not vfat and firmware typically not shipping with xfs drivers.
>
> If I'm not mistaken, XFS is the default used on RHEL, but ext4 is still used
> for /boot in Fedora, by default.
>
> > We could that by using vfat for /boot. Or by shipping & using xfs.efi,
> > simliar to how apple ships & uses apfs.efi to boot macOS from apfs
> > filesystems.
>
> Is there a notable benefit to using that over GRUB2, which already has support
> on both UEFI and BIOS?
>
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 for
their platform, you'd also need to load them some how, I'm guessing
sd-boot could try loading/locking if it can't read a file system...
suddenly things start to head towards complexity again.
10:10 a.m.
On Mo, 06.07.20 21:58, Peter Robinson (pbrobinson(a)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 for
their platform, you'd also need to load them some how, I'm guessing
sd-boot could try loading/locking if it can't read a file system...
suddenly things start to head towards complexity again.
Quite frankly, I don't see the point of using a different file system
than VFAT here. You cannot avoid VFAT anyway, since that's the only
thing EFI firmware can generally read, and hence your boot loader
itself is always read from VFAT anyway. Throwing in another file system
just increases the maintenance burden: previously you had one problem
and now you have two problems.
Given that the update cycles for boot loaders in a world where boot
loaders do certificate management, TLS, HTTP, networking, IP, yadda
yadda isn't much different from update cycles for kernels/initrds
adding in a second, separate file system such as XFS or ext4 won't
give you much additional data safety, it just gives you more code that
can break. In particular as features such as boot counting/assessment
require writable fs access from the boot loader, but that is very hard
to tackle on journalling file systems (grub doesn't do it afaik), and
basically means you need to maintain your own fully blown file system
implementation. VFAT on the other hand is simple, its there anyway,
you need to rely on it anyway and allows writing from firmware too.
That all said, one feature I'd like to add to sd-boot is that we
define a drop-in dir where you can put drivers in, and we'll load them
all, one by one. The idea would be that distros can drop in XFS or
ext4 drivers there, properly signed, and we'd load them, so that it
doesn't matter to sd-boot which file system you actually pick: if you
want XFS or ext4 then you can easily make it happen, just by dropping
in their driver files, and things will just work.
Lennart
--
Lennart Poettering, Berlin
4:05 p.m.
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
<johnmh(a)splentity.com>
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 sense to me. Why would you encrypt /boot? The
> > files you can find there are public anyway, you can download them from
> > the fedora servers. Encrypting /boot would make the boot process more
> > fragile for no benefit.
>
>
>
> 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 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 uses dm-verity, if I remember correctly.
That's true, in an ideal world, one of these modules would be used. However,
LUKS is often sufficient to know that it hasn't been modified, depending on
the ciphers used, if it does load correctly.
> > sd-boot still wouldn't work out-of-the-box though, due
to /boot being
> > xfs not vfat and firmware typically not shipping with xfs drivers.
>
>
>
> If I'm not mistaken, XFS is the default used on RHEL, but ext4 is still
> used for /boot in Fedora, by default.
>
>
>
> > We could that by using vfat for /boot. Or by shipping & using xfs.efi,
> > simliar to how apple ships & uses apfs.efi to boot macOS from apfs
> > filesystems.
>
>
>
> Is there a notable benefit to using that over GRUB2, which already has
> support on both UEFI and BIOS?
>
>
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.
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 for both.
--
John M. Harris, Jr.
4:08 p.m.
On Mon, Jul 6, 2020 at 5:05 PM John M. Harris Jr <johnmh(a)splentity.com> 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 <johnmh(a)splentity.com>
> 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 sense to me. Why would you encrypt /boot? The
> > > files you can find there are public anyway, you can download them from
> > > the fedora servers. Encrypting /boot would make the boot process more
> > > fragile for no benefit.
> >
> >
> >
> > 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 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 uses dm-verity, if I remember correctly.
That's true, in an ideal world, one of these modules would be used. However,
LUKS is often sufficient to know that it hasn't been modified, depending on
the ciphers used, if it does load correctly.
It's not guaranteed though, and you shouldn't rely on that for
verifying integrity if you care about that. You either will want an
authenticated filesystem or use a dm stack configuration that includes
authentication.
> > > sd-boot still wouldn't work out-of-the-box though,
due to /boot being
> > > xfs not vfat and firmware typically not shipping with xfs drivers.
> >
> >
> >
> > If I'm not mistaken, XFS is the default used on RHEL, but ext4 is still
> > used for /boot in Fedora, by default.
> >
> >
> >
> > > We could that by using vfat for /boot. Or by shipping & using
xfs.efi,
> > > simliar to how apple ships & uses apfs.efi to boot macOS from apfs
> > > filesystems.
> >
> >
> >
> > Is there a notable benefit to using that over GRUB2, which already has
> > support on both UEFI and BIOS?
> >
> >
>
>
> 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.
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 for both.
If we wanted to be UEFI first, we could make BIOS boots emulate UEFI
and boot through the UEFI chain all the way through. We already do
this for some boards on ARM with U-Boot, if I remember correctly. If
that were possible on x86, then we could get down to one boot chain
path regardless.
--
真実はいつも一つ！/ Always, there's only one truth!
5:03 p.m.
> 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 for both.
>
If we wanted to be UEFI first, we could make BIOS boots emulate UEFI
and boot through the UEFI chain all the way through. We already do
this for some boards on ARM with U-Boot, if I remember correctly. If
that were possible on x86, then we could get down to one boot chain
path regardless.
No, U-Boot is the firmware, it now implements a UEFI interface as a
means of interacting with OS/bootloaders for booting OSes in a generic
manner. It's not emulated, it is the interface between the firmware
(U-Boot) and the computer, for aarch64 it's mandated that the board
firmware implement UEFI to be supported in Fedora, whether that's the
Tianocore, U-Boot or another third party implementation, open or
proprietary we don't care.
Why would you wrap BIOS with another firmware implementation? You're
just making the problem worse. Fact is that while it won't go away
particularly fast we should actually be looking at sunsetting
traditional BIOS support, it's not secure or securable. MS has
mandated it for the Windows logo program to be certified HW since
Windows 8, they've now mandated that for server as well, in both cases
now requiring TPM2.
Don't hack up BIOS support, it vaguely sort of works now, leave it
vaguely working and just let it be, it's not evolving. One day we'll
wake up and no one will be using it, the sooner the better.
Peter
5:54 p.m.
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 sounds like. Right now, we have one solution that works well for
> > both.
> >
> >
>
>
>
> If we wanted to be UEFI first, we could make BIOS boots emulate UEFI
> and boot through the UEFI chain all the way through. We already do
> this for some boards on ARM with U-Boot, if I remember correctly. If
> that were possible on x86, then we could get down to one boot chain
> path regardless.
No, U-Boot is the firmware, it now implements a UEFI interface as a
means of interacting with OS/bootloaders for booting OSes in a generic
manner. It's not emulated, it is the interface between the firmware
(U-Boot) and the computer, for aarch64 it's mandated that the board
firmware implement UEFI to be supported in Fedora, whether that's the
Tianocore, U-Boot or another third party implementation, open or
proprietary we don't care.
Why would you wrap BIOS with another firmware implementation? You're
just making the problem worse. Fact is that while it won't go away
particularly fast we should actually be looking at sunsetting
traditional BIOS support, it's not secure or securable. MS has
mandated it for the Windows logo program to be certified HW since
Windows 8, they've now mandated that for server as well, in both cases
now requiring TPM2.
Don't hack up BIOS support, it vaguely sort of works now, leave it
vaguely working and just let it be, it's not evolving. One day we'll
wake up and no one will be using it, the sooner the better.
That day is still decades away, as others in this list have noted. I agree
with the rest, of course. Just let it be.
--
John M. Harris, Jr.
9 a.m.
On Mo, 06.07.20 16:34, Neal Gompa (ngompa13(a)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 uses dm-verity, if I remember correctly.
EFI SecureBoot uses PE signed executables.
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.
Could use SHIM like everything else.
Lennart
--
Lennart Poettering, Berlin
10:01 a.m.
Once upon a time, Lennart Poettering <mzerqung(a)0pointer.de> 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 <linux(a)cmadams.net>
5:17 a.m.
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. Which makes sense to me. Why would you encrypt /boot? The
> files you can find there are public anyway, you can download them from
> the fedora servers. Encrypting /boot would make the boot process more
> fragile for no benefit.
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 is your concern the answer is secure boot. That will not
only prevent tampering with /boot files, but also prevent tampering with
the bootloader itself.
or config files haven't been read by somebody other than the
end
user.
Hmm, typically that is pretty standard stuff and very simliar on all
fedora installs. Only the root filesystem uuid differs, and possibly
local tweaks like configuring a serial console. I can't see how reading
that is of much concern.
> We could that by using vfat for /boot. Or by shipping &
using xfs.efi,
> simliar to how apple ships & uses apfs.efi to boot macOS from apfs
> filesystems.
Is there a notable benefit to using that over GRUB2, which already has
support on both UEFI and BIOS?
Well, for my day-to-day work it doesn't make much of a difference. Both
get the job done.
I generally dislike the grub2 config file format. I'm not going to
repeat all the arguments here which have been mentioned numerous times
already. With BLS support things became a bit better because for the
most part I can just ignore grub.cfg after install.
I suspect the grub2 maintainers have a different view on this. They
have to deal with the mess to make sure I don't have to. And on top
of that getting changes merged upstream to grub2 seems to be a PITA,
leading to a huge stack of patches in the fedora grub2 rpm ...
take care,
Gerd
7:25 a.m.
On Tue, Jul 7, 2020 at 11:17 AM Gerd Hoffmann <kraxel(a)redhat.com> 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 full disk encryption LVM is encrypted, ESP + boot
> > are not. Which makes sense to me. Why would you encrypt /boot? The
> > files you can find there are public anyway, you can download them from
> > the fedora servers. Encrypting /boot would make the boot process more
> > fragile for no benefit.
>
> 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 is your concern the answer is secure boot. That will not
only prevent tampering with /boot files, but also prevent tampering with
the bootloader itself.
It's part of the solution, how exactly does secure-boot it deal with
the initrd when isn't signed because it's generate on install, or
changes to config files such as grub.cfg? It doesn't, you need
technologies such as a TPM2 to measure and attest, and things like IMA
to enforce policies.
> or config files haven't been read by somebody other than
the end
> user.
Hmm, typically that is pretty standard stuff and very simliar on all
fedora installs. Only the root filesystem uuid differs, and possibly
local tweaks like configuring a serial console. I can't see how reading
that is of much concern.
There's lots of cases where that is a concern, if you can't trust one
part of your boot chain can you trust any of it?
> > We could that by using vfat for /boot. Or by shipping
& using xfs.efi,
> > simliar to how apple ships & uses apfs.efi to boot macOS from apfs
> > filesystems.
>
> Is there a notable benefit to using that over GRUB2, which already has
> support on both UEFI and BIOS?
Well, for my day-to-day work it doesn't make much of a difference. Both
get the job done.
I generally dislike the grub2 config file format. I'm not going to
repeat all the arguments here which have been mentioned numerous times
already. With BLS support things became a bit better because for the
most part I can just ignore grub.cfg after install.
I suspect the grub2 maintainers have a different view on this. They
have to deal with the mess to make sure I don't have to. And on top
of that getting changes merged upstream to grub2 seems to be a PITA,
leading to a huge stack of patches in the fedora grub2 rpm ...
Well the whole upstream situation has started improving recently and
the number of patches is coming down and being unified. The whole
stack of patches was fairly standard across distros.
10:47 a.m.
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. 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 find there are public anyway, you can download them from
> > the fedora servers. Encrypting /boot would make the boot process more
> > fragile for no benefit.
>
>
> 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 is your concern the answer is secure boot. That will not
only prevent tampering with /boot files, but also prevent tampering with
the bootloader itself.
No, Secure Boot doesn't solve that problem. Secure Boot, in Fedora anyway,
needlessly disables a lot of kernel functionality, which makes it completely
unusable. You cannot load kernel modules you've built, hibernate your system,
etc. Additionally, Secure Boot does not prevent tampering with /boot files.
You can still change grub.cfg as you like.
> or config files haven't been read by somebody other than
the end
> user.
Hmm, typically that is pretty standard stuff and very simliar on all
fedora installs. Only the root filesystem uuid differs, and possibly
local tweaks like configuring a serial console. I can't see how reading
that is of much concern.
There's no reason to allow these files to be read to begin with, if the system
is going to be encrypted.
--
John M. Harris, Jr.
12:04 p.m.
On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr <johnmh(a)splentity.com> 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 to the hardware, including disabling various firmware
protection technologies.
tl;dr: if you care about platform security at all, enable secure boot.
Richard
1:54 p.m.
Once upon a time, Richard Hughes <hughsient(a)gmail.com> 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 <linux(a)cmadams.net>
4:17 p.m.
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
<johnmh(a)splentity.com>
wrote:
> needlessly disables a lot of kernel functionality
It disables functionality which can destroy platform security.
It disables functionality that users need, such as inserting their kernel
modules on their own system, or hibernating to disk. Let's be honest about
what this does. This is not something that's beneficial here, it's only
harming our users.
> You cannot load kernel modules you've built
If you can build and insert your own kernel module you can do almost
anything to the hardware, including disabling various firmware
protection technologies.
tl;dr: if you care about platform security at all, enable secure boot.
If you've got root, you can STILL do almost anything to the hardware,
including disabling various "firmware protection technologies". This is
needlessly kneecapping users.
--
John M. Harris, Jr.
2:26 a.m.
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 <johnmh(a)splentity.com>
> wrote:
> > needlessly disables a lot of kernel functionality
>
>
> It disables functionality which can destroy platform security.
It disables functionality that users need, such as inserting their kernel
modules on their own system, or hibernating to disk. Let's be honest about
what this does. This is not something that's beneficial here, it's only
harming our users.
Some users, not all users. Beware of making sweeping generalizations.
I've used Fedora since Fedora Core 5 across countless machines and never
cared about inserting custom kernel modules. Hibernating to disk is not
something I've used on my laptops in probably 10 years either, as suspend
to ram is generally sufficient. Again just my personal experiance.
There's always a tradeoff and it is likely to be different depending on
each users needs. While SecureBoot will disable some functionality it is
not unreasonable to think it is a net win out of the box for a potentially
quite large portion of Fedora's userbase.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
9:38 a.m.
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 <johnmh(a)splentity.com>
> > wrote:
> >
> > > needlessly disables a lot of kernel functionality
> >
> >
> >
> > It disables functionality which can destroy platform security.
>
>
> It disables functionality that users need, such as inserting their kernel
>
> modules on their own system, or hibernating to disk. Let's be honest about
> what this does. This is not something that's beneficial here, it's only
> harming our users.
Some users, not all users. Beware of making sweeping generalizations.
I've used Fedora since Fedora Core 5 across countless machines and never
cared about inserting custom kernel modules. Hibernating to disk is not
something I've used on my laptops in probably 10 years either, as suspend
to ram is generally sufficient. Again just my personal experiance.
There's always a tradeoff and it is likely to be different depending on
each users needs. While SecureBoot will disable some functionality it is
not unreasonable to think it is a net win out of the box for a potentially
quite large portion of Fedora's userbase.
Regards,
Daniel
Please keep in mind that it disables that functionality only because of
'lockdown' patches applied to the Fedora kernel, it's not a normal part of the
Linux kernel when running under Secure Boot. I have no idea why the decision
to hurt users was explicitly made here, it doesn't make a lot of sense.
--
John M. Harris, Jr.
9:51 a.m.
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 Wed, 8 Jul 2020 at 16:48, John M. Harris Jr <
> > > johnmh(a)splentity.com>
> > > wrote:
> > >
> > > > needlessly disables a lot of kernel functionality
> > >
> > >
> > > It disables functionality which can destroy platform security.
> >
> > It disables functionality that users need, such as inserting
> > their kernel
> >
> > modules on their own system, or hibernating to disk. Let's be
> > honest about
> > what this does. This is not something that's beneficial here,
> > it's only
> > harming our users.
>
> Some users, not all users. Beware of making sweeping
> generalizations.
>
> I've used Fedora since Fedora Core 5 across countless machines and
> never
> cared about inserting custom kernel modules. Hibernating to disk is
> not
> something I've used on my laptops in probably 10 years either, as
> suspend
> to ram is generally sufficient. Again just my personal experiance.
>
> There's always a tradeoff and it is likely to be different
> depending on
> each users needs. While SecureBoot will disable some functionality
> it is
> not unreasonable to think it is a net win out of the box for a
> potentially
> quite large portion of Fedora's userbase.
>
> Regards,
> Daniel
Please keep in mind that it disables that functionality only because
of
'lockdown' patches applied to the Fedora kernel, it's not a normal
part of the
Linux kernel when running under Secure Boot. I have no idea why the
decision
to hurt users was explicitly made here, it doesn't make a lot of
sense.
IIRC, if you sign a kernel that can load unsigned modules, you can boot
that kernel, then load a custom module, that boots a different kernel
or OS (such as Windows) and claim that secure boot was on, even though
you have modified and/or injected malicious code into the kernel. In
other words, you can circumvent the whole point of using secure boot.
If you want that, you might as well just disable secure boot. Otherwise
it is a bit like locking your front door, while leaving your back door
widely open.
You can argue all they long that secure boot doesn't bring you that
much security anyway (I'm in that camp, I don't think it's worth the
trouble for my home systems, so I disable them even on those that use
UEFI), but then, again, as long as it's not mandatory, so the user can
choose to turn it off, it should be ok. Some people might decide to
make an informed decision to enable it, and that's their decision to
make. It's a tradeoff - extra lockdown for some extra security. Maybe
only worth it for very important systems.
Nikolay
5:38 a.m.
On Wed, 8 Jul 2020 at 22:19, John M. Harris Jr <johnmh(a)splentity.com> 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 way to own a machine. And please don't
lecture me on why BIOS is more secure than UEFI, "compatibility" mode
is implemented *on top of* the UEFI bios these days, rather than as a
completely different software stack.
If you've got root, you can STILL do almost anything to the
hardware,
including disabling various "firmware protection technologies".
I don't think you understand what enabling SecureBoot actually does.
Richard.
9:46 a.m.
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
<johnmh(a)splentity.com>
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 way to own a machine. And please don't
lecture me on why BIOS is more secure than UEFI, "compatibility" mode
is implemented *on top of* the UEFI bios these days, rather than as a
completely different software stack.
"Attacking" the firmware has always been the best option, even with BIOS boot
systems. For example, coreboot is technically a hostile payload, to the OEM.
That doesn't mean that it makes any sense to prevent the end user from
actually owning the hardware they've purchased, and doing with it what they
please.
> If you've got root, you can STILL do almost anything to the
hardware,
> including disabling various "firmware protection technologies".
I don't think you understand what enabling SecureBoot actually does.
"Secure Boot" doesn't make root non-uid 0, and can't keep root from
controlling system devices, even uploading unsigned firmware to peripherals.
At the point that anything but the end user gets root on a Fedora install, all
of these "security gains" provided by creating needless headache for those
running under "Secure Boot" are null and void.
--
John M. Harris, Jr.
10:07 a.m.
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 <
> johnmh(a)splentity.com>
> 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 way to own a machine. And please don't
> lecture me on why BIOS is more secure than UEFI, "compatibility"
> mode
> is implemented *on top of* the UEFI bios these days, rather than as
> a
> completely different software stack.
"Attacking" the firmware has always been the best option, even with
BIOS boot
systems. For example, coreboot is technically a hostile payload, to
the OEM.
That doesn't mean that it makes any sense to prevent the end user
from
actually owning the hardware they've purchased, and doing with it
what they
please.
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.
> > If you've got root, you can STILL do almost anything to the
> > hardware,
> > including disabling various "firmware protection technologies".
>
> I don't think you understand what enabling SecureBoot actually
> does.
"Secure Boot" doesn't make root non-uid 0, and can't keep root from
controlling system devices, even uploading unsigned firmware to
peripherals.
At the point that anything but the end user gets root on a Fedora
install, all
of these "security gains" provided by creating needless headache for
those
running under "Secure Boot" are null and void.
Yeah, for me, it's pretty weak as a mitigation effort, because it will
usually only have some protective effect if someone already has root on
your computer, and that's already pretty bad. You don't normally want
to allow that to happen ever. And when someone has root, they can do
pretty much anything. IMHO, it's a lot of effort and inconvenience for
very little actual gain. But, that's why it should only be an option
and not mandatory. But yes, it might make sense for certain use cases.
Nikolay
1:17 p.m.
On Thu, 09 Jul 2020 18:07:39 +0300
nickysn(a)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 kernels, and sign them using
pesign with my own key that I generated locally, and put in the EFI key
database. I can then boot the custom kernel in secure mode. Couldn't I
also sign modules if I ever generated them with that same key?
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?
3:10 p.m.
On Thu, 2020-07-09 at 11:17 -0700, stan via devel wrote:
On Thu, 09 Jul 2020 18:07:39 +0300
nickysn(a)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 kernels, and sign them using
pesign with my own key that I generated locally, and put in the EFI
key
database. I can then boot the custom kernel in secure mode. Couldn't
I
also sign modules if I ever generated them with that same key?
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 honest, I don't know. Do all UEFI secure boot implementations
allow you to add your own keys to the list of trusted keys?
Nikolay
3:16 p.m.
On Thu, 2020-07-09 at 23:10 +0300, nickysn(a)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
> nickysn(a)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 kernels, and sign them using
> pesign with my own key that I generated locally, and put in the EFI
> key
> database. I can then boot the custom kernel in secure mode. Couldn't
> I
> also sign modules if I ever generated them with that same key?
>
> 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 honest, I don't know. Do all UEFI secure boot implementations
allow you to add your own keys to the list of trusted keys?
In theory they should, but the interface may be broken or overly complicated.
That said you can always disable secure boot on x86_64 ... not so on ARM based hw.
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
3:54 p.m.
On Thu, 09 Jul 2020 23:10:46 +0300
nickysn(a)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 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 don't know, but I used Fedora tools to create the key pair, and
insert the public key (x86_64). Anyway, just another data point in the
discussion.
4:19 p.m.
Once upon a time, nickysn(a)gmail.com <nickysn(a)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 the ability
for the system admin to add their own signing keys. So, most every
AMD/Intel system you run across should support that.
--
Chris Adams <linux(a)cmadams.net>
6:18 a.m.
On Thu, Jul 9, 2020 at 5:20 PM Chris Adams <linux(a)cmadams.net> wrote:
Once upon a time, nickysn(a)gmail.com <nickysn(a)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 the ability
for the system admin to add their own signing keys. So, most every
AMD/Intel system you run across should support that.
I don't know this for sure, but from what I've heard, that last point
(user management of keys) is no longer a requirement, as is being able
to disable Secure Boot. Some of my friends have reported getting
laptops from some big vendors without the ability to do either in the
last couple of years.
--
真実はいつも一つ！/ Always, there's only one truth!
6:50 a.m.
On Fri, Jul 10, 2020 at 07:18:06AM -0400, Neal Gompa wrote:
I don't know this for sure, but from what I've heard, that
last point
(user management of keys) is no longer a requirement, as is being able
to disable Secure Boot. Some of my friends have reported getting
laptops from some big vendors without the ability to do either in the
last couple of years.
The System.Fundamentals.Firmware.UEFISecureBoot section of the current
WHCP v2004 documentation [1] states that:
"For devices that are designed to always boot with a specific secure
boot configuration, the two requirements ... to support Custom Mode
and the ability to disable Secure Boot are optional."
(Custom mode: "It shall be possible for a physically present user... to
modify the contents of the secure boot signature databases and the PK...")
(Enable/Disable: "A physically presnet user must be allowed to disable
secure boot via firmware setup... programmatic disabling of secure boot
during boot services or after exiting boot services MUST NOT be
possible")
Note that "specific secure boot configuration" and "locked down
platforms" are not defined in this document, but appears to only apply
to ARM-based platforms]
Additionally, in System.Fundamentals.Firmware.UEFICompatibility
"All Windows systems must boot in UEFI mode by default. Other
requirements may add additional sections of compatibility to this list,
but this is the baseline."
"All systems, except servers, must be certified in UEFI mode without
activating CSM. If a system is available with 32bit and/or 64bit UEFI,
both configurations must be tested for certification."
And in System.Fundamentals.Firmware.UEFILegacyFallback:
"If the system ships with a UEFI-compatible OS, system firmware must be
implemented as UEFI and it must be able to achieve UEFI boot mode by
default. Such a system may also support fallback to legacy BIOS boot on
systems with OS which do not support UEFI, but only if the user selects
that option in a pre-boot firmware user interface. Legacy option ROMs
also may not be loaded by default."
"An OEM may not ship a 64-bit system which defaults to legacy BIOS ...
if that systems ships with a UEFI-compatible OS"
The language about servers is a bit muddled but it seems to say that if
you're going to ship a 64-bit Windows install it needs to default to,
and be certified with, CSM-less UEFI booting. Secure boot is not a
requirement for servers.
[1]
https://docs.microsoft.com/en-us/windows-hardware/design/compatibility/wh...
- Solomon
--
Solomon Peachy pizza at shaftnet dot org (email&xmpp)
@pizza:shaftnet dot org (matrix)
High Springs, FL speachy (freenode)
10:58 p.m.
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 in that direction, because it is just
inconceivable otherwise in the world with billions of autonomous IOT
devices---the consequences of a worm-type insecurity that would subvert
a significant portion of Internet-connected devices are just too scary.
For instance, one possible solution used e.g. for a secure BIOS updates
is to prevent loading firmware directly, and instead load it into a
separate flash area. Then, reset the system:
* existing certified firmware boots and finds the updated firmware
* new firmware is measured and verified
* if it passes, the old firmware copies and activates the updated firmware
So you see that you can't subvert this even with UID==0. Same thing for
controlling system devices---with secure software chain even the
applications can be certified and controlled. THis is not your or my
desktop system, of course, but there is a need for systems like this.
When I hear you say that this takes away the ownership of our computers
from us, I think that it's got to be this way for a large part of those
billions of systems---as the saying goes, we have to stop thinking of
computers as pets, and start seeing them as cattle. We can still have
pets as well, but there has to be a way to herd cattle.
4:06 a.m.
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 devices
That’s a joke isn’t it? 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, and refuse to provide the length
of support software-side, that users have come to expect hardware-side.
Leading to vast deployments of abandoware.
A lot of things, starting with the DRM target that funded secure boot,
would not exist if manufacturers were serious about updates, because
those systems are increadibly brittle and incompatible with a long term
support view.
--
Nicolas Mailhot
6:12 a.m.
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 cycle---so new versions and fixes have to be
developed separately by everyone. This does not scale, and so it doesn't
happen most of the time. I think the only long-term solution is a wide
use of platforms, such as Android or Fedora.
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---it doesn't scale to the size the IOT is going to be.
Moreover, without the secure method, any vulnerability can be easily
converted to persistent breakage.
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.
6:37 a.m.
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 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 the manufacturer disagreees with.
A system, that auto consults a remote update point, over https,
checking the certificate of this remote point, has zero need for secure
boot.
--
Nicolas Mailhot
6:51 a.m.
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 the manufacturer disagreees with.
s/manufacturer/device owner/
- Solomon
--
Solomon Peachy pizza at shaftnet dot org (email&xmpp)
@pizza:shaftnet dot org (matrix)
High Springs, FL speachy (freenode)
7:05 a.m.
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
> and
> DRPM is to prevent end users, present in the update loop, from
> doing
> things the manufacturer disagreees with.
s/manufacturer/device owner/
Nope, manufacturer. There are hundreds of other simpler ways to protect
device owner side (physical locks on racks, 2FA auth via a physical
button on the device or an sms code, etc).
The average device is not sold with locks in the supermarket. The home
or office or building or rack door is considered sufficient
protection.
Evil maid does exist, but applying evil maid generally would require
putting locks on everything you buy, from the drawers where you may
store sensitive documents someday, to the fridge where the evil maid
may serve herself on your precious lagger.
The threat scenario has been massively ovehyped to justify giving keys
to the manufacturers.
--
Nicolas Mailhot
4:24 p.m.
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 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 the manufacturer disagreees with.
>
>
> s/manufacturer/device owner/
Nope, manufacturer. There are hundreds of other simpler ways to protect
device owner side (physical locks on racks, 2FA auth via a physical
button on the device or an sms code, etc).
The average device is not sold with locks in the supermarket. The home
or office or building or rack door is considered sufficient
protection.
Evil maid does exist, but applying evil maid generally would require
putting locks on everything you buy, from the drawers where you may
store sensitive documents someday, to the fridge where the evil maid
may serve herself on your precious lagger.
The threat scenario has been massively ovehyped to justify giving keys
to the manufacturers.
Please note that SMS two factor has been known to be insecure since 2005, and
NIST has recommended against it for just as long. (Before a bit of nonsense in
2016-2017, which I think has been corrected?)
--
John M. Harris, Jr.
7 a.m.
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 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 the manufacturer disagreees with.
A system, that auto consults a remote update point, over https,
checking the certificate of this remote point, has zero need for secure
boot.
Not quite---as I said in next sentence that you didn't include in your
quote, secure boot also tries to prevent unauthorized modifications, for
instance resulting from exploited vulnerabilities. It turns out that
legitimate owners aren't the only users of IOT :)
Look---I agree this is a complex situation. Secure boot has many
consequences, and I share your concerns about many of them (walled
gardens and loss of control over hardware we own). This does not change
the fact that the current technology is inadequate and needs to evolve.
7:25 a.m.
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, it will just be remotely exploited at every boot, and
there will be nothing stored persistently for secure boot to block
(that is actually how some windows malware started to behave once
Microsoft added boot protections).
The other usual argument is that digital keys are cheap and physical
buttons or locks expensive. Well digital keys are definitely not cheap
once you count all the work to keep digital protections up to date and
bug free, and physical buttons are definitely not expensive. I have one
on every bargain-bin iot plug in my house, to authorise initial
pairing. And those buttons will keep working far after the IOT
manufacturer will have screwed up the software update part.
Regards,
--
Nicolas Mailhot
7:55 a.m.
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 your system is remotely
exploitable, it will just be remotely exploited at every boot, and
there will be nothing stored persistently for secure boot to block
(that is actually how some windows malware started to behave once
Microsoft added boot protections).
Except that you can fix the vulnerability, push
the update and prevent
the exploit, even if the vulnerability would somehow be in the boot
firmware. For the exploit to win it would have to hit the window just
after the boot, which can be prevented.
The other usual argument is that digital keys are cheap and physical
buttons or locks expensive. Well digital keys are definitely not cheap
once you count all the work to keep digital protections up to date and
bug free, and physical buttons are definitely not expensive. I have one
on every bargain-bin iot plug in my house, to authorise initial
pairing. And those buttons will keep working far after the IOT
manufacturer will have screwed up the software update part.
The marginal cost of a digital key has got to be smaller than the
marginal cost of the button. At billions of device, that's the only cost
that matters.
Again, I am a hardware hacker and I hate the locked devices. But I think
the secure updates have to happen, and it turns out that there is almost
always a local bypass--JTAG, serial port, whatever. Maybe that is a
regulatory issue---like a legal requirement that manufacturers need to
publish a local unlock key/code after (or maybe even before) their
support schedule ends.
3:03 a.m.
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 already builds a
ton of such things. A physical button is a on-of, a digital key
infrastructure is years of expensive maintenance and updates to keep
going. And as you noted they have to include physical bybass for other
reasons.
You’re used to computing costs as a software person, where hardware is
an additional external expense. IOT manufacturers are first and
foremost hardware people, they sell devices not bags of bits, they know
how to make hardware as cheap as possible, and how to market hardware
features so the marginal cost does not cost them a dime.
Regards,
--
Nicolas Mailhot
6:41 a.m.
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_ 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. Believe me, if they project that the NRE required to realize
that cost savings comes in under $1M, they will make it happen.
(Obviously the production volume is what determines what level of cost
optimzation is worthwhile...)
A physical button is a on-of, a digital key infrastructure is years
of
expensive maintenance and updates to keep going.
The marginal cost of additional users of digital key infrastructure is
infitesimal, especially if the widget already requires some sort of
online service to function. The costs of that get covered by the
subscrption fees. (and when there's no fee, the costs get covered by
mining your data)
Now the manufacturer may run the numbers and decide that using a
physical button vs pure digital implementation reduces the _support_
costs, so it's better to stick with a button, but if we're being honest
here most of the time post-sales lifecycle implications are rarely given
any consideration at all.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org (email&xmpp)
@pizza:shaftnet dot org (matrix)
High Springs, FL speachy (freenode)
12:35 p.m.
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.
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?
P.
--
Philip Rhoades
PO Box 896
Cowra NSW 2794
Australia
E-mail: phil(a)pricom.com.au
1:31 p.m.
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?
Yeah, yeah.. :)
Even if I've lost the ability to do basic math, I think my point is
still valid. If the NRE is less than the marginal BOM cost multiplied
out by the expected production run, it's considered a net win.
- Solomon
--
Solomon Peachy pizza at shaftnet dot org (email&xmpp)
@pizza:shaftnet dot org (matrix)
High Springs, FL speachy (freenode)
4:22 p.m.
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, that's the situation right now: everyone has a custom firmware tied
to a short product cycle---so new versions and fixes have to be
developed separately by everyone. This does not scale, and so it doesn't
happen most of the time. I think the only long-term solution is a wide
use of platforms, such as Android or Fedora.
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---it doesn't scale to the size the IOT is going to be.
Moreover, without the secure method, any vulnerability can be easily
converted to persistent breakage.
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 implementing systems such as this is obvious.. If the end
user cannot upload their own firmware, because the host has a hardware
mechanism for checking the signature of the firmware, that's not good for the
end user, it's harmful. It would mean they don't actually own the system, the
vendor does.
--
John M. Harris, Jr.
9:52 a.m.
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 implementing systems such as this is obvious.. If the end
user cannot upload their own firmware, because the host has a hardware
mechanism for checking the signature of the firmware, that's not good for the
end user, it's harmful. It would mean they don't actually own the system, the
vendor does.
Yes, but it it's too easy (and can be triggered remotely) it becomes a
huge problem.
I also want to be able to load alternative firmware---but it has to be
difficult, e.g. by requiring to disassemble the device and physically
access the electronics.
10:23 a.m.
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 everyone's system and b) having a secure remote update
>> method.
>
> The problem with implementing systems such as this is obvious.. If the end
> user cannot upload their own firmware, because the host has a hardware
> mechanism for checking the signature of the firmware, that's not good for
> the end user, it's harmful. It would mean they don't actually own the
> system, the vendor does.
Yes, but it it's too easy (and can be triggered remotely) it becomes a
huge problem.
I also want to be able to load alternative firmware---but it has to be
difficult, e.g. by requiring to disassemble the device and physically
access the electronics.
This is precisely what we're trying to fight with the libreboot project. It
should be as easy as possible, so that more end users can use FLOSS boot
firmware. Vendors have no trouble making it difficult as it is.
--
John M. Harris, Jr.
1:54 p.m.
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:
<Snip>
> Well, if that is your concern the answer is secure boot. That
will not
> only prevent tampering with /boot files, but also prevent tampering with
> the bootloader itself.
No, Secure Boot doesn't solve that problem. Secure Boot, in Fedora anyway,
needlessly disables a lot of kernel functionality, which makes it completely
unusable. You cannot load kernel modules you've built, hibernate your system,
etc. Additionally, Secure Boot does not prevent tampering with /boot files.
You can still change grub.cfg as you like.
<Snip>
Yet here I am, happily using it, across multiple systems...
4:16 a.m.
On Tue, Jul 7, 2020 at 6:17 AM Gerd Hoffmann <kraxel(a)redhat.com> 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 is your concern the answer is secure boot. That will not
only prevent tampering with /boot files, but also prevent tampering with
the bootloader itself.
Do review it. While "Trusted Computing" was blatantly aimed at DRM
rather than user security, its use to lock down the boot process and
prevent unauthorized bootloader access has been useful for high
security devices in poor security physical environments.
> or config files haven't been read by somebody other than
the end
> user.
Hmm, typically that is pretty standard stuff and very simliar on all
fedora installs. Only the root filesystem uuid differs, and possibly
local tweaks like configuring a serial console. I can't see how reading
that is of much concern.
> > We could that by using vfat for /boot. Or by shipping & using xfs.efi,
> > simliar to how apple ships & uses apfs.efi to boot macOS from apfs
> > filesystems.
Splitting of "/boot" is *bad* a long-known problem. It used to be
common place, but it makes disk size management that painful step more
awkward for resizing sotrage in virtualization or physical
environments.
> Is there a notable benefit to using that over GRUB2, which
already has
> support on both UEFI and BIOS?
Well, for my day-to-day work it doesn't make much of a difference. Both
get the job done.
I generally dislike the grub2 config file format. I'm not going to
repeat all the arguments here which have been mentioned numerous times
already. With BLS support things became a bit better because for the
most part I can just ignore grub.cfg after install.
It has problems, especially the lack of a useful "lint" for verifying
new configs before deployment. I still sadly lament the lack of a "run
this config as the default one time only, then revert to the other as
default" which LILO supported and I used for testing kernels on new
hardware. If the OS booted successfully, the init scripts would run a
command to set the default to the new kernel, otherwise a failed boot
would revert to the new kernel. Saved my company more than 1000
servers when a vendor did an unauthorized and incompatible hardware
upgrade for brand new systems, and the production kernel we deployed
on them failed to boot.
1:58 p.m.
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.
1:15 a.m.
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 everyone's preference.
I also own several legacy BIOS based systems that cannot support EFI, and they work fine,
including my daily driver Thinkpad T410.
While I know it will still be possible for *very* advanced Linux users such as me to get
Fedora working on BIOS systems with my own bootloader of choice even if Fedora drops
support, it would create a maintenance nuisance if I need to boot a recovery ISO etc or
reinstall Fedora from scratch, e.g. in drive failure. And, of course, most Fedora users
can't easily swap out a bootloader, they just haven't spent the energy learning
those parts of the OS.
Though, that would hardly be my concern. As sad as I was to see i686 support dropped, I
could at least understand the reasoning behind it, given how few people used it and how
large of a maintenance task it was. I myself didn't really use any systems that needed
it. This, however, is different.
Personally, I despise GRUB2, that's why I switched to syslinux when distros dropped
GRUB1. I find GRUB2 very bloated, needlessly complicated, with too many magic black
boxes.
That said, dropping BIOS support simply to adopt another bootloader in its place is a
deeply disturbing proposition. There are many BIOS based systems still in service, and
there will be for quite some time.
My Thinkpad was manufactured in 2011 and still only supports BIOS. In 2012, I started
seeing EFI-based PCs on the market due to Windows 8 and MSFT's push for secure boot.
Apple was an exception, they started using EFI as soon as they switched to Intel. The rest
of the world remained on BIOS until 2012.
Are you seriously considering dropping support for all systems older than 8 years of age?
Even if I could mostly work around such a decision, it would anger me and I imagine a
great many other users, purely on ideological grounds. I would consider switching
distributions, and I've been a Fedora loyalist since 2009.
Do you remember when Linux was touted as a lightweight alternative for older PCs, and you
could install flagship distros on grandma's PC to breathe new life into it? I do. I
don't want to live in the timeline where the only distros that run on such things are
puppy linux and similar.
11:47 a.m.
On Mon, 19 Oct 2020 at 02:15, Subsentient <thinkingrodent(a)gmail.com> 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 small it is, but that's me, and it's not
going to be everyone's preference.
I also own several legacy BIOS based systems that cannot support EFI, and
they work fine, including my daily driver Thinkpad T410.
While I know it will still be possible for *very* advanced Linux users
such as me to get Fedora working on BIOS systems with my own bootloader of
choice even if Fedora drops support, it would create a maintenance nuisance
if I need to boot a recovery ISO etc or reinstall Fedora from scratch, e.g.
in drive failure. And, of course, most Fedora users can't easily swap out a
bootloader, they just haven't spent the energy learning those parts of the
OS.
Though, that would hardly be my concern. As sad as I was to see i686
support dropped, I could at least understand the reasoning behind it, given
how few people used it and how large of a maintenance task it was. I myself
didn't really use any systems that needed it. This, however, is different.
Personally, I despise GRUB2, that's why I switched to syslinux when
distros dropped GRUB1. I find GRUB2 very bloated, needlessly complicated,
with too many magic black boxes.
That said, dropping BIOS support simply to adopt another bootloader in its
place is a deeply disturbing proposition. There are many BIOS based systems
still in service, and there will be for quite some time.
My Thinkpad was manufactured in 2011 and still only supports BIOS. In
2012, I started seeing EFI-based PCs on the market due to Windows 8 and
MSFT's push for secure boot. Apple was an exception, they started using EFI
as soon as they switched to Intel. The rest of the world remained on BIOS
until 2012.
Are you seriously considering dropping support for all systems older than
8 years of age? Even if I could mostly work around such a decision, it
would anger me and I imagine a great many other users, purely on
ideological grounds. I would consider switching distributions, and I've
been a Fedora loyalist since 2009.
Do you remember when Linux was touted as a lightweight alternative for
older PCs, and you could install flagship distros on grandma's PC to
breathe new life into it? I do. I don't want to live in the timeline where
the only distros that run on such things are puppy linux and similar.
I think the issue is that people have rose coloured glasses about how much
'life' we could get out of someone's older PC... and how old that desktop
was. In the 30 years I have worked in PC/Unix, I would say that before
2004, it was rare that it breathed new life into 2+ year old technology as
much as that the Linux kernel worked with all the hardware by then. Working
on an 1985 i386 in 1993 with Linux was great, but it was not any faster
than Windows 3.11 for a lot of things. A i486 with Linux was not running as
'fast' as a i586 with Windows 95 in 1997. You could get some better usage
from older hardware as long as you kept the tasks run meant to run in such
a 'limited' environment. But as soon as Grandpa wanted to open Netscape or
Staroffice.. you would watch a mouse crawl as you ran out of swap.
Having upgraded lots of "Grand-pa's" computer for 2 decades, I can say that
their computers were rarely older than 4-5 years old until after 2008. 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. When clock speeds were no longer doubling and
'standard' hardware memory bought came in a window of 2GB to 4 GB for a
decade, being able to keep hardware longer really started happening. At
that point, most of the time there was no giant performance boost for most
things people did on the computer and unless you were into gaming, or
professions using a CPU to its max... most people stuck with the old stuff.
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 were a 10+ year computer isn't very useful for
'modern' software (browser and various applications). Instead if you want
to have something work on a 2012 system well.. just use software from
2012. It is still available. Sure you can install Linux on that 15 year
old computer but if you have to tell the user well you can't actually use a
browser, an editor or half the things you can do on your cheapest
smart-phone.. what use is that computer?
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Stephen J Smoogen.
12:16 p.m.
On Mon, Oct 19, 2020 at 7:48 PM Stephen John Smoogen <smooge(a)gmail.com>
wrote:
On Mon, 19 Oct 2020 at 02:15, Subsentient <thinkingrodent(a)gmail.com>
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 small it is, but that's me, and it's
not
> going to be everyone's preference.
>
> I also own several legacy BIOS based systems that cannot support EFI, and
> they work fine, including my daily driver Thinkpad T410.
> While I know it will still be possible for *very* advanced Linux users
> such as me to get Fedora working on BIOS systems with my own bootloader of
> choice even if Fedora drops support, it would create a maintenance nuisance
> if I need to boot a recovery ISO etc or reinstall Fedora from scratch, e.g.
> in drive failure. And, of course, most Fedora users can't easily swap out a
> bootloader, they just haven't spent the energy learning those parts of the
> OS.
>
> Though, that would hardly be my concern. As sad as I was to see i686
> support dropped, I could at least understand the reasoning behind it, given
> how few people used it and how large of a maintenance task it was. I myself
> didn't really use any systems that needed it. This, however, is different.
>
> Personally, I despise GRUB2, that's why I switched to syslinux when
> distros dropped GRUB1. I find GRUB2 very bloated, needlessly complicated,
> with too many magic black boxes.
> That said, dropping BIOS support simply to adopt another bootloader in
> its place is a deeply disturbing proposition. There are many BIOS based
> systems still in service, and there will be for quite some time.
>
> My Thinkpad was manufactured in 2011 and still only supports BIOS. In
> 2012, I started seeing EFI-based PCs on the market due to Windows 8 and
> MSFT's push for secure boot. Apple was an exception, they started using EFI
> as soon as they switched to Intel. The rest of the world remained on BIOS
> until 2012.
>
> Are you seriously considering dropping support for all systems older than
> 8 years of age? Even if I could mostly work around such a decision, it
> would anger me and I imagine a great many other users, purely on
> ideological grounds. I would consider switching distributions, and I've
> been a Fedora loyalist since 2009.
>
> Do you remember when Linux was touted as a lightweight alternative for
> older PCs, and you could install flagship distros on grandma's PC to
> breathe new life into it? I do. I don't want to live in the timeline where
> the only distros that run on such things are puppy linux and similar.
>
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.
I think the issue is that people have rose coloured glasses about how
much
'life' we could get out of someone's older PC... and how old that desktop
was. In the 30 years I have worked in PC/Unix, I would say that before
2004, it was rare that it breathed new life into 2+ year old technology as
much as that the Linux kernel worked with all the hardware by then. Working
on an 1985 i386 in 1993 with Linux was great, but it was not any faster
than Windows 3.11 for a lot of things. A i486 with Linux was not running as
'fast' as a i586 with Windows 95 in 1997. You could get some better usage
from older hardware as long as you kept the tasks run meant to run in such
a 'limited' environment. But as soon as Grandpa wanted to open Netscape or
Staroffice.. you would watch a mouse crawl as you ran out of swap.
Having upgraded lots of "Grand-pa's" computer for 2 decades, I can say
that their computers were rarely older than 4-5 years old until after 2008.
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. When clock speeds were no longer doubling and
'standard' hardware memory bought came in a window of 2GB to 4 GB for a
decade, being able to keep hardware longer really started happening. At
that point, most of the time there was no giant performance boost for most
things people did on the computer and unless you were into gaming, or
professions using a CPU to its max... most people stuck with the old stuff.
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 were a 10+ year computer isn't very useful
for 'modern' software (browser and various applications). Instead if you
want to have something work on a 2012 system well.. just use software from
2012. It is still available. Sure you can install Linux on that 15 year
old computer but if you have to tell the user well you can't actually use a
browser, an editor or half the things you can do on your cheapest
smart-phone.. what use is that computer?
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
>
--
Stephen J Smoogen.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
12:25 p.m.
On Mon, Oct 19, 2020 at 8:16 pm, Arnoldas Skinderis
<arnoldas.linux(a)gmail.com> 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 rejected, so don't worry about it.
12:29 p.m.
On Mon, Oct 19, 2020 at 8:27 PM Michael Catanzaro <mcatanzaro(a)gnome.org>
wrote:
On Mon, Oct 19, 2020 at 8:16 pm, Arnoldas Skinderis
<arnoldas.linux(a)gmail.com> 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 rejected, so don't worry about it.
That's great news. Thank you!
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
12:45 p.m.
> 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 than loads the EFI loader. This would be a one time step.
Hopefully Fedora will have enough resources to support systemd-boot on
Fedora Silverblue,
which has never worked so far due to ostree naming conventions
https://github.com/ostreedev/ostree/issues/1951
1:15 p.m.
On Mon, Oct 19, 2020 at 5:46 PM Damian Ivanov <damianatorrpm(a)gmail.com> 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 efi using a boot tool
installed to the MBR which emulates EFI
and than loads the EFI loader. This would be a one time step.
I believe EFI emulation would be too big to fit in the
446 bytes available in the MBR, so one would need
a biosboot partition for that EFI emulator, but the
other issue (as I recall) was that the EFI emulation
had been using IP that may not be appropriately
"free" (fat32?). Perhaps now that that IP has been
contributed to OIN (and the various legal reviews
and processes for Fedora to properly utilize those
patents are complete) there may be a future path
forward (if someone is so motivated).
1:27 p.m.
>> 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 capsule updates for updating system firmware
I feel it's in quite good state with people improving on things
constantly.
Devices that are BIOS can IIRC still use efi using a boot tool
installed to the MBR which emulates EFI
and than loads the EFI loader. This would be a one time step.
Why bother, just adds an extra layer of complexity with no added
benefits that UEFI provides.
Hopefully Fedora will have enough resources to support systemd-boot
on
Fedora Silverblue,
which has never worked so far due to ostree naming conventions
I see that less likely because of the need to have a already stretched
team supporting yet another boot path.
> https://github.com/ostreedev/ostree/issues/1951
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
2:49 p.m.
On 19.10.2020 17:25, Michael Catanzaro wrote:
On Mon, Oct 19, 2020 at 8:16 pm, Arnoldas Skinderis
<arnoldas.linux(a)gmail.com> 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 rejected, so don't worry about it.
Never was an official proposal to begin with so I cant see how it was
"soundly rejected" but yes the dialog highlighted that there will be
quite few years before the distribution can get to the point where an
official proposal can be made. Maybe 2024 would be a target goal for
such effort. Regardless consensus has to be reached on how long/old
hardware should be supported so people expectations can be
raised/lowered accordingly. Arguably something that the Council should
look at.
JBG
4:28 p.m.
b
On Tue, Oct 20, 2020 at 8:49 PM Jóhann B. Guðmundsson
<johannbg(a)gmail.com> wrote:
On 19.10.2020 17:25, Michael Catanzaro wrote:
> On Mon, Oct 19, 2020 at 8:16 pm, Arnoldas Skinderis
> <arnoldas.linux(a)gmail.com> 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 rejected, so don't worry about it.
Never was an official proposal to begin with so I cant see how it was
"soundly rejected" but yes the dialog highlighted that there will be
quite few years before the distribution can get to the point where an
official proposal can be made. Maybe 2024 would be a target goal for
such effort. Regardless consensus has to be reached on how long/old
hardware should be supported so people expectations can be
raised/lowered accordingly. Arguably something that the Council should
look at.
While I don't actually believe old hardware should be dropped I don't
believe there was a consensus reached.
Fedora is a distribution that aims to be first so I believe there
should be work done so that spins or editions that wish to be able to
drop support for BIOS installs while other parts of the distribution
retaining compatibility for legacy platforms be enable to do so and I
don't feel that that discussion has been had, a lot of the discussion
was focused on single people "this is my use case" not the wider use
cases of the distribution or what SIGs are interested in.
8:56 p.m.
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. Ever. I have two
newer laptops, they run Fedora just fine, but the legendary Thinkpad
keyboard is generations ahead of the crappy chiclets on the other one.
Laughably easy to maintain. In the ten or so years I had it, I only had to
replace that keyboard once, that's it. Oh, and put a new touchpad sticker,
to replace the worn-out membrane cover.
This beast, as long as it can still run Fedora, will likely outlive me, and
I'll have to will it to someone…
1:33 p.m.
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 to the point were a 10+ year computer isn't very useful for 'modern'
software (browser and various applications). Instead if you want to have something work on
a 2012 system well.. just use software from 2012. It is still available. Sure you can
install Linux on that 15 year old computer but if you have to tell the user well you
can't actually use a browser, an editor or half the things you can do on your cheapest
smart-phone.. what use is that computer?
My daughter actually took a 12+ years old (one of the first 64 bit core 2 duo
models) laptop (Dell Latitude E6400) with her to school for a project last week
and happily ran a browser (latest firefox) and libreoffice on it without issues.
Sure I've probably upgraded the RAM a bit at some point (I don't remember
when I did that, so a long time ago) and I dropped in a SSD something like
5 years ago I guess. But with those 2 upgrades it still is a fine machine
for a lot of things.
And the PC in the living room used for netflix, disney+ and primevideo
is another core 2 duo (one of the later gens) models happily doing what
we ask of it; and my wife's home-office machine is another ...
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 and those
machines are still very capable.
It really just is way too early / too soon to cut of BIOS booting support.
Regards,
Hans
2:13 p.m.
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 and those
machines are still very capable.
I've got ~30 non-EFI Acer TimelineX Aspire 3820Ts, circa ~ 2009-10 still in
'production' across the enterprise. e.g.,
dmesg | grep DMI:
[ 0.000000] DMI: Acer Aspire 3820/JM31_CP, BIOS V1.19 10/27/2010
They currently run (recently migrated)
grep _NAME /etc/os-release
PRETTY_NAME="Fedora 32 (Server Edition)"
CPE_NAME="cpe:/o:fedoraproject:fedora:32"
uname -rm
5.8.15-201.fc32.x86_64 x86_64
**ALL* have
cat /proc/cpuinfo |grep "^model name"
model name : Intel(R) Core(TM) i3 CPU M 370 @ 2.40GHz
, 8GB RAM
free
total used free shared buff/cache available
Mem: 7806944 673488 3105532 102896 4027924 6733392
Swap: 8388604 0 8388604
, 500GB ssds,
hwinfo --disk | grep Device:
Device: "CT1000MX500SSD1"
and run
libreoffice-x11-6.4.7.2-1.fc32.x86_64
VirtualBox-6.1-6.1.14_140239_fedora32-1.x86_64 (Win10 guests)
Firefox 81.0.2
Thunderbird 78.3.3
as well as
java --version
openjdk 15 2020-09-15
OpenJDK Runtime Environment 20.9 (build 15+36)
OpenJDK 64-Bit Server VM 20.9 (build 15+36, mixed mode, sharing)
a number run
PhpStorm 2020.3 EAP
Build #PS-203.4818.52, built on October 15, 2020
&/or
Eclipse Platform
Version: 2020-03 (4.15)
Build id: I20200305-0155
My own manages nginx/php & mariadb quite nicely as well.
Are these screamin' fast? Do they have 8K screens to play video games on? No. Of
course not.
But they are *perfectly* serviceable/functional; and that's just one model of
'oldies' around here.
All that^ is _still_ more 'juice' than many a VPS ... what it requires to make old
boxes 'serve well' is some due diligence on right-sizing your
kernel/app/server/tool/etc configs. AND a distro (even if it's a DIY LFS ...) that
makes it possible.
It really just is way too early / too soon to cut of BIOS booting
support.
big emphasis on the 'way'.
i for one am certainly glad that that's the decision that's been taken, and that i
won't have to face migrating to yet-another-OS because of bad enterprise policy
decisions.
esp, since Fedora's grown on me ...
3:34 a.m.
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 missed its 64bit conversion.
Previously, you could always add a couple of years of useful lifetime
to a computer just by adding some memory (because memory is one of the
key parameters manufacturers skimp on). But, once most of the market
got stuck in 4GiB land due to Windows limitations, you could suddenly
add a decade or so of lifetime just by using the fact Linux was 64 bit
to grossly outscale the default Windows-oriented memory setup.
Now the gap is slowly shrinking now that Windows is 64bit and
manufacturers learn to use memory again. But it will be some time
before the 64bit-ed Linux installed base get outperformed enough to be
retired
Regards,
--
Nicolas Mailhot
5:21 a.m.
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 the point were a 10+ year computer
isn't very useful for 'modern' software (browser and various
applications). Instead if you want to have something work on a 2012
system well.. just use software from 2012. It is still available.
Sure you can install Linux on that 15 year old computer but if you
have to tell the user well you can't actually use a browser, an editor
or half the things you can do on your cheapest smart-phone.. what use
is that computer?
Sorry to interrupt, but thats not true. ATM i have a 2013 System running
and it's same as fast as it was 2013. No Firefox update changed that nor
did it stop me from running games on 100 FPS+ on FHD (FX8350/16GBRAM).
If you had made a choice for "invest more, keep it longer" in 2013, it
still runs smooth. I even had a friend mentioning his >11y old (now)
Win10 pc still running fine, and you know how much windows bloated in
this time.
But if you bought your PC in 2013 with 2 Intel Mobile Cores and 2 GB
RAM than it's your poor choice of hw in 2013 thats limiting you now.
The times, when PC hw is obsoleted 5 years later, are over for the
common users. What do they do? Watch Netflix, read mail, print picture.
You simply don't need a 48 Core cpu for this.
In this spirit: Dropping legacy bios support is a mistake.
best regards,
Marius
5:32 a.m.
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
has increased to the point were a 10+ year computer isn't very useful for
'modern' software (browser and various applications).
I'm curious what are the various applications.
Web browsers gained multi-threading because they expelled plugins and started
bundling everything what used to be part of a desktop (namely processing audio
and video). As far as I know JavaScript environment is still single-threaded.
Video players can offload decoding to graphics cards if needed. (Although in
my part of world a 10-year-old CPU is enough because you rarely get something
more demanding than 720p H.264.)
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
consumes 500 MB of memory and after logging in Gnome shell for user's session
takes another 500 MB. SDDM becomes insanely graphics-demanding. The QML
backend first started polling old Intel VGAs, then spits flickering artifacts
on old Radeons. Regarding feature-parity it completely looses to KDM (no XDM,
broken PAM with non-password authentication mechisms, it even became a blocker
for F33).
Instead if you want to have something work on a 2012 system well..
just use
software from 2012.
With security bugs from 2012. No thanks.
-- Petr
8:45 a.m.
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
consumes 500 MB of memory and after logging in Gnome shell for user's
session
takes another 500 MB. SDDM becomes insanely graphics-demanding. The
QML
backend first started polling old Intel VGAs, then spits flickering
artifacts
on old Radeons. Regarding feature-parity it completely looses to KDM
(no XDM,
broken PAM with non-password authentication mechisms, it even became
a blocker
for F33).
The worst thing is that was done as the same time that wayland moved
input management to the window manager. Any random GUI action can now
result in feel-good GUI prettification that will starve input
processing of CPU, resulting in frozen mouse pointers and missed
repeated or reordered keystrokes.
So, useless desktop except as a browser shell where typing is marginal.
journalctl | grep gnome-shell | grep 'libinput error' | grep
'your
system is too slow' | wc -l
7060
cat /proc/cpuinfo | grep model
model : 142
model name : Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
model : 142
model name : Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
model : 142
model name : Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
model : 142
model name : Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
Hardly an underpowered system
--
Nicolas Mailhot
8:12 a.m.
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 were a 10+ year computer isn't very useful for
'modern' software (browser and various applications). Instead if you want
to have something work on a 2012 system well.. just use software from
2012. It is still available.
I know you know, you are being polemic and cheating.
2012's SW is
unusable today.
Sure you can install Linux on that 15 year
old computer but if you have to tell the user well you can't actually use a
browser, an editor or half the things you can do on your cheapest
smart-phone.. what use is that computer?
Do yourselves a favor and try it
yourselves: A 2012 mid-class system
still outperforms many todays low-end systems and many notebooks.
These systems are well suitable for many purposes!
Ralf
4:35 a.m.
well,
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
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 argument since only this counts: How many users does BIOS have
today ?
And that number is huge.
10:41 a.m.
On Thu, 2021-05-27 at 09:35 +0000, eedio wrote:
well,
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
suggesting to drop BIOS is a nonstarter.
This thread died over half a year ago (back in October of last year)
after the proposal was comprehensively rejected. No-one is currently
proposing to remove it. The thread was inexplicably necro'ed yesterday
by a person I don't recall ever hearing from before ("L Five") purely
to lob some gratuitous personal attacks. I recommend letting it die
again.
--
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net
7:32 a.m.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
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 before the year 2030.
9:17 a.m.
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 common intel based x86 platform
since atleast 2005.
Now in 2017 Intel's technical marketing engineer Brian Richardson
revealed in a presentation that the company will require UEFI Class 3
and above as in it would remove legacy BIOS support from its client
and datacenter platforms by 2020 and one might expect AMD to follow
Intel in this regard.
This will fail i.e. on M$ Surface Pro * systems.
Also, a lot of laptops are installed in Legacy Mode, as setting them up
in EFI was impossible.
best regards,
Marius Schwarz
9:25 a.m.
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 install shim (only if needed).
6. Reboot.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
9:45 a.m.
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 and mount.
4. sudo dnf swap grub2 grub2-efi
5. sudo dnf install shim (only if needed).
6. Reboot.
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.
Nikolay
10:10 a.m.
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 doesn't have some (eventual) pain. And that
includes not migrating.
A useful place to start is a thorough read of
https://opensource.com/article/19/5/dual-booting-windows-linux-uefi
https://www.maketecheasier.com/convert-legacy-bios-uefi-windows10/
, considering what exactly your system supports (gpt, efi, etc.), and identifying where
you want to end up.
I don't migrate hardware until it's demonstrated to make technical & business
sense.
We've *lots* of legacy-bios/MBR hardware that's perfectly serviceable with
either/both modern linux / windows.
"It's bright & shiny" isn't a valid argument for change here.
Any _software_ that forces unnecessary cost on the ecosystem, including dropping BIOS
support or generally breaking stable user-space, will get removed from the picture. Or,
at least, _very_ marginalized/compartmentalized.
Personally I'm banking on the 'old, wise hats' @ distro here to prevent making
foolish choices. So far, so good.
4:28 p.m.
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 been
> available on any common intel based x86 platform since atleast 2005.
>
> Now in 2017 Intel's technical marketing engineer Brian Richardson revealed
> in a presentation that the company will require UEFI Class 3 and above as in
> it would remove legacy BIOS support from its client and datacenter platforms
> by 2020 and one might expect AMD to follow Intel in this regard.
This will fail i.e. on M$ Surface Pro * systems.
Also, a lot of laptops are installed in Legacy Mode, as setting them up in
EFI was impossible.
I have two servers that predate 2005. They've been running Fedora just fine
since then, with no problems whatsoever. Back then, server-level hardware
was built to last. I know that at least one of them does not support EFI.
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, it will be a shame.
4:41 p.m.
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, it will be a shame.
This is the same thread. Someone unfortunately re-activated it...
7:29 a.m.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
it came up on ask.fedora and is linked into here.
4:27 p.m.
[…] 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 non-(U)EFI BIOS. One is too old, manufactured
around 2010 when (U)EFI was not available. One is new enough to having (U)EFI, but
it's a mess and never worked with Fedora's (U)EFI integration so I was forced to
install it in legacy BIOS mode.
In other words: I think it is too early to drop non-(U)EFI BIOS support.
6:04 p.m.
On Tue, Jul 6, 2021 at 3:37 PM Christian Stadelmann
<genodeftest(a)fedoraproject.org> 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 was introduced around 2011.
UEFI support was introduced in Windows Vista, 2007. And it was refined
in Windows 7, 2009. Discussion of UEFI Secure Boot began in earnest in
the Linux world around 2012. And became a requirement for all new
consumer PC's wanting Windows 10 hardware certification, in 2015.
Server hardware has had more leeway.
I own 2 devices which are booting with non-(U)EFI BIOS. One is too
old, manufactured around 2010 when (U)EFI was not available. One is new enough to having
(U)EFI, but it's a mess and never worked with Fedora's (U)EFI integration so I was
forced to install it in legacy BIOS mode.
In other words: I think it is too early to drop non-(U)EFI BIOS support.
I think there probably are too many legacy BIOS systems for us to drop
legacy support in the near term.
We might consider:
(a) Revisiting GPT by default. By revisiting that means exploring the
bugs and work arounds. The reason for this is moving toward a
self-describing boot process, and abstracting the low level bootloader
requirements from user space configuration. There's good reasons to
get the user space configuration with Boot Loader Spec support
sufficiently abstracted that we could do a drop in bootloader swap one
day, either for use case specific reasons, or distro wide.
It could be that we can abandon hardware that can't tolerate GPT, if
the benefits outweigh the consequences.
(b) Consider DUET as a way to bring UEFI support to BIOS systems. I'm
not sure about the status of this work though, and if it's intended to
bring legacy BIOS systems forward with a single UEFI approach in a
distribution. Or if the intent was only for development purposes until
native UEFI implementations became more ubiquitous. Would adding this
kind of layer just be asking for more things to maintain,
troubleshoot, test, and break?
https://github.com/tianocore/tianocore.github.io/wiki/DuetPkg
--
Chris Murphy
6:59 p.m.
On Tue, Jul 6, 2021 at 7:05 PM Chris Murphy <lists(a)colorremedies.com> wrote:
On Tue, Jul 6, 2021 at 3:37 PM Christian Stadelmann
<genodeftest(a)fedoraproject.org> 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 was introduced around 2011.
UEFI support was introduced in Windows Vista, 2007. And it was refined
in Windows 7, 2009. Discussion of UEFI Secure Boot began in earnest in
the Linux world around 2012. And became a requirement for all new
consumer PC's wanting Windows 10 hardware certification, in 2015.
Server hardware has had more leeway.
> I own 2 devices which are booting with non-(U)EFI BIOS. One is too old, manufactured
around 2010 when (U)EFI was not available. One is new enough to having (U)EFI, but
it's a mess and never worked with Fedora's (U)EFI integration so I was forced to
install it in legacy BIOS mode.
>
> In other words: I think it is too early to drop non-(U)EFI BIOS support.
I think there probably are too many legacy BIOS systems for us to drop
legacy support in the near term.
We might consider:
(a) Revisiting GPT by default. By revisiting that means exploring the
bugs and work arounds. The reason for this is moving toward a
self-describing boot process, and abstracting the low level bootloader
requirements from user space configuration. There's good reasons to
get the user space configuration with Boot Loader Spec support
sufficiently abstracted that we could do a drop in bootloader swap one
day, either for use case specific reasons, or distro wide.
It could be that we can abandon hardware that can't tolerate GPT, if
the benefits outweigh the consequences.
(b) Consider DUET as a way to bring UEFI support to BIOS systems. I'm
not sure about the status of this work though, and if it's intended to
bring legacy BIOS systems forward with a single UEFI approach in a
distribution. Or if the intent was only for development purposes until
native UEFI implementations became more ubiquitous. Would adding this
kind of layer just be asking for more things to maintain,
troubleshoot, test, and break?
https://github.com/tianocore/tianocore.github.io/wiki/DuetPkg
DUET would probably be the best shot, but it was removed at the end of
2018 due to the lack of interest and usage[1]. If someone wants to
step up to maintain the DuetPkg module for EDK2, we could start going
down the path of streamlining the boot process in the same way that
has occurred in ARM[2]. We'd also benefit from a relatively consistent
UEFI implementation as EDK2 is built on TianoCore[3], which is also
where OVMF/AVMF used for UEFI on KVM is from.
[1]: https://bugzilla.tianocore.org/show_bug.cgi?id=1322
[2]: https://fedoraproject.org/wiki/Changes/ARMv7UEFI
[3]: https://www.tianocore.org/
--
真実はいつも一つ！/ Always, there's only one truth!
11:27 a.m.
On Wed, Jul 7, 2021 at 8:23 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> 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.
That is slightly more complicated in later updates
by Microsoft, which talks about new computers to
be sold retail and installed with Windows (and
Microsoft has been upping the requirements for
new retail computers slowly over time). They
also talk about needing an Intel gen8 processor
or better (although that is at least partially likely
to be the case because Intel no longer supports
older processors according to their support
list).
For existing devices to upgrade, TPM 1.2 is
apparently sufficient, and it is not clear that
UEFI (at all, or in Secure Boot mode) will
be required, and they do say that older
processors are likely to work, but they are
not testing them. And it is possible for
upgrades from W10 they might relax any
or all of the initially stated requirements. For
the early adopter builds that have been made
available it seems none of the requirements
are currently hard (just "recommendations").
So I am not sure that Microsoft's
announcements, which seem to be somewhat
fluid, should drive Fedora's decisions.
Personally, if DUET (or equivalent) worked
(and I have not tried it) that would work for
me with my few remaining legacy BIOS
only boxes;
1017
days inactive
1389
days old
316 comments
78 participants
participants (78)
-
Adam Williamson -
Alek Paunov -
Alex Thomas -
Alexander Ploumistos -
Alexey A. -
Andy Mender -
Arnoldas Skinderis -
Björn Persson -
Brandon Nielsen -
Brian C. Lane -
Chris Adams -
Chris Murphy -
Christian Stadelmann -
Christopher Engelhard -
Colin Walters -
Damian Ivanov -
Daniel P. Berrangé -
David Michael -
Dominik 'Rathann' Mierzejewski -
eedio -
Faye C. -
Felipe Borges -
Florian Weimer -
Gary Buhrmaster -
Gerd Hoffmann -
Gordon Messmer -
Hans de Goede -
Igor Raits -
Ivan Ivanov -
Javier Martinez Canillas -
Jiří Eischmann -
John M. Harris Jr -
Jonathan Wakely -
Julian Sikorski -
Jóhann B. Guðmundsson -
Kevin Kofler -
Leigh Scott -
Lennart Poettering -
Luya Tshimbalanga -
Marcin Juszkiewicz -
Marius Schwarz -
Markus Larsson -
Martin Jackson -
Mauricio Tavares -
Michael Catanzaro -
Neal Gompa -
nickysn＠gmail.com -
Nico Kadel-Garcia -
Nicolas Mailhot -
Nikolay Nikolov
-
Peter Robinson -
Petr Pisar -
PGNet Dev -
Philip Rhoades -
Przemek Klosowski -
Qiyu Yan -
Rahul Sundaram -
Ralf Corsepius -
Richard Hughes -
Richard Shaw -
Richard W.M. Jones -
Ricky Zhang -
Robbie Harwood -
Roberto Ragusa -
Sam Varshavchik -
Samuel Sieb -
Simo Sorce -
Solomon Peachy -
stan -
Stephen John Smoogen -
Steven Usdansky -
Subsentient -
Sumit Bhardwaj -
Tom Hughes -
Tom Seewald -
Tomasz Torcz -
Vitaly Zaitsev -
ziba