sgdisk Command: Tutorial & Examples

The scriptable way to carve up a disk — every GPT partition move, with no menus in the way.

What It Is

sgdisk is how you partition a disk without a human in the loop. Give it a block device and a string of flags, and it lays down a GPT partition table — create this partition, name that one, set its type, write it out — and exits. No prompts, no menus, no "are you sure?" It's the tool you reach for when a shell script has to prepare a fresh disk the same way, a thousand times, with nobody watching.

If you've never partitioned a disk before, here's the orientation. A raw disk is just a long row of bytes; a partition table is the tiny map at the front that says "bytes 1 MiB to 977 MiB are partition 1, the rest is partition 2." sgdisk writes that map. Its interactive twin is gdisk — same engine, but with a question-and-answer menu — and the two are the modern GPT replacement for the old fdisk family. By the end of this page you'll understand the GPT format itself, why it keeps a second copy of the map at the far end of the disk (the single best thing about it, and a genuine lifesaver), and how to drive sgdisk confidently — including the one detail that makes it dangerous and the discipline that makes it safe.

Danger

Almost everything sgdisk does writes to a disk, and writing a partition table over a disk that already holds data orphans that data instantly — the bytes are still there, but nothing knows where they start. Every command on this page that includes a device like /dev/sdb is a write. Read the whole page, double-check the device name with lsblk, and never run a destructive flag against a disk you haven't confirmed is the right one.

Your First Look

The safest thing sgdisk does is look, and that's where to start. -p (print) dumps the current partition table and changes nothing:

sgdisk -p /dev/sda

Disk /dev/sda: 3907029168 sectors, 1.8 TiB
Model: Samsung SSD 870
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 4F2A9C7E-1B3D-4A8E-9F10-2C5D7E8A1B6F
Partition table holds up to 128 entries
Main partition table begins at sector 2 and the backup at sector 3907029134
First usable sector is 34, last usable sector is 3907029134
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048         2050047   1000.0 MiB  EF00  EFI system partition
   2         2050048         4147199   1024.0 MiB  8300  boot
   3         4147200      3907028991   1.8 TiB     8300  root

Read it top to bottom and the whole GPT model is right there. The disk is 3.9 billion 512-byte sectors. There's a disk GUID — a globally-unique fingerprint for the whole disk. The table "holds up to 128 entries" — GPT's standard ceiling, versus the four primary partitions MBR ever allowed. And the line that quietly contains the magic: "Main partition table begins at sector 2 and the backup at sector 3907029134." Hold onto that — GPT keeps two copies of the map, and the second one has saved more disks than any backup ever made on purpose.

Each partition row carries a start and end sector, a human size, a four-hex-digit type code (EF00 = EFI system, 8300 = Linux filesystem, 8200 = Linux swap), and a free-text name. That's a partition: a labelled, typed range of sectors. Nothing more mysterious than that.

How I Use It

The thing to understand about sgdisk is that it's batch-first. You don't open it, fiddle, and save — you compose the entire operation as one line of flags, and when it exits, the disk is done. So my actual workflow is: figure out the layout on paper, then write it as a single incantation.

First, always, I look — and I look at the right device. sgdisk -p /dev/sdb, and I cross-check the model and size against lsblk. The number-one way to ruin a day with this tool is to be one letter off on the device name; /dev/sda is usually the disk you're running from. So the look is never optional.

Then I build the line. A real "prepare a blank disk into EFI + boot + root" looks like this — and yes, every one of these flags writes:

sgdisk -n 1:0:+512M -t 1:EF00 -c 1:"EFI system" \
       -n 2:0:+1G   -t 2:8300 -c 2:"boot" \
       -n 3:0:0     -t 3:8300 -c 3:"root" /dev/sdb

Read it like a sentence. -n 1:0:+512M means "new partition 1, starting at the first free sector (0 = let sgdisk pick), running for 512 mebibytes." -t 1:EF00 types it as an EFI system partition. -c 1:"EFI system" names it. Then partition 2, then partition 3 — and -n 3:0:0 is the lovely idiom for "start at the next free sector and run to the end of the disk," because a second 0 in the end slot means "as far as you can go." One line, three partitions, deterministic, repeatable. That's the whole appeal.

Then I verify, then I tell the kernel. sgdisk -p /dev/sdb to confirm the table looks as intended, and partprobe /dev/sdb (or udevadm settle) so the running kernel re-reads the table and the new /dev/sdb1, /dev/sdb2 device nodes appear. A freshly partitioned disk whose partitions don't show up in lsblk yet is almost always waiting on this re-read, not broken.

The craft is just those three beats: look hard, write once, re-read. Now let's explain every flag behind them.

The Flags, Explained

sgdisk has a lot of flags because GPT has a lot of fields. Here's the whole vocabulary, grouped by what it touches.

Looking (safe, read-only):

-p / --print — print the partition table (the command from "Your First Look").
-i N / --info=N — deep detail on a single partition N: its unique GUID, type GUID, start/end sectors, attribute flags, and name. This is where you read the partition's own GUID, distinct from the disk's.
-v / --verify — check the table for corruption (overlaps, bad checksums, a mismatched backup) and report problems without fixing them. The first thing to run on a disk you suspect is damaged.
-P / --pretend — dry-run: show what a command would do, touch nothing. Pair it with a destructive line to preview the result safely.

Creating and removing partitions (writes):

-n N:start:end / --new — the workhorse: new partition N from start to end. Either bound can be 0 (start = first free sector; end = last usable sector). Sizes take +512M, +1G, or a - prefix to measure back from the end (-8G = "8 GiB up from the disk's tail"). Use N=0 to mean "next free partition number."
-d N / --delete=N — delete partition N from the table. (The data is orphaned, not erased — see Gotchas.)
-t N:code / --typecode — set partition N's type to a four-hex-digit code (EF00, 8300, 8200, FD00 for Linux RAID, 8E00 for LVM…). Run sgdisk -L to list every code it knows.
-c N:"name" / --change-name — set partition N's human-readable name (the GPT name field, up to 72 bytes of UTF-16).
-u N:GUID / --partition-guid — set partition N's unique GUID by hand (use R for a fresh random one). Useful when cloning a disk and you need the copy to have different GUIDs so the system doesn't confuse the two.

Whole-disk operations (big writes):

-o / --clear — wipe the existing table and start a fresh, empty GPT. The blank canvas before a -n series.
-Z / --zap — destroy the GPT and the protective MBR, leaving the disk un-partitioned. -Z does the primary structures; --zap-all also scrubs the backup table at the far end. This is how you truly start over.
-g / --mbrtogpt — convert an existing MBR layout to GPT in place, keeping the partitions.
-G / --randomize-guids — give the disk and every partition fresh random GUIDs. The companion to disk cloning.

Backup and restore (the part you'll be glad exists):

-b file / --backup=file — dump the entire GPT (both copies, all entries) to a small file. Read-only on the disk; do this before you touch anything.
-l file / --load-backup=file — restore a GPT from a -b backup file. The undo button — if you saved one first.

Alignment and housekeeping:

-a N / --set-alignment=N — set the sector boundary partitions snap to (default 2048 sectors = 1 MiB; the right answer for nearly every modern disk and the reason that "aligned on 2048-sector boundaries" line appeared earlier).
-A N:flag / --attributes — set GPT attribute bits on a partition (legacy_boot, hidden, no_automount…).
-e / --move-second-header — relocate the backup GPT to the true end of the disk. Exactly what you run after growing a virtual disk, so GPT uses the new space.

What GPT Actually Is

You can't really use sgdisk well without a picture of what it's writing, so let's build one — it's simpler and more elegant than it sounds.

A GPT (GUID Partition Table) disk has a fixed anatomy at both ends:

Sector 0 holds a protective MBR — a single fake old-style partition spanning the whole disk. Its only job is to make ancient tools that don't understand GPT see "one big unknown partition" and refuse to touch it, rather than seeing empty space and helpfully offering to format it. A decoy that protects the real map.
Sector 1 holds the GPT header: the disk GUID, where the partition entries live, how many there are, and CRC checksums of itself and the entry array.
Sectors 2–33 hold the partition entry array — 128 slots by default, 128 bytes each, one per possible partition. Each slot is a partition's type GUID, unique GUID, start sector, end sector, attribute flags, and name.
And then — here's the beauty — a complete second copy of the header and the entry array sits at the very last sectors of the disk. That "backup begins at sector 3907029134" line from the print-out is this secondary GPT.

GPT replaced MBR, the 1983 scheme that ruled disks for thirty years, for three reasons that all bit people hard. MBR stored partition sizes in 32-bit sector counts, capping disks at 2 TiB — a wall the whole industry slammed into around 2010. MBR allowed only four primary partitions (hence the awkward "extended partition" hack to squeeze in more). And MBR kept one copy of its tiny table in one place: corrupt that single sector and the whole disk's layout vanished with nothing to fall back on. GPT fixes all three — 64-bit sector addresses (good to 9.4 zettabytes), 128 partitions as standard, checksummed, and mirrored. The GUIDs in the name aren't decoration either: a partition's unique GUID is how a modern system mounts "the root partition" by identity even if the device name shuffles from /dev/sda to /dev/sdb between boots. Names move; GUIDs don't.

The Magic: The Backup Table That Saves You

Here's the part worth the whole page. Because GPT keeps that second, identical copy of the partition table at the far end of the disk, a corrupted primary table is not a dead disk — it's a recoverable one.

Picture the classic disaster: some installer, a careless dd, or a flaky USB enclosure scribbles over the first few sectors of your disk. With MBR, that's the entire ballgame — your one and only map is gone, and the partitions are a needle in a haystack of bytes. With GPT, sgdisk notices on -v that the primary header is trashed but the backup at the end is intact, and it can rebuild the front from the back:

sgdisk --verify /dev/sdb     # confirms: primary damaged, backup OK

Problem: The CRC for the main partition table is invalid. This table may
be corrupt. The secondary partition table appears to be intact, however.
Caution! After loading partitions, verify that they look correct!

When you then run an operation that writes the table, sgdisk regenerates the broken primary from the good backup — your partitions reappear, intact, exactly where they were. The data was never gone; only the map's front page was, and GPT keeps a spare bound into the back cover of the book. The first time this digs you out of a hole that would have been total with MBR, you become a GPT believer for life.

The lesson under the lesson: the safest move of all is to make your own backup before you touch anything, so even the rebuild has a known-good source:

sgdisk --backup=/root/sdb-gpt.bin /dev/sdb   # read-only, do this FIRST

That file is a couple of kilobytes. sgdisk --load-backup=/root/sdb-gpt.bin /dev/sdb puts everything back. Belt, braces, and a spare pair of braces sewn into the disk itself.

Reading It by Example

Build instinct by recognizing the shapes. Here's what common situations look like through sgdisk's eyes.

A blank, never-used disk → sgdisk -p /dev/sdb reports Creating new GPT entries and an empty table, or complains there's no valid GPT at all. This is a clean slate; -o then -n from here is safe.

Found valid GPT with corrupt MBR; using GPT and will write new protective MBR → the backup MBR or protective MBR got mangled but the GPT is fine. Harmless and self-healing; the next write fixes it. Don't panic.

Caution! After loading partitions, verify that they look correct! on -v → the primary table is damaged but the backup is intact (the rescue scenario above). You're one careful write from recovery — but verify the recovered layout before you mount or format anything.

A type code of EF00 on partition 1, sitting at the very front → this is an EFI system partition; you're looking at a UEFI-booting machine. 8300 partitions are ordinary Linux filesystems; 8200 is swap; 8E00 is LVM; FD00 is a Linux RAID member. The codes tell you the machine's whole storage story at a glance — exactly what the disk on the laptop this page was written on shows: an EF00 EFI partition, a small 8300 boot, and a big 8300 root holding an encrypted volume.

Total free space is 2014 sectors (1007.0 KiB) at the bottom → that tiny sliver is normal: it's the unused tail between the last partition and the backup GPT, plus alignment rounding. Free space measured in megabytes or more means a real unallocated gap you could -n into.

Cheat Sheet

Safe / read-only:

sgdisk -p /dev/sdX — print the table · sgdisk -i N /dev/sdX — detail on partition N
sgdisk -v /dev/sdX — verify integrity · sgdisk -P … — dry-run any command
sgdisk -L — list every type code · sgdisk --backup=file /dev/sdX — save the GPT to a file

The build-a-disk moves (all write):

sgdisk -o /dev/sdX — fresh empty GPT
sgdisk -n N:start:end /dev/sdX — new partition (0 = auto/end; +512M, +1G, -8G sizes)
sgdisk -t N:CODE /dev/sdX — set type (EF00, 8300, 8200, 8E00, FD00)
sgdisk -c N:"name" /dev/sdX — set name · sgdisk -d N /dev/sdX — delete partition N

The big hammers (write, irreversible):

sgdisk -Z /dev/sdX — zap GPT + protective MBR · sgdisk --zap-all /dev/sdX — also the backup table
sgdisk -g /dev/sdX — MBR → GPT in place · sgdisk -G /dev/sdX — randomize all GUIDs (cloning)
sgdisk --load-backup=file /dev/sdX — restore a saved GPT
sgdisk -e /dev/sdX — move backup table to the true end (after growing a virtual disk)

After any write: partprobe /dev/sdX so the kernel re-reads the table.

How You'll Actually Use It

Three patterns cover almost everything.

Cloning a disk's layout. sgdisk --backup=/tmp/src.gpt /dev/sda then sgdisk --load-backup=/tmp/src.gpt /dev/sdb copies the partition table (not the data) from one disk to an identical one in two commands. Then — and this matters — sgdisk -G /dev/sdb to give the clone fresh GUIDs, so the system doesn't end up with two disks claiming the same partition identity and mounting the wrong one.

Scripting fresh-disk prep. The reason sgdisk exists. In a provisioning script, the non-interactive nature is the whole point: a for loop over a rack of new disks, each getting the identical sgdisk -o -n … -t … line, zero prompts, fully deterministic. This is the job gdisk can't do — its menu needs a human.

Resizing after the cloud grew the disk. You resize a VM's virtual disk in the hoster's panel; the disk is now bigger, but GPT's backup table is stranded in the old middle of the disk and the last partition can't grow into the new space. sgdisk -e /dev/sda walks the backup table to the true new end, after which you delete and recreate the last partition larger (its start sector unchanged), then grow the filesystem. A surprisingly common dance once you run anything in the cloud.

Gotchas

Deleting a partition does not erase its data. -d removes the entry from the map — the bytes sit there untouched, just unreachable. Good news if you -d'd the wrong one (recreate it with the same start/end and it reappears); bad news if you were trying to securely wipe a disk before selling it (you weren't — use shred or blkdiscard for that).
The kernel doesn't see your changes until it re-reads the table. Wrote new partitions but lsblk still shows the old ones? Run partprobe /dev/sdX. If the disk is in use, you may need a reboot — the kernel won't re-read a table whose partitions are mounted.
-Z leaves the backup; --zap-all removes it. If you "zapped" a disk with -Z and a later tool still finds ghost partitions, the backup GPT at the disk's end survived. --zap-all is the thorough one.
0 means two different things in -n. In the start slot, 0 = first free sector. In the end slot, 0 = last usable sector. Same character, opposite ends — -n 3:0:0 is "from the next free sector to the very end," the most-used new-partition idiom there is.
Alignment isn't cosmetic. Partitions that don't start on a 1 MiB boundary force a modern SSD to do read-modify-write across its internal pages, quietly halving write performance. sgdisk's default 2048-sector alignment handles this for you — leave -a alone unless you have a specific reason.

History & Philosophy

GPT was born alongside UEFI in the late 1990s, when Intel was designing the firmware to replace the original IBM PC BIOS for the Itanium era. The old MBR scheme it inherited from 1983 simply couldn't address the disks that were coming, so GPT was written into the EFI specification from the start. The GUIDs everywhere are very much an Intel-of-that-period fingerprint — Microsoft's COM was built on the same globally-unique-identifier idea, the bet being that 128 random bits are so vast that two independently-generated IDs colliding is, for all practical purposes, impossible. (It's the same probabilistic shrug you meet all over computing: not proven unique, just unique beyond any reason to worry.)

The tool itself — GPT fdisk, shipping as the gdisk package — was written by Roderick W. Smith in 2009, deliberately modeled on the muscle memory of classic fdisk so that anyone who'd partitioned a disk in the MBR days could feel at home in the GPT world. The family is a neat little trio: gdisk is the interactive menu, cgdisk is the ncurses full-screen version, and sgdisk is the "s" for scriptable — the same engine with the human stripped out, built precisely so a shell script can do what a sysadmin used to do by hand.

And that's the quiet philosophy worth carrying off this page. Linux exposes the disk as just another file under /dev, and the partition table as a small, well-documented structure of bytes at known offsets — checksummed, mirrored, and dumpable to a two-kilobyte backup. There's no sorcery in there; it's a map you can read, copy, verify, and restore. The first time you --backup a GPT, corrupt the primary on purpose in a throwaway VM, and watch sgdisk rebuild it from the spare bound into the disk's tail, the partition table stops being something you fear and becomes something you operate. That confidence — that the most dangerous-feeling layer of the machine is, underneath, just a tidy little file with a backup copy — is the whole reward.

Flag Reference

Flag	Meaning
`-p`	Print the partition table
`-n`	Create a new partition
`-d`	Delete a partition
`-t`	Set a partition's type code
`-c`	Set a partition's name
`-i`	Show one partition's info
`-R`	Replicate the partition table to another disk
`-G`	Randomize disk and partition GUIDs (do after a `-R` clone)
`-Z`	Zap (wipe) GPT data
`-b`	Back up the GPT to a file
`-l`	Load the GPT from a backup file
`-g`	Convert MBR to GPT