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.