bug-parted
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 4000GB partition becoming 1801GB after reboot?


From: Bryn M. Reeves
Subject: Re: 4000GB partition becoming 1801GB after reboot?
Date: Mon, 03 Nov 2008 17:45:59 +0000
User-agent: Thunderbird 1.5.0.12 (X11/20071019)

Isolationism wrote:
> 2) A GPT partition was never created in the first place, in which case parted
> not only happily let me create an illegally large msdos partition, but also
> proceed to use it for a month with absolutely no problems whatsoever -- that
> is, until the machine was rebooted (see the link in my reply to Håkon;
> someone else has reported precisely this problem in this list earlier this 
> year).

I strongly suspect this to be the problem. I'll try to reproduce this
here (don't have any storage that big but can probably fake something
with sparse devices/iSCSI).

I have seen a few reports of this problem, mostly on old versions of
parted and from users who weren't able to provide a lot of detail but I
believe the problem still exists.

The reason the system functioned OK in this state for a month is a
discrepancy between the capabilities of the BLKPG ioctl commands that
libparted uses to reload live partition tables on a Linux system and the
capabilities of a specific disk label type - libparted should enforce
the strictest of the two constraints (and so reject a 4T partition on an
MSDOS labeled device in the first place).

> I know for certain that I originally partitioned the drive using fdisk, which
> would ensure that an msdos label is present on the drive regardless of any
> other partition tables present; my reaction to the limited disk size was how
> I came across parted at all.

Did you create the 4T partition in fdisk or parted? Just wondering who
to blame (I suspect parted :).

For recovery purposes, it should be possible for you to re-create the
situation that you had working for a month. To do this, first backup
your current MBR with dd. Then you need to create a new disklabel in
parted and create a new partition that starts at the *exact* same
location as the previous one, but which ends at or after the original
(4T) end location. This should cause parted to issue the correct set of
BLKPG commands to the kernel to re-create the 4T partition.

This should allow you to access the data that is there, although I
suspect you'll need to back it up to another device & then re-create the
partition with a GPT disklabel before restoring (in-place conversion
between the two is possible in some but not all situations and there are
no tools that I'm aware of to automate the process).

Regards,
Bryn.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]