Mageia forum

Hi,

Bit of a problem with what seems like a corrupted partition table. I used diskdrake to delete a couple of partitions but now when I run disk drake I get:

I cannot read the partition table of device sda, it's too corrupted for me
I can try to go on, erasing over bad partitions (ALL DATA will be lost!).
The other solution is to not allow DrakX to modify the partition table.
(the error is extended partition: reading of partition in sector 4423744336 failed.
)

Do you agree to lose all the partitions?

'fdisk -l' returns:
fdisk: unable to seek on /dev/sda: Invalid argument

The first two partitions on the drive are still accessible and boot their OSs fine.

Is there any command to get this partition table fixed.


Thanks,
Nick

Does gparted offer more insightful information than diskdrake? If not, do the other OSes have partition managers which may be able to help?

gparted shows the entire disk as empty even though the first two partitions are accessible.

is this disk over 3 TB

if so i posted a post recently about same expirience and how i got out of it.

best of luck.

ill see if i can find it

edit

here it is

viewtopic.php?f=7&t=3855

regards peter

No only a 320Gb drive.

I have now found a solution to this by installing testdisk and letting it recover the deleted partitions.

I now edit the partitions using CentOS's disk manager, unfortunately every time I use Mageia's diskdrake on this drive it seems to corrupts the partition table in one way or another.

Nick

Well different partitioning tools do not always play nicely together. So best bet is to use only one tool for partitioning.
If you started with gparted, stay with it. If you started with diskdrake, don't use something else. If CentOS' disk manager works,
use that one exclusively.

This also applies for the used lowlevel partitioning tools, e.g. fdisk, cfdisk, sfdisk, (lib)parted etc.

This is a bug that has been lingering since it was introduced circa Mandriva 2009. Just like the OP, I once had a disk clobbered by diskdrake.

The problem is that the bug is both intermittent and devilishly difficult to reproduce, because diskdrake clobbers the "offending" partition table.

My take on this is that it seems to be related to whether the partitions end up on sector boundaries or not. Reason I say that is that I have been able to reproduce a similar problem using GParted by messing about with some sector boundaries settings (or whatever the setting was called).

Rhis is only one aspect of the problem.

The main rule is, as the doktor already said: DO NOT mix tools for partitioning the same harddisk! Repeat this 100x while powering up your system every day.

One reason is the different way gparted and other tools and diskdrake work. We found that out early in 2004 or 2005 during a linux event where Frank Hoffmann held a speech about different distributions and I was there as visitor. Result:

You start with diskdrake on a fresh harddisk.
You define 3 primary partitions and an extended partition. On this extended partition you define one logical drive and leave the rest of the harddisk free. Now, what happens is that diskdrake only defines the extended partition as far as this logical drive goes. If you add a second logical drive later, diskdrake extends the extemded partition up to the end of that logical drive.

Now, what happens if you boot another distribution and you use that distribution's tool, like gparted to add another logical drive on the free space of the harddisk? It doesn't work, the toll will tell you that there is no room available. Because 3 primary partitions are used and the extended partition is defined by diskdrake, but the other tool does not recognize this extended partition as "extendable" or "variable" as it is defined by diskdrake. Tested and reproduced there and again the same issue hit me during last year's FrOSCon when I wanted to install Debian (or was it Fedora?).

Thanks for the info wobo, just wish I had read about this behaviour _before_ I had tried to delete a couple of partitions.

Can't help but think that the way diskdrake behaves with an extended partition is a bit obscure and different to the way every other disk partitioning tool works. I have used other tools on disks that combine Linux partitions and Windows partitions and both seem to coexist reasonably well with both Windows disk manager and various Linux tools both editing the same disk successfully.

Just want to chime in i have been bitten too.
While i really like gparted i now stay away from when installing mageia it as i like the ease of which i just click a few buttons in diskdrake to ser up luks and lvm.

Whatever has gone wrong I'm sure it's a one-off but I doubt I will ever figure out what the cause was.

An update on the problem:
Must have done something wrong with testdisk before because I tried again and it did eventually find all my partitions.
So restored everything as best I can and although I have all the data back and have re-installed grub back to mbr, things still aren't right.
I can boot my main kubuntu install but can't boot windows.
All partitions are mountable and I can browse them and write to them but if I run a partition manager, it still shows I have no partitions.

So a bit of false hope. I have my stuff, though that wasn't that much of a problem since anything really important is backed but looks like I will still have to wipe everything out and start from scratch.

Hello,
I have experimented also corruption of the partition table with diskdrake. The only way to recover my disk was testdisk.
The problem for the written table was that the partitions was not ordered in a good way.
The way I used to have such a corruption was to first delete two partitions, then add a new one at the place of the two deleted partitions. I think that the better way should be to suppress one and to rise the other.
I never reported this bug, because I did not want to reproduce it on my box, although I thing that it is reproductable. It was a big challenge to recover my data.
The problem is that diskdrake accepts to write a wrong table. I don't thing that this problem has link with partition limits.
Papoteur

I've had this issue a few times. In my experience it actually comes about after partitions are renumbered back and fourth multiple times. In case anyone cares to try to recreate this issue.