Use DPS UUIDs for root and boot partitions

[Johan-Liebert1]

Use the Discoverable Partition Specification UUID for root and boot
partitions

We were already using DPS UUID for both partitions, but they were UUIDs
for generic Linux Data Parition

This lets us use systemd-systemd-gpt-auto-generator which is a good
choice for LUKS decryption without UKI addons for composefs backend

Use architecture specific DPS UUID for root partition, and use XBOOTLDR
UUID for boot partition

Related: coreos/fedora-coreos-tracker#2060

Closes: coreos/fedora-coreos-tracker#1038

[gemini-code-assist]

Code Review

This pull request correctly updates the partition type UUIDs for boot and root partitions across multiple architectures to use the Discoverable Partition Specification (DPS) values. This change is essential for enabling systemd-systemd-gpt-auto-generator. The review includes suggestions to define these new UUIDs as variables within the mpp-vars section of each manifest. This would improve maintainability and readability by replacing magic strings with named variables, a practice already in use for other UUIDs in these files.

[gemini-code-assist]

To improve readability and maintainability, consider defining these partition type UUIDs as variables in mpp-vars and referencing them here. This avoids using magic strings and makes their purpose clear. For example, you could add dps_boot_partition_type and dps_root_partition_type_aarch64 to mpp-vars.

        - name: boot
          type:
            mpp-format-string: '{dps_boot_partition_type}'
          size:
            mpp-format-int: "{boot_size_mb * 1024 * 1024 / sector_size}"
        - name: root
          type:
            mpp-format-string: '{dps_root_partition_type_aarch64}'

[gemini-code-assist]

For consistency, please apply the same variable-based approach for partition type UUIDs in the image4k definition.

        - name: boot
          type:
            mpp-format-string: '{dps_boot_partition_type}'
          size:
            mpp-format-int: "{boot_size_mb * 1024 * 1024 / four_k_sector_size}"
        - name: root
          type:
            mpp-format-string: '{dps_root_partition_type_aarch64}'

[gemini-code-assist]

To improve readability and maintainability, consider defining these partition type UUIDs as variables in mpp-vars and referencing them here. This avoids using magic strings and makes their purpose clear. For example, you could add dps_boot_partition_type and dps_root_partition_type_ppc64le to mpp-vars.

        - name: boot
          type:
            mpp-format-string: '{dps_boot_partition_type}'
          size:
            mpp-format-int: "{boot_size_mb * 1024 * 1024 / sector_size}"
        - name: root
          type:
            mpp-format-string: '{dps_root_partition_type_ppc64le}'

[gemini-code-assist]

For consistency, please apply the same variable-based approach for partition type UUIDs in the image4k definition.

        - name: boot
          type:
            mpp-format-string: '{dps_boot_partition_type}'
          size:
            mpp-format-int: "{boot_size_mb * 1024 * 1024 / four_k_sector_size}"
        - name: root
          type:
            mpp-format-string: '{dps_root_partition_type_ppc64le}'

[gemini-code-assist]

To improve readability and maintainability, consider defining these partition type UUIDs as variables in mpp-vars and referencing them here. This avoids using magic strings and makes their purpose clear. For example, you could add dps_boot_partition_type and dps_root_partition_type_riscv64 to mpp-vars.

        - name: boot
          type:
            mpp-format-string: '{dps_boot_partition_type}'
          size:
            mpp-format-int: "{boot_size_mb * 1024 * 1024 / sector_size}"
        - name: root
          type:
            mpp-format-string: '{dps_root_partition_type_riscv64}'

[gemini-code-assist]

For consistency, please apply the same variable-based approach for partition type UUIDs in the image4k definition.

        - name: boot
          type:
            mpp-format-string: '{dps_boot_partition_type}'
          size:
            mpp-format-int: "{boot_size_mb * 1024 * 1024 / four_k_sector_size}"
        - name: root
          type:
            mpp-format-string: '{dps_root_partition_type_riscv64}'

[gemini-code-assist]

To improve readability and maintainability, consider defining these partition type UUIDs as variables in mpp-vars and referencing them here. This avoids using magic strings and makes their purpose clear. For example, you could add dps_boot_partition_type and dps_root_partition_type_s390x to mpp-vars.

        - name: boot
          type:
            mpp-format-string: '{dps_boot_partition_type}'
          size:
            mpp-format-int: "{boot_size_mb * 1024 * 1024 / sector_size}"
          partnum: 3
        - name: root
          type:
            mpp-format-string: '{dps_root_partition_type_s390x}'
          partnum: 4

[gemini-code-assist]

For consistency, please apply the same variable-based approach for partition type UUIDs in the image4k definition.

        - name: boot
          type:
            mpp-format-string: '{dps_boot_partition_type}'
          size:
            mpp-format-int: "{boot_size_mb * 1024 * 1024 / four_k_sector_size}"
          partnum: 3
        - name: root
          type:
            mpp-format-string: '{dps_root_partition_type_s390x}'
          partnum: 4

[gemini-code-assist]

To improve readability and maintainability, consider defining these partition type UUIDs as variables in mpp-vars and referencing them here. This avoids using magic strings and makes their purpose clear. For example, you could add dps_boot_partition_type and dps_root_partition_type_x86_64 to mpp-vars.

        - name: boot
          type:
            mpp-format-string: '{dps_boot_partition_type}'
          size:
            mpp-format-int: "{boot_size_mb * 1024 * 1024 / sector_size}"
        - name: root
          type:
            mpp-format-string: '{dps_root_partition_type_x86_64}'

[gemini-code-assist]

For consistency, please apply the same variable-based approach for partition type UUIDs in the image4k definition.

        - name: boot
          type:
            mpp-format-string: '{dps_boot_partition_type}'
          size:
            mpp-format-int: "{boot_size_mb * 1024 * 1024 / four_k_sector_size}"
        - name: root
          type:
            mpp-format-string: '{dps_root_partition_type_x86_64}'

[jbtrystram]

Change LGTM but could you add the reference spec in the commit message ?
Also, does it interfere with coreos-boot-generator ? I guess we would drop that entirely ?

[openshift-ci]

@Johan-Liebert1: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
ci/prow/rhcos	a8f0ac0	link	true	/test rhcos

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[dustymabe]

This lets us use systemd-systemd-gpt-auto-generator

Unfortunately we don't include that right now. It got re-introduced recently and broke stuff.

If we were to make this change I think we'd need to make some more careful consideration. Would we want to do it everywhere immediately? Or would we want to phase this in? Right now changes here land downstream in rhel-9.6 pretty much immediately.

cc @travier