subject:"F37 Change\: Deprecate Legacy BIOS \(System\-Wide Change proposal\)"

On Mon, Apr 11, 2022 at 3:36 PM Brian C. Lane  wrote:
>
> On Mon, Apr 11, 2022 at 02:21:04PM -0500, Chris Adams wrote:
> > Once upon a time, Peter Boy  said:
> > > I want to reiterate, it's not just about cloud platforms! if we remove 
> > > BIOS boot (too early), we also kick Fedora servers, installed on 
> > > hardware, out of these data centers.  And the reason is not that this 
> > > server hardware does not support UEFI, but the management infrastructure 
> > > of the data centers.
> >
> > Speaking of servers... one thing I noticed is that a pure-Fedora system
> > only uses about 8M of /boot/efi.  Even my dual-boot laptop with Win10 is
> > only using 35M.  Is there a reason 256M was chosen for the default UEFI
> > system partition size (from the standard somewhere)?  I guess that's
> > what Windows does too (since Win10 was on this laptop first).
>
> It is likely because UEFI specifies FAT32 on harddrives, and the minimum
> size for FAT32 is 256MB.

That's just for 4KiB logical sectors though. Most everyone still has
512 byte logical sector size for internal drives. My nvme drive is 512
byte sectors, came with FAT 32 and 100 MiB EFI system (and reformatted
with Microsoft's own installer the same).


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-11 Thread Brian C. Lane

On Mon, Apr 11, 2022 at 02:21:04PM -0500, Chris Adams wrote:
> Once upon a time, Peter Boy  said:
> > I want to reiterate, it's not just about cloud platforms! if we remove BIOS 
> > boot (too early), we also kick Fedora servers, installed on hardware, out 
> > of these data centers.  And the reason is not that this server hardware 
> > does not support UEFI, but the management infrastructure of the data 
> > centers.
> 
> Speaking of servers... one thing I noticed is that a pure-Fedora system
> only uses about 8M of /boot/efi.  Even my dual-boot laptop with Win10 is
> only using 35M.  Is there a reason 256M was chosen for the default UEFI
> system partition size (from the standard somewhere)?  I guess that's
> what Windows does too (since Win10 was on this laptop first).

It is likely because UEFI specifies FAT32 on harddrives, and the minimum
size for FAT32 is 256MB.

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Mon, Apr 11, 2022 at 1:21 PM Chris Adams  wrote:
>
> Once upon a time, Peter Boy  said:
> > I want to reiterate, it's not just about cloud platforms! if we remove BIOS 
> > boot (too early), we also kick Fedora servers, installed on hardware, out 
> > of these data centers.  And the reason is not that this server hardware 
> > does not support UEFI, but the management infrastructure of the data 
> > centers.
>
> Speaking of servers... one thing I noticed is that a pure-Fedora system
> only uses about 8M of /boot/efi.  Even my dual-boot laptop with Win10 is
> only using 35M.  Is there a reason 256M was chosen for the default UEFI
> system partition size (from the standard somewhere)?  I guess that's
> what Windows does too (since Win10 was on this laptop first).

Any Microsoft produced ISO image (downloadable from microsoft.com,
versus an OEM created image) creates 100 MiB EFI system partitions.
OEM's are kinda all over the map.

Fedora makes them 600 MiB these days.

UEFI Spec 2.8, 13.3.1.1 says "The EFI firmware must support the FAT32,
FAT16, and FAT12 variants of the EFI file system. What variant of EFI
FAT to use is defined by the size of the media. The rules defining the
relationship between media size and FAT variants is defined in the
specification for the EFI file system."

I've never been able to find a separate spec though.

The UEFI spec itself defines the EFI file system earlier in this 13.3
section as "The file system supported by the Extensible Firmware
Interface is based on the FAT file system." i.e. it is intended to be
based on a frozen in time version of FAT. Further, "EFI encompasses
the use of FAT32 for a system partition, and FAT12 or FAT16 for
removable media."

> I did notice that anaconda forces it to be at least 50M - again, is
> there a reason?

Anaconda folks prefer to use mkfs defaults. And dosfstools doesn't
have an "EFI file system" specific flag to follow the UEFI rules,
including feature freezing it in time. It just so happens FAT isn't
changing much or at least not in a way that makes EFI firmware
confused. But one day we might need an actual mkfs.efi utility to
correctly make them.

Per the spec the internal drive should be a FAT 32 file system, and
either FAT 12 or 32 file system for removable drives. In practice,
mkdosfs's size based logic won't make a FAT 32 volume unless the
partition size is ~550 MiB (I'm not certain of the cutoff). When
Anaconda was making ~250 MiB EFI system partitions, they were FAT 16.
Now they are FAT 32 because the partition size is above mkdosfs's
cutoff for FAT 16. I don't know if anyone ever ran into weird bugs
related to the file system being 16-bit based, rather than 32-bit, but
it would be hard to find out because - why would you even think to try
a different FAT variant and see if what you think might be a bug still
reproduces?

I tried formatting a 2011 Apple Macbook as FAT 16 and FAT 12. FAT 16
was OK (although I didn't do any firmware updates which is the only
reason the EFI system partition is used on Macs of this era). But FAT
12 was a bad experience - my vague recollection is I had to remove the
drive from the laptop and reformat it FAT 32 because I couldn't get it
to boot anything, not even from a CD or into the recovery mode. There
can be pretty nasty bugs lurking around the corners of such a vast
spec as UEFI, with the only requirement that involves any testing is
Microsoft's hardware compatibility/certification program.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-11 Thread Peter Boy



> Am 11.04.2022 um 21:21 schrieb Chris Adams :
> 
> Once upon a time, Peter Boy  said:
>> I want to reiterate, it's not just about cloud platforms! if we remove BIOS 
>> boot (too early), we also kick Fedora servers, installed on hardware, out of 
>> these data centers.  And the reason is not that this server hardware does 
>> not support UEFI, but the management infrastructure of the data centers.
> 
> Speaking of servers... one thing I noticed is that a pure-Fedora system
> only uses about 8M of /boot/efi.  Even my dual-boot laptop with Win10 is
> only using 35M.  Is there a reason 256M was chosen for the default UEFI
> system partition size (from the standard somewhere)?  I guess that's
> what Windows does too (since Win10 was on this laptop first).
> 
> I did notice that anaconda forces it to be at least 50M - again, is
> there a reason?

I really don’t know. Never thought about it before, and it hasn't even occurred 
to me, unfortunately. Knowing our group members, it's kind of a general best 
practice, and the idea of not making it too small in any way.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-11 Thread Zbigniew Jędrzejewski-Szmek

On Mon, Apr 11, 2022 at 02:21:04PM -0500, Chris Adams wrote:
> Once upon a time, Peter Boy  said:
> > I want to reiterate, it's not just about cloud platforms! if we remove BIOS 
> > boot (too early), we also kick Fedora servers, installed on hardware, out 
> > of these data centers.  And the reason is not that this server hardware 
> > does not support UEFI, but the management infrastructure of the data 
> > centers.
> 
> Speaking of servers... one thing I noticed is that a pure-Fedora system
> only uses about 8M of /boot/efi.  Even my dual-boot laptop with Win10 is
> only using 35M.  Is there a reason 256M was chosen for the default UEFI
> system partition size (from the standard somewhere)?  I guess that's
> what Windows does too (since Win10 was on this laptop first).

Windows wants >= 100 MB, or >= 256 MB on 4k-sector drives.
(https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions?view=windows-11)
Whoever creates the partition should make it "large enough",
i.e. it's reasonable to make it large enough to satisfy also windows,
even if we only use a few MBs.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-11 Thread Chris Adams

Once upon a time, Peter Boy  said:
> I want to reiterate, it's not just about cloud platforms! if we remove BIOS 
> boot (too early), we also kick Fedora servers, installed on hardware, out of 
> these data centers.  And the reason is not that this server hardware does not 
> support UEFI, but the management infrastructure of the data centers.

Speaking of servers... one thing I noticed is that a pure-Fedora system
only uses about 8M of /boot/efi.  Even my dual-boot laptop with Win10 is
only using 35M.  Is there a reason 256M was chosen for the default UEFI
system partition size (from the standard somewhere)?  I guess that's
what Windows does too (since Win10 was on this laptop first).

I did notice that anaconda forces it to be at least 50M - again, is
there a reason?
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-11 Thread Peter Boy

> Am 10.04.2022 um 04:50 schrieb Gary Buhrmaster :
> 
> On Wed, Apr 6, 2022 at 6:01 PM Neal Gompa  wrote:
> 
>> Moving past the Big Three(tm), the actual
>> cloud providers that matter from a Fedora context are the smaller
>> outfits that principally serve Linux users. These are companies like
>> DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
>> graciously do offer Fedora Linux in their platforms. All of their
>> virtualization platforms are BIOS only right now, and getting them to
>> switch requires them to uplift their platforms to support UEFI in the
>> first place.

I want to reiterate, it's not just about cloud platforms! if we remove BIOS 
boot (too early), we also kick Fedora servers, installed on hardware, out of 
these data centers.  And the reason is not that this server hardware does not 
support UEFI, but the management infrastructure of the data centers.

And kicking ourselves out, really doesn't strike me as a brilliant idea. 

> They may only support Linux users today, but if
> they want to grow (and while it is possible to
> survive as a niche service, many see growth
> as the way to increased revenue/profits (go
> big or go home)), they are going to get pushed
> (perhaps kicking and screaming) to support
> UEFI as at least an alternative …

It’s not so much about kicking and streaming, but about time, man power and 
financial resources.

> Many of these comments seem to be about
> the date, not the end state (UEFI)(),
> just like 32-bit x86 and armv7.  No one wants
> their personal ox gored, but there will come
> a time when it will be time to let old systems
> go.

Yes indeed. It’s about time. 

And we need a solution we can keep operable longer than 3 years. It's more of a 
10-year thing.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Mon, Apr 11, 2022 at 4:36 AM Thomas Schmitt  wrote:

> > A legacy/fallback image (or two) would provide some breathing room to
> > remove more legacy layers. Including possibly even ISO 9660.
>
> Aww. 14 years of xorriso development would be obsoleted. {:|
>
> Giving up ISO 9660 would mean to give up El Torito, which means to give
> up legacy BIOS booting from CD/DVD/BD.

It's a fair point that this proposal is not considering ISO 9660 a
legacy or deprecated format. That's my editorialization.  But all good
things come to an end? Long live ISO 9660?  :D  Consider millions of
user's lives were made a ton easier because we have had these
remarkably clever universal boot images for so long that can boot
almost anything.

 The legacy/fallback image(s) would definitely include ISO 9660
support, using xorriso essentially as we are now if not exactly as it
is now, and support it as long as it can be supported by the future
Legacy BIOS Booting SIG. It'd be up to the SIG to decide whether ISO
9660 is eventually dropped, if ever.

But as long as the SIG and its work products are being produced
reliably, and at least one image is release blocking - that gives
quite a lot of room to drop ISO 9660 on other images *if* there's a
clear advantage of doing so. That's all I meant to indicate.

> > The one thing I think we'd still need to
> > tweak sooner than later is swapping isolinux with GRUB.
>
> I am optimistic that this will be possible with few new user complaints.

OK super.


> Summary as i understand this part of our discussion:
>
> Fedora just has to decide whether it wants to stay with the layout
> described in
>   https://mjg59.dreamwidth.org/11285.html
> or whether it wants to migrate to a specs compliant GPT as i propose in
>   
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EY4Q5EDHLFW6TBJQTJMJUS6LM6U5ZBFW/
>   Date: Sun, 10 Apr 2022 00:29:54 +0200
>   Message-Id: <28174385295326549...@scdbackup.webframe.org>
>
> In the latter case the xorrisofs options to change are given in the above
> list post. It would drop support for an obscure class of x86 Macs which
> need HFS+ for booting, and it would drop support for a class of buggy
> legacy BIOSes which don't boot if the boot/active isn't set in any MBR
> partition table slot. (Old HP laptops have been caught with such BIOS.)
>
> In the former case my change proposal is in
>   
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4DSTL34BTZEINKMA3VSBDTJHYSD7VO3O
>   Date: Fri, 08 Apr 2022 20:29:07 +0200
>   Message-Id: <25501385177039509...@scdbackup.webframe.org>
> Please read the first part up to "More unsolicited info:" to see all
> proposed options.
>
> I am ready to discuss xorriso-specific problems at bug-xorr...@gnu.org
> or in private, if not here. Cc me when starting a discussion here.

OK great thanks for all the input!


--
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-11 Thread Robbie Harwood

Neal Gompa  writes:

> Alright, I'll bite. I am within my rights to propose any Change I want
> for Fedora Cloud, which I help steward with David Duncan.

As, presumably, is anyone else?

> As an aside, I examined the state of all release blocking Fedora
> deliverables, and something I noticed is that only the Workstation WG
> has Red Hatters actively engaged in it. That means that this Change
> comes with absolutely no understanding of the state of the world in
> Fedora across the various WGs and SIGs that deliver release-blocking
> artifacts. That in itself isn't necessarily a problem, but the fact
> that none of you are listening to us (David Duncan and myself for
> Cloud and KDE, Chris Murphy for Cloud and Workstation, and Peter Boy
> for Server) when we tell you this is too early is extremely tone-deaf.
>
> None of us want to keep supporting BIOS forever, but we all have
> *real-world experience* saying that we can't do this yet. We're trying
> to find a way to meet halfway to simplify legacy BIOS support, but
> you're not listening to us. We've also been trying to tell you that
> there are *real problems* with Fedora's UEFI support that need fixing
> before we can cut off BIOS support, but you're not listening to us.
>
> This thread has, at the time of my writing this post, has 269 posts
> across 62 individuals. It is the most active thread we've had since
> the switch to nano by default. However, unlike that change, almost
> every single respondent has brought up feedback in this discussion
> saying that we're not ready and providing examples of why we're not
> ready. However, you're *not listening*.

Okay, this is really important: just because I don't agree with you
doesn't mean I'm not hearing what you say.  You appear to be conflating
the two things.

I hear your position that this is too soon.  But I need you to hear what
I'm saying too: community assistance is required to keep up the status
quo, if that's how we want to go.  If you think the best way to go is to
vote this down, and have firmly made up your mind to vote it down, then
vote it down!  But do so with that knowledge.

> I understand you want to drop BIOS support before Fedora Linux 40 is
> branched into RHEL 10.

No one has said anything at all about RHEL.  As a member of the team
responsible for RHEL's boot stack, I can say that most of our focus is
at the moment on <=9, not >9.

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-11 Thread David Cantrell

On Wed, Apr 06, 2022 at 01:57:00PM -0400, Neal Gompa wrote:
> On Wed, Apr 6, 2022 at 11:50 AM Jared Dominguez  wrote:
> >
> >
> >
> > On Wed, Apr 6, 2022 at 8:20 AM Neal Gompa  wrote:
> >>
> >> On Wed, Apr 6, 2022 at 8:04 AM Vít Ondruch  wrote:
> >> >
> >> >
> >> > Dne 05. 04. 22 v 17:08 Neal Gompa napsal(a):
> >> > > On Tue, Apr 5, 2022 at 10:54 AM Ben Cotton  wrote:
> >> > >> https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
> >> > >>
> >> > >> == Summary ==
> >> > >> Make UEFI a hardware requirement for new Fedora installations on
> >> > >> platforms that support it (x86_64).  Legacy BIOS support is not
> >> > >> removed, but new non-UEFI installation is not supported on those
> >> > >> platforms.  This is a first step toward eventually removing legacy
> >> > >> BIOS support entirely.
> >> > >>
> >> > >> == Owner ==
> >> > >> * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
> >> > >> Konečný]], [[User:bcl| Brian C. Lane]]
> >> > >> * Email: rharw...@redhat.com
> >> > >>
> >> > >>
> >> > >> == Detailed Description ==
> >> > >> UEFI is defined by a versioned standard that can be tested and
> >> > >> certified against.  By contrast, every legacy BIOS is unique. Legacy
> >> > >> BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
> >> > >> and on its way out.  As it ages, maintainability has decreased, and
> >> > >> the status quo of maintaining both stacks in perpetuity is not viable
> >> > >> for those currently doing that work.
> >> > >>
> >> > >> It is inevitable that legacy BIOS will be removed in a future release.
> >> > >> To ease this transition as best we can, there will be a period (of at
> >> > >> least one Fedora release) where it will be possible to boot using the
> >> > >> legacy BIOS codepaths, but new installations will not be possible.
> >> > >> While it would be easier for us to cut support off today, our hope is
> >> > >> that this compromise position will make for a smoother transition.
> >> > >> Additional support with issues during the transition would be
> >> > >> appreciated.
> >> > >>
> >> > >> While this will eventually reduce workload for boot/installation
> >> > >> components (grub2 reduces surface area, syslinux goes away entirely,
> >> > >> anaconda reduces surface area), the reduction in support burden
> >> > >> extends much further into the stack - for instance, VESA support can
> >> > >> be removed from the distro.
> >> > >>
> >> > >> Fedora already requires a 2GHz dual core CPU at minimum (and therefore
> >> > >> mandates that machines must have been made after 2006).  Like the
> >> > >> already accepted Fedora 37 change to retire ARMv7 support, the
> >> > >> hardware targeted tends to be rather underpowered by today’s
> >> > >> standards, and the world has moved on from it.  Intel stopped shipping
> >> > >> the last vestiges of BIOS support in 2020 (as have other vendors, and
> >> > >> Apple and Microsoft), so this is clearly the way things are heading -
> >> > >> and therefore aligns with Fedora’s “First” objective.
> >> > >>
> >> > >> == Feedback ==
> >> > >> Dropping legacy BIOS was previously discussed (but not proposed) in 
> >> > >> 2020:
> >> > >> https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/thread/QBANCA2UAJ5ZSMDVVARLIYAJE66TYTCD/
> >> > >>
> >> > >> Important, relevant points from that thread (yes, I reread the entire
> >> > >> thread) that have informed this change:
> >> > >>
> >> > >> * Some machines are BIOS-only.  This change does not prevent their use
> >> > >> yet, but they are effectively deprecated.  grub2 (our default
> >> > >> bootloader) is already capable of both BIOS and UEFI booting.
> >> > >> * Drawing a clear year cutoff, let alone a detailed list of hardware
> >> > >> this change affects, is basically impossible.  This is unfortunate but
> >> > >> unlikely to ever change.
> >> > >> * There is no migration story from Legacy BIOS to UEFI -
> >> > >> repartitioning effectively mandates a reinstall.  As a result, we
> >> > >> don’t drop support for existing Legacy BIOS systems yet, just new
> >> > >> installations.
> >> > >> * There is no way to deprecate hardware without causing some amount 
> >> > >> of friction.
> >> > >> * While at the time AWS did not support UEFI booting, that is no
> >> > >> longer the case and they support UEFI today.
> >> > >>
> >> > >> == Benefit to Fedora ==
> >> > >> UEFI is required for many desirable features, including applying
> >> > >> firmware updates (fwupd) and supporting SecureBoot.  As a standalone
> >> > >> change, it reduces support burden on everything involved in installing
> >> > >> Fedora, since there becomes only one way to do it per platform.
> >> > >> Finally, it simplifies our install/live media, since it too only has
> >> > >> to boot one way per arch.  Freedom Friends Features First - this is
> >> > >> that last one.
> >> > >>
> >> > >> == Scope ==
> >> > >> * Proposal owners:
> >> > >> ** bootloaders: No change (existing

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Mon, Apr 11, 2022 at 3:02 AM Lennart Poettering  wrote:
>
> On Mo, 11.04.22 02:34, Chris Murphy (li...@colorremedies.com) wrote:
>
> > > > OK, I'll bite.
> > > >
> > > > What are you missing in sd-boot, specifically?
> > > >
> > > > Also, why would a boot menu need a particularly fancy user experience?
> > > > It's a boot manager, not a web browser.
> > >
> > > "barebones crappy one" is pretty strong. I'm too am interested in
> > > hearing what is so wrong with the sd-boot experience.
> >
> > The problem with systemd-boot is it still has an interface. I prefer
> > no interface for bootloaders.
>
> Too much for some, too little for others ;-)
>
> The UI it has is by default turned off and you only get it if you hold
> shift down or so at boot.
>
> I mean, we do need some logic how you can pick an older kernel/edit
> kernel cmdline for debugging/recovery/testing reasons. And that's
> exactly what we offer, but not much more.

My comment was tongue in cheek, but yeah the "general case" in Fedora
is either no UI or boot an older kernel. Hence hidden GRUB menu by
default unless dual boot with Windows is detected (but due to
Bitlocker and TPM measured boot, the GRUB menu's Windows entry
increasingly won't work; where sd-boot has worked around this
correctly with the UEFI bootnext variable, upstream GRUB hasn't
committed to even recognizing the problem let alone a solution).


> > I'm a bit frustrated that systemd-boot isn't signed, and apparently (I
> > guess) shim hard codes GRUB as the next bootloader?
>
> That's mostly a political issue.

OK but it's true? I've got the story line correct? I'll start a
separate thread because if it's true...



-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-11 Thread Robbie Harwood

Neal Gompa  writes:

> Windows is a niche in the server space, rather than the default

That may be true for many workloads, but I doubt it's true in all cases
- Active Directory has a huge footprint, for instance, and Linux is not
"the default" for identity services.

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-11 Thread Thomas Schmitt

Hi,

Chris Murphy wrote:
> At least with the BIOS firmware without a bug, the GRUB LBA 0 code
> jumps direct to core.img, no instruction on how to read the GPT and
> find the core.img from BIOS boot partition.

That's probably because the GRUB MBR code for hard disk gets the LBA
of the next stage patched in at install time.

xorrisofs does the equivalent to the boot_hybrid.img MBR from GRUB:

   --grub2-mbr disk_path
  Install disk_path in the System Area  and  treat  it  as  modern
  GRUB2 MBR.  The content start address of the first boot image is
  converted to a count of 512 byte blocks, and an offset of  4  is
  added.   The result is written as 64 bit little-endian number to
  byte address 0x1b0.

"Install in the System Area" means "Copy it to the start of the ISO image".
"first boot image" means the one that is pointed to by first entry in the
El Torito catalog, which is supposed to be the GRUB boot image for
El Torito. GRUB docs say that this image gets concatenated from "cdrom.img"
and a suitably built "core.img".

> Still another idea might be to create a "legacy" image variant of
> Everything ISO that does things exactly as we do them today.

This would be handy at least during the first months of a new ISO image
layout being used. Any user complaint could be checked whether the problem
was introduced by the ISO image change.

> A legacy/fallback image (or two) would provide some breathing room to
> remove more legacy layers. Including possibly even ISO 9660.

Aww. 14 years of xorriso development would be obsoleted. {:|

Giving up ISO 9660 would mean to give up El Torito, which means to give
up legacy BIOS booting from CD/DVD/BD.
With UEFI i am not so sure about the consequences. OVMF is known to boot
via partition table from qemu -cdrom devices and via El Torito from -hda.
Whether other EFIs do the same would have to be broadly tested.

UEFI 2.8 Errata A, February 2020 still has the prescription for EFI to
follow the El Torito boot catalog when it encounters an optical drive
with medium:

  10.3.5.2 CD-ROM Media Device Path
  The CD-ROM Media Device Path is used to define a system partition that
  exists on a CD-ROM. The CD-ROM is assumed to contain an ISO-9660 file
  system and follow the CD-ROM “El Torito” format. [...]
  In EFI the bootable entity is an EFI System Partition that is pointed to
  by the Boot Entry.

  10.4.5 Media Device Path Rules
  The Media Device Path is used to define the location of information on
  a medium. Hard Drives are subdivided into partitions by the MBR and a
  Media Device Path is used to define which partition is being used.
  A CD-ROM has boot partitions that are defined by the “El Torito”
  specification, and the Media Device Path is used to point to these
  partitions.

(Somebody at UEFI should look at the statement "subdivided into
 partitions by the MBR" whether this needs mentioning of GPT.)

EFI was not invented when El Torito was specified. Thus UEFI extends
the original El Torito specs by

  13.3.2.1 ISO-9660 and El Torito
  [...] To boot from a CD-ROM or DVD-ROM in the boot services environment,
  an EFI System partition is stored in a “no emulation” mode as defined
  by the “El Torito” specification. A Platform ID of 0xEF indicates an
  EFI System Partition. EFI differs from “El Torito” “no emulation” mode
  in that it does not load the “no emulation” image into memory and jump
  to it. EFI interprets the “no emulation” image as an EFI system
  partition. [... more technicalities follow ...]

> The one thing I think we'd still need to
> tweak sooner than later is swapping isolinux with GRUB.

I am optimistic that this will be possible with few new user complaints.

Summary as i understand this part of our discussion:

Fedora just has to decide whether it wants to stay with the layout
described in
  https://mjg59.dreamwidth.org/11285.html
or whether it wants to migrate to a specs compliant GPT as i propose in

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EY4Q5EDHLFW6TBJQTJMJUS6LM6U5ZBFW/
  Date: Sun, 10 Apr 2022 00:29:54 +0200
  Message-Id: <28174385295326549...@scdbackup.webframe.org>

In the latter case the xorrisofs options to change are given in the above
list post. It would drop support for an obscure class of x86 Macs which
need HFS+ for booting, and it would drop support for a class of buggy
legacy BIOSes which don't boot if the boot/active isn't set in any MBR
partition table slot. (Old HP laptops have been caught with such BIOS.)

In the former case my change proposal is in

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/4DSTL34BTZEINKMA3VSBDTJHYSD7VO3O
  Date: Fri, 08 Apr 2022 20:29:07 +0200
  Message-Id: <25501385177039509...@scdbackup.webframe.org>
Please read the first part up to "More unsolicited info:" to see all
proposed options.

I am ready to discuss xorriso-specific problems at bug-xorr...@gnu.org
or in private, if not here. Cc me

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-11 Thread Lennart Poettering

On Mo, 11.04.22 02:34, Chris Murphy (li...@colorremedies.com) wrote:

> > > OK, I'll bite.
> > >
> > > What are you missing in sd-boot, specifically?
> > >
> > > Also, why would a boot menu need a particularly fancy user experience?
> > > It's a boot manager, not a web browser.
> >
> > "barebones crappy one" is pretty strong. I'm too am interested in
> > hearing what is so wrong with the sd-boot experience.
>
> The problem with systemd-boot is it still has an interface. I prefer
> no interface for bootloaders.

Too much for some, too little for others ;-)

The UI it has is by default turned off and you only get it if you hold
shift down or so at boot.

I mean, we do need some logic how you can pick an older kernel/edit
kernel cmdline for debugging/recovery/testing reasons. And that's
exactly what we offer, but not much more.

(And of course, you can hold W down to boot windows. But booting into
windows on dual-boot systems should actually move into gdm or so, we
provide all the basic building blocks to make this nice, except the UI
for it is actually missing).

> I'm a bit frustrated that systemd-boot isn't signed, and apparently (I
> guess) shim hard codes GRUB as the next bootloader?

That's mostly a political issue.

(We actually have some support in sd-boot to be installed inder the
"grubx64.efi" name, to work around this political mess...)

Lennart

--
Lennart Poettering, Berlin
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-11 Thread Hans de Goede

Hi,

On 4/11/22 01:07, Gabriel Ramirez wrote:
> On 4/10/22 16:10, Neal Gompa wrote:
>> On Sun, Apr 10, 2022 at 4:37 PM Dominik 'Rathann' Mierzejewski
>>  wrote:
>>> On Friday, 08 April 2022 at 16:14, Zamir SUN wrote:
>>> [...]
 Probably it isn't a problem for some users, but I'm still having bad
 experience with UEFI on x86_64 now. Out of my 3 machines I only have 1
 system that works fine with UEFI. And my parents' laptop was purchased
 2 years ago and the UEFI firmware does not allow to boot anything
 other than Windows on UEFI mode (regardless of turning secure boot on
 or off) and I have to switch to BIOS mode to make Fedora work there.
 So in this situation, I think it's way too aggressive to accept the
 change - this will probably drive away some potential new users with
 decent laptop like my parents'.
>>> Have you tried renaming your Fedora boot entry to "Windows Boot
>>> Manager"? I have one Sony laptop that boots only the boot entry with
>>> that exact name.
>>>
>> I wonder if this would work with one of my old machines too. I've
>> never thought to rename the boot entry in the firmware before...
>>
>>
> 
> about "Windows Boot Manager" efi entry required to boot: 
> https://mjg59.dreamwidth.org/20187.html
> 
> the above happens too with the lenovo thinkcentre m91

Yes and some UEFI-s will only consider non USB disks to be bootable if they
have a FAT ESP with  EFI/Microsoft/Boot/bootmgfw.efi on there.

Some of them are hardcoded to boot that file (just put shim + grubia32.efi
/ grubx64.efi there), while others check for the file, but boot another
path (which may also be hardcoded) see:

https://hansdegoede.dreamwidth.org/24232.html

For a couple of devices which I encountered which do this. I did not
know about the "Windows Boot Manager" name being a thing too.

So yes so much for UEFI being a sensible standard...

Regards,

Hans

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Sun, Apr 10, 2022 at 1:31 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, Apr 07, 2022 at 10:43:02AM +0200, Lennart Poettering wrote:
> > On Mi, 06.04.22 07:33, Neal Gompa (ngomp...@gmail.com) wrote:
> > > Irrespective of this change, I would flat-out oppose moving to
> > > sd-boot. In any case, you can't use sd-boot for live media.
> > >
> > > If we were going to move to pure EFI boot manager, I'd rather use one
> > > that has a decent user experience and not a barebones crappy one.
> >
> > OK, I'll bite.
> >
> > What are you missing in sd-boot, specifically?
> >
> > Also, why would a boot menu need a particularly fancy user experience?
> > It's a boot manager, not a web browser.
>
> "barebones crappy one" is pretty strong. I'm too am interested in
> hearing what is so wrong with the sd-boot experience.

The problem with systemd-boot is it still has an interface. I prefer
no interface for bootloaders.

I'm a bit frustrated that systemd-boot isn't signed, and apparently (I
guess) shim hard codes GRUB as the next bootloader?

This portion of the thread maybe ought to be split out?

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Sat, Apr 9, 2022 at 1:51 AM Thomas Schmitt  wrote:
>
> Hi,
>
> > OK so there isn't (yet) an option to embed the GRUB core.img in a GPT
> > BIOS boot partition, I take it? The assumption is MBR? On hard drives,
> > core.img goes in the MBR gap. I'm not sure where it goes on xorriso
> > produced ISOs though, but presumably not the gap because there's a
> > valid GPT there too.
>
> One could probably use core.img for booting from USB stick. But it would
> not obsolete the x86 code in MBR and it currently is not necessary for
> grub-mkrescue ISOs because eltorito.img does a job equivalent to core.img.
> eltorito.img is stored in the ISO 9660 filesystem as normal data file.
> The MBR x86 code transfers execution to it and the El Torito catalog has
> it as boot image for x86 legacy BIOS.

At least with the BIOS firmware without a bug, the GRUB LBA 0 code
jumps direct to core.img, no instruction on how to read the GPT and
find the core.img from BIOS boot partition.


> > Yeah, I'm not aware off hand of any UEFI that have a problem with the
> > first 440 bytes of LBA 0 being non-zero. I am aware though, of this
> > tianocore bug [1] where if the active bit on that 0xEE partition is
> > set, the GPT is considered invalid.
>
> That's why grub-mkrescue lets xorriso produce a pure GPT with no
> boot/active flag at the 0xEE partition. But this lets old HP laptops
> refuse to boot from USB stick.
> A foul compromise is to add another MBR partition of type 0x00 with
> boot/active flag. EFI is known to ignore it, but HP legacy BIOS takes it
> as reason to run the MBR x86 code (which is not related to partitions).
>
>
> > (b) we don't really want to work around buggy
> > BIOS firmware anyway, we want them to fail here rather than later.
>
> That's a harsh decision but would match the purpose of this thread, indeed.
> If so, then producing a pure GPT instead of the current jackalope seems
> the way to go. grub-mkrescue will point the way or could even be the
> solution to go for.

Still another idea might be to create a "legacy" image variant of
Everything ISO that does things exactly as we do them today. That way
there is a fallback for one image that isn't release blocking, for as
long as it can be maintained. The one thing I think we'd still need to
tweak sooner than later is swapping isolinux with GRUB.

A legacy/fallback image (or two) would provide some breathing room to
remove more legacy layers. Including possibly even ISO 9660. If
Everything ISO is for that use case, desktop and server images can
focus on being USB centric, including supporting persistence out of
the box.


>
> I would propose to care for a mountable ISO 9660 partition, by moving
> the EFI boot image / EFI system partition out of the filesystem and
> rather appending it as extra partition. An example can be created by
> MKRESCUE_SED_MODE=gpt_appended with script frontend/grub-mkrescue-sed.sh
> out of libisoburn.)
> Further one would need xorrisofs option
>   -partition_offset 16
> so that a mountable GPT partition can be created which starts at 512-block
> address 64, i.e. after the GPT partition table data. This wastes some
> space because a second directory tree has to be generated additionally to
> the normal directory tree which will be used when booting or mounting
> the ISO from a DVD.
> The waste would not be much with Fedora Live ISOs. In 3-year-old
> Fedora-Workstation-Live-x86_64-31-1.9.iso the first data file is already
> at 2048-block address 43. That would be at most 23 * 2048 bytes for the
> directory records which form the file tree (43 - 16 blocks System Area -
> 4 blocks of Volume Descriptors). So the waste would be <= 46 KiB.
>
> At that occasion consider to drop the HFS+ Mac boot image and the Apple
> Partition map which marks it for some obscure non-EFI x86 Macs. I.e.
> consider to remove from the current xorrisofs command the options
>   -eltorito-alt-boot
>   -e images/macboot.img -no-emul-boot -isohybrid-gpt-hfsplus
> and try to find a Mac which misses this boot image and refuses to boot
> but boots with the original ISO.

I have a 2011 Mac. Virtually certain ages ago I booted an openSUSE ISO
from USB stick, no problem, and it had no special tricks liks Fedora
is using (HFS+ and mactel boot).



> > If we can opt out of making a hybrid/faux MBR, and create a PMBR
> > instead, that'd also mean there's one clear unambiguous partition map
> > for USB sticks, which could make it easier to implement persistence.
>
> A PMBR is an MBR at the start of a partition and gets activated only
> if the device MBR decides to do so. Sometimes there is MBR code on newly
> bought USB sticks which looks for a partition with boot/active flag and
> then chain-loads the PMBR from there.
> But in an EL Torito bootable ISO this makes few sense. The little
> hybrid MBR and the larger BIOS boot image can do everything that is
> needed.
>
> A neat partition map is indeed a valuable goal. To my knowledge it can
> only be achieved by dropping support

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-11 Thread Dominik 'Rathann' Mierzejewski

On Sunday, 10 April 2022 at 22:30, Dominik 'Rathann' Mierzejewski wrote:
> On Friday, 08 April 2022 at 13:41, Vitaly Zaitsev via devel wrote:
> > On 08/04/2022 09:54, Dominik 'Rathann' Mierzejewski wrote:
> > > I already did. Isn't that what I wrote?
> > 
> > Can you post their answer?
> 
> Yes:
> ```
> On VPS, we do not provide images with UEFI enabled.
> ```
> 
> They support UEFI on their Public Cloud instances, but the same
> configuration as my current VPS seems to be twice as expensive.
> 
> I've asked them to clarify if they have any plans to enable UEFI for
> their VPS instances.

And their answer is:
```
Currently we do not have any plans for enabling UEFI booting with VPS.
```

So, if this change went ahead as planned, it would cost me twice as much
as I'm paying OVH right now to (re-)install Fedora 37+ on their hosting,
because I'd have to switch to a different, more expensive service.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Sun, Apr 10, 2022 at 11:06 PM Gary Buhrmaster
 wrote:
>
> On Sun, Apr 10, 2022 at 1:27 PM Neal Gompa  wrote:
>
> > Windows 11 *does not matter* here.
>
> (Windows) Desktop as a Service (DaaS)[0] may
> change that faster than some expect (or faster
> than some hope).  There is a large push by
> some orgs to move services off premise
> into the cloud (for a number of stated reasons
> including zero trust and WfH scenarios).
>
> And while I have zero plans to give up my
> linux systems in favor of cloud desktops,
> and some of the push for DaaS may be
> more hype than real, I do agree that there
> are valid use cases, and that is going to
> push some to support UEFI in the future.
>

The economics of Windows in the cloud is not great unless you're on
Azure, where Microsoft can give itself preferential pricing. And most
people that use Fedora in the Cloud aren't using Azure (or AWS or GCP
for that matter).


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Gary Buhrmaster

On Sun, Apr 10, 2022 at 1:27 PM Neal Gompa  wrote:

> Windows 11 *does not matter* here.

(Windows) Desktop as a Service (DaaS)[0] may
change that faster than some expect (or faster
than some hope).  There is a large push by
some orgs to move services off premise
into the cloud (for a number of stated reasons
including zero trust and WfH scenarios).

And while I have zero plans to give up my
linux systems in favor of cloud desktops,
and some of the push for DaaS may be
more hype than real, I do agree that there
are valid use cases, and that is going to
push some to support UEFI in the future.

Gary

[0] And certain SaaS application solutions.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Sun, Apr 10, 2022 at 7:08 PM Gabriel Ramirez  wrote:
>
> On 4/10/22 16:10, Neal Gompa wrote:
> > On Sun, Apr 10, 2022 at 4:37 PM Dominik 'Rathann' Mierzejewski
> >  wrote:
> >> On Friday, 08 April 2022 at 16:14, Zamir SUN wrote:
> >> [...]
> >>> Probably it isn't a problem for some users, but I'm still having bad
> >>> experience with UEFI on x86_64 now. Out of my 3 machines I only have 1
> >>> system that works fine with UEFI. And my parents' laptop was purchased
> >>> 2 years ago and the UEFI firmware does not allow to boot anything
> >>> other than Windows on UEFI mode (regardless of turning secure boot on
> >>> or off) and I have to switch to BIOS mode to make Fedora work there.
> >>> So in this situation, I think it's way too aggressive to accept the
> >>> change - this will probably drive away some potential new users with
> >>> decent laptop like my parents'.
> >> Have you tried renaming your Fedora boot entry to "Windows Boot
> >> Manager"? I have one Sony laptop that boots only the boot entry with
> >> that exact name.
> >>
> > I wonder if this would work with one of my old machines too. I've
> > never thought to rename the boot entry in the firmware before...
> >
> >
>
> about "Windows Boot Manager" efi entry required to boot:
> https://mjg59.dreamwidth.org/20187.html
>
> the above happens too with the lenovo thinkcentre m91

From the blog post:
> For now, if you want to run Fedora[2] on these systems you're probably best 
> off changing the firmware to perform a legacy boot.

*sigh*


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Gabriel Ramirez


On 4/10/22 16:10, Neal Gompa wrote:

On Sun, Apr 10, 2022 at 4:37 PM Dominik 'Rathann' Mierzejewski
 wrote:

On Friday, 08 April 2022 at 16:14, Zamir SUN wrote:
[...]

Probably it isn't a problem for some users, but I'm still having bad
experience with UEFI on x86_64 now. Out of my 3 machines I only have 1
system that works fine with UEFI. And my parents' laptop was purchased
2 years ago and the UEFI firmware does not allow to boot anything
other than Windows on UEFI mode (regardless of turning secure boot on
or off) and I have to switch to BIOS mode to make Fedora work there.
So in this situation, I think it's way too aggressive to accept the
change - this will probably drive away some potential new users with
decent laptop like my parents'.

Have you tried renaming your Fedora boot entry to "Windows Boot
Manager"? I have one Sony laptop that boots only the boot entry with
that exact name.


I wonder if this would work with one of my old machines too. I've
never thought to rename the boot entry in the firmware before...




about "Windows Boot Manager" efi entry required to boot: 
https://mjg59.dreamwidth.org/20187.html


the above happens too with the lenovo thinkcentre m91
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Sun, Apr 10, 2022 at 4:37 PM Dominik 'Rathann' Mierzejewski
 wrote:
>
> On Friday, 08 April 2022 at 16:14, Zamir SUN wrote:
> [...]
> > Probably it isn't a problem for some users, but I'm still having bad
> > experience with UEFI on x86_64 now. Out of my 3 machines I only have 1
> > system that works fine with UEFI. And my parents' laptop was purchased
> > 2 years ago and the UEFI firmware does not allow to boot anything
> > other than Windows on UEFI mode (regardless of turning secure boot on
> > or off) and I have to switch to BIOS mode to make Fedora work there.
> > So in this situation, I think it's way too aggressive to accept the
> > change - this will probably drive away some potential new users with
> > decent laptop like my parents'.
>
> Have you tried renaming your Fedora boot entry to "Windows Boot
> Manager"? I have one Sony laptop that boots only the boot entry with
> that exact name.
>

I wonder if this would work with one of my old machines too. I've
never thought to rename the boot entry in the firmware before...


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Dominik 'Rathann' Mierzejewski

On Friday, 08 April 2022 at 16:14, Zamir SUN wrote:
[...]
> Probably it isn't a problem for some users, but I'm still having bad
> experience with UEFI on x86_64 now. Out of my 3 machines I only have 1
> system that works fine with UEFI. And my parents' laptop was purchased
> 2 years ago and the UEFI firmware does not allow to boot anything
> other than Windows on UEFI mode (regardless of turning secure boot on
> or off) and I have to switch to BIOS mode to make Fedora work there.
> So in this situation, I think it's way too aggressive to accept the
> change - this will probably drive away some potential new users with
> decent laptop like my parents'.

Have you tried renaming your Fedora boot entry to "Windows Boot
Manager"? I have one Sony laptop that boots only the boot entry with
that exact name.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Dominik 'Rathann' Mierzejewski

On Friday, 08 April 2022 at 19:14, Brian C. Lane wrote:
[...]
> So like I said yesterday, I'll look into switching to use grub2 for
> Fedora 37, assuming grub2 continues to support BIOS.

Thank you very much! From my side, I've found another BIOS-only machine
in my junkyard and I'm willing to put both up for testing any changes
and maybe even help write some code if time permits.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Dominik 'Rathann' Mierzejewski

On Friday, 08 April 2022 at 13:41, Vitaly Zaitsev via devel wrote:
> On 08/04/2022 09:54, Dominik 'Rathann' Mierzejewski wrote:
> > I already did. Isn't that what I wrote?
> 
> Can you post their answer?

Yes:
```
On VPS, we do not provide images with UEFI enabled.
```

They support UEFI on their Public Cloud instances, but the same
configuration as my current VPS seems to be twice as expensive.

I've asked them to clarify if they have any plans to enable UEFI for
their VPS instances.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Zbigniew Jędrzejewski-Szmek

On Thu, Apr 07, 2022 at 10:43:02AM +0200, Lennart Poettering wrote:
> On Mi, 06.04.22 07:33, Neal Gompa (ngomp...@gmail.com) wrote:
> > Irrespective of this change, I would flat-out oppose moving to
> > sd-boot. In any case, you can't use sd-boot for live media.
> >
> > If we were going to move to pure EFI boot manager, I'd rather use one
> > that has a decent user experience and not a barebones crappy one.
> 
> OK, I'll bite.
> 
> What are you missing in sd-boot, specifically?
> 
> Also, why would a boot menu need a particularly fancy user experience?
> It's a boot manager, not a web browser.

"barebones crappy one" is pretty strong. I'm too am interested in
hearing what is so wrong with the sd-boot experience.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Zbigniew Jędrzejewski-Szmek

On Sun, Apr 10, 2022 at 10:27:25AM -0400, Neal Gompa wrote:
> And we can take incremental steps to get there, even now:
> 
> 1. Switch Anaconda to default to GPT even on BIOS setups
> 2. Drop syslinux and use GRUB everywhere
> 3. Configure new installations to always do hybrid boot installations
> 4. Develop documentation and/or tooling to do MBR->GPT conversions and
> reconfigure for hybrid boot for existing systems
> 
> These are all reasonably achievable things we can do. And that gives
> us time to work our relationships with our stakeholders to prepare
> them for the day legacy BIOS support is gone from the entire Red Hat
> family of distributions. It also gives room for improving the UEFI
> experience so it's *at least* as good as the BIOS one, if not better.
> Right now, it's not. And it needs to be in order to maintain the
> momentum we have now where Fedora Linux adoption is growing by leaps
> and bounds over the last couple of years.

This is a very concrete actionable and achievable proposal. /me likes.

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Nikolay Nikolov



On 4/10/22 16:27, Neal Gompa wrote:

On Sat, Apr 9, 2022 at 10:51 PM Gary Buhrmaster
 wrote:

On Wed, Apr 6, 2022 at 6:01 PM Neal Gompa  wrote:


Moving past the Big Three(tm), the actual
cloud providers that matter from a Fedora context are the smaller
outfits that principally serve Linux users. These are companies like
DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
graciously do offer Fedora Linux in their platforms. All of their
virtualization platforms are BIOS only right now, and getting them to
switch requires them to uplift their platforms to support UEFI in the
first place.

They may only support Linux users today, but if
they want to grow (and while it is possible to
survive as a niche service, many see growth
as the way to increased revenue/profits (go
big or go home)), they are going to get pushed
(perhaps kicking and screaming) to support
UEFI as at least an alternative moving forward
as some of their customers are going to prefer
using a single provider, and Windows 11
requires UEFI(*)(**), and it would be a shame
if only the big players were eligible for hosting
such services(***).

Many of these comments seem to be about
the date, not the end state (UEFI)(),
just like 32-bit x86 and armv7.  No one wants
their personal ox gored, but there will come
a time when it will be time to let old systems
go.

"We" (and when I say "we", I understand that
is mostly not me), are going to have to
continue to document (and fix, where "we"
have the knowledge) the areas that need
improvement for UEFI booting and runtime.


Windows is a niche in the server space, rather than the default. And
Microsoft didn't even remove the server exception to continue using
BIOS until last year from the Windows platform qualification
documentation. It's *definitely* going to be a while, especially with
Windows Server 2019 being supported until the end of the decade.
Just tested installing Windows Server 2019 in a QEMU virtual machine on 
a 40 GB virtual hard disk and 2 GB RAM. It formatted the disk as MBR and 
installed just fine, no warnings, no deprecations, no nothing. 
Mainstream support for Windows Server 2019 ends in January 9, 2024, 
extended support lasts until January 9, 2029.

Windows 11 *does not matter* here. Windows Server is what matters
here, and there are no announced Windows Server versions following the
Windows 11 platform requirements.
I agree. IMO, Windows 11 is only good for home desktop use (and for that 
purpose, Windows 10 is just as good, there are only cosmetic differences 
in the UI), it is irrelevant for servers, because of the artificial 
restrictions that Microsoft puts on their desktop operating systems 
(limited number of connections, limited number of websites you can host 
in IIS, etc.) in order to boost their Windows Server sales. Ironically, 
due to this fact, Windows Server works better as a desktop, than Windows 
10 or 11 as a server. At work we use Windows Server for web development 
in Visual Studio, because it just works better, e.g. you can deploy 
multiple web sites on your machine, etc. :)





--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Fri, Apr 8, 2022 at 2:23 PM Robbie Harwood  wrote:
>
> Michel Alexandre Salim  writes:
>
> > - as I stated, there are offers to help with getting syslinux replaced
> >   with GRUB. what I've not stated originally is Chris Murphy brought up
> >   protective MBR and switching all new installs to inst.gpt, which let
> >   us future proof new installations for when we do kill off legacy BIOS.
> >
> > What people who want to help needs, though, is some sense that our
> > contributions are welcome.
>
> (If you're looking for me to comment on proposals to change live media
> generation and installs, I can't really do that - that's Brian's and
> Jiri's areas of expertise.)
>
> > - Neal pointed out he has been working on addressing this for a while,
> >   and have not put up a Change Proposal because he thought it was
> >   premature
>
> While Neal's contributions are as welcome as anyone else's, Neal is not
> a maintainer of (or regular contributor to) bootloader packages and it
> would be very strange for Neal to propose such a change without
> discussing it with us first.  That said, if there was suggestion of such
> a proposal, I have missed it (which is very possible given the size of
> the thread at this point).
>

Alright, I'll bite. I am within my rights to propose any Change I want
for Fedora Cloud, which I help steward with David Duncan.

For Fedora Cloud, we've been discussing what we want to support going
forward. I added hybrid boot support[1] in Fedora Linux 35
specifically so that we can start working on adding Fedora Cloud to
Azure, who prefers UEFI for its Hyper-V VMs[2], but also supports
legacy BIOS. We decided to not propose a Change to deprecate BIOS
support yet specifically because we needed to have conversations with
the various VPSes that people *actually use Fedora* on before we do
that[3]. I was completely thrown by this Change proposal because it
threatens to poison the conversations that Fedora Cloud wants to have
with its actual stakeholders for a less acrimonious transition.

As an aside, I examined the state of all release blocking Fedora
deliverables, and something I noticed is that only the Workstation WG
has Red Hatters actively engaged in it. That means that this Change
comes with absolutely no understanding of the state of the world in
Fedora across the various WGs and SIGs that deliver release-blocking
artifacts. That in itself isn't necessarily a problem, but the fact
that none of you are listening to us (David Duncan and myself for
Cloud and KDE, Chris Murphy for Cloud and Workstation, and Peter Boy
for Server) when we tell you this is too early is extremely tone-deaf.

None of us want to keep supporting BIOS forever, but we all have
*real-world experience* saying that we can't do this yet. We're trying
to find a way to meet halfway to simplify legacy BIOS support, but
you're not listening to us. We've also been trying to tell you that
there are *real problems* with Fedora's UEFI support that need fixing
before we can cut off BIOS support, but you're not listening to us.

This thread has, at the time of my writing this post, has 269 posts
across 62 individuals. It is the most active thread we've had since
the switch to nano by default. However, unlike that change, almost
every single respondent has brought up feedback in this discussion
saying that we're not ready and providing examples of why we're not
ready. However, you're *not listening*.

I understand you want to drop BIOS support before Fedora Linux 40 is
branched into RHEL 10. Obviously you could drop it in RHEL 10 even if
Fedora doesn't, but it'd be better to drop it in Fedora first and make
sure everything is flushed out. I would be fine with us doing that if
there was some expectation that the UEFI experience in Fedora Linux
was going to improve to resolve the issues people have *now* by the
time we get there.

And we can take incremental steps to get there, even now:

1. Switch Anaconda to default to GPT even on BIOS setups
2. Drop syslinux and use GRUB everywhere
3. Configure new installations to always do hybrid boot installations
4. Develop documentation and/or tooling to do MBR->GPT conversions and
reconfigure for hybrid boot for existing systems

These are all reasonably achievable things we can do. And that gives
us time to work our relationships with our stakeholders to prepare
them for the day legacy BIOS support is gone from the entire Red Hat
family of distributions. It also gives room for improving the UEFI
experience so it's *at least* as good as the BIOS one, if not better.
Right now, it's not. And it needs to be in order to maintain the
momentum we have now where Fedora Linux adoption is growing by leaps
and bounds over the last couple of years.

[1]: https://fedoraproject.org/wiki/Changes/FedoraCloudHybridBoot
[2]: https://pagure.io/cloud-sig/issue/309
[3]: https://pagure.io/cloud-sig/issue/345

--
真実はいつも一つ！/ Always, there's only one truth!
___
devel

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Sat, Apr 9, 2022 at 10:51 PM Gary Buhrmaster
 wrote:
>
> On Wed, Apr 6, 2022 at 6:01 PM Neal Gompa  wrote:
>
> > Moving past the Big Three(tm), the actual
> > cloud providers that matter from a Fedora context are the smaller
> > outfits that principally serve Linux users. These are companies like
> > DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
> > graciously do offer Fedora Linux in their platforms. All of their
> > virtualization platforms are BIOS only right now, and getting them to
> > switch requires them to uplift their platforms to support UEFI in the
> > first place.
>
> They may only support Linux users today, but if
> they want to grow (and while it is possible to
> survive as a niche service, many see growth
> as the way to increased revenue/profits (go
> big or go home)), they are going to get pushed
> (perhaps kicking and screaming) to support
> UEFI as at least an alternative moving forward
> as some of their customers are going to prefer
> using a single provider, and Windows 11
> requires UEFI(*)(**), and it would be a shame
> if only the big players were eligible for hosting
> such services(***).
>
> Many of these comments seem to be about
> the date, not the end state (UEFI)(),
> just like 32-bit x86 and armv7.  No one wants
> their personal ox gored, but there will come
> a time when it will be time to let old systems
> go.
>
> "We" (and when I say "we", I understand that
> is mostly not me), are going to have to
> continue to document (and fix, where "we"
> have the knowledge) the areas that need
> improvement for UEFI booting and runtime.
>

Windows is a niche in the server space, rather than the default. And
Microsoft didn't even remove the server exception to continue using
BIOS until last year from the Windows platform qualification
documentation. It's *definitely* going to be a while, especially with
Windows Server 2019 being supported until the end of the decade.

Windows 11 *does not matter* here. Windows Server is what matters
here, and there are no announced Windows Server versions following the
Windows 11 platform requirements.




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Thomas Schmitt

Hi,

Nikolay Nikolov wrote:
> I imagine it is like those polyglot programs, that are simultaneously valid
> in several totally different programming languages:

Yep. A boot-everywhere ISO for x86 is quite like that.
Every firmware variant can see in it what it expects.


> Actually, I have already invested in a Blu-ray burner, I just haven't
> purchased any BD-R or BD-RE install media, so I haven't even tested the
> Blu-ray burning :)

Then it's about time. :))
I propose to backup a few GiB of your favorite data by xorriso and update
that backup daily until the medium is full. See in
  https://www.gnu.org/software/xorriso/
the example
  "The following command performs incremental backup."

(I apologize to the list for this off-topic advertising of my program.)


Have a nice day :)

Thomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Nikolay Nikolov



On 4/10/22 05:50, Gary Buhrmaster wrote:

On Wed, Apr 6, 2022 at 6:01 PM Neal Gompa  wrote:


Moving past the Big Three(tm), the actual
cloud providers that matter from a Fedora context are the smaller
outfits that principally serve Linux users. These are companies like
DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
graciously do offer Fedora Linux in their platforms. All of their
virtualization platforms are BIOS only right now, and getting them to
switch requires them to uplift their platforms to support UEFI in the
first place.

They may only support Linux users today, but if
they want to grow (and while it is possible to
survive as a niche service, many see growth
as the way to increased revenue/profits (go
big or go home)), they are going to get pushed
(perhaps kicking and screaming) to support
UEFI as at least an alternative moving forward
as some of their customers are going to prefer
using a single provider, and Windows 11
requires UEFI(*)(**), and it would be a shame
if only the big players were eligible for hosting
such services(***).

Many of these comments seem to be about
the date, not the end state (UEFI)(),
just like 32-bit x86 and armv7.  No one wants
their personal ox gored, but there will come
a time when it will be time to let old systems
go.
Yes, but the whole point is that it's way too early. Windows 10 still 
supports not only legacy BIOS, but also i686 (which Fedora has dropped 
support for in Fedora 31; Fedora 30 was EOL'd in May 2020) and Windows 
10 will be supported until at least October 14, 2025. For comparison, 
Fedora 36 will be EOL'd in May 2023.


"We" (and when I say "we", I understand that
is mostly not me), are going to have to
continue to document (and fix, where "we"
have the knowledge) the areas that need
improvement for UEFI booting and runtime.

Gary



(*) Technically it is possible to jump through
enough hoops to get Windows 11 to run on
BIOS only systems, but it is not supported,
and may break at any time.  Most people
prefer something that the vendor supports.


BIOS-only users can stay on Windows 10. They have very little reason to 
upgrade to Windows 11. It's mostly cosmetic changes to the UI and 
there's no major software product that requires Windows 11, but doesn't 
run on Windows 10. Adoption of new Windows versions has always been 
painstakingly slow, even after the old version is EOL'd, people continue 
to use it (I know it's a bad idea, but people do it anyway - look at how 
much time it took for people to upgrade from Windows XP, after it was 
EOL'd). But Windows 10 is still supported, so it can be used, it's not 
more dangerous than Windows 11.


So the question is, why should cloud providers care about Windows 11? 
Long term, yes, they do care, but none of their Windows users are in a 
hurry to upgrade, they are fine staying on Windows 10 until 2025, 
there's nothing in Windows 11 that makes it worth upgrading (in my 
personal opinion), especially not for server/cloud use. I must check 
this (please correct me if I'm wrong), but I think Windows Server 2019 
still supports legacy BIOS and has extended support until January 2029.




(**) Yes, some may prefer living in a
Windows-less world, but the reality is that
(especially at business scale) there are
services and applications that require
Windows today, and will likely require
Windows for a number of tomorrows.
Like I said, Windows 10 supports i686 + Legacy BIOS, as well as x86_64 + 
Legacy BIOS until at least October 14, 2025.


(***) Yes, using multiple cloud providers
is often advantageous to avoid vendor
lock-in and provider failures, but scale
(at one provider) can result in savings
(both expense, and duplication of work
supporting the different providers' services).
There is statement by a VC regarding
startups which is (essentially) everyone
should start by using AWS, and then
have a plan to move off when their
scale is sufficient (of course, many
startups never survive sufficiently long
to move off, and others simply prefer
to spend their (precious) engineering
resources in other ways).

() Yes, some hope coreboot/linuxboot
can replace UEFI (and it can in some use
cases).  But unless/until MS embraces it,
UEFI is the answer (even if one is still
discussing the question that was asked).
I believe the PC-compatible coreboot payloads are the way to go - either 
coreboot+SeaBIOS or coreboot+TianoCore. I don't know what's the state of 
TianoCore and whether it works on real hardware. I have one working 
system with coreboot+SeaBIOS (it's a Chromebook) and I'd like to be able 
to use it.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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:

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Nikolay Nikolov

On 4/10/22 09:56, Thomas Schmitt wrote:

Hi,

Nikolay Nikolov wrote:

Maybe I should try adapting my code, so that it finds the GRUB BIOS boot
partition and loads it?

This would be a nice stunt for which we would have to find a use case.
As stated yesterday, the GRUB El Torito image contains a core.img which
serves the same purpose as a BIOS partition.
The use case I'm thinking about is not for the install image, but for
hard disk installations in legacy BIOS mode, that use the GPT partition
scheme, instead of the MBR partition scheme. In this case, with my MBR
bootloader code, you still need the extra GRUB BIOS boot partition, but
it can be moved anywhere on the disk, without breaking the bootloader.
In the case of the traditional GRUB MBR code, you would need to boot
from a rescue media and reinstall the bootloader, every time this
partition is moved (or partition tools should treat it as unmovable,
which reduces your flexibility). The disadvantage of my MBR boot code is
that it doesn't support really old systems without the INT 13h LBA
extensions. And you cannot detect in the distro installer whether the
system supports these extensions or not, so if it's installed by
default, some old systems would be rendered unbootable. In theory,
anything that supports x86_64 should support these extensions (they were
introduced in the Windows 95/98 times, when hard drives started hitting
the 8 GB mark, while x86_64 appeared much later, in 2003, at the time
hard drives were hitting 160GB-200GB as far as I can remember, and the 8
GB limit was becoming a joke), however I don't know what's the reality,
BIOSes are surprisingly buggy.

the main obstacle is
that I'm not familiar with GRUB's code and I don't know what GRUB's next
stage needs

I myself only learn about GRUB at occasions like this here.
There is a vivid community at grub-de...@gnu.org. If you have an
interesting use case they might be willing to explain things. But on the
other hand the BIOS stuff is old and Vladimir Serbinenko, who created it,
is not very busy with GRUB any more.
Yeah, I'll join that mailing list and explain the use case I have in
mind (the one that I described above).

Unfortunately, I'm not familiar with how El Torito works,

Roughly:

At 2048-byte-LBA 17 (decimal) there is the Boot Record, which points to
the El Torito Boot Catalog. The catalog contains entries, which describe
boot images. In case of Fedora Live there are three of them: One for BIOS,
and two for EFI.

The boot image for BIOS is a plain x86 program. The first EFI image is
a FAT filesystem with boot programs /EFI/BOOT/BOOT*.EFI for the intended
processor architectures (x86-32bit, x86-64bit, ARM-32bit, ... ).

The second boot image for EFI (macboot.img) is actually a HFS+ filesystem
image which should not be listed in the catalog. That's a hack by Matthew
J. Garrett to let the rather dumb ISOLINUX program isohybrid.c find the
HFS+ image and mark it by an Apple Partition Map. isohybrid.c does not
understand ISO 9660 but it knows the El Torito boot catalog.
Fedora does not use isohybrid.c any more, but rather lets libisofs under
xorriso create the Apple Partition Map, if at all. Nevertheless, xorriso
produces the same inappropriate catalog entry for EFI, which the firmware
ignores in favor of the appropriate EFI boot image.
(Who am i to change mjg's invention ?)

My knowledge about boot lures for various processors and firmwares is
compiled at

https://dev.lovelyhq.com/libburnia/libisofs/raw/branch/master/doc/boot_sectors.txt

Original specs:

El Torito:

http://web.archive.org/web/20010706014919/http://www.ibm.com/products/surepath/documents/standard/cdrom7.pdf
UEFI:
https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
Legacy BIOS:
Only rumors around. Start exploring at Wikipedia. Re-use your knowledge
about BIOS booting from floppy/hard disk/USB flash drive.

Thanks for the explanation and the links. I'll check them out.

This hybrid USB stick/DVD iso image has always seemed
like black magic to me :)

It's just a matter of outmost cramming of boot lures which are barely
compatible. (The unusual block size 2048 for Apple Partition Map
gives room for GPT. Some noop-x86 code at the start of the MBR lets
it look like the first block of an Apple Partition Map. It's just weird
from the view of specs and BIOS tradition. But it works since 10 years.)

I imagine it is like those polyglot programs, that are simultaneously
valid in several totally different programming languages:

https://en.wikipedia.org/wiki/Polyglot_(computing)

AFAIK, Windows only
provides an ISO download, that is suitable for burning on optical media and
then it boots, but it doesn't work, when you "dd" it to an USB flash drive.
I think you need to use special tool, to write it to a USB stick,

You are supposed to create a FAT filesystem in a MBR partition of the
USB stick with a traditional partition type like 0x0C. Then you copy all
files

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-10 Thread Thomas Schmitt

Hi,

Nikolay Nikolov wrote:
> Maybe I should try adapting my code, so that it finds the GRUB BIOS boot
> partition and loads it?

This would be a nice stunt for which we would have to find a use case.
As stated yesterday, the GRUB El Torito image contains a core.img which
serves the same purpose as a BIOS partition.

> the main obstacle is
> that I'm not familiar with GRUB's code and I don't know what GRUB's next
> stage needs

I myself only learn about GRUB at occasions like this here.
There is a vivid community at grub-de...@gnu.org. If you have an
interesting use case they might be willing to explain things. But on the
other hand the BIOS stuff is old and Vladimir Serbinenko, who created it,
is not very busy with GRUB any more.

> Unfortunately, I'm not familiar with how El Torito works,

Roughly:

At 2048-byte-LBA 17 (decimal) there is the Boot Record, which points to
the El Torito Boot Catalog. The catalog contains entries, which describe
boot images. In case of Fedora Live there are three of them: One for BIOS,
and two for EFI.

The boot image for BIOS is a plain x86 program. The first EFI image is
a FAT filesystem with boot programs /EFI/BOOT/BOOT*.EFI for the intended
processor architectures (x86-32bit, x86-64bit, ARM-32bit, ... ).

The second boot image for EFI (macboot.img) is actually a HFS+ filesystem
image which should not be listed in the catalog. That's a hack by Matthew
J. Garrett to let the rather dumb ISOLINUX program isohybrid.c find the
HFS+ image and mark it by an Apple Partition Map. isohybrid.c does not
understand ISO 9660 but it knows the El Torito boot catalog.
Fedora does not use isohybrid.c any more, but rather lets libisofs under
xorriso create the Apple Partition Map, if at all. Nevertheless, xorriso
produces the same inappropriate catalog entry for EFI, which the firmware
ignores in favor of the appropriate EFI boot image.
(Who am i to change mjg's invention ?)

My knowledge about boot lures for various processors and firmwares is
compiled at

https://dev.lovelyhq.com/libburnia/libisofs/raw/branch/master/doc/boot_sectors.txt

Original specs:

El Torito:

http://web.archive.org/web/20010706014919/http://www.ibm.com/products/surepath/documents/standard/cdrom7.pdf
UEFI:
  https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
Legacy BIOS:
  Only rumors around. Start exploring at Wikipedia. Re-use your knowledge
  about BIOS booting from floppy/hard disk/USB flash drive.

> This hybrid USB stick/DVD iso image has always seemed
> like black magic to me :)

It's just a matter of outmost cramming of boot lures which are barely
compatible. (The unusual block size 2048 for Apple Partition Map
gives room for GPT. Some noop-x86 code at the start of the MBR lets
it look like the first block of an Apple Partition Map. It's just weird
from the view of specs and BIOS tradition. But it works since 10 years.)

> AFAIK, Windows only
> provides an ISO download, that is suitable for burning on optical media and
> then it boots, but it doesn't work, when you "dd" it to an USB flash drive.
> I think you need to use special tool, to write it to a USB stick,

You are supposed to create a FAT filesystem in a MBR partition of the
USB stick with a traditional partition type like 0x0C. Then you copy all
files from the ISO 9660 filesystem into that FAT filesystem.
Et voila: An undocumented property of EFI implementations will find
and start /EFI/BOOT/BOOT*.EFI to boot MS-Windows.
(M$-Knowledge gained from Pete Batard, developer of program Rufus.)

Interestingly, Fedora Live ISOs have a /EFI/BOOT/ tree in the ISO 9660
filesystem, probably to support this feature. I learned about it from
Pete Batard's protests when Ubuntu began to produce ISOs which omitted
this copy of the EFI System Partition FAT content.

> And what's worse,
> they now require the rarer and more expensive DVD+R DL discs, since their
> install image exceeds 4.7 GB :)

Consider to invest in a Blu-ray burner. Single layer BD-R and BD-RE are
much more reliable than DVD+R DL and meanwhile at least BD-R are cheaper
than DVD+R DL. BD-RE cost about the same as DVD+RW with more than 5 times
the storage capacity. Still cheaper than 16 GB USB sticks.

Have a nice day :)

Thomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-09 Thread Gary Buhrmaster

On Wed, Apr 6, 2022 at 6:01 PM Neal Gompa  wrote:

> Moving past the Big Three(tm), the actual
> cloud providers that matter from a Fedora context are the smaller
> outfits that principally serve Linux users. These are companies like
> DigitalOcean, Linode (Akamai), Hetzner, VexxHost, and others who
> graciously do offer Fedora Linux in their platforms. All of their
> virtualization platforms are BIOS only right now, and getting them to
> switch requires them to uplift their platforms to support UEFI in the
> first place.

They may only support Linux users today, but if
they want to grow (and while it is possible to
survive as a niche service, many see growth
as the way to increased revenue/profits (go
big or go home)), they are going to get pushed
(perhaps kicking and screaming) to support
UEFI as at least an alternative moving forward
as some of their customers are going to prefer
using a single provider, and Windows 11
requires UEFI(*)(**), and it would be a shame
if only the big players were eligible for hosting
such services(***).

Many of these comments seem to be about
the date, not the end state (UEFI)(),
just like 32-bit x86 and armv7.  No one wants
their personal ox gored, but there will come
a time when it will be time to let old systems
go.

"We" (and when I say "we", I understand that
is mostly not me), are going to have to
continue to document (and fix, where "we"
have the knowledge) the areas that need
improvement for UEFI booting and runtime.

Gary

(*) Technically it is possible to jump through
enough hoops to get Windows 11 to run on
BIOS only systems, but it is not supported,
and may break at any time.  Most people
prefer something that the vendor supports.

(**) Yes, some may prefer living in a
Windows-less world, but the reality is that
(especially at business scale) there are
services and applications that require
Windows today, and will likely require
Windows for a number of tomorrows.

(***) Yes, using multiple cloud providers
is often advantageous to avoid vendor
lock-in and provider failures, but scale
(at one provider) can result in savings
(both expense, and duplication of work
supporting the different providers' services).
There is statement by a VC regarding
startups which is (essentially) everyone
should start by using AWS, and then
have a plan to move off when their
scale is sufficient (of course, many
startups never survive sufficiently long
to move off, and others simply prefer
to spend their (precious) engineering
resources in other ways).

() Yes, some hope coreboot/linuxboot
can replace UEFI (and it can in some use
cases).  But unless/until MS embraces it,
UEFI is the answer (even if one is still
discussing the question that was asked).
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-09 Thread Nikolay Nikolov



On 4/10/22 00:30, Thomas Schmitt wrote:

Hi,

Nikolay Nikolov wrote:

I haven't looked at GRUB's MBR code, but there's enough space in the MBR to
scan the GPT entries, find a specific GUID partition type and load the first
several kilobytes from it and transfer control to it.

Well, GRUB goes a different way on legacy BIOS. It boots its core code
without knowing about partitions and then loads the modules which its
configuration expects to need. I understand GPT is handled by "part_gpt"
and MBR partitions by "part_msdos".



The code takes up only 262 bytes so far

It is astounding what can be squeezed into 440 bytes of x86 machine code.
Maybe I should try adapting my code, so that it finds the GRUB BIOS boot 
partition and loads it? It shouldn't be too hard to do, the main 
obstacle is that I'm not familiar with GRUB's code and I don't know what 
GRUB's next stage needs (i.e. at what address it should be loaded, and 
how it should be called). But regarding size, core.img is apparently 
less than 32 kb, and it fits between the MBR and the first partition on 
MBR systems, and my code already loads almost 64kb from a GPT partition, 
so even if the next GRUB stage needs some special requirements (like 
moving to a different address, enabling gate A20, entering protected 
mode, etc), it can be done at least with a wrapper, but perhaps also 
even in the remaining bytes of my MBR code.


---

I meanwhile learned that the El Torito boot image eltorito.img used by
grub-mkrescue is not a plain copy of cdboot.img but rather a
concatenation of cdboot.img and a core.img :

   
https://www.gnu.org/software/grub/manual/grub/grub.html#Making-a-GRUB-bootable-CD_002dROM
   "For booting from a CD-ROM, GRUB uses a special image called cdboot.img,
which is concatenated with core.img. The core.img used for this should
be built with at least the ‘iso9660’ and ‘biosdisk’ modules."

So the role of the BIOS partition is properly fulfilled by the El Torito
boot image which has 27874 bytes in my example ISO from grub-mkrescue.
Unfortunately, I'm not familiar with how El Torito works, I only 
understand the legacy PC boot process from floppy/hard disk/USB flash 
drive, but not from optical media. This hybrid USB stick/DVD iso image 
has always seemed like black magic to me :) And we've been spoiled and 
expect it to work, but I think it doesn't work with Windows 10, for 
example. :) AFAIK, Windows only provides an ISO download, that is 
suitable for burning on optical media and then it boots, but it doesn't 
work, when you "dd" it to an USB flash drive. I think you need to use 
special tool, to write it to a USB stick, but I've never done it, I 
still burn DVD+R for Windows installs :) And what's worse, they now 
require the rarer and more expensive DVD+R DL discs, since their install 
image exceeds 4.7 GB :)



Have a nice day :)

Thomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-09 Thread Thomas Schmitt

Hi,

this is what i propose as boot layout of an entirely GRUB based ISO
which boots on EFI and not-so-buggy legacy BIOS from USB stick and DVD:



$ xorriso -indev grub_mkrescue_gpt_appended.iso -report_el_torito plain 
-report_system_area plain
...
El Torito catalog  : 165  1
El Torito cat path : /boot.catalog
El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz LBA
El Torito boot img :   1  BIOS  y   none  0x  0x00  42040
El Torito boot img :   2  UEFI  y   none  0x  0x00   57606043
El Torito img path :   1  /boot/grub/i386-pc/eltorito.img
El Torito img opts :   1  boot-info-table grub2-boot-info
El Torito img blks :   2  1440
System area options: 0x4201
System area summary: MBR protective-msdos-label grub2-mbr cyl-align-off GPT
ISO image size/512 : 29996
Partition offset   : 16
MBR heads per cyl  : 64
MBR secs per head  : 32
MBR partition table:   N Status  TypeStart   Blocks
MBR partition  :   1   0x00  0xee129995
GPT:   N  Info
GPT disk GUID  :  e59ea280058a754fb57833ebe50cd3e0
GPT entry array:  2  248  separated
GPT lba range  :  64  29932  29995
GPT partition name :   1  490053004f003900360036003000
GPT partname local :   1  ISO9660
GPT partition GUID :   1  e59ea280058a754fb57933ebe50cd3e0
GPT type GUID  :   1  a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags:   1  0x1001
GPT start and size :   1  64  24108
GPT partition name :   2  41007000700065006e006400650064003200
GPT partname local :   2  Appended2
GPT partition GUID :   2  e59ea280058a754fb57a33ebe50cd3e0
GPT type GUID  :   2  28732ac11ff8d211ba4b00a0c93ec93b
GPT partition flags:   2  0x
GPT start and size :   2  24172  5760



$ /sbin/fdisk -l grub_mkrescue_gpt_appended.iso

Disk grub_mkrescue_gpt_appended.iso: 14.7 MiB, 15357952 bytes, 29996 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 80A29EE5-8A05-4F75-B578-33EBE50CD3E0

Device  Start   End Sectors  Size Type
grub_mkrescue_gpt_appended.iso164 24171   24108 11.8M Microsoft basic data
grub_mkrescue_gpt_appended.iso2 24172 299315760  2.8M EFI System



xorrisofs (minimum version 1.5.2) options would be:

  --grub2-mbr /usr/lib/grub/i386-pc/boot_hybrid.img
  -partition_offset 16
  -appended_part_as_gpt
  -append_partition 2 C12A7328-F81F-11D2-BA4B-00A0C93EC93B 
/...diskpath.../efiboot.img
  -iso_mbr_part_type EBD0A0A2-B9E5-4433-87C0-68B6B72699C7
  -c /boot/grub/boot.cat
  -b /boot/grub/i386-pc/eltorito.img
 -no-emul-boot -boot-load-size 4 -boot-info-table --grub2-boot-info
  -eltorito-alt-boot
  -e '--interval:appended_partition_2:all::'
 -no-emul-boot

They would replace these options from the current xorriso command with
Live ISOs as quoted by Chris Murphy:

> -isohybrid-mbr /usr/share/syslinux/isohdpfx.bin
> -b isolinux/isolinux.bin
> -c isolinux/boot.cat
> -boot-load-size 4 -boot-info-table -no-emul-boot
> -eltorito-alt-boot
> -e images/efiboot.img -no-emul-boot -isohybrid-gpt-basdat
> -eltorito-alt-boot
> -e images/macboot.img -no-emul-boot -isohybrid-gpt-hfsplus

The file efiboot.img should not be in the ISO 9660 filesystem.

Similar to the old /isolinux/isolinux.bin ione has to bring a GRUB
El Torito BIOS image as /boot/grub/i386-pc/eltorito.img into the ISO 9660
filesystem, so that option -b finds it.
(eltorito.img gets made by grub-mkimage. But i am quite sure one can
 simply grab it from a grub-mkrescue ISO of the same GRUB version as
 used inside efiboot.img. Maybe one needs to move GRUB configuration
 lines out of a grub.conf in efiboot.img to a grub.conf in the ISO 9660
 filesystem, so that both boot paths can use them.)

Support would vanish for old pre-EFI Macs and for buggy legacy BIOS
which demands to see a boot/active flag in some MBR partition slot
if the ISO is presented on a USB stick.

The benefit iwould be to have a neat GPT instead of the current MBR
partition table with the mockup of a GPT and with the EFI partition
sitting inside the ISO 9660 partition.


Have a nice day :)

Thomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-09 Thread Thomas Schmitt

Hi,

Nikolay Nikolov wrote:
> I haven't looked at GRUB's MBR code, but there's enough space in the MBR to
> scan the GPT entries, find a specific GUID partition type and load the first
> several kilobytes from it and transfer control to it.

Well, GRUB goes a different way on legacy BIOS. It boots its core code
without knowing about partitions and then loads the modules which its
configuration expects to need. I understand GPT is handled by "part_gpt"
and MBR partitions by "part_msdos".

> The code takes up only 262 bytes so far

It is astounding what can be squeezed into 440 bytes of x86 machine code.

---

I meanwhile learned that the El Torito boot image eltorito.img used by
grub-mkrescue is not a plain copy of cdboot.img but rather a
concatenation of cdboot.img and a core.img :

https://www.gnu.org/software/grub/manual/grub/grub.html#Making-a-GRUB-bootable-CD_002dROM
  "For booting from a CD-ROM, GRUB uses a special image called cdboot.img,
   which is concatenated with core.img. The core.img used for this should
   be built with at least the ‘iso9660’ and ‘biosdisk’ modules."

So the role of the BIOS partition is properly fulfilled by the El Torito
boot image which has 27874 bytes in my example ISO from grub-mkrescue.

Have a nice day :)

Thomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-09 Thread Nikolay Nikolov



On 4/9/22 03:07, Chris Murphy wrote:

On Fri, Apr 8, 2022 at 4:31 PM Thomas Schmitt  wrote:

Yeah, I'm not aware off hand of any UEFI that have a problem with the
first 440 bytes of LBA 0 being non-zero.


If they did, then they would have problems with GPT disks, initialized 
by Windows 10, because Windows 10 puts its standard non-GPT aware 
bootloader code there. :)


Only Fedora-initialized disks have zeros there. :)

I can confirm this, because I have three disks (two 512GB SSDs and one 
2TB HDD) on my UEFI-enabled, dual booting between Windows 11 and Fedora, 
desktop computer.



  I am aware though, of this
tianocore bug [1] where if the active bit on that 0xEE partition is
set, the GPT is considered invalid. This is now fixed in Tianocore,
but it might be widespread in firmware in hardware. But the idea would
be to not set this boot flag on our increasingly hypothetical future
ISOs because (a) it might cause UEFI to drop to an EFI shell, if this
bug is more widespread (b) we don't really want to work around buggy
BIOS firmware anyway, we want them to fail here rather than later.

Pretty sure I discovered this bug when testing Fedora 35 Cloud base
images, which are GPT with PMBR, and boot both BIOS and UEFI systems.
There's jump code in the first 440 bytes of LBA 0, pointing to the
core.img in BIOS Boot partition, and also there's an EFI system volume
that UEFI firmware discover.



But if
there are still some systems out there that will face plant on GPT
anyway, it's probably best if they face plant when booting the
installation media rather than getting all the way to a successful
installation, just to face plant upon reboot.

Legacy BIOS does not care for partition tables. At least to my knowledge
from supporting production of bootable ISOs. My mileage may vary.
Problems with partitions will arise only after BIOS handed control to
the MBR x86 code on USB stick or the El Torito boot image on DVD.

Some legacy BIOS insist on seeing certain MBR structures in LBA 0 or
they face plant. This was why Fedora never proceeded with GPT by
default on BIOS systems. Too many at the time didn't like the PMBR for
one reason or another. I think the more common reason (?) was the
single partition in the PMBR didn't have BootIndicator set, hence
parted's pmbr_boot flag, which sets this bit.



Possibly this here describes what is needed for GRUB if started by
legacy BIOS and facing GPT:
   https://wiki.archlinux.org/title/GRUB#BIOS_systems
I understand that the GPT boot partition substitutes for the traditional
gap between MBR block and the start of the first MBR partition. 1 MiB
of "embedded area" if i remember correctly.

yeah that's what I'm calling BIOS boot partition type, it's partition
type GUID is 21686148-6449-6E6F-744E-656564454649 which grub-install
is looking for, and how it knows where to embed core.img. But as I
understand it, the code in the first 440 bytes of LBA 0, written by
grub-install as well, is just jump to the LBA for core.img. There's no
code to "teach" the computer how to read the GPT and go find BIOS
Boot. It's a hard coded LBA to just blindly jump to.


I haven't looked at GRUB's MBR code, but there's enough space in the MBR 
to scan the GPT entries, find a specific GUID partition type and load 
the first several kilobytes from it and transfer control to it. And this 
is even without assuming 512-byte sectors. I know this, because I have 
written such code for my hobby DOS-like OS, which I want to be able to 
support GPT in BIOS legacy mode, so it can coexist with modern Windows 
and Linux distros (which boot in UEFI mode, while my OS boots in legacy 
mode - I can switch between the two modes from my UEFI boot menu).


Here's the code I've written (consider it proof of concept), but it can 
be used by GRUB as well:


https://sourceforge.net/p/fpcdos/code/HEAD/tree/trunk/src/gptboot/mbr.asm

The code takes up only 262 bytes so far, so it has plenty of bytes to 
spare (for e.g. nicer diagnostic error messages). The only thing it 
assumes is that the INT 13h LBA BIOS extensions are available - there's 
no CHS fallback support.


The code *doesn't* assume that the sectors size is 512 bytes, it doesn't 
assume the GPT partition it is looking for is in a specific position in 
the table, or starting on a specific LBA, it doesn't assume the number 
of GPT partitions are less than 128, it doesn't assume that GUID 
partition entries are 128-byte sized and it doesn't care about the 4 MBR 
partitions at all, it only searches through the GPT partitions.


The code assumes that the GPT partition table is correct, and doesn't do 
a lot of error checking, e.g. it doesn't check the CRC32 fields in the 
GPT header.





But grub-mkrescue ISOs have GPT without a dedicated boot partition.
Probably that job is fulfilled by the El Torito boot image which has a
few more KiB than the MBR x86 code.

So i assume that face planting will happen only at later stages if the
booted system makes false assumptions

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-09 Thread Thomas Schmitt

Hi,

> OK so there isn't (yet) an option to embed the GRUB core.img in a GPT
> BIOS boot partition, I take it? The assumption is MBR? On hard drives,
> core.img goes in the MBR gap. I'm not sure where it goes on xorriso
> produced ISOs though, but presumably not the gap because there's a
> valid GPT there too.

One could probably use core.img for booting from USB stick. But it would
not obsolete the x86 code in MBR and it currently is not necessary for
grub-mkrescue ISOs because eltorito.img does a job equivalent to core.img.
eltorito.img is stored in the ISO 9660 filesystem as normal data file.
The MBR x86 code transfers execution to it and the El Torito catalog has
it as boot image for x86 legacy BIOS.


> Yeah, I'm not aware off hand of any UEFI that have a problem with the
> first 440 bytes of LBA 0 being non-zero. I am aware though, of this
> tianocore bug [1] where if the active bit on that 0xEE partition is
> set, the GPT is considered invalid.

That's why grub-mkrescue lets xorriso produce a pure GPT with no
boot/active flag at the 0xEE partition. But this lets old HP laptops
refuse to boot from USB stick.
A foul compromise is to add another MBR partition of type 0x00 with
boot/active flag. EFI is known to ignore it, but HP legacy BIOS takes it
as reason to run the MBR x86 code (which is not related to partitions).


> (b) we don't really want to work around buggy
> BIOS firmware anyway, we want them to fail here rather than later.

That's a harsh decision but would match the purpose of this thread, indeed.
If so, then producing a pure GPT instead of the current jackalope seems
the way to go. grub-mkrescue will point the way or could even be the
solution to go for.

I would propose to care for a mountable ISO 9660 partition, by moving
the EFI boot image / EFI system partition out of the filesystem and
rather appending it as extra partition. An example can be created by
MKRESCUE_SED_MODE=gpt_appended with script frontend/grub-mkrescue-sed.sh
out of libisoburn.)
Further one would need xorrisofs option
  -partition_offset 16
so that a mountable GPT partition can be created which starts at 512-block
address 64, i.e. after the GPT partition table data. This wastes some
space because a second directory tree has to be generated additionally to
the normal directory tree which will be used when booting or mounting
the ISO from a DVD.
The waste would not be much with Fedora Live ISOs. In 3-year-old
Fedora-Workstation-Live-x86_64-31-1.9.iso the first data file is already
at 2048-block address 43. That would be at most 23 * 2048 bytes for the
directory records which form the file tree (43 - 16 blocks System Area -
4 blocks of Volume Descriptors). So the waste would be <= 46 KiB.

At that occasion consider to drop the HFS+ Mac boot image and the Apple
Partition map which marks it for some obscure non-EFI x86 Macs. I.e.
consider to remove from the current xorrisofs command the options
  -eltorito-alt-boot
  -e images/macboot.img -no-emul-boot -isohybrid-gpt-hfsplus
and try to find a Mac which misses this boot image and refuses to boot
but boots with the original ISO.


> Some legacy BIOS insist on seeing certain MBR structures in LBA 0 or
> they face plant.

I only know of the buggy demand for a boot/active flag at some MBR
partition. If you can name more stumble stones, i would be highly
interested to learn about them.


> If we can opt out of making a hybrid/faux MBR, and create a PMBR
> instead, that'd also mean there's one clear unambiguous partition map
> for USB sticks, which could make it easier to implement persistence.

A PMBR is an MBR at the start of a partition and gets activated only
if the device MBR decides to do so. Sometimes there is MBR code on newly
bought USB sticks which looks for a partition with boot/active flag and
then chain-loads the PMBR from there.
But in an EL Torito bootable ISO this makes few sense. The little
hybrid MBR and the larger BIOS boot image can do everything that is
needed.

A neat partition map is indeed a valuable goal. To my knowledge it can
only be achieved by dropping support for the buggy legacy BIOSes which
demand to see an MBR partition with boot/active flag or by dropping
support for buggy EFIs which do not recognize the MBR partition type
0xEF unless a smell of GPT is on the storage device.

-
Just for the fun of it i post xorriso's assessment of the jackalope boot
equipment in Fedora-Workstation-Live-x86_64-31-1.9.iso :

  $ xorriso -indev Fedora-Workstation-Live-x86_64-31-1.9.iso -report_el_torito 
plain -report_system_area plain
  ...
  El Torito catalog  : 42  1
  El Torito cat path : /isolinux/boot.cat
  El Torito images   :   N  Pltf  B   Emul  Ld_seg  Hdpt  Ldsiz LBA
  El Torito boot img :   1  BIOS  y   none  0x  0x00  4   16852
  El Torito boot img :   2  UEFI  y   none  0x  0x00  21716  43
  El Torito boot img :   3  UEFI  y   none  0x  0x00  45520

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-08 Thread Samuel Sieb


On 4/8/22 12:07, Jared Dominguez wrote:
If the experience is buggy with Windows too, HP probably has addressed 
that as previously stated, which is why I asked about how up-to-date 
Samuel's BIOS is. On several occasions I've seen complaints about 
firmware issues that are solved by updating. Firmware is software too.


Windows didn't run in EFI mode on it.  I only turned on the EFI mode 
when I put a new drive in with no windows, accepting the big warning 
that it was experimental.


If not, that sounds like a big in Fedora and possibly Linux in general. 
Windows is the reference operating system for most personal computer 
manufacturers, whether we like it or not.


The biggest issue was that it seemed to ignore the efi boot entry for 
Fedora and used the fallback system.  This caused something in the 
Fedora boot system to create another entry every time.  I had to delete 
the extra entries every once in a while.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-08 Thread Chris Murphy

On Fri, Apr 8, 2022 at 4:31 PM Thomas Schmitt  wrote:
>
> Hi,
>
> Chris Murphy wrote:
> > Is there a possibility of dropping MBR? i.e. use GPT containing both a
> > biosboot partition type, and EFI System partition type?
>
> I am not aware that legacy BIOS would hop directly on any GPT partition
> or any MBR partition table partition.
>
> The convention for hard-disk-like devices is to start the x86 code in
> bytes 0 to 439 (or maybe to byte 445) of the MBR as 16-bit program.
> In case of ISOLINUX or GRUB hybrid MBR, the only goal is to hand over
> program execution to the El Torito boot image which is allowed to be
> larger and is also the starting point for booting from DVD.
> The connection is made by xorriso by patching the LBA of the boot image
> into the x86 code of the MBR. Format and byte address for this patching
> depends on the boot loader. Thus the mutually exclusive options
> -isohybrid-mbr and --grub2-mbr.

OK so there isn't (yet) an option to embed the GRUB core.img in a GPT
BIOS boot partition, I take it? The assumption is MBR? On hard drives,
core.img goes in the MBR gap. I'm not sure where it goes on xorriso
produced ISOs though, but presumably not the gap because there's a
valid GPT there too.

> > The advantage of this is not just to get rid of MBR really.
>
> We have the room for those 440 bytes anyways if we have GPT.
> The magic number of GPT is the "protective" MBR partition table at
> bytes 446 to 509. There must be one partition slot of type 0xee and
> no other valid partition marked by the other three slots.
> The content of bytes 0 to 439 is specified by UEFI for "Protective
> MBR" as "Unused by UEFI systems". In contrast to that, the bytes from
> 440 to 445 are specified as "Unused. Set to zero."
> (UEFI 2.4 Table 15, UEFI 2.8 Table 19)

Yeah, I'm not aware off hand of any UEFI that have a problem with the
first 440 bytes of LBA 0 being non-zero. I am aware though, of this
tianocore bug [1] where if the active bit on that 0xEE partition is
set, the GPT is considered invalid. This is now fixed in Tianocore,
but it might be widespread in firmware in hardware. But the idea would
be to not set this boot flag on our increasingly hypothetical future
ISOs because (a) it might cause UEFI to drop to an EFI shell, if this
bug is more widespread (b) we don't really want to work around buggy
BIOS firmware anyway, we want them to fail here rather than later.

Pretty sure I discovered this bug when testing Fedora 35 Cloud base
images, which are GPT with PMBR, and boot both BIOS and UEFI systems.
There's jump code in the first 440 bytes of LBA 0, pointing to the
core.img in BIOS Boot partition, and also there's an EFI system volume
that UEFI firmware discover.

> > But if
> > there are still some systems out there that will face plant on GPT
> > anyway, it's probably best if they face plant when booting the
> > installation media rather than getting all the way to a successful
> > installation, just to face plant upon reboot.
>
> Legacy BIOS does not care for partition tables. At least to my knowledge
> from supporting production of bootable ISOs. My mileage may vary.
> Problems with partitions will arise only after BIOS handed control to
> the MBR x86 code on USB stick or the El Torito boot image on DVD.

Some legacy BIOS insist on seeing certain MBR structures in LBA 0 or
they face plant. This was why Fedora never proceeded with GPT by
default on BIOS systems. Too many at the time didn't like the PMBR for
one reason or another. I think the more common reason (?) was the
single partition in the PMBR didn't have BootIndicator set, hence
parted's pmbr_boot flag, which sets this bit.

> Possibly this here describes what is needed for GRUB if started by
> legacy BIOS and facing GPT:
>   https://wiki.archlinux.org/title/GRUB#BIOS_systems
> I understand that the GPT boot partition substitutes for the traditional
> gap between MBR block and the start of the first MBR partition. 1 MiB
> of "embedded area" if i remember correctly.

yeah that's what I'm calling BIOS boot partition type, it's partition
type GUID is 21686148-6449-6E6F-744E-656564454649 which grub-install
is looking for, and how it knows where to embed core.img. But as I
understand it, the code in the first 440 bytes of LBA 0, written by
grub-install as well, is just jump to the LBA for core.img. There's no
code to "teach" the computer how to read the GPT and go find BIOS
Boot. It's a hard coded LBA to just blindly jump to.

>
> But grub-mkrescue ISOs have GPT without a dedicated boot partition.
> Probably that job is fulfilled by the El Torito boot image which has a
> few more KiB than the MBR x86 code.
>
> So i assume that face planting will happen only at later stages if the
> booted system makes false assumptions like "GPT means EFI".

Well it's been a long time since the GPT by default attempts, so I
kinda forget how they manifested, though that information is probably
in this list's archive :) My vague recollection is black

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-08 Thread Thomas Schmitt

Hi,

Chris Murphy wrote:
> Is there a possibility of dropping MBR? i.e. use GPT containing both a
> biosboot partition type, and EFI System partition type?

I am not aware that legacy BIOS would hop directly on any GPT partition
or any MBR partition table partition.

The convention for hard-disk-like devices is to start the x86 code in
bytes 0 to 439 (or maybe to byte 445) of the MBR as 16-bit program.
In case of ISOLINUX or GRUB hybrid MBR, the only goal is to hand over
program execution to the El Torito boot image which is allowed to be
larger and is also the starting point for booting from DVD.
The connection is made by xorriso by patching the LBA of the boot image
into the x86 code of the MBR. Format and byte address for this patching
depends on the boot loader. Thus the mutually exclusive options
-isohybrid-mbr and --grub2-mbr.

> The advantage of this is not just to get rid of MBR really.

We have the room for those 440 bytes anyways if we have GPT.
The magic number of GPT is the "protective" MBR partition table at
bytes 446 to 509. There must be one partition slot of type 0xee and
no other valid partition marked by the other three slots.
The content of bytes 0 to 439 is specified by UEFI for "Protective
MBR" as "Unused by UEFI systems". In contrast to that, the bytes from
440 to 445 are specified as "Unused. Set to zero."
(UEFI 2.4 Table 15, UEFI 2.8 Table 19)

> But if
> there are still some systems out there that will face plant on GPT
> anyway, it's probably best if they face plant when booting the
> installation media rather than getting all the way to a successful
> installation, just to face plant upon reboot.

Legacy BIOS does not care for partition tables. At least to my knowledge
from supporting production of bootable ISOs. My mileage may vary.
Problems with partitions will arise only after BIOS handed control to
the MBR x86 code on USB stick or the El Torito boot image on DVD.

Possibly this here describes what is needed for GRUB if started by
legacy BIOS and facing GPT:
  https://wiki.archlinux.org/title/GRUB#BIOS_systems
I understand that the GPT boot partition substitutes for the traditional
gap between MBR block and the start of the first MBR partition. 1 MiB
of "embedded area" if i remember correctly.

But grub-mkrescue ISOs have GPT without a dedicated boot partition.
Probably that job is fulfilled by the El Torito boot image which has a
few more KiB than the MBR x86 code.

So i assume that face planting will happen only at later stages if the
booted system makes false assumptions like "GPT means EFI".

Have a nice day :)

Thomas
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-08 Thread Chris Murphy

On Fri, Apr 8, 2022 at 12:29 PM Thomas Schmitt  wrote:

> The lines, which will need changes for using GRUB, are at least:
>
>   -isohybrid-mbr /usr/share/syslinux/isohdpfx.bin
>   [...]
>   -boot-load-size 4 -boot-info-table -no-emul-boot
>   -b isolinux/isolinux.bin
>
> grub-mkrescue (on Debian) uses instead:
>
>   --grub2-mbr /usr/lib/grub/i386-pc/boot_hybrid.img
>   -b boot/grub/i386-pc/eltorito.img
>  -no-emul-boot -boot-load-size 4 -boot-info-table --grub2-boot-info

Is there a possibility of dropping MBR? i.e. use GPT containing both a
biosboot partition type, and EFI System partition type?

The advantage of this is not just to get rid of MBR really. But if
there are still some systems out there that will face plant on GPT
anyway, it's probably best if they face plant when booting the
installation media rather than getting all the way to a successful
installation, just to face plant upon reboot.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-08 Thread Jared Dominguez

On Fri, Apr 8, 2022, 11:52 Neal Gompa  wrote:

> On Fri, Apr 8, 2022 at 11:47 AM Jared Dominguez  wrote:
> >
> >
> >
> >
> > On Thu, Apr 7, 2022, 19:46 Samuel Sieb  wrote:
> >>
> >> On 4/7/22 14:51, Jared Dominguez wrote:
> >> > On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb  >> > > wrote:
> >> >
> >> > On 4/7/22 08:02, Jared Dominguez wrote:
> >> >  > This is a proposal. Nothing has changed yet. The choice is now
> >> > whether
> >> >  > to go forward with it or come together with a cohesive
> >> >  > alternative, including one of the two listed in the proposal.
> But we
> >> >  > need a solution that accounts for the existing maintainers not
> >> > having
> >> >  > capacity to continue maintaining legacy code. I've seen
> responses
> >> > from
> >> >
> >> > I haven't yet seen a clear answer about what code is "rotting" and
> >> > which
> >> > legacy code is too hard to maintain.  Is there something actually
> >> > broken
> >> > right now?
> >> >
> >> >
> >> > For one, syslinux hasn't seen an update in 3 years and a release in 7
> >> > years, and it has outstanding bugs. Legacy boot isn't where grub2 is
> >> > getting development attention. The current maintainers in Fedora won't
> >> > have capacity to continue maintaining legacy boot support in Fedora.
> As
> >> > grub2 continues to be developed for UEFI systems (ARMv8-9 and x86-64,
> >> > not to mention non-UEFI ppc64le and s390x), there is added risk of
> >> > regressions on legacy x86 boot that won't be getting developer
> attention.
> >>
> >> I don't understand why we're still using syslinux instead of grub for
> >> legacy boots, especially since I think now you can use the same grub.cfg
> >> file for both.
> >
> >
> > It's development and validation work for something that's not a priority
> for those who are doing bootloader work, and no one else has stepped up to
> put in the time to do this work. The change proposal being discussed in
> this thread is calling for community contributors.
> >
> >> There is always a risk of regressions, but if there is
> >> no current problem, then why is there this push to obsolete a lot of
> >> active hardware?
> >
> >
> > There is a problem: the current maintainers don't have capacity to
> support legacy x86 boot anymore. The code is going to bit rot if no one
> steps up to fill in.
> >
> >> This is not comparable to the 32-bit removal where it
> >> was only a few really old systems.  This is going to affect decent
> >> systems that are less than 10 years old.  I have a work HP laptop from
> >> 2012 that has "experimental" EFI support that really doesn't work well
> >> and possibly a newer one as well, but I can't check it right now.
> >
> >
> > I'm curious if you've updated your BIOS on that system. If it's really
> that bad, Microsoft (and HP customers) would have been on HP's case about
> fixing a bad user experience.
> >
>
> Why? It works for Windows, and HP has only done token support for
> other platforms over the past decade (see most recent thing promoting
> WSL as a good Linux on HP experience[1]). All of my HP computers have
> been extremely difficult to get Linux working on properly, which is
> why I stopped buying them.
>

If the experience is buggy with Windows too, HP probably has addressed that
as previously stated, which is why I asked about how up-to-date Samuel's
BIOS is. On several occasions I've seen complaints about firmware issues
that are solved by updating. Firmware is software too.

If not, that sounds like a big in Fedora and possibly Linux in general.
Windows is the reference operating system for most personal computer
manufacturers, whether we like it or not.

Just because Dell is sometimes good at its job doesn't mean everyone
> else is. The reality is that most aren't.
>
> [1]:
> https://press.hp.com/us/en/press-releases/2021/hp-powers-real-time-collaboration-workflows.html
>
>
>
> --
> 真実はいつも一つ！/ Always, there's only one truth!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it:

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Fri, Apr 08, 2022 at 02:39:04PM -0400, Robbie Harwood wrote:
> Michel Alexandre Salim  writes:
> 
> > - as I stated, there are offers to help with getting syslinux replaced
> >   with GRUB
> 
> More generally, I'm concerned that folks think this'll help a lot more
> than it actually will.  There's a tendency to think in terms of packages
> - they're contained units and therefore convenient to reason about.  But
> just being in a container is not an indication of complexity or size.
> The obligatory example of this that is (I hope) generally understood is
> the kernel.  One source package, wildly different complexity than
> anything else - to the point where it's more meaningful to talk about
> the workflows enabled, subsystems, etc. than the rpms themselves.  I've
> mentioned this upthread as well, but this is the nature of the problem:
> it's not about *packages*, it's about *use case*.
> 

Right, not saying this is a viable long-term solution. But having
everything being GRUB, *plus* using protective MBR, would allow us to
not force people to reinstall when we finally kill off legacy BIOS.

* yes, we still need to figure out how to convert existing systems to
* protective MBR plus GPT, but at least we won't be creating new legacy
* installs that will require reinstallation

Best,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

Michel Alexandre Salim  writes:

> - as I stated, there are offers to help with getting syslinux replaced
>   with GRUB

More generally, I'm concerned that folks think this'll help a lot more
than it actually will.  There's a tendency to think in terms of packages
- they're contained units and therefore convenient to reason about.  But
just being in a container is not an indication of complexity or size.
The obligatory example of this that is (I hope) generally understood is
the kernel.  One source package, wildly different complexity than
anything else - to the point where it's more meaningful to talk about
the workflows enabled, subsystems, etc. than the rpms themselves.  I've
mentioned this upthread as well, but this is the nature of the problem:
it's not about *packages*, it's about *use case*.

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-08 Thread Samuel Sieb


On 4/8/22 08:46, Jared Dominguez wrote:
On Thu, Apr 7, 2022, 19:46 Samuel Sieb > wrote:

This is not comparable to the 32-bit removal where it
was only a few really old systems.  This is going to affect decent
systems that are less than 10 years old.  I have a work HP laptop from
2012 that has "experimental" EFI support that really doesn't work well
and possibly a newer one as well, but I can't check it right now.


I'm curious if you've updated your BIOS on that system. If it's really 
that bad, Microsoft (and HP customers) would have been on HP's case 
about fixing a bad user experience.


It was never intended to run as a UEFI system.  The support is clearly 
marked as "experimental" in the BIOS settings.  (And yes, I updated the 
BIOS.)  That was my point.  This is not an old, outdated system, but it 
doesn't have real UEFI support.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Fri, Apr 08, 2022 at 10:14:19PM +0800, Zamir SUN wrote:
> 
> 
> Probably it isn't a problem for some users, but I'm still having bad
> experience with UEFI on x86_64 now. Out of my 3 machines I only have 1
> system that works fine with UEFI. And my parents' laptop was purchased 2
> years ago and the UEFI firmware does not allow to boot anything other than
> Windows on UEFI mode (regardless of turning secure boot on or off) and I
> have to switch to BIOS mode to make Fedora work there. So in this situation,
> I think it's way too aggressive to accept the change - this will probably
> drive away some potential new users with decent laptop like my parents'.
> 
I've encountered one such laptop - turning off secure boot was not
enough, there's another option somewhere else for disabling key
verification (IIRC).

I agree that this means dropping legacy BIOS is premature, and we should
focus more on future-proofing our installations to make the transition
easier in the future.

Cheers,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-08 Thread Thomas Schmitt

Hi,

i'm the developer of xorriso. Please CC me with replies just in case
that i unsubscribe because of too much traffic.

Further: Sorry for my reply-id pointing to the predecessor of the message
which i quote. I found it at
  https://www.spinics.net/lists/fedora-devel/msg299915.html

Chris Murphy wrote:
> For what it's worth, the current xorriso command used [...] is
>
> xorrisofs -o /var/tmp/lmc-work-hrb6zq5j/images/boot.iso
> -isohybrid-mbr /usr/share/syslinux/isohdpfx.bin
> -b isolinux/isolinux.bin
> -c isolinux/boot.cat
> -boot-load-size 4 -boot-info-table -no-emul-boot
> -eltorito-alt-boot
> -e images/efiboot.img -no-emul-boot -isohybrid-gpt-basdat
> -eltorito-alt-boot
> -e images/macboot.img -no-emul-boot -isohybrid-gpt-hfsplus
> -R -J -V Fedora-WS-Live-36-20220407-n-0
> -graft-points
> [... various files and directories grafted in ...]
>
> There's a bit to unpack there...

The lines, which will need changes for using GRUB, are at least:

  -isohybrid-mbr /usr/share/syslinux/isohdpfx.bin
  [...]
  -boot-load-size 4 -boot-info-table -no-emul-boot
  -b isolinux/isolinux.bin

grub-mkrescue (on Debian) uses instead:

  --grub2-mbr /usr/lib/grub/i386-pc/boot_hybrid.img
  -b boot/grub/i386-pc/eltorito.img
 -no-emul-boot -boot-load-size 4 -boot-info-table --grub2-boot-info

/usr/lib/grub/i386-pc/boot_hybrid.img is part of Debian's grub-pc-bin
package. It gets built by upstream file grub-core/Makefile.core

https://sources.debian.org/src/grub2/2.06-2/grub-core/Makefile.core.am/?hl=23370#L23370

/boot/grub/i386-pc/eltorito.img has to be inserted as data file into
the emerging ISO 9660 filesystem. grub-mkrescue puts it into the
file tree on hard disk which it then gives to xorrisofs as input file.
It gets produced by GRUB from a file named "cdboot.img". In Debian it
is part of package grub-pc-bin as
  /usr/lib/grub/i386-pc/cdboot.img
It does not appear as if the read-in cdboot.img would get modified before
it gets written back as "eltorito.img":
  https://sources.debian.org/src/grub2/2.06-2/util/mkimage.c/?hl=1271#L1266
Its production/copying gets ordered in:
  https://sources.debian.org/src/grub2/2.06-2/util/grub-mkrescue.c/?hl=598#L584

The emerging GRUB MBR is supposed to boot from USB sticks quite like the
ISOLINUX MBR. Both hop with their execution onto the El Torito boot
images for BIOS.

grub-mkrescue uses no option -c, which does not matter for boot success.
Fedora can well keep its

  -c isolinux/boot.cat

The EFI-related options -isohybrid-gpt-basdat and -isohybrid-gpt-hfsplus
will continue to work, if additionally option

  -part_like_isohybrid

is given (once is enough).

More unsolicited info:

An opportunity to watch grub-mkrescue's xorriso options is given by
the script
  frontend/grub-mkrescue-sed.sh
from the source tarball of xorriso (which in Fedora is libisoburn-*.tar.gz):

https://dev.lovelyhq.com/libburnia/libisoburn/raw/branch/master/frontend/grub-mkrescue-sed.sh

I derived above BIOS proposal by

  mkdir minimal
  touch minimal/empty-file.txt
  export MKRESCUE_SED_DEBUG=yes
  grub-mkrescue -o output.iso minimal \
--xorriso=/...localpath.../frontend/grub-mkrescue-sed.sh

If i install (on Debian)
  grub-common grub-pc-bin grub-efi-amd64-bin grub-efi-ia32-bin
i get from grub-mkrescue an ISO with both, BIOS and EFI equipment.

The original purpose of the script grub-mkrescue-sed.sh is to enable
variations of the xorriso options to create different layouts of partition
tables for the EFI stuff. See "Variation settings" in the script.
The main drawback of grub-mkrescue's original partition layout is that
there is no mountable partition for the ISO 9660 filesystem.
For Fedora's ISOs it might be interesting to inspect the messages and
the resulting ISO of

  export MKRESCUE_SED_MODE=mjg
  export MKRESCUE_SED_DEBUG=yes
  grub-mkrescue -o output.iso minimal \
--xorriso=/...localpath.../frontend/grub-mkrescue-sed.sh

It produces a layout that is inspired by mjg59's from 2012, but avoids
to have the EFI partition inside the ISO 9660 filesystem and its partition
by appending the EFI partition.
(The HFS+ filesystem for Macs gets produced by libisofs. It would be
interesting to learn whether such Macs still exist and work with the
grub-mkrescue ISO.)

Discussions with other distro's ISO maintainers and their users yielded
that some old BIOS machines demand an MBR partition with "boot/active"
flag. Some new EFIs demand the presence of a GPT. So ye olde nested
pseudo-GPT partition layout of Fedora (and also of Debian) still has
its merits.
Just the nesting is ugly, unneeded, and causes protests from partition
editors.

With original grub-mkrescue layout and its pure GPT, the remedy is to use
xorrisofs option --mbr-force-bootable which makes the GPT a bit less pure
by adding a little dummy MBR partition of type 0x00.

Have a nice day :)

Thomas

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

Michel Alexandre Salim  writes:

> - as I stated, there are offers to help with getting syslinux replaced
>   with GRUB. what I've not stated originally is Chris Murphy brought up
>   protective MBR and switching all new installs to inst.gpt, which let
>   us future proof new installations for when we do kill off legacy BIOS.
>
> What people who want to help needs, though, is some sense that our
> contributions are welcome.

(If you're looking for me to comment on proposals to change live media
generation and installs, I can't really do that - that's Brian's and
Jiri's areas of expertise.)

> - Neal pointed out he has been working on addressing this for a while,
>   and have not put up a Change Proposal because he thought it was
>   premature

While Neal's contributions are as welcome as anyone else's, Neal is not
a maintainer of (or regular contributor to) bootloader packages and it
would be very strange for Neal to propose such a change without
discussing it with us first.  That said, if there was suggestion of such
a proposal, I have missed it (which is very possible given the size of
the thread at this point).

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Fri, Apr 08, 2022 at 12:41:22PM -0400, Robbie Harwood wrote:
> Michel Alexandre Salim  writes:
> 
> > I sympathize with the change owners' position that detractors need
> > to assume their good intentions, but I feel like the same needs to be
> > assumed for community contributions,
> 
> That's not really a "position" so much as a restatement of the Fedora
> Project's code of conduct.  If you feel that our comportment is not up
> to snuff, please provide specific feedback so we can improve.
> (Otherwise, a statement like that just comes across as propagating FUD.)
> 
Apologies if this came across that way, I'm actually trying to calm
waters here. I'm rather surprised I came across as propagating FUD...

As for specifics:
- my general impression from reading this thread is this Change as
  originally written is too aggressive in its timeline, and too
  optimistic in assuming hardware, esp on the server side, is ready
- let's ignore the unfortunate dispute over the "PR was disabled" issue,
  I think that was a red herring
- as I stated, there are offers to help with getting syslinux replaced
  with GRUB. what I've not stated originally is Chris Murphy brought up
  protective MBR and switching all new installs to inst.gpt, which let
  us future proof new installations for when we do kill off legacy BIOS.

What people who want to help needs, though, is some sense that our
contributions are welcome. I've been at the receiving end of being
FUD-ed as having a 'hidden agenda', so I know how that feels, and I'm
definitely not trying to do that.

What I'm trying to point out is that the perceived lack of contribution
should not really be used as a reason to push this change right now:

- Neal pointed out he has been working on addressing this for a while,
  and have not put up a Change Proposal because he thought it was
  premature
- if the Change Proposal becomes "we can't support legacy BIOS long
  term, it's deprecated, community contributions welcome to help define
  the timeline and milestones" - that would probably get more people
  contributing rather than "this is our really fast timeline to
  deprecate this". Plus as many have stated, immediately breaking new
  installation is not deprecation, so I feel all subsequent discussion
  has been unfortunately tainted by that


Best regards,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Fri, Apr 8, 2022 at 1:50 PM Hans de Goede  wrote:
>
> Hi Brian,
>
> On 4/8/22 19:14, Brian C. Lane wrote:
>
> 
>
> > So like I said yesterday, I'll look into switching to use grub2 for
> > Fedora 37, assuming grub2 continues to support BIOS.
>
> Thank you for looking into switching to using GRUB for the livecds.
>
> If you have some test livecd img using grub instead of syslinux
> for BIOS booting and you wanted it tested on some more / older
> hw let me know and I'll test it on the BIOS-only machines which
> I have.
>

I've got one or two of them around here somewhere too if you need testing. :)


-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-08 Thread Hans de Goede

Hi Brian,

On 4/8/22 19:14, Brian C. Lane wrote:



> So like I said yesterday, I'll look into switching to use grub2 for
> Fedora 37, assuming grub2 continues to support BIOS.

Thank you for looking into switching to using GRUB for the livecds.

If you have some test livecd img using grub instead of syslinux
for BIOS booting and you wanted it tested on some more / older
hw let me know and I'll test it on the BIOS-only machines which
I have.

Regards,

Hans
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-08 Thread Chris Murphy

On Fri, Apr 8, 2022 at 11:14 AM Brian C. Lane  wrote:

> The reason I wrote the PR was because, as I understand it, syslinux is
> going away soon. It was an easy patch to write, and I find it easier to
> discuss things when there is code present (or absent as in this case).
>
> My *personal* opinion is we should not drop BIOS. I think BIOS will
> continue to haunt use for the forseeable future, there is just too much
> existing hardware that still works. But if the tools used to make it
> work aren't present I have to remove them.
>
> So like I said yesterday, I'll look into switching to use grub2 for
> Fedora 37, assuming grub2 continues to support BIOS.

If switching from syslinux to GRUB isn't onerous, it's essentially an
invisible change, i.e. new installations to BIOS systems is still
possible. But also, it would give some breathing room to evaluate BIOS
GRUB as a going-concern, versus clover. If we're looking at something
like 2-3 years of BIOS support, that might favor sticking it out with
BIOS GRUB. If it's much longer, that might favor using a UEFI emulator
on BIOS systems to bring them forward.

What about all the MBR handling in the installer? The change proposal
doesn't mention it. But if the ability to install to BIOS systems were
to go away, that would presumably take MBR with it. So I'm wondering
if it's viable to use BIOS GRUB instead of syslinux, should inst.gpt
become the default? And then would inst.mbr go away? Or would it stick
around for another cycle or two as a manual fallback? Or is it simple
and static enough that it'll persist for a long time without rotting?

Hindsight being 20/20 I kinda wonder if we should have just bit the
bullet on inst.gpt, because at least inst.mbr has been available this
whole time.

-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-08 Thread Brian C. Lane

On Fri, Apr 08, 2022 at 06:46:30AM +0200, Kevin Kofler via devel wrote:
> Neal Gompa wrote:
> > The pull request to delete the code for BIOS support in lorax means
> > that we can't produce media with BIOS support at all once that's
> > merged. They've tied dropping syslinux to dropping BIOS support
> > entirely. It is also unclear that they'd take a contribution to rewire
> > lorax to produce media with BIOS support using GRUB like we do for
> > UEFI.
> 
> So the change is actually already being implemented without approval? This 
> kind of forcing facts turns the whole change policy to the absurd.

No. It's just a PR, and actually it's currently in Draft state to
indicate that it isn't ready to be merged. If I merge it without
approval from the community then you can yell at me :)

> As I understand it, dropping support in Lorax affects both livemedia-creator 
> and livecd-creator, so the only way forward to build ISOs that actually boot 
> would be to fork Lorax. Unless we can reuse some other distro's tools 
> instead.

This does not effect livecd-creator, that is a totally separate project
that I am no longer involved with. It would effect lorax built boot.iso
and live iso's created with livemedia-creator. Possibly also the DVD's
built by pungi.

The reason I wrote the PR was because, as I understand it, syslinux is
going away soon. It was an easy patch to write, and I find it easier to
discuss things when there is code present (or absent as in this case).

My *personal* opinion is we should not drop BIOS. I think BIOS will
continue to haunt use for the forseeable future, there is just too much
existing hardware that still works. But if the tools used to make it
work aren't present I have to remove them.

So like I said yesterday, I'll look into switching to use grub2 for
Fedora 37, assuming grub2 continues to support BIOS.

Brian

-- 
Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Fri, Apr 8, 2022 at 12:41 PM Robbie Harwood  wrote:
>
> Michel Alexandre Salim  writes:
>
> > Would using Grub for legacy boot be more, or less work than continuing
> > to support syslinux, assuming people step up to do the development and
> > validation?
>
> syslinux is by default only used on the live media.  Legacy installs
> today provision grub2.  So moving them to live media would probably be
> less, but it won't solve the overall problem.
>

SYSLINUX is also used for PXE and a number of other boot methods in
BIOS. The main deliverable we use it for is live media, but there are
other things too. Most of that is thankfully documentation on how to
use GRUB for the same thing.




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

Michel Alexandre Salim  writes:

> Would using Grub for legacy boot be more, or less work than continuing
> to support syslinux, assuming people step up to do the development and
> validation?

syslinux is by default only used on the live media.  Legacy installs
today provision grub2.  So moving them to live media would probably be
less, but it won't solve the overall problem.

> I sympathize with the change owners' position that detractors need
> to assume their good intentions, but I feel like the same needs to be
> assumed for community contributions,

That's not really a "position" so much as a restatement of the Fedora
Project's code of conduct.  If you feel that our comportment is not up
to snuff, please provide specific feedback so we can improve.
(Otherwise, a statement like that just comes across as propagating FUD.)

Be well,
--Robbie

signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Fri, Apr 08, 2022 at 11:46:50AM -0400, Jared Dominguez wrote:
> On Thu, Apr 7, 2022, 19:46 Samuel Sieb  wrote:
> 
> > I don't understand why we're still using syslinux instead of grub for
> > legacy boots, especially since I think now you can use the same grub.cfg
> > file for both.
> 
> 
> It's development and validation work for something that's not a priority
> for those who are doing bootloader work, and no one else has stepped up to
> put in the time to do this work. The change proposal being discussed in
> this thread is calling for community contributors.
> 
Would using Grub for legacy boot be more, or less work than continuing
to support syslinux, assuming people step up to do the development and
validation?

As someone who is also interested in eventually phasing out legacy BIOS
support, but think it's too early, I sense that this is a better way to
deprecate - first future proof the legacy installations in such a way
that at some future time you can simply upgrade the system, switch to
UEFI and keep your system disk - is a much better transition for our
users.

*and* I have been hearing from people who are interested in doing this
work. I sympathize with the change owners' position that detractors need
to assume their good intentions, but I feel like the same needs to be
assumed for community contributions, and we've unfortunately been
talking past each other a bit in this thread.

Best regards,

-- 
Michel Alexandre Salim
identities: https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Fri, Apr 8, 2022 at 11:47 AM Jared Dominguez  wrote:
>
>
>
>
> On Thu, Apr 7, 2022, 19:46 Samuel Sieb  wrote:
>>
>> On 4/7/22 14:51, Jared Dominguez wrote:
>> > On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb > > > wrote:
>> >
>> > On 4/7/22 08:02, Jared Dominguez wrote:
>> >  > This is a proposal. Nothing has changed yet. The choice is now
>> > whether
>> >  > to go forward with it or come together with a cohesive
>> >  > alternative, including one of the two listed in the proposal. But we
>> >  > need a solution that accounts for the existing maintainers not
>> > having
>> >  > capacity to continue maintaining legacy code. I've seen responses
>> > from
>> >
>> > I haven't yet seen a clear answer about what code is "rotting" and
>> > which
>> > legacy code is too hard to maintain.  Is there something actually
>> > broken
>> > right now?
>> >
>> >
>> > For one, syslinux hasn't seen an update in 3 years and a release in 7
>> > years, and it has outstanding bugs. Legacy boot isn't where grub2 is
>> > getting development attention. The current maintainers in Fedora won't
>> > have capacity to continue maintaining legacy boot support in Fedora. As
>> > grub2 continues to be developed for UEFI systems (ARMv8-9 and x86-64,
>> > not to mention non-UEFI ppc64le and s390x), there is added risk of
>> > regressions on legacy x86 boot that won't be getting developer attention.
>>
>> I don't understand why we're still using syslinux instead of grub for
>> legacy boots, especially since I think now you can use the same grub.cfg
>> file for both.
>
>
> It's development and validation work for something that's not a priority for 
> those who are doing bootloader work, and no one else has stepped up to put in 
> the time to do this work. The change proposal being discussed in this thread 
> is calling for community contributors.
>
>> There is always a risk of regressions, but if there is
>> no current problem, then why is there this push to obsolete a lot of
>> active hardware?
>
>
> There is a problem: the current maintainers don't have capacity to support 
> legacy x86 boot anymore. The code is going to bit rot if no one steps up to 
> fill in.
>
>> This is not comparable to the 32-bit removal where it
>> was only a few really old systems.  This is going to affect decent
>> systems that are less than 10 years old.  I have a work HP laptop from
>> 2012 that has "experimental" EFI support that really doesn't work well
>> and possibly a newer one as well, but I can't check it right now.
>
>
> I'm curious if you've updated your BIOS on that system. If it's really that 
> bad, Microsoft (and HP customers) would have been on HP's case about fixing a 
> bad user experience.
>

Why? It works for Windows, and HP has only done token support for
other platforms over the past decade (see most recent thing promoting
WSL as a good Linux on HP experience[1]). All of my HP computers have
been extremely difficult to get Linux working on properly, which is
why I stopped buying them.

Just because Dell is sometimes good at its job doesn't mean everyone
else is. The reality is that most aren't.

[1]: 
https://press.hp.com/us/en/press-releases/2021/hp-powers-real-time-collaboration-workflows.html



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-08 Thread Jared Dominguez

On Thu, Apr 7, 2022, 19:46 Samuel Sieb  wrote:

> On 4/7/22 14:51, Jared Dominguez wrote:
> > On Thu, Apr 7, 2022 at 3:49 PM Samuel Sieb  > > wrote:
> >
> > On 4/7/22 08:02, Jared Dominguez wrote:
> >  > This is a proposal. Nothing has changed yet. The choice is now
> > whether
> >  > to go forward with it or come together with a cohesive
> >  > alternative, including one of the two listed in the proposal. But
> we
> >  > need a solution that accounts for the existing maintainers not
> > having
> >  > capacity to continue maintaining legacy code. I've seen responses
> > from
> >
> > I haven't yet seen a clear answer about what code is "rotting" and
> > which
> > legacy code is too hard to maintain.  Is there something actually
> > broken
> > right now?
> >
> >
> > For one, syslinux hasn't seen an update in 3 years and a release in 7
> > years, and it has outstanding bugs. Legacy boot isn't where grub2 is
> > getting development attention. The current maintainers in Fedora won't
> > have capacity to continue maintaining legacy boot support in Fedora. As
> > grub2 continues to be developed for UEFI systems (ARMv8-9 and x86-64,
> > not to mention non-UEFI ppc64le and s390x), there is added risk of
> > regressions on legacy x86 boot that won't be getting developer attention.
>
> I don't understand why we're still using syslinux instead of grub for
> legacy boots, especially since I think now you can use the same grub.cfg
> file for both.


It's development and validation work for something that's not a priority
for those who are doing bootloader work, and no one else has stepped up to
put in the time to do this work. The change proposal being discussed in
this thread is calling for community contributors.

There is always a risk of regressions, but if there is
> no current problem, then why is there this push to obsolete a lot of
> active hardware?


There is a problem: the current maintainers don't have capacity to support
legacy x86 boot anymore. The code is going to bit rot if no one steps up to
fill in.

This is not comparable to the 32-bit removal where it
> was only a few really old systems.  This is going to affect decent
> systems that are less than 10 years old.  I have a work HP laptop from
> 2012 that has "experimental" EFI support that really doesn't work well
> and possibly a newer one as well, but I can't check it right now.
>

I'm curious if you've updated your BIOS on that system. If it's really that
bad, Microsoft (and HP customers) would have been on HP's case about fixing
a bad user experience.

___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-08 Thread Jared Dominguez

On Fri, Apr 8, 2022, 00:48 Kevin Kofler via devel <
devel@lists.fedoraproject.org> wrote:

> Neal Gompa wrote:
> > The pull request to delete the code for BIOS support in lorax means
> > that we can't produce media with BIOS support at all once that's
> > merged. They've tied dropping syslinux to dropping BIOS support
> > entirely. It is also unclear that they'd take a contribution to rewire
> > lorax to produce media with BIOS support using GRUB like we do for
> > UEFI.
>

Neal, the change proposal already made it clear that this isn't just about
syslinux, and this fact has been discussed over and over. Your speculation
here and earlier in this thread on what would and would not be accepted
just reads to me as inflammatory, especially when the ones actually doing
development here have shown a clear willingness both in this thread and
explicitly in the change proposal for collaboration and help with
development.

So the change is actually already being implemented without approval? This
> kind of forcing facts turns the whole change policy to the absurd.
>

An _unmerged_ pull request still in review that's tied to this change
_proposal_.

As I understand it, dropping support in Lorax affects both
> livemedia-creator
> and livecd-creator, so the only way forward to build ISOs that actually
> boot
> would be to fork Lorax. Unless we can reuse some other distro's tools
> instead.
>
> The liveinst part of Anaconda can be replaced with Calamares, but ISO
> composing (which can be done with (livemedia-creator) or without Anaconda
> (livecd-creator), but both code paths end up in Lorax eventually) is not
> in
> the scope of Calamares.
>
> Kevin Kofler
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-08 Thread Vít Ondruch



Dne 08. 04. 22 v 6:46 Kevin Kofler via devel napsal(a):

Neal Gompa wrote:

The pull request to delete the code for BIOS support in lorax means
that we can't produce media with BIOS support at all once that's
merged. They've tied dropping syslinux to dropping BIOS support
entirely. It is also unclear that they'd take a contribution to rewire
lorax to produce media with BIOS support using GRUB like we do for
UEFI.

So the change is actually already being implemented without approval?



Having implementation ready for approval is +, isn't it?



  This
kind of forcing facts turns the whole change policy to the absurd.



But it also needs to be merged first to have any real effect. The PR is 
in the change proposal.



Vít




As I understand it, dropping support in Lorax affects both livemedia-creator
and livecd-creator, so the only way forward to build ISOs that actually boot
would be to fork Lorax. Unless we can reuse some other distro's tools
instead.

The liveinst part of Anaconda can be replaced with Calamares, but ISO
composing (which can be done with (livemedia-creator) or without Anaconda
(livecd-creator), but both code paths end up in Lorax eventually) is not in
the scope of Calamares.

 Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-08 Thread Zamir SUN

On 4/5/22 22:52, Ben Cotton wrote:

https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS

== Summary ==
Make UEFI a hardware requirement for new Fedora installations on
platforms that support it (x86_64). Legacy BIOS support is not
removed, but new non-UEFI installation is not supported on those
platforms. This is a first step toward eventually removing legacy
BIOS support entirely.

== Owner ==
* Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
Konečný]], [[User:bcl| Brian C. Lane]]
* Email: rharw...@redhat.com

== Detailed Description ==
UEFI is defined by a versioned standard that can be tested and
certified against. By contrast, every legacy BIOS is unique. Legacy
BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
and on its way out. As it ages, maintainability has decreased, and

Probably it isn't a problem for some users, but I'm still having bad
experience with UEFI on x86_64 now. Out of my 3 machines I only have 1
system that works fine with UEFI. And my parents' laptop was purchased 2
years ago and the UEFI firmware does not allow to boot anything other
than Windows on UEFI mode (regardless of turning secure boot on or off)
and I have to switch to BIOS mode to make Fedora work there. So in this
situation, I think it's way too aggressive to accept the change - this
will probably drive away some potential new users with decent laptop
like my parents'.

the status quo of maintaining both stacks in perpetuity is not viable
for those currently doing that work.

It is inevitable that legacy BIOS will be removed in a future release.
To ease this transition as best we can, there will be a period (of at
least one Fedora release) where it will be possible to boot using the
legacy BIOS codepaths, but new installations will not be possible.
While it would be easier for us to cut support off today, our hope is
that this compromise position will make for a smoother transition.
Additional support with issues during the transition would be
appreciated.

While this will eventually reduce workload for boot/installation
components (grub2 reduces surface area, syslinux goes away entirely,
anaconda reduces surface area), the reduction in support burden
extends much further into the stack - for instance, VESA support can
be removed from the distro.

Fedora already requires a 2GHz dual core CPU at minimum (and therefore
mandates that machines must have been made after 2006). Like the
already accepted Fedora 37 change to retire ARMv7 support, the

I know ARMv7 is irrelevant here, but I feel ARMv7 never use BIOS in Fedora.

The dropping of ARMv7 support already renders most of my ARM devices
unable to use new Fedora, which is a great pain and I have to switch to
something else if I need to reinstall in the future. Similarly, if we
drive BIOS users out of fresh installation, we have even more
possibility of attracting less new users, which I feel isn't what
Fedoraproject want to see.

hardware targeted tends to be rather underpowered by today’s
standards, and the world has moved on from it. Intel stopped shipping
the last vestiges of BIOS support in 2020 (as have other vendors, and
Apple and Microsoft), so this is clearly the way things are heading -
and therefore aligns with Fedora’s “First” objective.

== Feedback ==
Dropping legacy BIOS was previously discussed (but not proposed) in 2020:
https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.org/thread/QBANCA2UAJ5ZSMDVVARLIYAJE66TYTCD/

Important, relevant points from that thread (yes, I reread the entire
thread) that have informed this change:

* Some machines are BIOS-only. This change does not prevent their use
yet, but they are effectively deprecated. grub2 (our default
bootloader) is already capable of both BIOS and UEFI booting.
* Drawing a clear year cutoff, let alone a detailed list of hardware
this change affects, is basically impossible. This is unfortunate but
unlikely to ever change.
* There is no migration story from Legacy BIOS to UEFI -
repartitioning effectively mandates a reinstall. As a result, we
don’t drop support for existing Legacy BIOS systems yet, just new
installations.
* There is no way to deprecate hardware without causing some amount of friction.
* While at the time AWS did not support UEFI booting, that is no
longer the case and they support UEFI today.

== Benefit to Fedora ==
UEFI is required for many desirable features, including applying
firmware updates (fwupd) and supporting SecureBoot. As a standalone
change, it reduces support burden on everything involved in installing
Fedora, since there becomes only one way to do it per platform.
Finally, it simplifies our install/live media, since it too only has
to boot one way per arch. Freedom Friends Features First - this is
that last one.

== Scope ==
* Proposal owners:
** bootloaders: No change (existing Legacy BIOS installations still supported).
** anaconda: No change (there could be only optional

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

Vitaly Zaitsev via devel  writes:

> On 07/04/2022 18:10, Robbie Harwood wrote:
>
>> While we do maintain a large set of patches downstream, due to upstream
>> being inactive for a while, today upstream is alive and very much not
>> abandoned:
>
> Why not upstream all those patches then?

I resent the implication that I'm not doing that.

The idea that one would show up with a decent-sized pile of patches and
have an upstream merge them immediately sits somewhere between "naïve"
and "a reason to vote no-confidence in upstream".

Be well,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Fri, Apr 8, 2022 at 8:07 AM Vitaly Zaitsev via devel
 wrote:
>
> On 07/04/2022 18:10, Robbie Harwood wrote:
> > While we do maintain a large set of patches downstream, due to upstream
> > being inactive for a while, today upstream is alive and very much not
> > abandoned:
>
> Why not upstream all those patches then?
>

It's not quite that simple. There are currently 214 patches on
GRUB[1]. Some of those are backports of reviewed and merged patches,
but a large chunk of them are feature development patches that are
either in review or haven't been submitted because dependent patches
are in review. Patch review is long, slow, and complex. It's even more
so for GRUB. Top that with there being only one major committer for
the upstream project right now (Daniel Kiper). I'm not fully aware of
the dynamics of the GRUB project, so I don't know the reason for the
lack of other committers. But needless to say, I know that Daniel
considers it a top priority to eliminate the Red Hat GRUB fork by
incorporating its changes into mainline because a large number of
distributions use it instead of upstream due to the lack of
responsiveness, feature development, and fixes present in the upstream
code.

However, taking it all in wholesale without review is crazy because
then nobody else knows how the code was developed and if it should go
in as-is. That said, my personal opinion is that a couple of the folks
who work on RH GRUB should be part of the project leadership in
upstream GRUB and have commit access to maintain and manage this. That
may already be in place, but I don't know for sure.

[1]: 
https://src.fedoraproject.org/rpms/grub2/tree/d17f80cfd556d8a582756ee393361f6d203f2d77

--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-08 Thread Vitaly Zaitsev via devel


On 07/04/2022 18:10, Robbie Harwood wrote:

While we do maintain a large set of patches downstream, due to upstream
being inactive for a while, today upstream is alive and very much not
abandoned:


Why not upstream all those patches then?

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-08 Thread Vitaly Zaitsev via devel


On 07/04/2022 22:04, Demi Marie Obenour wrote:

*Virtual*  hardware is another matter entirely.


All popular hypervisors (KVM/qemu, VirtualBox and VMWare) have full UEFI 
boot support.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-08 Thread Vitaly Zaitsev via devel


On 08/04/2022 09:54, Dominik 'Rathann' Mierzejewski wrote:

I already did. Isn't that what I wrote?


Can you post their answer?

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

2022-04-08 Thread Ralf Corsépius




Am 07.04.22 um 18:14 schrieb Robbie Harwood:

Robert Marcano via devel  writes:


Is this change only related to install media support for booting with
BIOS only? Would I be able to install newer Fedora releases using Legacy
PXE on BIOS only machines?


The intent is to indicate that new legacy installations are not
supported, regardless of how one gets there.  Mechanically, there are
few ways to actually *prevent* these installations[1] - rather, we send
a message that this is on its way out (i.e., deprecated) and that it's
time for users to consider migrating their setups.

So the direct answer is: yes, probably, if you're willing to work at it
hard enough.  But it wouldn't be supported.


Your answer once more confirms my impression on Red Hat's current role 
in Fedora: Red Hat is abusing Fedora is not willing to contribute to the 
community and is striving to get rid of the community (similar to RHAT's 
management faults wrt. CentOS)


That said, should this change happen, I will probably drop using und 
supporting fedora and switch to a different flavor of Linux. It's 
apparently what RHAT wants.


Ralf
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Thursday, 07 April 2022 at 18:42, Robbie Harwood wrote:
> Michael Catanzaro  writes:
> 
> > On Wed, Apr 6 2022 at 03:35:38 PM -0400, Jared Dominguez 
> >  wrote:
> >> This seems like a strong assumption to me considering that aside from 
> >> the largest cloud providers (with whom Red Hat is directly working 
> >> with on UEFI boot features and bug reports), cloud providers are 
> >> using off-the-shelf hypervisors that support UEFI boot.
> >
> > I'm going to ask the proposal authors to at least mention this as a 
> > risk in the Feedback section of the change proposal. Maybe cloud 
> > providers will all see this as a good opportunity to enable UEFI on 
> > their platforms, and we'll be perfectly fine. I rather suspect it's not 
> > going to happen quite so smoothly, though
> 
> I have appended added my analysis of this to the Feedback section.  For
> clarity, it's copied here:
> 
> During mailing list discussion of this change, concern was expressed
> that some of the smaller hosting providers who do not provision with
> UEFI today and do not also support Windows would drop Fedora rather
> than enabling UEFI.  Given that the major virtualization solutions
> (vsphere, kvm, xen, bhve, virtualbox, ...) all support UEFI today,

...latest versions of... And the provider in question might not be
running the latest version.

> this would likely be exposing an existing capability rather than
> making a sweeping change.

It's equally likely that they'd have to upgrade their virtualization
platform to the latest version first and then update their internal
UI/tooling to expose UEFI. I'd call that a sweeping change while you're
downplaying the scope of it.

> That said, it is always possible that
> providers may elect to drop Fedora rather than adjust their setups -
> be it for this change or any other change Fedora makes.

That's completely unnecessary. It adds nothing but attempt to dilute the
impact of this change.

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Friday, 08 April 2022 at 08:57, Samuel Sieb wrote:
> On 4/7/22 18:54, Neal Gompa wrote:
> > On Thu, Apr 7, 2022 at 9:21 PM Chris Adams  wrote:
> > > 
> > > Once upon a time, Chris Murphy  said:
> > > > syslinux (really isolinux) is only used on installation media.
> > > 
> > > It's commonly used for BIOS PXE booting as well.
> > > 
> > 
> > *shudders at the memories of dealing with pxelinux*
> > 
> > GRUB is way better for that. Yes, you can use GRUB for PXE and UEFI netboot 
> > too.
> 
> That's what I use for both.

Would you care to document your set-ups?

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)

On Friday, 08 April 2022 at 04:37, Gary Buhrmaster wrote:
> On Thu, Apr 7, 2022 at 10:05 PM Matthew Miller  
> wrote:
> >
> > On Thu, Apr 07, 2022 at 03:43:07PM +0100, Richard W.M. Jones wrote:
> > > Clover is described here:
> > > https://github.com/CloverHackyColor/CloverBootloader
> >
> > This is interesting. Seems like considerable up-front work, but a much
> > cleaner possible future than completely dual paths.
> 
> On my (still countably) infinite TODO list I had
> an item on it to spend more time looking at
> Clover to be able to boot (in UEFI mode) one
> of my older BIOS only Core 2 duo quad systems
> that I had picked up for pennies on the dollar
> at a local surplus store.  At this point it is a
> question of whether I will find the time to do
> so or the system itself will finally die.  Since
> the original placement (on my list), the Clover
> devs have substantially improved it to the
> point that a lot of the rough edges have been
> mitigated, although given all the various
> implementations of BIOS's there are still
> going to be edge cased (just as there are
> still rough edges with UEFI, especially the
> earliest implementations).

I'd be willing to lend a hand to adapting Clover on Fedora and testing
booting with it on my 12yo BIOS-only Intel Atom machine.

> > Are there docs on this somewhere other than the Arch wiki? (Which, as usual,
> > is very helpful!) -- https://wiki.archlinux.org/title/Clover
> 
> As is typically the case, the Arch wiki is better
> than almost all other available docs.

Indeed. How do they do it? ;)

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)