Last Web page update: 3/11/2011
I'm a technical writer and consultant specializing in Linux technologies. This Web page is provided free of charge and with no annoying outside ads; however, I did take time to prepare it, and Web hosting does cost money. If you find this Web page useful, please consider making a small donation to help keep this site up and running. Thanks!
|Donate $1.00||Donate $2.50||Donate $5.00||Donate $10.00|
The GNU libparted library is an extremely important partitioning tool for Linux and some other operating systems (OSes). Programs such as the text-mode GNU Parted (aka parted) and the GUI GNOME Partition Editor (aka GParted) are built atop libparted, as are the partitioning tools employed by many Linux distributions' installation routines.
Unfortunately, although libparted has many very useful features, it also has some bugs and limitations. Some of these motivated me to write my own partitioning tool for GUID Partition Table (GPT) disks, GPT fdisk. Another issue motivates this Web page: GParted sometimes claims that disks have no partitions, even though other tools, such as the Linux kernel and the fdisk utility, clearly see partitions on the disk. This problem has been cropping up a lot lately on Web forums.
The problem is easily spotted. If you're using GParted, you may see a display like this:
If you use the text-mode parted on the disk, you'll see a somewhat more helpful diagnostic message than that produced by GParted:
# parted /dev/sdc print Error: Can't have a partition outside the disk!
Of course, a disk can be legitimately unpartitioned, so a completely "unallocated" disk isn't evidence of a problem by itself. The parted message, though, hints that partitions exist, but are corrupted. To be sure what's going on, you must use the fdisk -lu command on the disk. You can either type this command from a root login or precede it with the sudo command (the latter is most common in Ubuntu):
# fdisk -lu /dev/sdc Disk /dev/sdc: 16.2 GB, 16166944768 bytes 64 heads, 32 sectors/track, 15418 cylinders, total 31576064 sectors Units = sectors of 1 * 512 = 512 bytes Disk identifier: 0xd6810789 Device Boot Start End Blocks Id System /dev/sdc1 32 16779263 8389616 83 Linux /dev/sdc2 16779264 32581375 7901056 5 Extended /dev/sdc5 16779296 31576063 7398384 83 Linux
Note that the fdisk command uses a lowercase "L" and a lowercase "U" as options. Don't confuse the l with a digit 1, and be sure to include the u. This example shows that partitions exist on the disk: One (/dev/sdc1) is a primary Linux partition, another (/dev/sdc2) is an extended partition, and the third (/dev/sdc5) is a logical Linux partition. In the Master Boot Record (MBR) partitioning system used on most Linux computers, an extended partition serves as a placeholder for one or more logical partitions, so the logical partitions must reside entirely within the area occupied by the extended partition, as is the case in this example.
This type of problem has five common causes:
Other partition table problems, such as overlapping partitions, can cause the same symptoms; however, such problems are rarer than the ones just noted.
This page provides pointers on fixing a wide variety of partition table problems. I'm not an expert on the RAID problems, though, so my advice on fixing those problems is a bit thin. You can use the Linux mdadm utility to remove the RAID data from the disk. Removing the mdadm package can also eliminate the symptoms, although the cause (old RAID data) will remain on the disk.
For the remaining problems, the easy fix is to use my FixParts program,
as described in Fixing the Problem the Easy Way:
FixParts. If you need more control over the process, though, you can
use other tools to do the job, as described in Fixing the
Problem the Hard Way.
My FixParts program is designed to fix common problems of this type. You should refer to the main FixParts page for detailed usage information. A brief example of its use to fix this type of problem begins with using sfdisk to create a backup of your current partitions:
# sfdisk -d /dev/sdc > parts.txt
Change /dev/sdc as appropriate for your computer, of course. Copy the parts.txt file to a floppy disk, USB flash drive, CD-R, or other disk other than the one you're attempting to repair. With the backup made, you can launch FixParts on the disk and display its partition table via the p command:
# fixparts /dev/sdc FixParts 0.7.0 Loading MBR data from /dev/sdc MBR command (? for help): p ** NOTE: Partition numbers do NOT indicate final primary/logical status, ** unlike in most MBR partitioning tools! ** Extended partitions are not displayed, but will be generated as required. Disk size is 3981312 sectors (1.9 GiB) MBR disk identifier: 0x00080CB1 MBR partitions: Can Be Can Be Number Boot Start Sector End Sector Status Logical Primary Code 1 * 62 1171799 primary Y 0x07 2 1171800 1562399 primary Y 0x83 5 1564672 2744319 logical Y Y 0x0B 6 2746368 3981293 logical Y Y 0xAF MBR command (? for help):
If your disk has stray GPT data, you'll be told this, and given the opportunity to immediately erase the GPT data. If this is the disk's only problem, I recommend erasing the GPT data and then exiting by typing q, which will preserve your existing MBR data in its exact form.
If you have no old GPT data and if you're lucky, the display will be in order, as it is here. If any partitions are marked as omitted under the Status column, you should consult the FixParts documentation for advice on how to proceed.
Some partition table problems can result in partitions being changed from logical to primary or vice-versa. If these assignments are important to you, you can type r to change a partition to primary form or l to change it to logical form. (You'll be prompted for a partition number.) Be aware that not all conversions are possible; the Can Be Logical and Can Be Primary columns note which partitions can take either form at any given moment.
Assuming you're happy with your partition table, type w to write your changes to disk. The program will then make changes to the disk. If you can't seem to figure out how to make the changes you want, type q to quit without saving your changes. Your disk will then be untouched (except for any GPT data erasures).
One possible complication to this approach to fixing the problem is that your partition numbering may change. This can in turn affect boot loader configuration and (on Linux, FreeBSD, and other Unix-like OSes) /etc/fstab entries. Thus, you may need to edit /etc/fstab and your boot loader files if your partition numbering changes. Fortunately, many modern installations use UUID values to identify partitions, so partition number changes won't affect them.
Several possible solutions to the problem exist. I've seen some reports that simply launching fdisk on a disk and then saving the partition table (via the w command) can solve this type of problem, but this didn't work for me in my tests, so it could be that this works only on some specific variants of the problem. As this solution is easy if it works, it's worth trying before you try anything else.
Another relatively easy solution is to use my GPT fdisk program to convert the disk from MBR to GPT form. Because GPT doesn't distinguish between primary, extended, and logical partitions, such a conversion throws away the extended partition (while retaining the formerly logical partitions it contained), thus eliminating the problem. Unfortunately, this solution has a weakness: Not every disk can be safely converted. The biggest stumbling block is Windows, which can't boot from GPT disks on BIOS-based computers. Thus, if you boot Windows from this disk, this isn't a good solution. If the computer doesn't run Windows, though, or if the disk has only Linux boot and data partitions, or even if it includes Windows data partitions and the system boots Windows Vista or Windows 7 from another disk, such a conversion may make sense. Be aware that if you boot Linux or some other GPT-friendly OS from the disk, you'll probably have to re-install your boot loader once the conversion is complete.
For many users, unfortunately, the preceding solutions won't work or aren't practical. For them, it's necessary to fix the problem by altering the extended partition and keeping the disk in MBR form. One way to do this is to use the Linux sfdisk utility. (Note that this is sfdisk, not fdisk.) To begin, you must create a text file that contains partition information by typing sfdisk -d /dev/sdc > parts.txt. Change /dev/sdc to whatever your disk's device filename is, and type the command with root privileges (via a root login or by using sudo). You should then back up this file to a removable disk in case you make a bad mistake when editing it. You can then edit the parts.txt file, which will look something like this (note that the first line is a comment within the file; this isn't a command to be typed at a root command prompt):
# partition table of /dev/sdc unit: sectors /dev/sdc1 : start= 32, size= 16779232, Id=83 /dev/sdc2 : start= 16779264, size= 15802112, Id= 5 /dev/sdc3 : start= 0, size= 0, Id= 0 /dev/sdc4 : start= 0, size= 0, Id= 0 /dev/sdc5 : start= 16779296, size= 14796768, Id=83
Locate the extended partition by its Id value—it will be either 5 or f. If your extended partition extends past the end of the disk, as in this example, you must adjust the size field so that this no longer happens. You can compute a new size value by subtracting the start value from the total number of sectors on the disk from the fdisk -lu output—31576064 in this example. Thus, for my example disk, I calculate 31576064 - 16779264 = 14796800. (Try cutting-and-pasting values from your text-mode console into a Linux calculator application to minimize the risk of typos when performing these calculations.) Enter the value you compute into the size field for the extended partition. You can then write the change back to the disk by typing sfdisk /dev/sdc < parts.txt (changing the device filename as appropriate for your system). Note that this command will replace your entire partition table with whatever you've created in parts.txt, so you should double-check your work and be sure you type the command correctly, including entering the correct device filename—you do not want to overwrite the wrong disk! If sfdisk complains that it doesn't like your partitions, you may need to add the --force option, as in sfdisk --force /dev/sdc < parts.txt; however, you should triple- and quadruple-check your arithmetic and device filename before doing this. The problem is that sfdisk is rather fussy about the partitions it creates, so it sometimes complains about perfectly valid partition tables, particularly if another utility has had a hand in creating partitions in the past.
If your problem is something other than a too-large extended partition that overruns the end of the disk, you may be able to adapt these instructions for your situation. For instance, if you've got a logical partition that extends beyond the end of a too-short extended partition, you can increase the extended partition's size much as described here. Be wary of off-by-1 errors, particularly if you need to adjust partitions that lie between two partitions. The end point of a partition, as reported by fdisk, is the partition's start point plus its length minus 1; or:
end = start + length - 1
Put another way, the length is the end point minus the start point plus 1:
length = end - start + 1
All sector numbers are counted starting with 0, so the end sector number of the last partition should be one less than the total number of sectors on the disk, or a lesser value. (Many disks have a few unused sectors at the end of the disk; this is perfectly normal.) The preceding example computation didn't add 1 because it used the number of sectors rather than a target end value. Since the number of sectors is 1 more than the target end value, the "+1" part of the equation was implicit in the starting point.
Whatever you do, you should not adjust primary or logical partitions, and especially not their start points. The sfdisk program adjusts partition definitions, but not the filesystems, swap space, or other data they contain. Thus, if you change a data partition using sfdisk, you can make it impossible to access the data in the partition. You can adjust the extended partition in relative safety because it contains logical partition definitions, which sfdisk rewrites along with everything else. If you need to resize primary or logical partitions, you should be able to do so with parted or GParted once you've fixed the problem that was giving them problems. These libparted-based tools include the ability to manipulate filesystems within the partitions.
For safety, you should now type fdisk -lu /dev/sdc again and check that the partitions are all legal. If they are, try parted or GParted again. You should now see your partitions on the disk, as shown here:
If you have problems with or comments about this web page, please e-mail me at email@example.com. Thanks.
Return to my main web page.