[Gllug] Extremely strange disk imaging problem.

david at gbenet.com david at gbenet.com
Thu Jan 20 16:33:35 UTC 2011

Hash: SHA1

The trouble seems to be the MBR of the disks. I remember with WIN 2000 Pro. Windows writes
to the MBR - even preventing you from booting from a CD or DVD. Microsoft even write the
disk size to the MBR. With WD drives, on their big drives the have built in utilities for

Delete the MBR is all I can think of now - I fractured my skull and it's hard to remember much.

Good luck


general_email at technicalbloke.com wrote:
> I often upgrade hard drives for people, the procedure is dead simple...
> I image their existing HD to my computer (using gddrescue) then image
> that onto the new drive and use gparted to expand their main partition
> to use the rest of the space. Sometimes I will stick the original drive
> in a caddy and directly copy it to the new drive skipping my computer
> altogether which is effectively the same thing. I've never had any
> trouble with this procedure until today...
> Last night I did the process above from an 80GB hitachi onto a brand new
> 500GB WD Scorpio Blue and it worked perfectly except that there is NO
> free space left over! Ordinarily in gparted (and windows disk
> management) I would see 400+ GB of unused space after the existing
> partitions but in this case there is none! I've checked on several
> computer and both windows and linux and to all intents and purposes this
> drive now IS and 80GB drive! Even the BIOS reports it's 78GB!
> I tried zeroing the drive with dd if=/dev/zero of=/dev/sde in the hope
> that wiping it clean might make it see sense and return to it's former
> 500GB self but no.
> Annoying though this was I was willing to chalk it down to a fluke of
> hardware, boxed the drive up and got an RMA number from my suppliers. As
> I hadn't gone to the trouble of verifying the drives size before I
> started I figured it could just be an 80GB drive had gotten mislabelled
> at the factory or something.
> Anyway, today I got some more hard drives in the post and repeated the
> process, copying that same 80GB image onto a new 320GB WD Scorpio Black
> and exactly the same thing happened! Again, after imaging the BIOS shows
> the drive is only 78GB! Before that it was correctly detected as 320GB -
> I checked and double checked. What on earth is going on here? I'm at my
> wits end and I have a customer waiting who I assured that their machine
> would definitely be ready today!...
> Fdisk output before:
> Disk /dev/sde: 320.1 GB, 320072933376 bytes
> 255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0x00000000
> Fdisk output after:
> Disk /dev/sde: 78.5 GB, 78518522880 bytes
> 255 heads, 63 sectors/track, 9546 cylinders, total 153356490 sectors
> Units = sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk identifier: 0xe686f016
> How can writing data to a disk change the number of blocks available on
> it? It makes no sense, grrrrrr :/
> Roger.
> --
> Gllug mailing list  -  Gllug at gllug.org.uk
> http://lists.gllug.org.uk/mailman/listinfo/gllug

- --
“See the sanity of the man! No gods, no angels, no demons, no body. Nothing of the kind.
Stern, sane,every brain-cell perfect and complete even at the moment of death. No delusion.”
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/

Gllug mailing list  -  Gllug at gllug.org.uk

More information about the GLLUG mailing list