Partition the disk

Wipe the existing partition table and write the new one. sgdisk does both in one pass:

Run this on the live system:

: "${DISK:?set DISK on the previous page first}" &&
sgdisk --zap-all "$DISK" &&
sgdisk --clear \
  --new=1:0:+1G --typecode=1:ef00 --change-name=1:ESP \
  --new=2:0:0   --typecode=2:8300 --change-name=2:root \
  "$DISK" &&
partprobe "$DISK"

The first line is a guard, not a command: ${DISK:?...} aborts with that message if DISK is unset or empty, and the && chain means nothing after it runs. Without it, an empty $DISK sends sgdisk off into four lines of Problem opening '' for writing before the remaining commands try anyway. Since the whole chapter hangs off one variable set in a shell that may not be the one you are in, it is worth the line.

Reading the rest across: --zap-all destroys the old GPT and any leftover MBR, which matters when you are reinstalling over a disk that had something else on it. --new=1:0:+1G creates partition 1, starting at the first aligned sector (0 means “wherever is next”) and running one gibibyte; --new=2:0:0 gives partition 2 all the remaining space. Type code ef00 marks the first as an EFI System Partition and 8300 marks the second as a plain Linux filesystem. partprobe then asks the kernel to re-read the table, so the new /dev/...p1 and p2 nodes appear.

Confirm the result:

[bash]: Run this on your workstation:

lsblk -o NAME,SIZE,TYPE,FSTYPE,PARTLABEL "$DISK"

(stdout)

NAME          SIZE TYPE FSTYPE PARTLABEL
nvme0n1     238.5G disk
├─nvme0n1p1     1G part        ESP
└─nvme0n1p2   237.5G part      root

Why one gibibyte

A gibibyte is far more than a single kernel needs, and that is the point. On x86_64 the kernel and initramfs are copied onto this partition on every update, and keeping a few generations around is what lets you boot an older one when a new kernel misbehaves. On the Pi it also holds the firmware blobs and every model’s device tree. Disks are large; boot partitions that are too small are a well-worn regret.

On the Raspberry Pi

The ef00 type code is an x86_64 convention, and the Pi’s bootloader does not read partition types at all – it looks for the first FAT partition on the device. Partition 1 is that partition, so the same command works unchanged, and tagging it ef00 keeps the two architectures telling the same story.