Re: F37 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
> Am 03.06.2022 um 07:17 schrieb Neal Gompa : > > > 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. ___ 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 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
On Thu, Jun 2, 2022 at 6:19 PM Peter Boy wrote: > > > > > Am 02.06.2022 um 22:42 schrieb Neal Gompa : > > > > > > 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 ___ 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 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
On Thu, Jun 2, 2022 at 3:27 PM Peter Boy wrote: > > > > > Am 02.06.2022 um 19:20 schrieb Zbigniew Jędrzejewski-Szmek > > : > > > > 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 ___ 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 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
On Fri, Jun 3, 2022 at 12:19 AM Peter Boy wrote: > > > > > Am 02.06.2022 um 22:42 schrieb Neal Gompa : > > > > > > 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! ___ 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 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
> Am 02.06.2022 um 22:42 schrieb Neal Gompa : > > > 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? ___ 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 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
On Thu, Jun 2, 2022 at 9:27 PM Peter Boy wrote: > > > > > Am 02.06.2022 um 19:20 schrieb Zbigniew Jędrzejewski-Szmek > > : > > > > 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! ___ 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 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
> Am 02.06.2022 um 19:20 schrieb Zbigniew Jędrzejewski-Szmek > : > > 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 ___ 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 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
On Mon, May 30, 2022 at 09:18:27AM +0200, Peter Boy wrote: > > > > Am 30.05.2022 um 04:28 schrieb Chris Murphy : > > > > On Sun, May 29, 2022 at 6:56 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/ser...@lists.fedoraproject.org/thread/VSM473WRHKIIIJYZZCVXAO7XFS4ACHPH/) > >> - 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 ___ 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 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
> Am 30.05.2022 um 11:39 schrieb Colin Walters : > > 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_the_root_filesystem > https://github.com/coreos/enhancements/blob/main/os/20201103-full-disk-raid.md > 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. ___ 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 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/ser...@lists.fedoraproject.org/thread/VSM473WRHKIIIJYZZCVXAO7XFS4ACHPH/) > > - 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_the_root_filesystem https://github.com/coreos/enhancements/blob/main/os/20201103-full-disk-raid.md https://github.com/coreos/butane/pull/162 ___ 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 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 ___ 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 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
> Am 30.05.2022 um 04:28 schrieb Chris Murphy : > > On Sun, May 29, 2022 at 6:56 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/ser...@lists.fedoraproject.org/thread/VSM473WRHKIIIJYZZCVXAO7XFS4ACHPH/) >> - 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). ___ 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 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
On Sun, May 29, 2022 at 6:56 AM Peter Boy wrote: > > > > > Am 14.05.2022 um 18:45 schrieb Ben Cotton : > > > > 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: ngomp...@gmail.com, dcava...@fb.com, mic...@michel-slm.name, > > chrismur...@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/ser...@lists.fedoraproject.org/thread/VSM473WRHKIIIJYZZCVXAO7XFS4ACHPH/) > - 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 ___ 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 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
> Am 14.05.2022 um 18:45 schrieb Ben Cotton : > > 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: ngomp...@gmail.com, dcava...@fb.com, mic...@michel-slm.name, > chrismur...@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/ser...@lists.fedoraproject.org/thread/VSM473WRHKIIIJYZZCVXAO7XFS4ACHPH/) - 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. ___ 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 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
On Mon, May 16, 2022 at 9:25 AM Gerd Hoffmann 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-de...@lists.fedoraproject.org/thread/SISDA5JBUO6ORO3GKD7TZPEG3WUO73RF/ -- 真実はいつも一つ！/ 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 proposal: Install Using GPT on x86_64 BIOS by Default (System-Wide Change proposal)
> == 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 ___ 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
