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@gmail.com, dcavalca@fb.com, michel@michel-slm.name, chrismurphy@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.
== 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
On Mon, May 16, 2022 at 9:25 AM Gerd Hoffmann kraxel@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.fedorapro...
-- 真実はいつも一つ！/ Always, there's only one truth!
Am 14.05.2022 um 18:45 schrieb Ben Cotton bcotton@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@gmail.com, dcavalca@fb.com, michel@michel-slm.name,
chrismurphy@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.org...) - 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.
On Sun, May 29, 2022 at 6:56 AM Peter Boy pboy@uni-bremen.de wrote:
Am 14.05.2022 um 18:45 schrieb Ben Cotton bcotton@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@gmail.com, dcavalca@fb.com, michel@michel-slm.name,
chrismurphy@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.org...) - 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.
Am 30.05.2022 um 04:28 schrieb Chris Murphy lists@colorremedies.com:
On Sun, May 29, 2022 at 6:56 AM Peter Boy pboy@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.org...) - 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).
On Mon, May 30, 2022 at 09:18:27AM +0200, Peter Boy wrote:
Am 30.05.2022 um 04:28 schrieb Chris Murphy lists@colorremedies.com:
On Sun, May 29, 2022 at 6:56 AM Peter Boy pboy@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.org...) - 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
Am 02.06.2022 um 19:20 schrieb Zbigniew Jędrzejewski-Szmek zbyszek@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
On Thu, Jun 2, 2022 at 9:27 PM Peter Boy pboy@uni-bremen.de wrote:
Am 02.06.2022 um 19:20 schrieb Zbigniew Jędrzejewski-Szmek zbyszek@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.
Am 02.06.2022 um 22:42 schrieb Neal Gompa ngompa13@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?
On Fri, Jun 3, 2022 at 12:19 AM Peter Boy pboy@uni-bremen.de wrote:
Am 02.06.2022 um 22:42 schrieb Neal Gompa ngompa13@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!
Am 03.06.2022 um 07:17 schrieb Neal Gompa ngompa13@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.
On Thu, Jun 2, 2022 at 6:19 PM Peter Boy pboy@uni-bremen.de wrote:
Am 02.06.2022 um 22:42 schrieb Neal Gompa ngompa13@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.
On Thu, Jun 2, 2022 at 3:27 PM Peter Boy pboy@uni-bremen.de wrote:
Am 02.06.2022 um 19:20 schrieb Zbigniew Jędrzejewski-Szmek zbyszek@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 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
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.org...)
- 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/#_reconfiguring_t... https://github.com/coreos/enhancements/blob/main/os/20201103-full-disk-raid.... https://github.com/coreos/butane/pull/162
Am 30.05.2022 um 11:39 schrieb Colin Walters walters@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/#_reconfiguring_t... https://github.com/coreos/enhancements/blob/main/os/20201103-full-disk-raid.... 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.
-
Ben Cotton -
Chris Murphy -
Colin Walters -
Gerd Hoffmann -
Kevin Kofler -
Neal Gompa -
Peter Boy -
Zbigniew Jędrzejewski-Szmek