[P2] UKI dm-verity uses PARTNROFF=1/2 — hardcodes BOOT-A / ROOT-A / HASH-A partition adjacency.
The PARTUUID=${boot_partuuid}/PARTNROFF=1 (ROOT-A) and .../PARTNROFF=2 (HASH-A) references on L530-531 rely on the current on-disk order (BIOS, EFI-A, BOOT-A, ROOT-A, HASH-A). This is fine today, but sgdisk --sort (rpm2img:205) reorders by start sector, so any future layout change that inserts a partition between BOOT-A and ROOT-A (or between ROOT-A and HASH-A) — e.g. a LUKS keyslot partition as this feature series grows — silently breaks the UKI verity table. The failure appears at boot as a dm-verity setup error.
Robust fix: resolve the real PARTUUIDs of ROOT-A and HASH-A via get_partition_uuid and pass them into generate_verity_root directly, replacing the offset arithmetic entirely.
Originally posted by @jmt-lab in #701 (comment)
[P2] UKI dm-verity uses
PARTNROFF=1/2— hardcodes BOOT-A / ROOT-A / HASH-A partition adjacency.The
PARTUUID=${boot_partuuid}/PARTNROFF=1(ROOT-A) and.../PARTNROFF=2(HASH-A) references on L530-531 rely on the current on-disk order (BIOS, EFI-A, BOOT-A, ROOT-A, HASH-A). This is fine today, butsgdisk --sort(rpm2img:205) reorders by start sector, so any future layout change that inserts a partition between BOOT-A and ROOT-A (or between ROOT-A and HASH-A) — e.g. a LUKS keyslot partition as this feature series grows — silently breaks the UKI verity table. The failure appears at boot as a dm-verity setup error.Robust fix: resolve the real PARTUUIDs of ROOT-A and HASH-A via
get_partition_uuidand pass them intogenerate_verity_rootdirectly, replacing the offset arithmetic entirely.Originally posted by @jmt-lab in #701 (comment)