Hi all.

I'm having a bit of a problem solving this. So any tips are welcome.

Setup,
Hardw: Dell Inspiron 6400, 2GB RAM, 1.8GHz
Linux: SystemRescueCD
Disk1: SATA 80GB (sdb)
Disk2: SATA 250GB (sda)

Partition info:
sdx1 - 3GB DELLSYS
sdx2 - 70GB NTFS
sdx3 - 7GB Unallocated

Index of commands used with 'dd':
1. dd if=/dev/sdb of=/dev/sda bs=32256 (cloning = OK)
2. dd if=/dev/zero of=/dev/sda bs=32256 (zero-fill = OK)

Index of software used:
- dd
- gparted
- parted
- fdisk
- partprobe
- ntfs-3g

It all started when a friend of mine wanted to upgrade a laptop with some RAM and a new disk. All went smooth until I started cloning the disks with 'dd'. Cloning the disk went ok, the new disk booted fine. But one problem remained that I couldn't solve. The new disk (sda) was showing the size of 'sdb'. Tried deleting sda3 and sizing up sda2 but it wasn't possible. The disk responded 80GB size with no unallocated space after sda3.

To solve this I tried removing all partitions in sda several times. Even zero-filled the disk in a desperate attempt at getting all the geometry setting wiped so I could start over. But all in vain.

Help to solve the size problem would be greatly appreciated.

Best regards
PrNull

This sort of problem is inherent in using dd as a backup tool. The solution is to create a new backup plan which does not use dd. I recommend that you use the cp command with the update option to copy your file systems to backup partitions.

----------------------
Steve Stites

I don't know dd well enough to know what if anything might be wrong with your dd command for zeroing sda. You only need to kill the first 512 bytes of sda, not the whole drive, to get things fixed. I think dd should need some count= when used with if=/dev/zero, but I don't know for sure.


After zapping the first 512 bytes of sda, you likely need to reboot (a live CD or SDB or whatever is bootable) to get Linux to forget what it saw in those first 512 bytes.

Then whatever partitioning tool you like should be able to repartition sda based on its true size.

I'm not an expert on cloning, but a method that has worked for me is:
1) Partition the target drive creating a partition slightly larger than the source partition. Exactly the same size would be nicer, but there are usually cylinder rounding issues such that trying for exactly the same size gets you a tiny bit smaller, which can go very wrong.
2) Use dd to clone the partition, rather then the drive. Now you have a filesystem slightly small for the partition containing it.
3) Resize that partition and the tools will automatically independently resize the filesystem and the partition to the new size, so now the size of the filesystem matches the size of the partition containing it.
4) Repeat for other partitions if needed
5) Reinstall Grub.

The problem is not so much geometry. That (fortunately) will be still be set correctly as LBA - it's the cylinder count that's wrong. You should be able to make a reasonable guess as to a likely number - don't get greedy and go beyond the physical disk (actual) size.
Then use any of grub, fdisk, [cs]fdisk ...

I have not put myself in a position to have needed to test this BTW.

You didn't do anything to change the drives geometry. You cloned the partition table so your partitions are the same size on the new drive as they were in the old one. If you clone a person with freckles, the clone will have freckles as well.
If the last partition is your main one, you could resize it. I am not a big fan of cloning partitions for backups. You are putting all of your eggs in a single basket. What will you do if the source drive is defective and has a read error. What if a backed up clone file goes bad.

Plus, reinstalling is a good way to getting rid of the extra junk you have installed over time and don't need. This is especially true for Windows which really needs to be reinstalled every 2 years to clean out extraneous dll files and registry garbage which slows down performance and only eats memory and cycles. To say nothing of malware (viruses, spyware, obsolete hidden DRM remnants).

Jailbait:

Thx for the responce. I think I wasn't clear enough. The cloning was not intended as a backup procedure, I'm upgrading a laptop with a new (bigger) disk and reinstalling is not an option I'm afraid.


johnsfine:
I tried rebooting the system several times. The thougt behind zeroing out the disk was that it wouldn't show up as a 80GB disk... it didn't work.

I'll try your steps later, when I get the size of the disk to match it's physical size.
Thx for the tips!


syg00:
I'll test that right away! Thx!



jschiwal:
The funky part about all this is that I can't get the correct size back un the partition. I tried killing it off and repartitioning it all but no luck.

As I mentioned earlier in the post reinstallation of windows is not a possability. That would take up too mush time for me and the friend who has to find all the installation CDs again.




Thanx for all the replies. I'll get right on them


Best regards
PrNull

When you reboot, the only place from which it could get the incorrect size for sda is the partition table in the first sector (512 bytes) of sda.

Combining that fact with the results you reported, I deduced that the command you used to zero sda didn't really work. So my suggestion was to use a correct command to zero the first 512 bytes of sda, then reboot, then any partitioning program (gparted, fdisk etc.) should use the correct physical info (because it can tell there is no valid info in the existing partitioning table).

I think /dev/zero has no size, so dd should not be able to operate correctly unless you provide the (normally optional) count parameter, which you did not provide when trying to zero sda.

You shouldn't ever need to tell the partitioning program the physical size of the drive. So you shouldn't need to research or guess that exact size. Partitioning programs work with brand new drives. So if the partitioning program can tell that the previous contents of the first sector are not a valid partition table, then it should automatically ignore those contents and use the correct size.

FYI: I recently followed the exact procedure you describe to upgrade my laptop's 80GB drive to a 120GB drive, and had the same problem you describe.

The solution turned out to be quite simple: I used gparted to rewrite the partition table. Interestingly, neither parted nor qtparted were able to do so.

You may be interested to know that the HD I cloned contained working XP and and Fedora systems (with a logical volume for the Fedora root directory), and that the cloned drive (after the partition table rewrite) worked (and continues to work) with no problem.

The zeroing out worked. I checked the output from the first 512B of the disk (hex), all zero. No partitioning info att all. Fdisk/Gparted/parted/sfdisk showed the same result.

Thats whats making me crazy!

No partitioning software is giving me 250GB disk. I'm starting to think this disk is defect. Just downloaded Samsung harddrive diagnostics, will give it a run and see if I need to return the drive or struggle on (just for the fun of it I'd prefer the latter)

What same result? From context I would guess you mean the partition programs say sda is the size of sdb. Is that it?

What does the bios say about the two drives? Maybe some BIOS setting is wrong to keep it from detecting a drive correctly.

Are you sure you know which is which between sda and sdb?

Hi again.

Yes, the result from part.soft I refered to is size, showing that sda==sdb.

BIOS is Dell and not configurable on this part. Linux kernel and samsung soft show a native size of 250GB but currently only 80GB available.

Yes, absolutely. I removed the second drive. Only 250GB inserted.


Ran the samsung soft and something realy seems wrong. I'll give this drive the boot. Getting a new one tomorrow.

Thx for all the help!

Best regards
PrNull

THE SOLUTION!

After several days i finally solved this stupid problem

I have to admit, It's been extremely educating and nice. So here comes the sum up of the problem.

The Mob:
It seems as though Dell has some love towards using something called HPA (Host Protected Area) making life living hell for us mortals. And diskcloning a nightmare. It's used to contain among other thing MediaDirect v2 (Google it)

HPA, the villain:
HPA is an "invisible" partition, that Dell uses to contain various software of theirs. It's not visible to partitioning software making it teadeus to find and remove. Thanks to the magnificent Dell bootloader removing HPA is even harder (thank you Dell, we love you!).

The Superheros:
The brave Linux livecd SystemRescueCD and the superhero acomplis HDAT2 will kill them both off. Making life good again. And disks the size they where manufactured.

The problemo:
Well, see the above postings

The solution:
To restore a disk to it's original (native) size we need to use a app called HDAT2 (www.hdat2.com) that tells the disk to remove the secret HPA part. Using HDAT2 is easy.
- Download & Burn ISO image.
- Boot HDA2
- Select the drive and press enter
- type "NHPA", press "S" to set drive back to native size. If the drive is a clone of a drive smaller than 137GB the HPA is protected in LBA-28 and you need to change this with "v". Then use set. if the drive gets a new size of 137GB but still flags HPA then reboot the machine and do this step again with LBA-48.

!!! DO NOT LET DELL BOOTLOADER LOAD (it will reapply HPA again!)

- Reboot the system
- Boot SystemRescueCD / Other LiveLinux.
- Set new MRB boot record (google).

Now all that is left is to reboot back into Windows! New bigger drive and all!

Bon voyage dell bootloader!

regards
PrNull

dd copies the lot, including the parts of the partition which denote its size. After a dd do this to correct the issue:

resize2fs /device size e.g. resize2fs /dev/hda2 20GB or resize2fs /dev/xvda2 21.5G