On Wed, Apr 27, 2011 at 10:18:28AM -0500, Robert Nichols wrote: > On 04/27/2011 07:26 AM, Timothy Murphy wrote: > > James Pearson wrote: > > > >>> Is there a safe way of recovering the partition table? > >>> I have a vague idea that copies are kept at various places on the disk? > >> > >> AFAIK, there is only one copy at the start of the disk - however what > >> does /proc/partitions contain? > >> > >> This may well have the details of the partitions and sizes when the > >> machine was booted - it this is the case, take a copy of this info - > >> which you can then use to manually re-create the partition table using > >> fdisk > > > > Thanks very much for that; > > /proc/partitions does indeed seem to contain correct information, > > so all will not be lost if there is a power outage tomorrow: > > It most certainly _will_ be lost. The "files" you see in /proc are just > windows into various kernel data structures. The /proc file system does > not exist anywhere on disk. > > Make a paper copy of those numbers, and don't lose it. You will need to > be very careful to re-create the partitions exactly as they were or risk > losing data. Each logical partition within the extended partition begins > with a secondary partition table, and if those get written in the wrong > places they could overwrite something important. When you create the > partitions with fdisk, you will have to play around with numbers until > you get a listing with block counts that exactly match those numbers > (except for the size of sdb4, the extended partition, which the kernel > always reports as "1"). Only then can you safely write out the new table. > > It would make life so much easier if fdisk would simply accept those same > numbers as Kilobytes, but alas it keeps trying to round up to the next > "cylinder" boundary, so you have to fiddle a bit to get it right. Yes, > fdisk is a very old, crufty, and slightly buggy program. Newer programs > are either much too "user-friendly" (e.g., cfdisk "enter partition size > in decimal magabytes"), or way too dangerous (e.g., parted, which writes > each change out to disk immediately without giving you a chance to > verify what it just did). > sfdisk has "dump" mode, and it can also import old dump to new disk. -- Pasi