On 04/27/2011 07:08 PM, Timothy Murphy wrote:
> Robert Nichols wrote:
>
>>> sfdisk has "dump" mode, and it can also import old dump to new disk.
>>
>> That dump mode doesn't help if the partition table is currently munged,
>> and sfdisk is extraordinarily unforgiving of the tiniest mistake in
>> human-generated input.
>
> But it seems I could generate correct input for sfdisk
> from the entries in /proc/partitions ?
>
> But I notice "man sfdisk" has a warning against use with large partitions,
> which it defines as> 8GB.
> Hopefully this no longer applies?
That warning was inserted in July, 2005, and there hasn't been much
change to sfdisk since. On a 64-bit system, at least, it seems to work
OK on a 1 Terabyte disk where I just successfully copied the
partitioning from another disk of that same size.
Figuring out the exact numbers to put into that hand-made dump file is
not quite as simple as it seems, and sfdisk isn't known for doing much
in the way of validating what you feed it. I would advise trying your
hand at re-creating the partitioning for some spare disk first.
Actually, if it were my drive I would just re-create the 4 primary
partitions using whatever tool was handy, but giving that extended
partition a "normal" type instead. Once I had the primary partitions
looking right, then I'd go in with a hex editor and change the type code
to "5" for that partition. Listing the partition table again with fdisk
should now show that everything is back. (It's very unlikely that any
of those secondary partition tables got overwritten when you
essentially turned the whole disk into one giant DOS file system.)
--
Bob Nichols "NOSPAM" is really part of my email address.
Do NOT delete it.