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
-----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.
https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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@fedoraproject.org
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
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
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.
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
Jóhann B. Guðmundsson johannbg@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
On 30.6.2020 17:47, Robbie Harwood wrote:
Jóhann B. Guðmundsson johannbg@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
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
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
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?
On Mi, 01.07.20 22:09, John M. Harris Jr (johnmh@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
Igor Raits ignatenkobrain@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.
On Tue, Jun 30, 2020 at 01:34:42PM -0400, Robbie Harwood wrote:
Igor Raits ignatenkobrain@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
On Tue, Jun 30, 2020 at 12:35 PM Robbie Harwood rharwood@redhat.com wrote:
Igor Raits ignatenkobrain@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
* 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
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
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.
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
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
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.
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.
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.
On Tue, Jun 30, 2020 at 4:01 PM Florian Weimer fweimer@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/c486da262f6566326fbcb5ef...
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
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@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/c486da262f6566326fbcb5ef...
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
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
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.
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
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/
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
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
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/stora... 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...
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
On Di, 30.06.20 19:15, Gerd Hoffmann (kraxel@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
On 1.7.2020 09:36, Lennart Poettering wrote:
On Di, 30.06.20 19:15, Gerd Hoffmann (kraxel@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:
Create a large ESP and just use that. Everything is nice and simple
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
On Wed, Jul 1, 2020 at 11:37 AM Lennart Poettering mzerqung@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-and-a...
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
On Mi, 01.07.20 13:14, Javier Martinez Canillas (javier@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
On Wed, Jul 1, 2020 at 4:36 PM Lennart Poettering mzerqung@0pointer.de wrote:
On Mi, 01.07.20 13:14, Javier Martinez Canillas (javier@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
On Mi, 01.07.20 17:19, Javier Martinez Canillas (javier@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_SPECIFICATIO...
Thank you,
Lennart
-- Lennart Poettering, Berlin
On Sat, Jul 4, 2020 at 6:27 PM Lennart Poettering mzerqung@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
On 5.7.2020 18:34, Javier Martinez Canillas wrote:
On Sat, Jul 4, 2020 at 6:27 PM Lennart Poettering mzerqung@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
On Mon, Jul 6, 2020 at 10:39 AM Jóhann B. Guðmundsson johannbg@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@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
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@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@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
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
On Mi, 01.07.20 18:31, Gerd Hoffmann (kraxel@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
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.
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.
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.
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-1i...
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.
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-1i...
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
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-1i...
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
On Tue, 30 Jun 2020 at 17:26, Adam Williamson adamwill@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-1i...
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 :(.
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
On 6/30/20 8:24 AM, nickysn@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.
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.
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
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?
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/
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
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
On Wed, Jul 1, 2020 at 12:19 AM Jóhann B. Guðmundsson johannbg@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?
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@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_Guide/s...
On Do, 02.07.20 12:46, Peter Robinson (pbrobinson@gmail.com) wrote:
On Wed, Jul 1, 2020 at 12:19 AM Jóhann B. Guðmundsson johannbg@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
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.
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
On Wed, Jul 1, 2020 at 7:19 PM Björn Persson <Bjorn@rombobjörn.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!
On 1.7.2020 23:28, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 7:19 PM Björn Persson <Bjorn@rombobjörn.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
On Wed, Jul 1, 2020 at 9:03 PM Jóhann B. Guðmundsson johannbg@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@rombobjörn.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.
On 2.7.2020 01:06, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 9:03 PM Jóhann B. Guðmundsson johannbg@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@rombobjörn.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
On Wed, Jul 1, 2020 at 9:23 PM Jóhann B. Guðmundsson johannbg@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@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@rombobjörn.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.
On 2.7.2020 01:42, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 9:23 PM Jóhann B. Guðmundsson johannbg@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@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@rombobjörn.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>
On Wed, Jul 1, 2020 at 10:08 PM Jóhann B. Guðmundsson johannbg@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@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@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@rombobjörn.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.
On Mi, 01.07.20 22:10, Neal Gompa (ngompa13@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
On Sat, Jul 4, 2020 at 11:30 AM Lennart Poettering mzerqung@0pointer.de wrote:
On Mi, 01.07.20 22:10, Neal Gompa (ngompa13@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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Sa, 04.07.20 11:39, Mauricio Tavares (raubvogel@gmail.com) wrote:
On Sat, Jul 4, 2020 at 11:30 AM Lennart Poettering mzerqung@0pointer.de wrote:
On Mi, 01.07.20 22:10, Neal Gompa (ngompa13@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
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.
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.
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
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/
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
On Mon, 6 Jul 2020 at 07:38, Gerd Hoffmann kraxel@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 :).
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@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.
- 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
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
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
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
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.
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
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
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
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,
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
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,
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.
On Mi, 01.07.20 21:06, Neal Gompa (ngompa13@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
On Sat, Jul 4, 2020 at 11:20 AM Lennart Poettering mzerqung@0pointer.de wrote:
On Mi, 01.07.20 21:06, Neal Gompa (ngompa13@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.
On Sat, 4 Jul 2020 at 11:34, Neal Gompa ngompa13@gmail.com wrote:
On Sat, Jul 4, 2020 at 11:20 AM Lennart Poettering mzerqung@0pointer.de wrote:
On Mi, 01.07.20 21:06, Neal Gompa (ngompa13@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.
On 5 July 2020 16:27:07 CEST, Stephen John Smoogen smooge@gmail.com wrote:
On Sat, 4 Jul 2020 at 11:34, Neal Gompa ngompa13@gmail.com wrote:
On Sat, Jul 4, 2020 at 11:20 AM Lennart Poettering mzerqung@0pointer.de wrote:
On Mi, 01.07.20 21:06, Neal Gompa (ngompa13@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
On Sun, 5 Jul 2020 at 11:23, Markus Larsson qrsbrwn@uidzero.se wrote:
On 5 July 2020 16:27:07 CEST, Stephen John Smoogen smooge@gmail.com wrote:
On Sat, 4 Jul 2020 at 11:34, Neal Gompa ngompa13@gmail.com wrote:
On Sat, Jul 4, 2020 at 11:20 AM Lennart Poettering mzerqung@0pointer.de wrote:
On Mi, 01.07.20 21:06, Neal Gompa (ngompa13@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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
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.
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.
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
Jóhann B. Guðmundsson johannbg@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
On 30.6.2020 19:22, Robbie Harwood wrote:
Jóhann B. Guðmundsson johannbg@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/
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
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
On 30.6.2020 21:14, nickysn@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
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
On Tue, 2020-06-30 at 21:55 +0000, Jóhann B. Guðmundsson wrote:
On 30.6.2020 21:14, nickysn@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
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
On 30.6.2020 22:31, nickysn@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@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
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
On Tuesday, June 30, 2020 2:55:42 PM MST Jóhann B. Guðmundsson wrote:
On 30.6.2020 21:14, nickysn@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
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?
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
On Mi, 01.07.20 14:45, Hans de Goede (hdegoede@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
On Wed, 2020-07-01 at 16:30 +0200, Lennart Poettering wrote:
On Mi, 01.07.20 14:45, Hans de Goede (hdegoede@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
On Wednesday, July 1, 2020 7:30:37 AM MST Lennart Poettering wrote:
On Mi, 01.07.20 14:45, Hans de Goede (hdegoede@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?
On Thu, Jul 2, 2020 at 1:55 AM John M. Harris Jr johnmh@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@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.
On Thu, Jul 2, 2020 at 6:01 AM Neal Gompa ngompa13@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:
- It is absolutely butt-ugly.
- 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
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.
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".
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.
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.
On Mi, 01.07.20 22:55, John M. Harris Jr (johnmh@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
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
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
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.
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.
On Tue, Jun 30, 2020 at 2:39 PM Tom Seewald tseewald@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.
https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration
The primary areas of concern I have about Fedora dropping grub2 and BIOS boot support are:
- 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.
- 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?
- 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.
- 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.
- 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
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.
- 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.
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
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
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@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.
https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
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.
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@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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
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
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
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
On Wed, Jul 1, 2020 at 3:29 PM Alek Paunov alex@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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
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@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.
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
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.
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
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
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
On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson johannbg@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!
On 1.7.2020 21:00, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson johannbg@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
On Wed, Jul 1, 2020 at 5:29 PM Jóhann B. Guðmundsson johannbg@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@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.
On Wed, Jul 1, 2020 at 5:51 PM Neal Gompa ngompa13@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
On 1.7.2020 21:50, Neal Gompa wrote:
On Wed, Jul 1, 2020 at 5:29 PM Jóhann B. Guðmundsson johannbg@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@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
On Wed, Jul 1, 2020 at 6:45 PM Jóhann B. Guðmundsson johannbg@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@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@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.
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
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@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.
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
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).
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.
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.org/...
On Do, 02.07.20 15:30, Brandon Nielsen (nielsenb@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
On Sat, Jul 4, 2020 at 10:19 AM Lennart Poettering mzerqung@0pointer.de wrote:
If it way my decision I'd propose the following as the path to the future:
Unify/standardize on the boot loader spec, not the boot loader
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.
On Sa, 04.07.20 12:49, Chris Murphy (lists@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
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:
Unify/standardize on the boot loader spec, not the boot loader
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?
On Sa, 04.07.20 18:11, John M. Harris Jr (johnmh@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
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@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.
On Sun, Jul 5, 2020 at 11:26 AM John M. Harris Jr johnmh@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@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.
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,
On Sun, Jul 5, 2020 at 12:41 PM Nicolas Mailhot via devel devel@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!
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.
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,
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.
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.
On Thu, Jul 2, 2020 at 4:06 AM Vitaly Zaitsev via devel devel@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.
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.
On Wed, Jul 1, 2020 at 10:01 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson johannbg@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.
On Thu, Jul 2, 2020 at 9:49 AM Peter Robinson pbrobinson@gmail.com wrote:
On Wed, Jul 1, 2020 at 10:01 PM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Jul 1, 2020 at 12:34 PM Jóhann B. Guðmundsson johannbg@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!
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
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.
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
On 2.7.2020 10:16, nickysn@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-har...
On Thu, Jul 02, 2020 at 01:16:43PM +0300, nickysn@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
On 7/2/20 3:16 AM, nickysn@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.
On Thu, 2020-07-02 at 08:24 -0700, Gordon Messmer wrote:
On 7/2/20 3:16 AM, nickysn@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
On Thursday, July 2, 2020 8:24:49 AM MST Gordon Messmer wrote:
On 7/2/20 3:16 AM, nickysn@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.
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
On Thu, Jul 2, 2020 at 10:54 PM John M. Harris Jr johnmh@splentity.com wrote:
On Thursday, July 2, 2020 8:24:49 AM MST Gordon Messmer wrote:
On 7/2/20 3:16 AM, nickysn@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/...
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@splentity.com wrote:
On Thursday, July 2, 2020 8:24:49 AM MST Gordon Messmer wrote:
On 7/2/20 3:16 AM, nickysn@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.
On Fri, Jul 3, 2020 at 12:22 AM John M. Harris Jr johnmh@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.
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@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.
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
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. :)
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
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
Hi
On Fri, Jul 3, 2020 at 4:32 PM John M. Harris Jr wrote:
These "qualifiers" are important.
- 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"
- 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
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.
- 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.
- 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.
On Fri, Jul 3, 2020 at 12:49 AM John M. Harris Jr johnmh@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@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.
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@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.
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@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.
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.
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?
On Thu, Jul 2, 2020 at 6:24 PM Alex Thomas karlthane@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.
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@gmail.com wrote:
On Thu, Jul 2, 2020 at 6:24 PM Alex Thomas karlthane@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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Do, 02.07.20 17:24, Alex Thomas (karlthane@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
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)
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
On Wed, Jul 1, 2020 at 10:31 pm, Ralf Corsepius rc040203@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.
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.
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
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
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.
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.
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.
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
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.
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
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.
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.
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
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.
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
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
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.
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
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.
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
- 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
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
- 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.
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,
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
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,
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
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.
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
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.
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-informatio...
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
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.
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
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
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.
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.
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.
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.
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
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?
On Mon, Jul 6, 2020 at 4:26 PM John M. Harris Jr johnmh@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.
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.
On Mo, 06.07.20 21:58, Peter Robinson (pbrobinson@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
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@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.
On Mon, Jul 6, 2020 at 5:05 PM John M. Harris Jr johnmh@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@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.
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
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.
On Mo, 06.07.20 16:34, Neal Gompa (ngompa13@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
Once upon a time, Lennart Poettering mzerqung@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).
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
On Tue, Jul 7, 2020 at 11:17 AM Gerd Hoffmann kraxel@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.
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.
On Wed, 8 Jul 2020 at 16:48, John M. Harris Jr johnmh@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
Once upon a time, Richard Hughes hughsient@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.
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@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.
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@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
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@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.
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@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
On Wed, 8 Jul 2020 at 22:19, John M. Harris Jr johnmh@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.
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@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.
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@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
On Thu, 09 Jul 2020 18:07:39 +0300 nickysn@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?
On Thu, 2020-07-09 at 11:17 -0700, stan via devel wrote:
On Thu, 09 Jul 2020 18:07:39 +0300 nickysn@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
On Thu, 2020-07-09 at 23:10 +0300, nickysn@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@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.
On Thu, 09 Jul 2020 23:10:46 +0300 nickysn@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.
Once upon a time, nickysn@gmail.com nickysn@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.
On Thu, Jul 9, 2020 at 5:20 PM Chris Adams linux@cmadams.net wrote:
Once upon a time, nickysn@gmail.com nickysn@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.
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/whcp-...
- Solomon
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.
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.
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.
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.
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
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.
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?)
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.
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,
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.
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,
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,
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.
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
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.
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.
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.
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...
On Tue, Jul 7, 2020 at 6:17 AM Gerd Hoffmann kraxel@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.
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.
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.
On Mon, 19 Oct 2020 at 02:15, Subsentient thinkingrodent@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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Mon, Oct 19, 2020 at 7:48 PM Stephen John Smoogen smooge@gmail.com wrote:
On Mon, 19 Oct 2020 at 02:15, Subsentient thinkingrodent@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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On Mon, Oct 19, 2020 at 8:16 pm, Arnoldas Skinderis arnoldas.linux@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.
On Mon, Oct 19, 2020 at 8:27 PM Michael Catanzaro mcatanzaro@gnome.org wrote:
On Mon, Oct 19, 2020 at 8:16 pm, Arnoldas Skinderis arnoldas.linux@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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
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
On Mon, Oct 19, 2020 at 5:46 PM Damian Ivanov damianatorrpm@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).
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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@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
On 19.10.2020 17:25, Michael Catanzaro wrote:
On Mon, Oct 19, 2020 at 8:16 pm, Arnoldas Skinderis arnoldas.linux@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
b
On Tue, Oct 20, 2020 at 8:49 PM Jóhann B. Guðmundsson johannbg@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@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.
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…
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
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 ...
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,
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
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
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
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
well,
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
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.
On Thu, 2021-05-27 at 09:35 +0000, eedio wrote:
well,
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
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.
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
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.
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
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.
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.
- Backup all data.
- Convert MBR to GPT.
- Create an ESP partition, add it to the /etc/fstab file and mount.
- sudo dnf swap grub2 grub2-efi
- sudo dnf install shim (only if needed).
- 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
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.
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.
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...
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/...
it came up on ask.fedora and is linked into here.
[…] 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.
On Tue, Jul 6, 2021 at 3:37 PM Christian Stadelmann genodeftest@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
On Tue, Jul 6, 2021 at 7:05 PM Chris Murphy lists@colorremedies.com wrote:
On Tue, Jul 6, 2021 at 3:37 PM Christian Stadelmann genodeftest@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/
On 06/07/2021 23:27, Christian Stadelmann wrote:
In other words: I think it is too early to drop non-(U)EFI BIOS support.
Btw, the upcoming Windows 11 will require full UEFI support, enabled UEFI Secure Boot and TPM 2.0.
On Wed, Jul 7, 2021 at 8:23 AM Vitaly Zaitsev via devel devel@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;