I was use dd command to copy my 500GB hard-disk into my new 1TB hard disk.
After 9 hours system display message everything was successfully copied but I can't display any data into my new hard disk.
I go through following steps.
step1:-
After that system disply message :- step2:-
but now 1 TB HDD can't display anything. 
How to solve that issue?
This problem was created by an incorrect dd command.
Accurate dd command for disk cloning is:
dd if=/dev/sda of=/dev/sdb
sda and sdb point to the hard-disks themselves, which includes the partition table as well. if= points to the input file (in this case, /dev/sda), and of= points to the output file (/dev/sdb).
dd command is time consuming but it is more trusted and also default system tool so I gave priority to dd.
After successful operation, the next step is to restart the system, then your new hard-disk will look like this:
Here is the second last step, that is also required after dd:
Use Gparted utility to resize the extended partition. The old hard-disk partition table was Legacy boot type and did not support more than 4 primary partitions. Therefore, resizing is the only safe option to use 500GB free-space.
After resizing the extended partition:
Recently I've had to use dd for recovery and image work. I used it intensively some 10 years back for cloning drives and backing up partitions. I must say that it's use is light-years away from direct and simple. With respect to HDDs, you need to know exactly how the drive is structured at the lowest level. For this you need other programs that you can trust (fdisk, sfdisk, cfdisk, etc.) Trust only comes from experimentation with known objects and examining the results -- not from word of mouth. I'm in agreement with muru's initial comment about wrong dd command, but more should be said. if=/dev/sda starts reading at the very beginning of the device (byte address 0) while of=/dev/sdb1 writes to the first partition of device b. The result is that your sda-MBR resides at sdb-part1, along with your OS, etc., and I don't know what will happen when it gets to the end of sdb1, if it's larger than sdb1.
I'm guessing that sda is the boot device and you want sdb to also be your boot device, but maybe you just want sdb1 to be a backup clone. Your question is vague about this. You might be able to copy partition to partition if they are exactly the same size but maybe the OS has meta-data about the partition filesystem that doesn't match, so it can't 'view' it. If you just want a clone for backup then maybe your command is ok, but there are issues about reaching the end of the partition and over-writing the next partition, and whether your OS will object to the filesystem destruction on sdb1 (booting still from sda1(?)). In principal, such might work, but it's probably better to write sda to sdb only and forget about booting from sdb, it's just a clone for reading. You could probably write to file if you had extFAT or some system that accepted 500GB file sizes, but I doubt that you do.
There are dozens of other questions as well. If you wanted to transfer to sdb and later boot from it, you must know the bytes and sectors to copy and include that in your command -- making sure your output drive has the size necessary, again /dev/sda to /dev/sdb should work except for some problems that I've encountered. Namely, what should dd do if it encounters a read error that is common on older used drives? You can set dd to ignore them but what then does it write? In my experience, it writes nothing, thus that 512 bytes (normal traditional block, but your disk might be different; newer drives may use 4096 byte blocks) is taken out of the write and all further bytes are shifted 'to the left' of where they should be. This happens for each read error that maybe you've optioned to ignore because a read error stops dd cold and a restart is painfully hard. In short, dd for cloning can be done, but it should be done in a bash script with an error recovery loop that fills unread blocks with nulls, the command should specify exact block counts, and you should know exactly the low-level format of the drives involved. In the end, it's probably best for serious cloning to use a dedicated open source c executable that does what dd and sfdisk do but more professionally. But, I'll admit that dd is useful. It's like a Bowie knife on your belt -- impressive and powerful, but with limited usefulness.
Also, OSs can check for UUIDs stored in free space and other places on HDD and can object to booting if they don't match. This is one of the black art areas of OS competitiveness. Official software knows these things.)
GPT tables are also important, even essential these days, unlike 10 years ago. And EFI boot partitions complicate things too. With the little I know about low-level disk formatting, I won't even waste my time trying to clone a whole disk. Parts of the disk might be useful for very special problems. Ignoring LVM and its significance, a partition might usefully be cloned but only for reading back to the original drive (no OS mixing, boot changes, etc.) To transfer a bootable 500GB drive to make a 1TB bootable system, assuming the OS doesn't object to a different drive (hardware signatures?), then my suggestion for a successful experiment would be to make the low-level formatting on the 1TB drive exactly like the 500GB drive -- I mean exactly! You must examine the MBR and GPT tables with a hex editor. Then dd the partitions byte-for-byte to the new drive. Then, boot-up the 1TB drive (assuming success) and make another partition in the new 500GB of additional space, or expand the partition and live filesystem, if you have and trust such software. Trust in this realm is hard to find because this stuff is difficult and disastrous if gotten wrong. Better to buy a new system or software with a great reputation and SHA256SUMed so you can check its integrity. Digital systems are by nature volatile and impermanent, so best to get used to change, if you need more than what you have.
I have:
If it works with virtualbox it works even with real hardware....
Check source disks and partition by:
udisksctl status
then run :
sudo dd bs=400M conv=sync,noerror status=progress if=/dev/hda of=/dev/hdb
where hda=source partition disk and hdb is distination disk
Caution: destination capacity must be >= source
I have started to clone using
ddrescue -f -r3 /dev/sd_OLD /dev/sd_NEW mapfile
N.B. remember to double and triple check the serial numbers of the two drives before cloning
hdparm -I /dev/sd_OLD|grep Num
Then when the old data is on the new drive I would expand the partitions to fill the new available space with fdisk and resize2fs (as outlined on unix.stackexchange.com )
Don't skip the mapfile as that will enable you to restart ddrescue if it is interrupted, (and only takes up a few hundred bytes.)
Why not just using gparted and simply copy/paste the old hdd in the new one?
I just done this with my home harddisk.
Copy and paste in gparted, edit fstab, reboot et voila... ;-)
rsyncorcpinstead oddd/dev/sdb1. You should havedd'd to/dev/sdb.