> Am 30.05.2022 um 04:28 schrieb Chris Murphy <lists@xxxxxxxxxxxxxxxxx>: > > On Sun, May 29, 2022 at 6:56 AM Peter Boy <pboy@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx/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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
