VisParted: The Partition Editor That Proves What It Did

Every other partition editor you can name is a front end. It hands your instructions to the same shared library, reads whatever that library prints back, and tells you it worked. VisParted does not. It reads and writes GPT, MBR and extended-boot-record chains itself, byte by byte, and when the work is finished it reads the disk back and proves the result matched the plan. That difference is the entire product. VisParted 2.0 ships in Parted Magic.

This page is the manual. It covers what every operation does, what it asks you before it does it, what it refuses and why, the terminal keys, the command line, and the evidence a finished job leaves behind. The same text ships inside the program: press Help in the window, ? in the terminal interface, or run visparted manual.

The VisParted window showing a disk's layout bar, findings brief and partition table

On This Page

Why We Rebuilt the Partition Editor From Nothing

A customer cloned a Windows disk to a larger drive and needed to move the recovery partition to the end so the system partition could grow. The tooling of the day could not do it, said little about why, and he finished the job with a Windows product instead. That is a small story, but it is the whole industry in miniature: partition editors that fail quietly, explain nothing, and leave a technician guessing whether the disk is now worse than when they started.

So we did not patch it. We rebuilt the partition editor from an empty file, around one idea: a disk utility should never say a thing it has not verified. Just over nineteen thousand lines later, VisParted 2.0 contains no source code from GParted, from GNU Parted, or from any other partition manager, and links no other project’s libraries at run time. We did not estimate that — we compared every line of VisParted against the complete source trees of both projects and found zero matches. It is our own reader, our own writer, our own planner, and as of 2.0 its own FAT resizer.

Two rules shape everything below:

  • Nothing is silent. Long work narrates itself. A stalled tool is reported, not waited on quietly.
  • Never guess. Unknown means refused, or reported as unknown. A refusal always says why, in the engine’s own words — and those are the same words in the window, the terminal and the command line.

How VisParted Works: Probe, Plan, Execute, Attest

Every change you make travels the same six stages. Understanding them is most of understanding the program.

1. Probe — it reads the disk itself

VisParted parses GPT headers, both entry arrays, MBR slots and the full extended-partition chain natively. It reads filesystem superblocks directly — ext2/3/4, NTFS, FAT12/16/32, exFAT, btrfs, XFS, linux-swap, LUKS1/LUKS2 headers and LVM physical-volume labels — and builds its own allocation maps from the filesystem’s own metadata. That is why it can tell you things a scraper structurally cannot: that your primary and backup GPT disagree, that a filesystem believes it is larger than the partition holding it, that two volumes on this disk carry the same identity. Nobody printed that for us. We read the bytes.

2. Model — the disk as an object, not a screen

What the probe read becomes a model: the device, its table, every partition with its four identities, every filesystem with its real used bytes, every free region, and what the machine is currently doing with each slot. Everything the three interfaces display is drawn from that one model, which is why the window, the terminal and visparted show cannot disagree with each other.

3. Plan — nothing happens when you click a button

Your intent compiles into an ordered plan: numbered steps, the risks in plain English, and the layout the disk will have afterward drawn beside the layout it has now. Destructive plans require you to type the word yes — a click is not enough for data loss. The plan also records a fingerprint of the disk it was built from, so if anything about that disk changed in the meantime it refuses to run rather than acting on stale assumptions.

4. Simulate — the plan is proved before it is run

Before any byte moves, the plan is replayed against a model of the disk: partitions that would overlap, a table that would not hold the result, an extended chain that would break, a filesystem asked to go below its measured floor. A plan that cannot be proved is not offered for execution. You can run this stage on its own from the command line at any time with visparted simulate.

5. Execute — journaled, narrated, resumable

Execution refuses to start while a partition the plan touches is mounted, active as swap, or held by an open LUKS container or an active volume group. Every step is written to a journal before it runs. External tools have their own output streamed to the screen as they produce it, so a long e2fsck is a program working, not a window that has stopped responding. If power is lost, the journal is what finishes the job.

6. Attest — the disk gets the last word

When a tool exits zero, most software calls that success. VisParted calls it a claim. After every operation it re-reads the disk with its own native readers and attests the outcome slot by slot: the table is what the plan said it would be, the filesystem is the kind and size it should be, the label survived, the identifier changed if it was supposed to change. If the disk disagrees with the plan, the operation is reported as failed — even when every tool involved reported success. That single rule catches drives that lie, tools that no-op, and firmware that silently ignores a command. The whole record is written to an evidence file in the journal.

Before You Start

Set where journals live — do this first

This is the one piece of setup worth doing before any work, and it takes ten seconds.

Parted Magic runs from RAM. The whole filesystem, /home included, is gone after a reboot — so by default a journal written where the program started would not survive the power cut it exists for. Click Journal… in the device row (or press J in the terminal interface) and pick somewhere that does survive: the boot USB stick, or any disk this job does not touch. VisParted lists the filesystems that qualify — persistent, writable, and not on the disk being changed — mounts the one you choose, and then looks there for interrupted work from a previous run, which is exactly what a freshly booted rescue system needs.

If there is genuinely nowhere — a single-disk machine with no stick in it — that is a real situation, not a fault, and VisParted does not block you. It states the consequence as a risk in the same confirmation as every other risk, and goes ahead when you accept it: an interrupted run would have to be redone rather than resumed. One combination is refused rather than offered, because it cannot be honoured — a move whose destination overlaps its own source consumes the original as it copies, and only the journal can finish it afterwards.

Every plan shows you where its journal will go before you commit, on the plan window itself, with a warning if that location lives in RAM.

One copy at a time

Starting a second copy of VisParted while one is already running is refused, and the refusal names the process holding the lock. Two windows writing one partition table is a way to lose a disk, not a convenience: each proves its plan against a layout the other is free to change.

Choosing a disk

Started with no arguments, VisParted opens whatever is attached. Name devices or image files to work only on those. A drive plugged in mid-session appears on its own — the kernel’s own hot-plug notifications drive the picker, so Rescan is for re-reading a disk, not for finding one. A disk that cannot be read does not take the window down with it: that one disk says what is wrong with it, and the rest stay usable.

Reading the Window

The graphical window, the terminal interface and the command line are not three programs that resemble each other. They are three faces of one engine, and each shows you the engine’s own words rather than a rephrasing of them. Here is what the window is telling you, top to bottom.

ElementWhat it shows
Header and badgesDevice name, size, sector size and table kind, plus badges for capacity, table, bus (NVMe, USB, SATA, SD/MMC, VirtIO) and SMART health with temperature where the drive reports one. A badge that cannot be known is absent, never guessed.
Layout barOne rounded segment per partition, width strictly proportional to size. The strip on top names the kind; the gauge below is filled by the filesystem’s own used bytes; free regions are hollow, dashed slots that state their size. A partition in use says so in words at its right edge — mounted for a mount, in use for active swap or a device-mapper holder.
Chip rowThe legible twin of the bar: one chip per partition, readable no matter how thin its true proportion drew. The bar never lies about size, so the chips carry the words. Click one to select it.
Findings briefWhat the probe itself proved is wrong or costly on this disk, with the cure one click away. See below.
Partition tableSlot, kernel node, start, size, type, filesystem with a colour chip, label, used (a bar drawn from the filesystem’s own allocation metadata), free, mountpoint, flags, and the filesystem UUID. The node column is hidden for image files, which have no kernel node to type.
Action groupsVerbs grouped FILESYSTEM, PARTITION and DEVICE, because the eye finds the family first. A verb that cannot apply right now is greyed with a tooltip saying exactly why — “disabled” with no reason is its own kind of clunky.
ThemeDark by default; the Light/Dark button switches live, including every open dialog.

Two behaviours are worth knowing about because they exist to protect you. The selection is anchored to the partition number, not to a row position, so nothing you are about to act on can shift under the cursor while the table redraws. And if the partition you had selected is gone after an operation, VisParted selects nothing and says so, rather than moving the highlight onto a neighbour — which is exactly how the next action lands on the wrong partition.

The device row

ButtonWhat it does
Table…Convert the partition table between MBR and GPT, or write one on a device that has none.
Device InfoEverything the probe read, verbatim: the device and its table, then every partition with its four identities — slot number, PARTUUID, PARTLABEL and the filesystem UUID — plus type, flags, size, usage and what holds it. A boot failure is usually one of those four disagreeing with fstab, so they are shown side by side. Copy puts the whole sheet on the clipboard for a support mail.
FS SupportWhat this machine’s tools can create, grow, shrink and check, per filesystem, with the missing tool named where one is missing. Grow and shrink are answered separately, because they are separate questions.
HistoryEvery action this program has taken on this machine, newest first.
Journal…Where journals live for this session. Set it before starting work.
HelpThe built-in manual — this text.
QuitLeaves. A running plan window cannot be closed out from under its own execution.

The Findings Brief: The Disk Explains Itself

Opening a disk is also a diagnosis. Everything the native readers already established as wrong or costly is stated in plain words with its cure attached, before you have asked for anything. Nothing in the brief ran a tool: it is what the probe itself proved. The window shows it under the layout bar, the ! key pages it in the terminal, and visparted doctor /dev/sda prints it into a ticket.

FindingWhat it meansCure
A filesystem smaller than its partitionWhat an interrupted grow leaves behind — the partition was enlarged but the filesystem inside it was not.Check verifies it and grows it to fill.
A filesystem that believes it is bigger than its partitionThe signature of a clone onto a smaller target. Mounting it can be actively dangerous.Stated with its numbers so you can decide before mounting anything.
Two volumes with the same identityHow fstab, bootloaders and udev end up mounting the wrong one after a clone.New UUID, on whichever one is the copy.
A partition that starts off the 1 MiB gridCosts write performance on modern media; usually an artefact of an older tool.Fix Alignment, with the exact target offset it would move to.
A stale backup GPTThe primary and backup GPT disagree — firmware may read either.Named the moment it is read, not when it blocks you.
A broken extended chainAn EBR link that does not lead where it claims.Stated up front; a table this damaged is refused for planning rather than half-repaired.

No other partition editor opens with a diagnosis, because no other partition editor has read enough of the disk to write one.

Partition Operations, One by One

Every operation below compiles to a plan you read before it runs, and is attested against the disk afterwards. What differs is what each one asks you, and what each one refuses.

Resize

Grows or shrinks in either direction; the filesystem and the partition move together. The smallest size is measured on the real filesystem when a tool on this host can measure it, and reported as not measurable when it cannot — never guessed, which is the whole lesson of a dialog that opens with its OK button already greyed out. Every keystroke is answered by the engine: the resolved size, the change it implies, a proportional bar of the result, or the refusal, so there is nothing to submit and discover.

Growing into space occupied by later partitions relocates them, and the dialog says how many before you commit. On a CHS-era partition that does not start on the 1 MiB grid, grow-to-max stops at the largest reachable grid size and quotes the way out: Fix Alignment first, then resize, and the sliver is reclaimed.

Move

Moving a partition means relocating every occupied byte to a new offset — the operation with the most to lose, and the one VisParted was rebuilt for. It is journaled, resumable and verified: data is copied in chunks against a bitmap of what has actually been written, so an interrupted move resumes exactly where it stopped instead of starting over or leaving a half-moved filesystem nobody can account for. Only the blocks the filesystem’s own usage map says are in use get copied, which is why a mostly-empty 500 GB partition does not take a 500 GB read to move. Every chunk is hashed and re-checked after the table is rewritten, and FAT and NTFS boot sectors have their hidden-sectors field repointed so the volume still knows where it lives.

The move dialog answers as you type: the resolved start offset, which way it slides and how far, and the layout bar as it would look. max means as far as it will go — the truth of the span this partition can actually reach, whether or not that span touches the end of the disk. A partition with no free space beside it cannot move, and the button says so rather than opening a dialog whose every answer is already there.

Copy

Copies a whole partition into free space on the same disk or another one, with source and destination chosen in one dialog and a live preview of the destination as it would look. The source is only ever read — nothing is written to it, including when source and destination are the same disk. The copy is verified against a hash taken before the first byte moved. Only disks this session was opened with are offered as targets: a copy writes to the disk you chose, and choosing it is not something a partition editor should do on your behalf.

Copying a filesystem that is being written to is a copy of no particular moment, so a mounted source is refused by name.

New and Delete

New creates a partition in a free region, optionally formatting it in the same plan. On MBR it handles primaries, the extended container and logicals — slot 5 and up — writing the EBR chain natively. The whole form is live: size, type, name, filesystem and label all revalidate through the engine as you type, so a label one character too long, or a size below a filesystem’s own floor, is answered while you are typing rather than after you press a button. On a device with no partition table, New offers to write one first rather than dead-ending.

Delete removes the slot. The bytes are not touched — to destroy the contents as well, use Shred, which can take the slot with it in the same plan.

Format

Writes a fresh filesystem: ext2, ext3, ext4, NTFS, FAT16, FAT32, exFAT, btrfs, XFS, linux-swap, or an LVM physical volume. The label limit belongs to the kind, so changing the kind can make a label too long — the dialog says so instead of quietly cutting what you typed. FAT volume serials are written natively.

On OK, where the mkfs tool offers a no-op mode (mkfs.xfs -N, mkfs.ext* -n), VisParted asks it whether it could make this filesystem here — so “too small” is answered before you are shown a destruction warning rather than after. The other tools have no such mode; they refuse at execute time, having written nothing.

Check

Two legs, both with the tools’ own words on screen: repair what the filesystem’s own checker can, then grow the filesystem to fill its partition. That second leg is the cure for the most common finding on a cloned or half-resized disk. There is no dialog — there is nothing to choose, and the plan window is the confirmation. FAT12 volumes are probed and checked like any other, though this build neither creates nor resizes them.

Label, New UUID, Flags, Type and Name

Label renames the filesystem — the name a file manager shows, and what LABEL= in fstab resolves. It lives in the filesystem, not the partition table, and changing it reads and reformats nothing. The dialog answers as you type: how much room is left, and the characters FAT and exFAT reject, in the engine’s own words.

New UUID gives the filesystem a fresh identifier — the cure for a cloned volume, verified by reading it back. Recipes match GParted’s for each kind; FAT is a documented native write of the serial bytes. The plan carries the risk that anything naming the old identifier, fstab and bootloaders included, stops matching.

Flags, Type and Name is what the table says about a partition: the MBR type byte and boot flag, the GPT type GUID, GPT attributes, and the GPT partition name. Nothing inside the partition is read or changed by any of it. One change at a time — and the dialog says so while you work, naming what is pending, rather than quietly keeping one change and dropping the rest. The type and the name are checked as you type.

Fix Alignment

The smallest journaled move that puts a partition back on the 1 MiB grid, using the same verified machinery as any other move. The tooltip tells you the exact offset it would move to before you click.

Shred

Overwrites a partition’s bytes in place: one pass of zeros, one pass of a seeded random stream, or a random pass followed by a zero pass. The random data is a keyed stream derived from a journaled seed, so the full read-back verify can re-derive and check every byte rather than merely confirming that something was written. After the last pass the slot must probe as no filesystem at all, or the step fails. Optionally the same plan then deletes the empty slot — one intent, one typed yes, and nothing of the partition survives, not even the entry.

Stated plainly, because it matters: this is a block-layer overwrite. Sectors the device has remapped away and any over-provisioned area are not reached. Device-level sanitization is the Secure Erase suite’s job, not this one’s.

Partition Table: Convert or Write

MBR converts to GPT and back in place where everything fits, with the whole table rewritten from the model — no third-party converter, no stale copies left behind. Every partition keeps its bytes, its filesystem and its label; nothing inside them is read or written. What does not survive is partition numbering and the way the disk boots, and the plan lists exactly what changes before anything is written.

On a device with no table — a blank disk, or one holding a single whole-disk filesystem — the same button writes a fresh GPT or MBR. If there is a filesystem there, writing a table destroys it, and the plan demands a typed yes.

Mount and Unmount

The button’s label is the state: Mount, Unmount, Swapon or Swapoff. The system fstab is consulted first — on Parted Magic the mount daemon’s entry is the authority — with the daemon’s own option table used when no entry exists. An fstab entry naming the partition by device path, UUID=, LABEL=, PARTUUID= or PARTLABEL= is all honoured, on both GPT and MBR. Mounting runs off the main loop with the tool’s words on the status line, because an unmount can block on a final sync.

A locked LUKS container and an LVM physical volume both refuse, with directions to Encryption or LVM — the filesystem lives inside the mapping, and mounting the raw partition would be wrong even if the kernel allowed it.

Encryption (LUKS)

Opens a locked LUKS1 or LUKS2 container, or locks an open one. The passphrase travels on cryptsetup’s stdin and never appears in a command line, a log, or a journal. Opening attests that the kernel lists the crypt mapping; locking refuses while the mapping is mounted, active as swap or stacked under LVM, and attests that the mapping is gone.

A partition under an open container is in use, full stop: the bar marks it and every destructive action refuses by name until it is locked. The mount table alone cannot see this, because the mount lives on /dev/mapper, not on the partition — which is precisely the case that gets disks damaged by other tools.

LVM

Physical volumes are probed natively — kind, PV UUID, and the volume-group name read from the live metadata text. Creating a PV is a Format kind, so it carries the destruction risk and typed yes like any other format. The LVM button activates or deactivates a volume group and manages membership: create a VG on an orphan PV, add an orphan to a VG, remove a PV from its VG, remove a whole VG. Every verb is attested through the native probe and LVM’s own listing. Deactivation refuses while any volume is mounted. Logical-volume creation and removal arrive in a later release, and the refusal says so rather than pretending.

Whole devices with no partition table

Flash media and encrypted externals are often one filesystem written straight across the device, with no partition table at all. VisParted treats that as a first-class object rather than an error: it is partition 0. Mount, Encryption and LVM act on it in every interface, and --part 0 addresses it on the command line. On a disk that does have a partition table, --part 0 refuses — it exists exactly when the machine itself treats the device as one filesystem.

The Size Language

Every prompt that takes a size or an offset — in the window, in the terminal, on the command line — speaks one language, resolved in one place so the three interfaces cannot drift apart on what 4 means.

You typeIt means
44 GiB. A bare number is GiB — the unit partition work is actually done in.
500m, 2g, 1tMiB, GiB, TiB. The iB is optional: 500mib is the same thing.
500mb, 2gb, 1tbDecimal megabytes, gigabytes, terabytes — the numbers on the drive’s label.
4096b, 2048sExact bytes; sectors at the disk’s real sector size.
12.96gFractions are accepted and rounded to the nearest byte, so anything the program printed can be typed back into it.
min, maxThe measured bounds. min refuses rather than guessing when the floor cannot be measured on this host.
currentLeave it as it is — useful for reverting a half-typed entry.
+2, -500mRelative to the current value: grow by 2 GiB, shrink by 500 MiB. In the move dialog, slide right or left by that much.
50%Half of the largest reachable size.
+10%, -10%A tenth more, or a tenth less, than the current size.

Partition Editor Filesystem Support

Move and copy work on any partition, because both operate on blocks and on the filesystem’s own allocation map rather than on a filesystem driver. The remaining columns depend on the tools each filesystem provides. Click FS Support in the program to see what this particular machine can do right now — checked against the tools present, not against a marketing table.

FilesystemCreateGrowShrinkCheckLabelNew UUIDMove / Copy
ext2 / ext3 / ext4✓✓✓✓✓✓✓
NTFS✓✓✓✓✓✓✓
FAT16 / FAT32✓✓✓✓✓✓✓
FAT12———✓✓✓✓
exFAT✓——✓✓✓✓
btrfs✓✓✓✓✓✓✓
XFS✓✓—✓✓✓✓
linux-swap✓✓✓—✓✓✓
LVM2 physical volume✓—————✓
LUKS1 / LUKS2——————✓

Four of those rows deserve their footnote, because “it resizes” is not the same sentence for every filesystem:

  • FAT16 and FAT32 are resized natively. Every release before 2.0 loaded libparted at run time for this one job. VisParted 2.0 does the FAT arithmetic itself and links nothing. Two consequences are honest limits: the cluster size is kept fixed, so a FAT volume’s floor is whatever its own cluster size allows — going below that means re-clustering, which is a reformat here — and the resizer holds a whole allocation table in memory, so tables past 256 MiB are refused by name rather than attempted.
  • btrfs and XFS have no offline resizer, and their tools take a mountpoint rather than a device — the work happens inside the running kernel. For those two, VisParted mounts the volume at a private directory of its own, resizes it, and unmounts it again before the partition table is touched. A volume something else already has mounted is refused, not reused: a mount this program did not make is one it cannot promise to take down.
  • XFS grows only. No released xfsprogs can shrink an XFS filesystem — that is a property of the filesystem, not a gap here. It also grows in whole allocation groups, so the size it settles on is its own, reported afterwards rather than predicted.
  • btrfs decides its own floor by relocating chunks. The minimum shown is what the volume has allocated today; btrfs may go lower, or refuse in its own words. A btrfs spanning several devices is refused outright — this program can only see the one in front of it.

Windows and Booting

Moving a Windows partition is easy. Moving one and still booting afterward is the hard part, and it is the case this program was rebuilt for.

VisParted surveys the boot chain natively. It locates BCD stores on FAT EFI system partitions and on NTFS system partitions, reads the registry hive itself, decodes which partitions each boot entry references and how — by MBR byte offset, which breaks when a partition moves, or by GPT GUID, which does not — and checks GRUB’s BIOS embedding in the gap after the MBR. Run visparted boot /dev/sda, or read the survey before committing to a move.

After a move or a copy, the hidden-sectors field in FAT and NTFS boot sectors is repointed so the volume still knows where it lives. Where a BCD entry references a partition by MBR offset, VisParted can patch the store in place — and where it cannot patch one safely, it says which entry and why rather than writing something hopeful.

The identity rules worth carrying in your head: a device path breaks when the kernel enumerates differently; a filesystem UUID survives a move but changes when you reformat; PARTUUID survives everything except rewriting the table; and converting MBR to GPT mints new partition GUIDs, so PARTUUID= references stop matching while UUID= references keep working. VisParted states all four identities side by side on the Device Info sheet, which is usually where a boot failure is diagnosed in about fifteen seconds.

When the Power Fails: Journals and Resume

Every execution writes a journal: the plan, each step as it begins and as it completes, and for a move, a bitmap of exactly which chunks have been written and verified. Nothing is inferred afterwards from what the disk looks like.

Boot Parted Magic again and start VisParted. It goes looking for interrupted work on its own and offers to finish it, naming what was interrupted and on which disk — because resume existing only as a command line is, for someone who launched this from a desktop menu and lost power, the same as not existing at all. If more than one interrupted run is found, all of them are offered; showing only the newest and calling the rest invisible is how work gets lost.

Finishing continues from the last verified chunk rather than restarting, and the partition table itself is only rewritten once the data is where the plan says it should be. From a command line:

visparted resume                              # list what can be finished
visparted resume --journal /mnt/usb/journals/visparted-journal-… --commit

Two kinds of work are load-bearing on the journal specifically, and VisParted tells you which before you start: a move whose destination overlaps its own source, which consumes the original as it copies, and a FAT resize, which snapshots the volume’s original tables before its first destructive write and replays the rest from that snapshot.

Refusals, and What They Mean

A refusal in VisParted is not an error dialog. It names the partition, the reason and what would have to change — and it is the same sentence in all three interfaces. The ones you are most likely to meet:

What it saysWhat to do
The partition is mounted, or active as swapUnmount or swapoff — the button does both, and its label tells you which one it is about to do.
The partition is held by an open LUKS container, or an active volume groupLock it under Encryption, or deactivate the VG under LVM. The mount table cannot see either of these; VisParted can.
The smallest size could not be measured on this hostThe tool that measures that filesystem’s floor is not installed. FS Support names it. Type an explicit size, and the resizer will refuse rather than truncate if it is too small.
No backend for this filesystem kind, or missing toolsThe plan is still worth reading, and is shown — it simply cannot be executed on this machine. FS Support says which tool is absent.
The disk changed since this plan was builtSomething else touched the disk, or a previous operation completed. Re-read the disk and compile the plan again; VisParted will not act on a stale picture.
This move consumes its own source and the journal will not survive a rebootPoint Journal… at a USB stick or another disk. This is the one case that is refused rather than offered with a warning.
The table is not usable for planningThe integrity findings say what is broken — a stale backup GPT, a broken EBR chain. VisParted refuses to plan on a table it cannot trust rather than half-repairing it underneath you.
Already runningAnother copy holds the lock, and the message names the process. Use the window that is already open.

The Terminal Interface

The full partition editor in a terminal — over SSH, over a serial console, and on a machine with no graphics stack at all. Every window in the graphical interface is one of these screens with pixels; nothing is missing here. Run visparted tui, or visparted --tui.

KeyActionKeyAction
↑ ↓select a partitioneresize
mmoveccopy
nnewddelete
fformatkcheck
lfilesystem labelinew UUID
gflags, type and nameafix alignment
sshredtpartition table
umount / unmountoencryption (LUKS)
vLVM!findings brief
Idevice infoJjournal location
hhistory?this manual
rrescanqback / quit

Prompts behave the way the graphical dialogs do: the engine answers every keystroke with the resolved value, the change it implies, and a proportional preview bar — in which partitions currently in use are marked with *. Enter accepts, Esc cancels, and a plan that carries a destruction risk asks you to type yes. Passphrase prompts echo stars and never store the text.

Command-Line Reference

Every capability has a command-line form. Plans serialize to JSON, so you can compile one on one machine, read it, and apply it on another — or keep it as the record of what you intended.

Looking at a disk

visparted show /dev/sda              # probe and display, integrity findings included
visparted show /dev/sda --json       # the same model, machine-readable
visparted doctor /dev/sda            # the findings brief
visparted info /dev/sda              # every partition's four identities
visparted boot /dev/sda              # survey the boot chain
visparted history -n 20              # what this machine has done, newest first
visparted manual                     # this text

Compiling a plan

visparted plan takes exactly one goal, resolves it against the disk as it is right now, prints the steps and risks, and optionally writes the plan to a file. Nothing is written to the disk by this command.

visparted plan /dev/sda --resize 2 --size min --out shrink.json
visparted plan /dev/sda --expand 1 --out grow.json
visparted plan /dev/sda --move 3 --at max
visparted plan /dev/sda --relocate-end 3
visparted plan /dev/sda --create 500g --fs ext4 --label DATA --out new.json
visparted plan /dev/sda --format 4 --fs ntfs --label Windows
visparted plan /dev/sda --copy 2 --size needed          # same disk
visparted plan /dev/sdb --copy /dev/sda:2               # across disks
visparted plan /dev/sda --check 1
visparted plan /dev/sda --new-uuid 2
visparted plan /dev/sda --fix-alignment 1
visparted plan /dev/sda --delete 5
visparted plan /dev/sda --shred 5 --pattern random-zero --delete-after
visparted plan /dev/sda --flag +boot --part 1
visparted plan /dev/sda --set-label PAYROLL --part 2
visparted plan /dev/sda --set-type "Linux filesystem" --part 2
visparted plan /dev/sda --convert gpt
visparted plan /dev/sdb --init gpt                      # a device with no table

Useful modifiers: --size and --at speak the size language; --logical places a new partition inside the MBR extended container; --pattern must be named explicitly for a shred, because a destructive default is not a default this tool has; and --fstab FILE scans an fstab or crypttab for references the plan would strand.

Proving and applying

visparted simulate shrink.json                          # re-prove against the disk now
visparted apply shrink.json --journal /mnt/usb/journals  # dry run: proof only
visparted apply shrink.json --journal /mnt/usb/journals --commit

apply simulates first and refuses if the disk drifted. Without --commit it stops after the proof and precondition checks, having written nothing. --journal is required and should point somewhere that survives a reboot and is not on a disk this plan touches; --accept-unresumable is how you say, deliberately, that there is nowhere on this machine that qualifies. --report-spool DIR seals a fleet report on success.

Immediate verbs

Mount, LUKS and LVM are not plans — they change no bytes on the disk — so they run immediately and are attested through the kernel’s own state.

visparted crypt open /dev/sda --part 3      # passphrase on stdin, or prompted on a tty
visparted crypt close /dev/sda --part 3
visparted lvm activate /dev/sda --part 2
visparted lvm deactivate /dev/sda --part 2
visparted lvm create /dev/sda --part 2 --vg vg0
visparted lvm extend /dev/sda --part 3 --vg vg0
visparted lvm reduce /dev/sda --part 3
visparted lvm remove /dev/sda --part 2

Evidence and Fleet Reporting

Data destruction has certificates. Partition work never did — the technician’s word was the audit trail.

Every completed job writes an evidence record into its journal: what was planned, what every tool said, how long each step took, and what the bytes read back as afterwards. That file is the primary record and it stays with the journal. Reporting is how it travels: VisParted seals the journal’s evidence into a content-addressed report — its identity is the hash of its own contents, so a report cannot be edited without becoming a different report — and delivers it to your own Parted Magic Report Server, which recomputes that identity before accepting it and countersigns the stored bytes with an Ed25519 signature you can verify offline, forever.

The shape fits a refurbishing bench: machines with no network until the job is done spool reports onto the boot USB, and one command pushes the spool whenever the wire exists. Re-syncing is harmless — a report the server already holds is answered as a duplicate, and counted as delivered.

visparted report build --journal JOURNALDIR --spool /mnt/usb/spool
visparted report show   /mnt/usb/spool/2026….report.json
visparted report verify /mnt/usb/spool/2026….report.json --key KEY
visparted report probe  --server https://reports.example.lan
visparted report sync   /mnt/usb/spool --server https://reports.example.lan

No server address is ever baked in or guessed — it comes from --server or VISPARTED_SERVER, always your word. Tokens use the same X-PM-Token header the rest of Parted Magic uses. An optional HMAC key adds tamper evidence to a report on top of its content hash. A fleet of machines partitioning drives in three buildings produces one auditable record, on your hardware, with no vendor account and no cloud in the path.

Practise on a Disk Image

Disk images are first-class targets: point any interface at a file and it behaves exactly like a 512-byte-sector disk — same probe, same plans, same attestation. That is the honest way to learn the program, and a real rehearsal for an unfamiliar operation with zero hardware at risk.

truncate -s 8G /tmp/practice.img
visparted gui /tmp/practice.img        # or: visparted tui /tmp/practice.img

Write a table, create partitions, format them, fill one, then shrink it, move it, and interrupt the move — the same journal and the same resume are waiting for you on a file as on a drive.

What VisParted Will Not Do

Software that lists only its strengths is asking you to find its limits on your own disk. Ours are here:

  • Logical-volume creation and removal arrive in a later release. Volume groups can be created, removed, extended and reduced today.
  • XFS cannot be shrunk, because no released xfsprogs can shrink it. It grows here.
  • exFAT is not resized — its tools offer no resizer.
  • A btrfs volume spanning more than one device is not resized: this program can only see the one in front of it.
  • FAT12 volumes are probed, checked, labelled and re-identified, but this build neither creates nor resizes them.
  • The native FAT resizer keeps the cluster size fixed, so a FAT volume’s floor is what its own cluster size allows; and it refuses allocation tables past 256 MiB by name rather than attempting them.
  • NTFS directory indexes are not rebuilt.
  • A partition cannot be moved and formatted in a single plan, and a primary cannot become a logical in place.
  • Shred is a block-layer overwrite. Remapped sectors and flash over-provisioning are not reached.

Every one of those refusals names itself before anything is written to the disk.

For whole-disk imaging and network deployment, use Parted Magic Clonezilla. For recovering partitions that are already lost and carving deleted files, Parted Magic includes TestDisk and PhotoRec, which are built for exactly that job. For device-level sanitization — the sectors a block-layer overwrite cannot reach — use Secure Erase.

Under the Hood

  • Native readers and writers. GPT, protective MBR, MBR and extended boot records are parsed and written by VisParted itself. Filesystem superblocks, LUKS headers, LVM labels, NTFS attributes, FAT directory entries and Windows registry hives are read directly. There is no parted subprocess anywhere in the program.
  • Nothing linked at run time. Earlier releases loaded libparted for one job — resizing FAT16 and FAT32. VisParted 2.0 resizes them natively and links no other project’s library. The debt to GNU Parted’s years of correct FAT arithmetic is acknowledged all the same, as is GParted’s source, where the correct invocations and exit-code contracts for the filesystem tools below were learned. No code from either project is used.
  • The tools it does run, as separate programs whose words you see and whose outcome it verifies itself: e2fsprogs, ntfs-3g and ntfsprogs, dosfstools, exfatprogs, btrfs-progs, xfsprogs, util-linux, cryptsetup, LVM2 and smartmontools. It reads their exit codes, and then re-reads the disk to find out what actually happened.
  • Integer arithmetic end to end. Bytes and logical block addresses, never floating point. Sector sizes from 512 through 4Kn are handled at their real size.
  • Proven every release. 26 automated test batteries and 458 individual checks run against real loop devices, real filesystems, real LUKS containers and real LVM volume groups — including a power-failure test that kills a running move with SIGKILL and requires the resume to finish it correctly.
  • Readable. One Python 3 program, just over 19,000 lines, shipped as source. You can read exactly what is about to touch your disk.

Partition Editor FAQ

Is VisParted just GParted with a new coat of paint?

No. VisParted shares zero lines of source code with GParted or GNU Parted — a claim we verified by comparing the complete source trees rather than asserting it. The architecture is different in kind: GParted drives a shared library for everything, while VisParted reads and writes the partition tables itself and verifies every outcome against the disk afterward.

What happens if the power fails during a resize or a move?

Boot Parted Magic again and start VisParted; it looks for interrupted work and offers to finish it. Work is tracked in chunks, so it continues from the last verified chunk instead of restarting or leaving the partition in a state nobody can describe. The table itself is only rewritten once the data is where the plan says it should be. The one thing to do in advance is tell it where journals live, since a live system’s own filesystem is in RAM.

Will Windows still boot after I move or resize its partition?

That is the case this program was rebuilt for. VisParted repoints the boot sector’s hidden-sectors field after a move or copy, and it surveys the boot chain first so you can see which partitions the BCD store actually references, and whether it references them by MBR offset or by GPT GUID, before you commit to anything.

Can it resize btrfs and XFS?

Yes — btrfs grows and shrinks, XFS grows. Neither has an offline resizer, so VisParted mounts the volume at a private directory of its own, resizes it, and unmounts it again before the partition table is touched. XFS cannot be shrunk by any released xfsprogs, which is a property of the filesystem rather than a limit of this program, and a btrfs spanning several devices is refused because only one of them is in front of us.

Does it still need libparted to resize FAT?

No. Every release before 2.0 loaded libparted at run time for that one job. VisParted 2.0 resizes FAT16 and FAT32 natively and links nothing. The resize is journaled: the volume’s original tables are snapshotted before the first destructive write, and an interrupted resize replays from that snapshot rather than guessing.

Where did the operation queue and undo go?

They were replaced deliberately. A queue lets you stack operations against a picture of the disk that stops being true the moment the first one runs, and “undo” on a partition table is a promise no software can keep once bytes have moved. VisParted instead compiles each action into its own plan, simulates it against the disk as it is right now, and journals it so it can be resumed. You get the review step the queue was really for, without the pretence of reversibility.

Does it need an internet connection or an account?

No. VisParted runs entirely offline. Fleet reporting is optional, and when you enable it the evidence goes to a report server you run on your own network — not to us.

Can I automate it?

Yes. Every capability has a command-line form, plans serialize to JSON, and you can simulate a plan and read the outcome before any machine touches a disk. visparted show --json gives you the whole model for a script to reason about. The terminal interface covers the interactive case over SSH or a serial console.

What hardware does it handle?

SATA, NVMe, SAS, IDE, USB and eMMC, with 512-byte, 512e and 4Kn sector sizes read at their true size. It works equally on a 2008 laptop drive with a 63-sector layout and on a 4Kn enterprise disk. Modern tools align everything to 1 MiB and treat anything else as broken — but a working XP-era disk starts at sector 63, and rewriting that layout to satisfy a convention would write into the partition next door. VisParted applies alignment only to what a plan actually creates or moves, and preserves the real position of everything it carries forward, including each logical partition’s own extended boot record. Drives that other editors declare unusable are simply drives here.

What about a USB stick with no partition table at all?

It is a first-class object, not an error. A filesystem written straight across a device is treated as partition 0: mount it, unlock it, activate it, or write a partition table over it — which destroys it, and the plan says so and asks you to type yes.

Get the Partition Editor

VisParted ships inside Parted Magic. One license covers unlimited drives and unlimited machines — no per-seat fees, no per-drive fees, nothing installed on the host. Boot it, do the work, prove the work, move on.

Get Parted Magic