Last Web page update: 5/13/2010
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.
If you're eagle-eyed, you'll have spotted the problem from the fdisk output alone. The parted output provides another clue. If you don't care for puzzle games, I'll point it out now: The extended partition (/dev/sdc2) ends at sector number 32,581,375, but the disk has just 31,576,064 sectors. In other words, the extended partition is impossibly large! Fortunately, the logical partition within the extended partition is within legal bounds, so it's possible to recover the system without data loss.
Similar symptoms can occur if a logical partition extends beyond the bounds of the extended partition. I've not seen reports of this problem "in the wild," but I've created it by mucking about with the low-level disk structures. I recommend you review the start and end partition numbers provided by fdisk to ensure that no partitions overlap or extend beyond the scope of the disk. Be careful with those numbers—they can get quite large, so it's easy to mis-read one or err when copying them into a pocket calculator.
I'm not sure what causes this problem in real life. (I created it artificially on a USB flash drive for this Web page.) I have noticed that several people who've reported this problem have mentioned that they've used a variety of data recovery tools, though, so one of them may be creating bogus extended partitions.
Warning: Every possible fix for ths problem carries with it some risk of doing further damage. If possible, you should back up your important data from the drive before proceeding. At the very least, back up your existing partition table by typing sfdisk -d /dev/sdc > parts.txt (changing /dev/sdc to your disk device filename) and then copying the parts.txt file to a safe removable medium, such as a USB flash drive. If you seriously damage your partition table, you should be able to restore it by typing sfdisk /dev/sdc < parts.txt, as described shortly.
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 rodsmith@rodsbooks.com. Thanks.
Return to my main web page.