Ubuntu – Unable to satisfy all constraints on the partition


I have dual-boot windows 7 32bit with ubuntu 12.04 lts 64bit in a single HDD. I wanted to gave my ubuntu partition more space of my HDD. Unfortunately, when I open GParted it showed me an unallocated space on my partitioning table. This very "unallocated space" actually contains my C:/ and D:/ partition of my windows 7. When I double clicked the item, it showed me this warning: "unable to satisfy all constraints on the partition".

Please, help me. I want my partitioning table to be fixed. So that, I can grow my ubuntu partition.

Best Answer

If you're saying that GParted is showing the entire disk as being unallocated, then you probably have one of two problems:

  • Leftover RAID data -- If the disk was used with motherboard-based software RAID in the past, the leftover RAID data can confuse GParted. Typing sudo dmraid -E -r /dev/sda in Linux can correct this problem; however, you should be absolutely positive that the system isn't currently configured to use RAID before you do this. (Some computers use RAID even on single-disk setups -- weird, but true.)
  • A damaged partition table -- Any number of partition table problems can cause GParted to flake out and claim the disk is unpartitioned. Most of these can be fixed by using my FixParts program on the disk. This program is part of the gdisk package in Ubuntu.

You might also want to consult my Web page on this problem, which describes it in more detail.

If you mean that only some partitions seem to be missing, but others appear in GParted, then the problem has another cause. Providing more detail, such as the output of sudo parted /dev/sda print and a clear description of precisely what's missing, is necessary to diagnose and fix the problem.

Edit: Based on the information in the comment below, it appears that the partition table is damaged. FixParts might be able to help, but I make no promises of that, and I advise caution in its use. If FixParts doesn't do an adequate job, TestDisk might be able to recover the lost partitions.

Background, and to answer your questions: On a traditional Master Boot Record (MBR) partitioning system (which you've got), there can be up to four primary partitions, one of which (the extended partition) can serve as a placeholder for an arbitrary number of logical partitions. The partition that fdisk has identified as w95 ext'd (lba) is an extended partition. Under Linux, primary partitions (including the extended partition, if one is present) are numbered 1-4, while logical partitions are numbered 5 and up. All the primary partitions are defined in the first sector of the disk (the MBR), but each logical partition is defined in its own data structure, known as an Extended Boot Record (EBR), which is similar in structure to an MBR. The message about "invalid flag 0x6165 of partition table 7" means that a key identifying feature of one of these EBRs is damaged. Depending on the partitioning software and the partitions involved, this can make it difficult or impossible to recover the partitions in the usual way.

Partitions contain filesystems, but the two are distinct concepts -- a partition is just a set of contiguous sectors on the disk (say, sectors 2048 to 923,647). A filesystem is a much more complex data structure that enables you to store files in a partition. The two are often created and manipulated together, but there are tools for doing each part of the job separately. fdisk and parted, for instance, both manipulate partitions but not filesystems; while mkfs, tune2fs, fsck, and similar tools manipulate filesystems. Filesystem-manipulation tools typically take partition identifiers as arguments, since they need a way to locate their filesystems, and partitions do that -- the filesystem usually begins on the first sector of the containing partition. I'm babbling on about this because it's your partition table that's damaged; your filesystems may well be perfectly OK, except that with the partition table damaged, you have no way to identify their start points.

TestDisk ignores the partition table and scans for filesystems in order to construct a new partition table, which is why it might be useful -- it doesn't need the data structures that are damaged. OTOH, scanning the whole disk for filesystems can be time-consuming and can turn up stray bits of old filesystems that are no longer valid, particularly if you've re-partitioned or moved filesystems on your disk in the past. TestDisk is also likely to fail if the filesystem is damaged, which could be the case -- whatever damaged your partition table might not have stopped there, but might have wreaked havoc with one or more filesystems. Thus, TestDisk should be used only as a last resort.