F42 Change Proposal: Install Using GPT on all architectures by Default (system-wide)

Install Using GPT on all architectures by Default

This is a proposed Change for Fedora Linux.
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.

Wiki
Announced

:link: Summary

This is a follow-up for the Fedora 37 change which made GPT the default partition table for x86_64. This change proposes switching to GPT for the other supported architectures as well.

:link: Owner

:link: Detailed Description

In Fedora 37 we switched to GPT as the default partition table (disklabel) for x86_64, for Fedora 42 we propose to make the switch for other architectures as well. Because GPT was already the default for ARM64 this means switching to GPT for ppc64le and s390x architectures when installing on an empty disk or when the disk is being completely reset during the installation.

Note: for s390x this applies only to disks where MSDOS disklabel is currently being used as the default disklabel, for DASD we’ll continue to use the DASD disklabel.

:link: Feedback

:link: Benefit to Fedora

Similarly to the previous change: simplifying the code path and making the same default across all architectures with as few exceptions as possible. Fedora CoreOS now also uses GPT as default on all architectures so this change will also unify our defaults.

:link: Scope

:link: Upgrade/compatibility impact

This change will affect only new installations, no change to the partition table will be done during the upgrade.

:link: Early Testing (Optional)

Do you require ‘QA Blueprint’ support? N

Early testing can be done by using the boot option inst.disklabel=gpt. This option tells the installer to use GPT disklabel so it can be used to make sure the system is compatible and will install and boot correctly with GPT.

:link: How To Test

Any of the installer test cases (for example QA:Testcase_Anaconda_autopart_(use_all_space)_install) can be used to test this. Note that the installer will create a new partition table only when an empty disk is used or when all preexisting devices are selected to be removed, the partition table cannot be changed when existing partitions are being reused.

The expected result is that GPT will be used as the partition table type on s390x and ppc64le. sudo fdisk -l /dev/sdx can be used to verify that GPT was used by the installer.

:link: User Experience

Users shouldn’t notice any significant change other than the switch from MSDOS to GPT disklabel. Other than that the user experience during installation, booting or using the system shouldn’t change at all.

:link: Dependencies

There are no dependencies for this change, all work will be done in Blivet, the library that Anaconda uses for storage configuration.

:link: Contingency Plan

  • Contingency mechanism: Revert the change in upstream
  • Contingency deadline: Final Freeze
  • Blocks release? Yes

:link: Documentation

The change will be documented in Anaconda release notes for Fedora 42 similarly to the documentation for the original Fedora 37 change.

:link: Release Notes

Last edited by @amoloney 2024-12-12T15:13:11Z

Last edited by @amoloney 2024-12-12T15:13:11Z

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

This is something that should be coordinated with the production of Fedora disk images (Cloud, Server, and desktop images for ARM, etc.)

It does not make sense for there to be a difference like this between user-installed and distro-installed environments.

FYI @davdunc

1 Like

I found myself wondering what platforms do not expect GPT by default at this point, but more to the point of your statement @ngompa, I have to say, yes. We do need coordination across the released images and an idea on what does or what should change. User experience should be consistent.

Makes sense to me, but I wonder if the proposal should have been more clear about ppc64le and s390x in the title?

I installed F41 Server to a Legacy AMD64 motherboard (Phenom II X4) and assume it was GPT (according to the proposal; I did Custom → Standard partitioning though); it worked fine. I’d say it’s probably good-to-go everywhere, but I have no idea about those two platforms.

Yes, it might have been better. I am not sure if I can change the title now when the change is already announced.

1 Like

We did testing on the ppc64 and sr390 hardware we have available in Red Hat and it worked without problems (FWIW this change is also going to RHEL).

1 Like

I am not against this, but it changes the scope significantly and I’d definitely need help with this, I have no idea how the images are generated these days.

Maybe I could change the title of the change to better match the change scope (s390x and ppc64le defaults in the installer) as someone suggested.

Right now, images are built with a mixture of ImageFactory, KIWI, and OSBuild. We are in the process of retiring ImageFactory and moving the remaining artifacts using it to KIWI.

For kiwi, we are now looking into adding GPT support for IBM Z. We already use GPT for Power Systems.

1 Like

This change proposal has now been submitted to FESCo with ticket #3314 for voting.

To find out more, please visit our Changes Policy documentation.

1 Like