Repair an MBR Partition Table with fixparts

fixparts fixes specific problems in an MBR partition table, such as bad primary or logical numbering. It will happily rewrite your disk's first sectors if you let it, so treat it with respect. The examples use FixParts 1.0.10 from the installed gdisk package, version 1.0.10-1build1.

The route

Jump straight to the step you need, or tick off Done means at the end.

1. Confirm the target before opening it
2. Save a partition-table backup
3. Inspect the table without saving
4. Handle leftover GPT data carefully
5. Apply one supported repair
6. Review, then write exactly once
7. Re-read the result and check dependencies
Common traps

Allow about 20 minutes for inspection, longer if you need to shut down services or boot rescue media. You need a root shell for the disk write, a backup destination on a different disk, and a disk that genuinely uses MBR partitioning. This is a partition-table repair tool, not a general partition editor.

1. Confirm the target before opening it

List disks and their partition-table types first. This is an ordinary, read-only check:

$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,PTTYPE,MODEL
$ command -v fixparts
/usr/sbin/fixparts
$ dpkg-query -W -f='${Package} ${Version}\n' gdisk
gdisk 1.0.10-1build1

Use the whole disk in later commands, such as /dev/sdb, never a partition like /dev/sdb1.
Check the PTTYPE column actually says MBR. fixparts refuses conventional GPT disks outright, and pointing it at a partition path is not a safe shortcut.

Checkpoint

Record the exact device name and model from lsblk. Do not carry on from memory if several disks are a similar size.

2. Save a partition-table backup

Before using a tool that can rewrite the first sectors of a disk, save a text dump of the partition table to another storage device. This is unprivileged if you can read the disk; add sudo only if it complains:

$ sudo sfdisk --dump /dev/DEVICE > /path/on/another-disk/DEVICE-partitions.txt
$ test -s /path/on/another-disk/DEVICE-partitions.txt && echo 'backup is non-empty'
backup is non-empty

Replace both placeholders. Do not put the backup on the disk being repaired, and keep it until the machine has booted and the filesystems have been checked. The dump helps reconstruction with sfdisk, but it is not a substitute for a real filesystem backup.

Destructive action

Saving in fixparts rewrites partition-table data. It can change partition numbers and ordering, and one mistake can make filesystems unreadable. If the data matters, make a separate file-level or image backup and plan a recovery boot before you go any further.

3. Inspect the table without saving

Start fixparts with elevated privileges, since the device normally needs them:

$ sudo fixparts /dev/DEVICE
FixParts 1.0.10
Loading MBR data from /dev/DEVICE
MBR command (? for help): p

The exact banner and rows depend on your disk. p prints partition numbers, active flags, sector ranges, primary or logical status, omission state, convertibility and type codes.

fixparts hides the extended partition in its own interface and regenerates one when needed. Its displayed numbers are not guaranteed to become the kernel's final numbers: that is normal behaviour, not a sign the display is broken.

Checkpoint

Use p, compare every start and end sector against your backup and earlier notes, then type q if you only meant to look:

MBR command (? for help): q
Do you really want to quit? (Y/N): y

q abandons in-memory changes only. It does not undo the optional GPT-signature cleanup described next.

4. Handle leftover GPT data carefully

When fixparts starts, it scans for GPT headers. A disk that looks like MBR but still carries stray GPT data may prompt you to erase it. Read the prompt and confirm the device before accepting; if it actually looks like a normal GPT disk, stop rather than forcing an MBR interpretation.

Warning

This initial cleanup is the one exception to the safe, in-memory rule above: accepting it can erase a GPT header immediately, and no fixparts q restores an erased header. Only accept it once you are sure MBR is the intended layout and your backup exists.

5. Apply one supported repair

At the MBR command prompt, make the smallest change that fixes the problem:

l changes a selected partition to logical, when the layout permits it.
r changes a selected partition to primary, when the layout permits it.
o omits a partition from the saved table. It stays visible while you edit, but is lost the moment you write.
a toggles the active or boot flag.
t changes a partition type code, entered as one-byte hexadecimal.
s sorts the display by on-disk position.
c recomputes CHS values, obsolete but still relevant to some old software.

fixparts cannot create partitions. For ordinary type-code, flag or deletion work, the manual actually recommends fdisk, because fixparts can renumber partitions even when you never asked for a layout conversion.

If a conversion is refused, inspect the layout rather than forcing it. Primary and logical partitions cannot be interleaved arbitrarily, though omitting a preceding partition can sometimes free the space a logical conversion needs. Remember that omission itself is destructive once saved.

6. Review, then write exactly once

After the edit, type p again and check the sector ranges, selected status, active flag and type code match what you expect. Use ? if you lose your place:

MBR command (? for help): p
MBR command (? for help): ?
MBR command (? for help): w

w writes the table and exits; treat its confirmation prompt as your final checkpoint. If anything looks wrong, type q instead. Once the write completes, stop using the old partition numbers until the kernel and your tools have rediscovered the new table.

7. Re-read the result and check dependencies

After fixparts exits, ask the kernel and a partitioning tool what they now see:

$ lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,PTTYPE /dev/DEVICE
$ sudo fdisk -l /dev/DEVICE

Some running kernels will not immediately re-read a changed table, especially with partitions still mounted; a reboot into maintenance or rescue mode is often the cleanest next move. Do not mount filesystems or start services until the device and partition numbers match your plan.

Check anything that names partitions directly too. A renumbered table can break boot-loader entries and /etc/fstab references such as /dev/sdb1. Filesystem UUIDs are safer where possible, but verify them against the real filesystems before you edit anything. If the result is wrong, stop, boot from recovery media if you need to, and restore from the saved dump or a tested image backup rather than running a guessed restore command against the disk.

Common traps

Targeting a GPT disk. That is not an MBR repair job; use a GPT-aware tool or restore the intended GPT layout instead.
Trusting displayed numbers. fixparts numbers are temporary editor numbers, not a promise about final Linux device names.
Ignoring CHS quirks. CHS values are mostly obsolete, and fixparts itself warns its values may be wrong on disks smaller than about 8 GiB except on Linux.
Hitting the partition cap. The tool loads at most 128 partitions: four primary entries plus 124 logical entries.
Repairing a live disk. A mounted root or boot disk is a poor repair target; use a rescue environment and a maintenance window instead.

Done means

Target confirmed as the intended MBR disk.
Backup exists as a non-empty partition-table dump on different storage.
Table reviewed with p before w was ever used.
Post-write checks pass. Ranges, types and flags match what you expected.
References updated. Mounts, boot configuration and /etc/fstab checked for changed partition numbers.
Backup kept until a normal boot and filesystem check both succeed.