[Techtalk] Partitioning issues.

[Conor Daly]

On Sat, Jul 26, 2003 at 08:20:13PM -0500 or so it is rumoured hereabouts, 
Staci thought:
> Yes and no.
> It was a Win96 fat32 (lba).
> But not bootable, just for storage.
> and the answer is NO.  I cannot just reverse the changes.
> I tried and it didn't work.

In this case, it doesn't just reverse.  Why?  Because you turned it from
primary into extended.  As mentioned earlier, an extended partition
contains (at the front) its _own_ partition table.  This describes the
first logical partition within it.  That logical partition contains a
pointer to the next logical partition and so on.  The upshot of this is
that the fat32 partition's data _has_ been altered but probably only
within the first FAT (File allocation table).  It may be possible to use
MS scandisk to fix the drive but this is dangerous since scandisk will
just go and "fix" the disk without asking (If you run it in Windows and
uncheck "automatically fix errors" this may be OK).  At the same time,
windows may just say "not formatted" and therefore not run scandisk.

I came across something on http://grc.com/cih.htm [0] some time ago which
describes the layout of the fat32 FATs.  From the info there, it should be
possible to calculate the chunk of disk to copy to retrieve the backup
FAT.  

	"For example, a one gigabyte drive (or partition) formatted with a
	32-bit FAT will consist of approximately 262,144 clusters of 4,096
	(4k) bytes each. Since each FAT table entry requires 32-bits, or
	four bytes, a single copy of the FAT for a one gigabyte drive will
	require exactly one megabyte of sectors!"

His style is a little "wow!" but it contains the necessary info to
identify the location and size of the backup FAT.  You need two things:

Size of the partition (you said 17Gb right?).
Cluster size on the fat32 filesystem (starts at 4k).

To get the size of the FAT, divide the size of the partition by the
cluster size (which may be more than 4k for a 17Gb drive) and multiply by
32bits (4bytes).  This will give you the FAT size in bytes and also the
offset from the start of the partition which you can use with dd to grab
the (hopefully) good FAT.  I'm not sure that the first FAT starts at the
exact start of the partition  or if you need to add a bit to the seek
(anyone?).  Here's an example:

The only fat32 partition I have available is a: 
6 Gb 
6333244 Kb
6485241856 bytes
4096 bytes/cluster
1583311 clusters 

the FAT size is 1583311 * 4 = 6333244 bytes and the offset is (presumably)
6333244 so the dd command would be:

dd if=/dev/hda4 seek=6333244 size=4 count=1583311 of=backup_FAT

The command to write it back to the start of the partition is:

dd if=backup_FAT of=/dev/hda4

WARNING!  I'm not sure if there's space used before the first FAT and the
commands above will work only ONCE!  You'll need to find out where the
first FAT starts and adjust the seek accordingly (this includes adding a
seek to the write it back command also).  If you need extra (start of
drive) sectors, you can get these by making a fat32 partition somewhere
else and using dd to grab the first few sectors in much the same way as
detailed above (you could use your C: drive for this assuming it's fat32
rather than NTFS).

I haven't enough info to hand to be clearer on this but perhaps someone
else can elaborate and/or fix my gross errors.

BTW, how long will it take to restore the 17Gb of music?

Conor

[0] This is a fix for the "Chernobyl" virus which wipes the first (raw)
1Mb of every fixed drive, wiping out MBR, partition tables and the first
FAT of the primary partition.  
-- 
Conor Daly <conor.daly at oceanfree.net>

Domestic Sysadmin :-)
---------------------
Faenor.cod.ie
 10:44am  up 73 days, 13:11,  0 users,  load average: 0.00, 0.02, 0.05
Hobbiton.cod.ie
 10:43am  up 73 days, 13:08,  1 user,  load average: 0.06, 0.09, 0.06