If you’re a computer tinkerer (since you’re here, there’s a pretty good chance you are), you’re probably familiar with the following dreaded sight: You’ve finished one of your projects, and have just rebooted. You’re greeted with a pitch black screen with the words in tiny white letters, “Invalid partition table!” It’s dreaded because that’s as far as your machine will get while booting.
Let’s take a look at exactly what a partition table is and why it’s important to take care when reconfiguring your computer’s drives.
All About Hard Disk Drives
To help understand partitions, it is useful to understand the media: the hard drive.
The Anatomy of a Hard Drive
The handling of drives is based on the original construction of hard disks. (While modern SSDs aren’t built this way, they do share the same formatting.) These disks consisted of one or more platters of magnetic material. The platters spin over an arm (not unlike the needle arm of a record player), which also moves back and forth across the disk’s radius. The arm not only reads the disks, but magnetizes (i.e. writes data) as well.
Saving Data to Hard Disks
The circular platters of hard disks are divided up into tracks, or the circular regions around the disk. When a drive has more than one platter these are also called cylinders, since they are three-dimensional. Sectors are the segments of a circular track, with each sector holding some number of bytes of data (originally 512, more recently as high as 4,096). This previous article contains some great detail on how data is actually saved (sectors are labeled “B” in the below image).
But for our current purpose, it’s enough to know that files are spread across those sectors. When you save a file, your operating system begins writing its data to the hard disk one sector at a time until it’s completely stored. When you open the file later, the arm will read these sectors one at a time until the file is loaded again. If the sectors are located together, they comprise a block. It is these blocks that Windows is trying to re-arrange when defragmentation takes place, so that sectors related to the same file are close together.
Formatting a Hard Disk
But when your operating system accesses a disk’s sectors, all it sees is ones and zeroes. You need to let the OS know how to interpret those as files and folders.
Each operating system stores data on a hard disk in its own way — this format is called a file system. For example, the original Windows file system used File Allocation Tables (FAT) to store information about all the directories and files on the disk. This information sat at the beginning sectors of the hard disk, and if they were corrupted in any way you wouldn’t be able to access your data (without help). In contrast, the Linux ext3 file system uses little summaries of the sectors containing file data called inodes, which are spread out across the disk. If the list of these inodes was damaged, a user could run a utility to rebuild it (since the inodes themselves still exist).
File systems apply to disk paritions. In the past, disks came with only one partition, but many nowadays contain more. These additional partitions may, for example, hold the manufacturer’s recovery image for the machine. The below image shows a hard disk with multiple partitions of different types.
Types of Partition Tables
The partition table then describes how the zeroes and ones are divided into partitions, and which file systems the partitions use. Armed with this information the OS can correctly interpret the sectors of the disk, understand which ones contain your files, and read them so you can admire your cat’s selfies. Without this information, on startup the bootloader will look at many millions of bits, not knowing where the OS is. And a bootloader is not in the habit of looking around. It will simply give up with a short, grumpy message.
Your machine will likely already have one of the following types of partition table:
- GPT (GUID Partition Table)
- MBR (Master Boot Record)
- APM (Apple Partition Map)
- BSD Disklabels
What’s the point of this article then, if a partition table is already there? Well, there are times when you’ll need to modify entries in the partition table, or even remove them and start over.
When Do You Modify Partitions and/or Partition Tables?
It’s not advisable to go mucking about with your disks’ partition tables unless you really need to do so. Because every time you do so, there’s a chance it goes wrong. The following sections describe instances where you may be changing it without even realizing.
You’re Installing an Alternative Operating System
If you’re a stalwart Linux fan, no matter the OS that comes bundled with your new machine you’ll be wiping it out. And when you do that, the installer will ask you which partition you want to use. It will change the ID of the partition you select to Linux, updating the partition table. Now, next time the machine next boots up it will look for a Linux kernel to pass control to.
You’re Resizing or Modifying an Existing Partition
You’ll also change the partition table if you’re resizing, renaming, or reformatting of any of the system’s partitions. Even if you’re only changing the name (label) of a partition as shown in the below image, you’re still writing information to the partition table. And therefore you run the risk of that partition table update going bad, leaving you stranded.
You’re Restoring a Clone Copy of Your Drive
If you use a disk-cloning tool to back up your machine, you may be writing partitions directly to the hard disk (rather than syncing or copying files one by one). In this case, it’s important to make sure the partition matches what’s in the partition table. You won’t typically have an issue if you’re cloning the entire drive, as this will include the partition table. But if you only clone individual partitions, on restore you may be writing back a partition that doesn’t match the size or file system listed in the partition table.
How to Avoid Partition Table Issues
The easiest way to avoid these issues is to clone the entire disk when completing a backup. You are making regular backups, aren’t you? Then when you restore, you’re actually returning your disk, bit by bit, to the exactly way it was before.
But perhaps you need to optimize your backups (e.g. because you don’t have the space to clone the whole drive). In this case make sure you’re doing a backup of the partition table as well. This is usually an option in cloning programs (the image above shows a backed-up MBR created using Clonezilla ). It’s a little less reliable than cloning the whole drive though. There’s nothing preventing someone from messing with the configuration of the drive in the meanwhile.
Another option is to design your backups so they aren’t dependent on exact partitions. Instead, find a way to backup each element of your system (OS, programs, data, configs) individually. Then you can restore them to a system with a different partition scheme. For example, suppose you have a Windows system. The OS and programs are on the C: drive, and your personal data on the D: drive (two separate partitions). If you end up having to restore both to the C: drive of a new machine later, you’re still OK. At least all your data is intact.
Beware the Partition Table
A partition table is a sensitive critter. Before you undertake any of the activities above, make sure you have a backup. Two of different types is even better (e.g. one clone copy of the disk, with individual backups of your programs, settings and files). One small misstep can leave your system in an unbootable state, with little hope for recovering your data.
Have you ever seen one of the errors listed above? Or perhaps you have a solid backup strategy? Let us know your experience trampling (or not) your partition table in the comments below!