11:45 a.m.
https://fedoraproject.org/wiki/Changes/GPTforBIOSbyDefault
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
This Change makes it so that Fedora Linux systems installed on legacy
x86 BIOS systems will get GPT partitioning by default instead of
legacy MBR partitioning. This makes x86 BIOS installs more similar to
x86 UEFI installs.
== Owner ==
* Name: [[User:Ngompa| Neal Gompa]], [[User:Dcavalca| Davide
Cavalca]], [[User:Salimma| Michel Alexandre Salim]],
[[User:Chrismurphy| Chris Murphy]]
* Email: ngompa13(a)gmail.com, dcavalca(a)fb.com, michel(a)michel-slm.name,
chrismurphy(a)fedoraproject.org
== Detailed Description ==
Once implemented, Anaconda will create a GPT disk table on
non-partitioned disks or when the disk is being completely reset when
Fedora x86 install/live media is booted in BIOS mode.
== Benefit to Fedora ==
This simplifies our default code path by using the same partitioning
scheme as UEFI systems and aligns us more to how Fedora variants that
are delivered as disk images, which all use a similar setup. It also
paves the way to implement hybrid BIOS+UEFI boot for legacy BIOS
installs to enable future conversion to UEFI boot or emulated UEFI
boot on legacy BIOS.
This is a step toward a longer transition to eventually eliminate
direct BIOS boot support, as identified in the discussion for
[[Changes/DeprecateLegacyBIOS|the rejected Change to deprecate BIOS
support in Fedora Linux 37]].
== Scope ==
* Proposal owners:
** Submit code changes to Anaconda to use GPT by default on BIOS
systems ([https://github.com/rhinstaller/anaconda/pull/4104
gh#rhinstaller/anaconda#4104])
* Other developers:
** Anaconda developers need to review and merge the pull request
* Release engineering: [https://pagure.io/releng/issue/10796 #10796]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
There will be no impact for existing Fedora Linux systems that
upgrade. We will not convert the partitioning on upgrade. However,
some very old systems have buggy EFI implementations that do not
handle legacy BIOS boot on GPT well, and on those systems, users will
need to request Anaconda to create a legacy MBR partition table by
using <code>inst.mbr</code> on the boot command-line.
== How To Test ==
Currently, users can test by booting Fedora media on BIOS systems with
the <code>inst.gpt</code> option to try installing Fedora Linux on a
legacy BIOS boot system with a GPT disk. After the change is merged
and released, this behavior will be the default, and
<code>inst.mbr</code> would be required to go back to the previous
behavior.
== User Experience ==
In general, there should nothing materially changing for users. If
users look at the disk with <code>fdisk</code> or
<code>parted</code>,
they'll see a GPT disk instead of an MBR one and a BIOS boot partition
will be present, which stores the GRUB boot code on a GPT disk.
== Dependencies ==
This is isolated to Anaconda and is principally dependent on getting
the changes into Anaconda.
== Contingency Plan ==
* Contingency mechanism: Revert the change in upstream Anaconda
* Contingency deadline: Final Freeze
* Blocks release? Yes
== Documentation ==
The upstream documentation will be updated as part of the change in Anaconda.
== Release Notes ==
Fedora Linux now uses GPT (GUID Partition Table) partitioning by
default for x86_64 systems that use legacy BIOS instead of UEFI. This
brings a more modern method of partitioning disks and aligns closer
with UEFI-based installations, which already use GPT partitioning.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
8:24 a.m.
== Benefit to Fedora ==
This simplifies our default code path by using the same partitioning
scheme as UEFI systems and aligns us more to how Fedora variants that
are delivered as disk images, which all use a similar setup. It also
paves the way to implement hybrid BIOS+UEFI boot for legacy BIOS
installs to enable future conversion to UEFI boot or emulated UEFI
boot on legacy BIOS.
Any reasons to not go straight to a hybrid BIOS+UEFI setup? As far
I know anaconda already has support for that as it is needed to build
cloud images, so it probably isn't that difficuilt.
Additional benefit: It is possible to switch between BIOS and UEFI mode
without reinstall.
take care,
Gerd
8:27 a.m.
On Mon, May 16, 2022 at 9:25 AM Gerd Hoffmann <kraxel(a)redhat.com> wrote:
> == Benefit to Fedora ==
> This simplifies our default code path by using the same partitioning
> scheme as UEFI systems and aligns us more to how Fedora variants that
> are delivered as disk images, which all use a similar setup. It also
> paves the way to implement hybrid BIOS+UEFI boot for legacy BIOS
> installs to enable future conversion to UEFI boot or emulated UEFI
> boot on legacy BIOS.
Any reasons to not go straight to a hybrid BIOS+UEFI setup? As far
I know anaconda already has support for that as it is needed to build
cloud images, so it probably isn't that difficuilt.
Additional benefit: It is possible to switch between BIOS and UEFI mode
without reinstall.
I want to, I just don't know how yet to make Anaconda do it for BIOS
installs. I sent an email to Anaconda development mailing list[1]
asking about it. If someone wants to help make it happen, I'd love to
get it done in one go.
[1]:
https://lists.fedoraproject.org/archives/list/anaconda-devel@lists.fedora...
--
真実はいつも一つ！/ Always, there's only one truth!
5:55 a.m.
Am 14.05.2022 um 18:45 schrieb Ben Cotton
<bcotton(a)redhat.com>:
https://fedoraproject.org/wiki/Changes/GPTforBIOSbyDefault
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
This Change makes it so that Fedora Linux systems installed on legacy
x86 BIOS systems will get GPT partitioning by default instead of
legacy MBR partitioning. This makes x86 BIOS installs more similar to
x86 UEFI installs.
== Owner ==
* Name: [[User:Ngompa| Neal Gompa]], [[User:Dcavalca| Davide
Cavalca]], [[User:Salimma| Michel Alexandre Salim]],
[[User:Chrismurphy| Chris Murphy]]
* Email: ngompa13(a)gmail.com, dcavalca(a)fb.com, michel(a)michel-slm.name,
chrismurphy(a)fedoraproject.org
== Detailed Description ==
Once implemented, Anaconda will create a GPT disk table on
non-partitioned disks or when the disk is being completely reset when
Fedora x86 install/live media is booted in BIOS mode.
Fedora Server WG discussed the proposal and insists that the proposal be deferred until
Anaconda can install software raid on biosboot systems with GPT (see
https://bugzilla.redhat.com/show_bug.cgi?id=2088113 and
https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject....)
- at least for Fedora Server where software raid is a common use.
The issue is known to all server WG members at least since F32 and is mentioned in the
server user documentation.
A hybrid boot configuration may be useful for cloud because the same image is to be used
for different runtime environments. For physical servers it is irrelevant and for VMs in
a libvirt virtualization it is completely pointless. It would only introduce an additional
potential source of errors for Fedora servers, without any benefit at all.
9:28 p.m.
On Sun, May 29, 2022 at 6:56 AM Peter Boy <pboy(a)uni-bremen.de> wrote:
> Am 14.05.2022 um 18:45 schrieb Ben Cotton <bcotton(a)redhat.com>:
>
> https://fedoraproject.org/wiki/Changes/GPTforBIOSbyDefault
>
> This document represents a proposed Change. As part of the Changes
> process, proposals are publicly announced in order to receive
> community feedback. This proposal will only be implemented if approved
> by the Fedora Engineering Steering Committee.
>
> == Summary ==
> This Change makes it so that Fedora Linux systems installed on legacy
> x86 BIOS systems will get GPT partitioning by default instead of
> legacy MBR partitioning. This makes x86 BIOS installs more similar to
> x86 UEFI installs.
>
> == Owner ==
> * Name: [[User:Ngompa| Neal Gompa]], [[User:Dcavalca| Davide
> Cavalca]], [[User:Salimma| Michel Alexandre Salim]],
> [[User:Chrismurphy| Chris Murphy]]
> * Email: ngompa13(a)gmail.com, dcavalca(a)fb.com, michel(a)michel-slm.name,
> chrismurphy(a)fedoraproject.org
>
>
> == Detailed Description ==
> Once implemented, Anaconda will create a GPT disk table on
> non-partitioned disks or when the disk is being completely reset when
> Fedora x86 install/live media is booted in BIOS mode.
Fedora Server WG discussed the proposal and insists that the proposal be deferred until
Anaconda can install software raid on biosboot systems with GPT (see
https://bugzilla.redhat.com/show_bug.cgi?id=2088113 and
https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject....)
- at least for Fedora Server where software raid is a common use.
What's the basis for holding up this feature though? Yes it's a bug,
but it wouldn't be a release blocking bug because there's no release
criteria covering degraded boot. And on UEFI we already have this
problem because multiple ESPs aren't created or populated (sync'd). I
think it's a worthwhile use case to improve the current behavior so
that it works, but I don't think it's OK to hold up a release
indefinitely while insisting other people do the work required to
bring such functionality to Fedora.
--
Chris Murphy
2:18 a.m.
Am 30.05.2022 um 04:28 schrieb Chris Murphy
<lists(a)colorremedies.com>:
On Sun, May 29, 2022 at 6:56 AM Peter Boy <pboy(a)uni-bremen.de> wrote:
>
>
>
>
> Fedora Server WG discussed the proposal and insists that the proposal be deferred
until Anaconda can install software raid on biosboot systems with GPT (see
https://bugzilla.redhat.com/show_bug.cgi?id=2088113 and
https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject....)
- at least for Fedora Server where software raid is a common use.
What's the basis for holding up this feature though?
Sorry, under the current circumstances your „feature“ is effectively a regression. It
would make it impossible for many Fedora Server users to continue using Fedora Server as
soon as they have to re-install or just want to set up a new additional server.
And even those who can continue to use Fedora Server via update are under the threat of
having to switch distributions overnight in the event of a technical error. Fedora will
become unusable for them. A great "feature", that you would like to introduce,
obviously at all costs.
Yes it's a bug,
but it wouldn't be a release blocking bug because there's no release
criteria covering degraded boot.
Degraded boot? According to our tests it results in an non-bootable state on physical
servers.
And on UEFI we already have this
problem because multiple ESPs aren't created or populated (sync'd).
And why would we intentionally and deliberately impose this problem on non-UEFI boot
systems, as well?
I
think it's a worthwhile use case to improve the current behavior so
that it works, but I don't think it's OK to hold up a release
indefinitely while insisting other people do the work required to
bring such functionality to Fedora.
Wouldn't it be a better order for our users to solve the problem first and then make
the feature the default?
We have to discuss with the Anaconda team. Maybe they are able to solve it, but need some
time to develop and test ist. What is the problem with introducing the change with F38
instead of (prematurely) with F37?
Maybe, Anaconda can’t fix it. Then we have to find another solution. Maybe we have to give
up on Anaconda for Server and distribute as preinstalled image (like we currently do with
Aarch64) or develop a pre-installation step as on option in the boot screen (like
previously with memtest), or something else that we can't come up with at the moment.
But we have to resolve it ==first==! (and soon)
You have thankfully created a bug report on this and thus opened the discussion about a
solution. We both have known about the problem for more than a year now, when we first
discussed it. We both should have done this earlier (the bug report).
12:20 p.m.
On Mon, May 30, 2022 at 09:18:27AM +0200, Peter Boy wrote:
> Am 30.05.2022 um 04:28 schrieb Chris Murphy <lists(a)colorremedies.com>:
>
> On Sun, May 29, 2022 at 6:56 AM Peter Boy <pboy(a)uni-bremen.de> wrote:
>>
>>
>>
>>
>> Fedora Server WG discussed the proposal and insists that the proposal be
deferred until Anaconda can install software raid on biosboot systems with GPT (see
https://bugzilla.redhat.com/show_bug.cgi?id=2088113 and
https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject....)
- at least for Fedora Server where software raid is a common use.
>
> What's the basis for holding up this feature though?
Sorry, under the current circumstances your „feature“ is effectively a regression. It
would make it impossible for many Fedora Server users to continue using Fedora Server as
soon as they have to re-install or just want to set up a new additional server.
And even those who can continue to use Fedora Server via update are under the threat of
having to switch distributions overnight in the event of a technical error. Fedora will
become unusable for them. A great "feature", that you would like to introduce,
obviously at all costs.
Is 'inst.mbr' a viable workaround? (The bug mentions 'inst.gpt' to trigger
the issue.)
Zbyszek
2:26 p.m.
Am 02.06.2022 um 19:20 schrieb Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl>:
On Mon, May 30, 2022 at 09:18:27AM +0200, Peter Boy wrote:
>
> ...
>
> And even those who can continue to use Fedora Server via update are under the threat
of having to switch distributions overnight in the event of a technical error. Fedora will
become unusable for them. A great "feature", that you would like to introduce,
obviously at all costs.
Is 'inst.mbr' a viable workaround? (The bug mentions 'inst.gpt' to
trigger the issue.)
According to the latest Anaconda documentation [1] there is no option inst.mbr, there is
just inst.gpt. Maybe, it is an undocumented feature.
And do we really want our users to fiddle around with editing boot line options as a
standard procedure for using a standard use case?
[1] https://anaconda-installer.readthedocs.io/en/latest/boot-options.html
3:42 p.m.
On Thu, Jun 2, 2022 at 9:27 PM Peter Boy <pboy(a)uni-bremen.de> wrote:
> Am 02.06.2022 um 19:20 schrieb Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl>:
>
> On Mon, May 30, 2022 at 09:18:27AM +0200, Peter Boy wrote:
>>
>> ...
>>
>> And even those who can continue to use Fedora Server via update are under the
threat of having to switch distributions overnight in the event of a technical error.
Fedora will become unusable for them. A great "feature", that you would like to
introduce, obviously at all costs.
>
> Is 'inst.mbr' a viable workaround? (The bug mentions 'inst.gpt' to
trigger the issue.)
According to the latest Anaconda documentation [1] there is no option inst.mbr, there is
just inst.gpt. Maybe, it is an undocumented feature.
It's going to replace inst.gpt. This is described in the Change document.
And do we really want our users to fiddle around with editing boot
line options as a standard procedure for using a standard use case?
It's not standard at all. We don't even test for this setup regularly.
It's not a test case, and it's not even supposed to work right now.
Also, any system with drives >=2TB will get GPT automatically, you
can't have MBR in those setups. All this does is remove the default
special case for smaller disks.
--
真実はいつも一つ！/ Always, there's only one truth!
5:18 p.m.
Am 02.06.2022 um 22:42 schrieb Neal Gompa
<ngompa13(a)gmail.com>:
It's not standard at all. We don't even test for this setup regularly.
It's not a test case, and it's not even supposed to work right now.
It’s standard as it is a typical use case in private or SME environments.
And do you really think we distribute dmraid for years now "and it's not even
supposed to work right now.“?
And don't hide behind formalistic arguments that just suit you by chance. Your change
proposal deliberately makes it impossible for existing server users (or makes it
unnecessarily overly difficult) who have relied (and could rely) on us so far to continue
using Fedora Server. I consider this irresponsible. And I don't understand why you
stubbornly insist on this change proposal as is, instead of looking for solutions that
keep mischief away from our users and change to GPT as default (which is undoubtedly the
future standard).
Also, any system with drives >=2TB will get GPT automatically,
you
can't have MBR in those setups. All this does is remove the default
special case for smaller disks.
This is a completely different case. For disks > 2 TB simply nothing changes, neither
better nor worse. For disks < 2 TB your change proposal results in a deterioration. Why
do you want it so badly?
12:17 a.m.
On Fri, Jun 3, 2022 at 12:19 AM Peter Boy <pboy(a)uni-bremen.de> wrote:
> Am 02.06.2022 um 22:42 schrieb Neal Gompa <ngompa13(a)gmail.com>:
>
>
> It's not standard at all. We don't even test for this setup regularly.
> It's not a test case, and it's not even supposed to work right now.
It’s standard as it is a typical use case in private or SME environments.
It's not *that* typical in my experience. Most of the SME server
environments I know of don't have that. It's more common in larger
server environments, but they also typically use hardware RAID there
instead of software RAID.
If we care about this behavior, we should have a test case to verify
this behavior for all three Anaconda install modes (MBR+BIOS,
GPT+BIOS, UEFI). If this is truly something we care about, then we
should have communicated this need to the Anaconda team so that they
would care about it, independent of this feature.
And do you really think we distribute dmraid for years now "and
it's not even supposed to work right now.“?
dmraid has been unmaintained for over 15 years, so yes I do. It was
dropped from RHEL 8 as well. It only exists in Fedora because someone
decided to not retire the package, but upstream has been dead since
the early 2000s.
And don't hide behind formalistic arguments that just suit you by
chance. Your change proposal deliberately makes it impossible for existing server users
(or makes it unnecessarily overly difficult) who have relied (and could rely) on us so far
to continue using Fedora Server. I consider this irresponsible. And I don't understand
why you stubbornly insist on this change proposal as is, instead of looking for solutions
that keep mischief away from our users and change to GPT as default (which is undoubtedly
the future standard).
Outside of having Anaconda create BIOS boot partitions and install the
bootloader on every disk, there's no solution for this problem. Also,
calling it "mischief" is disingenuous, since until this week, nobody
ever mentioned this case at all. We even discussed the GPT thing
before I proposed the Change and it did not come up.
> Also, any system with drives >=2TB will get GPT automatically, you
> can't have MBR in those setups. All this does is remove the default
> special case for smaller disks.
This is a completely different case. For disks > 2 TB simply nothing changes, neither
better nor worse. For disks < 2 TB your change proposal results in a deterioration. Why
do you want it so badly?
You know why I want this Change, and I even wrote it into the
proposal. We have to do *something* to start preparing new installs
for a world when legacy BIOS is *gone*, and switching to GPT is a
simple first step to doing that.
--
真実はいつも一つ！/ Always, there's only one truth!
5:09 p.m.
Am 03.06.2022 um 07:17 schrieb Neal Gompa
<ngompa13(a)gmail.com>:
It's not *that* typical in my experience. Most of the SME server
environments I know of don't have that. It's more common in larger
server environments, but they also typically use hardware RAID there
instead of software RAID.
We don’t have detailed numbers how Fedora is used. But we know from questions and
discussions that people use software raid. And software raid is supported by Anaconda for
years now. And in my memory, these were all cases in the private or SME environment, and
often with rented hardware in some commercial data centers, where hardware raid is usually
offered at a considerable price premium.
Anyway, we have users who use software raid and rely on us as a distribution, and they
should be able to continue to do so in my opinion.
If we care about this behavior, we should have a test case to verify
this behavior for all three Anaconda install modes (MBR+BIOS,
GPT+BIOS, UEFI). If this is truly something we care about, then we
should have communicated this need to the Anaconda team so that they
would care about it, independent of this feature.
We have test cases for the former 2 in issue #87
(https://pagure.io/fedora-server/issue/87) and Stephen Gallagher copied it to a bugzilla
bug report (https://bugzilla.redhat.com/show_bug.cgi?id=2092116). I’ll add a UEFI test
case to a separate issue this weekend. I’ve it already in place on my test equipment here
and have just to copy and paste it.
dmraid has been unmaintained …
Yes, of course, it’s mdadm. That
was a slip into the good old days. Don’t mind.
calling it "mischief" is disingenuous, since until this
week, nobody
ever mentioned this case at all. We even discussed the GPT thing
before I proposed the Change and it did not come up.
Yes, when we discussed this in the server IRC meeting before the change proposal was
published, I hadn't thought of it either. But all of us know it since about one year.
But we missed to pick it up carry it forward.
You know why I want this Change, and I even wrote it into the
proposal. We have to do *something* to start preparing new installs
for a world when legacy BIOS is *gone*, and switching to GPT is a
simple first step to doing that.
Yes, I know, and we completely agree on that from the very beginning.
My only suggestion is to organize this changeover process in such a way that our users are
not negatively affected in any way. And about this there were (hopefully just)
misunderstandings, which we could clarify by now.
The changeover only affects Workstation and Server anyway. All others are either spins of
Workstation or do not use Anaconda.
So, let’s try to convince the Anaconda team to fix the GPT biosboot issue until beta. And
if they need more time, let’s either postpone the switch to F38 or switch Workstation now
(provided there are no software raid users) and switch Server as soon as the Anaconda bug
is fixed.
9:36 a.m.
On Thu, Jun 2, 2022 at 6:19 PM Peter Boy <pboy(a)uni-bremen.de> wrote:
> Am 02.06.2022 um 22:42 schrieb Neal Gompa <ngompa13(a)gmail.com>:
>
>
> It's not standard at all. We don't even test for this setup regularly.
> It's not a test case, and it's not even supposed to work right now.
It’s standard as it is a typical use case in private or SME environments.
If that's true there should be plenty of people willing to put in the
work to make this work reliably. So far they haven't, in particular on
UEFI.
And do you really think we distribute dmraid for years now "and
it's not even supposed to work right now.“?
dmraid is deprecated in favor of either mdadm or LVM based RAID (both
use the kernel's md driver as the backend), for a very long time.
dmraid is even deprecate at least as far back as RHEL 7.6
And don't hide behind formalistic arguments that just suit you by
chance. Your change proposal deliberately makes it impossible for existing server users
(or makes it unnecessarily overly difficult) who have relied (and could rely) on us so far
to continue using Fedora Server. I consider this irresponsible. And I don't understand
why you stubbornly insist on this change proposal as is, instead of looking for solutions
that keep mischief away from our users and change to GPT as default (which is undoubtedly
the future standard).
GPT is already the default when the drive size is > 2 TB, for about a
decade. GPT is the default on UEFI since the start. So the problem
you're talking about, while real, seems to be a low enough of a
priority that no one really wants to fix the problem - so far.
You continue to use emotionally charged language as both a distraction
from the real issue as well as a motivator to stop a feature. The
reality is MBR support is going away, because BIOS support is going
away. This feature is part of moving forward with that reality. We
cannot make people do work they don't want to do. The solution to the
degraded raid problem is actually relatively well understood, it's
just that insufficient resources have come forward to actually solve
the issue. But that cannot be an impediment for making other necessary
changes.
> Also, any system with drives >=2TB will get GPT
automatically, you
> can't have MBR in those setups. All this does is remove the default
> special case for smaller disks.
This is a completely different case. For disks > 2 TB simply nothing changes, neither
better nor worse. For disks < 2 TB your change proposal results in a deterioration. Why
do you want it so badly?
It's not completely different, it results in the *exact* problem
you're complaining about. You don't get to say the effect of GPT > 2T
is OK, but it's a negative when applied to < 2T as if your entire
strategy for working "standard" and "typical" use cases means < 2T
drives are mandatory. If the use case is important, the issue needs to
be fixed.
--
Chris Murphy
9:20 a.m.
On Thu, Jun 2, 2022 at 3:27 PM Peter Boy <pboy(a)uni-bremen.de> wrote:
> Am 02.06.2022 um 19:20 schrieb Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl>:
>
> On Mon, May 30, 2022 at 09:18:27AM +0200, Peter Boy wrote:
>>
>> ...
>>
>> And even those who can continue to use Fedora Server via update are under the
threat of having to switch distributions overnight in the event of a technical error.
Fedora will become unusable for them. A great "feature", that you would like to
introduce, obviously at all costs.
>
> Is 'inst.mbr' a viable workaround? (The bug mentions 'inst.gpt' to
trigger the issue.)
According to the latest Anaconda documentation [1] there is no option inst.mbr, there is
just inst.gpt. Maybe, it is an undocumented feature.
And do we really want our users to fiddle around with editing boot line options as a
standard procedure for using a standard use case?
Define standard. I can't tell what you mean by it here.
Bootable degraded raid is not a common use case. It's not a default
and preset configuration in the installer. You really have to know
what you're doing, and you have to know the installer's idiosyncrasies
to make the installation work this way. This use case is not in the
Server edition product requirements doc, or technical spec doc, or in
Fedora release criterion
It is true that the use case is reasonable and useful, but it is also
unusual. If it's really important, then it at least needs a discussion
on the test@ list, with QA folks about how to go about making it a
release criterion, which minimally involves (a) writing up the
criterion, using unambiguous language, narrowly defining the
requirement (b) documentation changes (c) creating test cases (d)
resources to actually run the test cases every release cycle (e)
optionally+hopfully some portion of the testing can be automated but
all the previous items are prerequisites to that.
--
Chris Murphy
3:18 a.m.
New subject: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
Chris Murphy wrote:
What's the basis for holding up this feature though? Yes it's
a bug,
Making the setup with the bug the default turns the longstanding bug into a
regression (for the default setup) though.
There also seems to be no reasonable workaround, or is there a checkbox or
dropdown somewhere in Anaconda to force using MBR instead of GPT?
but it wouldn't be a release blocking bug
That only makes the issue worse. If the bug were release-blocking, the
feature could be pushed forward under the (implied by default) condition
that the release-blocking bug be addressed before the release goes out, or
otherwise the change rolled back as per the contingency plan.
because there's no release criteria covering degraded boot.
If the release criteria do not cover "a common use" (according to Peter
Boy), then that is an issue in the release criteria and needs to be
addressed there, i.e., a suitable criterion added.
but I don't think it's OK to hold up a release indefinitely
while
insisting other people do the work required to bring such functionality to
Fedora.
The whole point of pushing the feature to a later release is to not hold up
the entire release because of it.
Kevin Kofler
4:39 a.m.
New subject: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide
Change proposal)
On Sun, May 29, 2022, at 6:55 AM, Peter Boy wrote:
Fedora Server WG discussed the proposal and insists that the proposal
be deferred until Anaconda can install software raid on biosboot
systems with GPT (see
https://bugzilla.redhat.com/show_bug.cgi?id=2088113 and
https://lists.fedoraproject.org/archives/list/server@lists.fedoraproject....)
- at least for Fedora Server where software raid is a common use.
Just a note: Fedora CoreOS has used a hybrid BIOS/UEFI setup since its inception, and also
supports this "mirrored boot" setup:
https://docs.fedoraproject.org/en-US/fedora-coreos/storage/#_reconfigurin...
https://github.com/coreos/enhancements/blob/main/os/20201103-full-disk-ra...
https://github.com/coreos/butane/pull/162
5:32 a.m.
Am 30.05.2022 um 11:39 schrieb Colin Walters
<walters(a)verbum.org>:
Just a note: Fedora CoreOS has used a hybrid BIOS/UEFI setup since its inception, and
also supports this "mirrored boot" setup:
https://docs.fedoraproject.org/en-US/fedora-coreos/storage/#_reconfigurin...
https://github.com/coreos/enhancements/blob/main/os/20201103-full-disk-ra...
https://github.com/coreos/butane/pull/162
Thanks for the hint! I could curiously just take a quick look at it (due to a very tight
schedule). According to my impression
- It is not a ready-to-use solution to empower an Anaconda based installation
- We would have to develop a lot of adjustments or replace Anaconda
I hope I have understood this reasonably correctly.
686
days inactive
706
days old
16 comments
8 participants
participants (8)
-
Ben Cotton -
Chris Murphy -
Colin Walters -
Gerd Hoffmann -
Kevin Kofler -
Neal Gompa -
Peter Boy -
Zbigniew Jędrzejewski-Szmek