install/baseline: Use sfdisk, not sgdisk

[cgwalters]

Port from gdisk to sfdisk (util-linux) as gdisk is less well maintained and is specifically targeted to be dropped from RHEL10 (xref https://issues.redhat.com/browse/RHELMISC-6651 ).

Closes: #774

[cgwalters]

A diff of the old and new partitions looks like this:

--- /tmp/old.json	2024-09-03 14:46:25.863951421 -0400
+++ /tmp/new.json	2024-09-03 14:44:15.957720107 -0400
@@ -1,10 +1,10 @@
 {
    "partitiontable": {
       "label": "gpt",
-      "id": "6EE0DD52-1175-42E9-A3FB-20600117A828",
+      "id": "4CB4805F-5E03-4D92-8D2C-589725F0E778",
       "device": "/dev/vda",
       "unit": "sectors",
-      "firstlba": 34,
+      "firstlba": 2048,
       "lastlba": 20971486,
       "sectorsize": 512,
       "partitions": [
@@ -13,21 +13,21 @@
             "start": 2048,
             "size": 2048,
             "type": "21686148-6449-6E6F-744E-656564454649",
-            "uuid": "01331A3A-D766-4DD1-A205-5974175D0449",
+            "uuid": "DBFDE957-B16F-8D4F-8258-7876B340E963",
             "name": "BIOS-BOOT"
          },{
             "node": "/dev/vda2",
             "start": 4096,
             "size": 1048576,
             "type": "C12A7328-F81F-11D2-BA4B-00A0C93EC93B",
-            "uuid": "5EC7DA28-2CFE-4524-A2BF-F15E8DD3E13F",
+            "uuid": "B3A15F64-D1F1-C74D-A5E0-8C0297B218D4",
             "name": "EFI-SYSTEM"
          },{
             "node": "/dev/vda3",
             "start": 1052672,
             "size": 19918815,
             "type": "0FC63DAF-8483-4772-8E79-3D69D8477DE4",
-            "uuid": "841F3DAB-6A93-4849-B031-1931C13CFCFC",
+            "uuid": "0F7BC331-06FD-0A4B-84B1-14B62CE243C8",
             "name": "root"
          }
       ]

Which is all expected (we generate random uuids) today except for firstlba...hmm...digging in slightly I think this may be because sgdisk creates a protective MBR by default but sfdisk doesn't? Hmm, not totally sure.

[jmarrero]

lgtm

[jlebon]

Which is all expected (we generate random uuids) today except for firstlba...hmm...digging in slightly I think this may be because sgdisk creates a protective MBR by default but sfdisk doesn't? Hmm, not totally sure.

sgdisk sets it to 34 because that's the size of the protective MBR + GPT table and the minimum required by the spec (see e.g. https://en.wikipedia.org/wiki/GUID_Partition_Table#/media/File:GUID_Partition_Table_Scheme.svg). sfdisk sets it to 2048 presumably because it's the first location it could create the first partition with the default 1M alignment. (sgdisk defaults to 1M too, but doesn't reflect it in the first LBA field.)

There was actually fallout related to this in FCOS (well, more related to the fact that the last LBA is a mirrored version of the first LBA, which means the last partition can have different sizes). See coreos/fedora-coreos-tracker#1745 (comment) for all the fun.