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.