disk: systemd-repart compatibility

[supakeen]

So; bit funky and a bit all over the place. This PR introduces 4 new options on the partition table struct. When combined together they make our partition tables identical to those created by systemd-repart with the caveat that partition tables that have start offsets (for example; the aarch64 partition tables for Fedora) are not compatible, but that would have to come from the other side (e.g. systemd-repart would need to support padding before the first partition).

I've implemented each of these options separately behind toggles so we can decide if we want them 'by default' or not. Especially the absolute_start_offset + start_offset: "1 MiB" feels funky. Perhaps someone has better ideas for that.

We could also decide we don't want to be compatible at all and instead opt for a future approach (that I still plan to PR) which allows partitioning through systemd-repart instead of through sfdisk.

A partition table with:

grain_size: 4096                                                                                                                              
start_offset: "1 MiB"                                                                                                                         
absolute_start_offset: true                                                                                                                   
align_footer: true

Creates the exact same partition table as systemd-repart would create with the following inputs:

€ cat 00-esp.conf 
[Partition]
Type=esp
SizeMinBytes=200M
repart € cat 10-root.conf 
[Partition]
Type=root
SizeMinBytes=2G
€ sudo systemd-repart --definitions=. --empty=create --size=auto repart.raw
Automatically determined minimal disk image size as 2.1G.
Sized 'repart.raw' to 2.1G.
TYPE        LABEL       UUID                                 PART FILE           RAW SIZE     SIZE PADDING
esp         esp         2e7b5217-05b1-4404-a392-9759d36ea12d    0 00-esp.conf   209715200   → 200M    → 0B
root-x86-64 root-x86-64 00fc3f3e-25cd-47d4-be90-f6f417e6351b    1 10-root.conf 2147483648     → 2G    → 0B
                                                                                          Σ = 2.1G  Σ = 0B

 ▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒░
 │           └─ 10-root.conf                                                                                                                     
 └─ 00-esp.conf                                                                                                                                  

Applying changes to repart.raw.
Adding new partition 0 to partition table.
Adding new partition 1 to partition table.
Writing new partition table.
All done.

€ fdisk -l repart.raw 
Disk repart.raw: 2.2 GiB, 2358267904 bytes, 4605992 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: DF796A0B-5A11-4BAB-A693-2C8925D4F98F

Device       Start     End Sectors  Size Type
repart.raw1   2048  411647  409600  200M EFI System
repart.raw2 411648 4605951 4194304    2G Linux root (x86-64)

Let's compare that to a partition table created by images with the default settings; a 200 MiB ESP and a 2 GiB root:

€ fdisk -l 1M.raw 
Disk 1M.raw: 2.2 GiB, 2359296000 bytes, 4608000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A07BA799-6E25-4F45-A84F-CEC5C8C7C10B

Device      Start     End Sectors  Size Type
1M.raw1      2048  411647  409600  200M EFI System
1M.raw2    411648 4607966 4196319    2G Linux root (x86-64)

Note the difference in end sector and total sectors for the root partition.

When building that same partition table but adding all the toggles introduced in this PR we get:

artifacts € fdisk -l 4k.raw 
Disk 4k.raw: 2.2 GiB, 2358267904 bytes, 4605992 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 3721BFEE-0D51-4EC1-803E-1AEB924D4126

Device      Start     End Sectors  Size Type
4k.raw1      2048  411647  409600  200M EFI System
4k.raw2    411648 4605951 4194304    2G Linux root (x86-64)

Booting these disk images most importantly gets rid of the failing systemd-repart service saying that it can't fit the partitions inside the disk 🙂

[achilleas-k]

Neat!!

Before I read everything (not that it's a lot, this is surprisingly small), what would be the downside to changing our defaults to be the same as systemd-repart?

Ignoring the fact that some users might rely on specific alignments (which sounds horrifying), are there are other problems or side effects?

[supakeen]

Neat!!

Before I read everything (not that it's a lot, this is surprisingly small), what would be the downside to changing our defaults to be the same as systemd-repart?

Ignoring the fact that some users might rely on specific alignments (which sounds horrifying), are there are other problems or side effects?

1. I think the configurable grain size is safe to land.
2. I think the alignment of the footer (and thus the alignment of the last sector of the last partition) is safe to apply by default.

As far as the start of the first partition; currently we align it up to the grain size (which is by default 1 MiB and thus 2048 sectors).

I would like to make the standard 'offset' 2048 (have it in a constant called FirstLBA or such) regardless of grain size (we can't set it lower without passing additional arguments to sfdisk but we might want that in the future?) and add the StartOffset on top of that (and then align it to grainsize). That means we get slightly more room in that case which also shouldn't break anything.

If we do it that way there are in my opinion no harmful results though yes if people expect very specific alignments in the StartOffset (e.g. they set it to 2 MiB which was 4096 sectors but would now be 6144 sectors and then dd something onto their first partition which they assume to be at a specific offset?

I don't think that happens, usually when people dd firmware onto their device it's at sector 64 and they just expect room after it for which there is now slightly more room.

---

Want me to just make the above the default behavior?

[achilleas-k]

Want me to just make the above the default behavior?

Let's talk about it after I've read through everything. Could be a follow-up.

[brlane-rht]

I think this is generally ok, but I think adding the bool for absolute start offset just makes things confusing. Just change it to behave as expected by other tools.