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
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
