So yesterday I received a HDD that was used for cloning, the whole thing went like this:
An HDD of 1TB which had 120GB used was resized to 140GB. After that they did the following:
sudo dd if=/dev/sdb of=/dev/sdc
where sdb is the 1TB hdd that was resized to 120GB (The rest was left empty/unused as I was told). sdc is a new 160GB HDD. So they cloned the 1TB to a 140GB because apparently, they tried to copy the partitions before with gparted (They copied sdb1 and sdb2 to sdc1 and sdc2 respectively. But this did not work even after activating the boot flag on the disk).
Now, they also said that after starting the cloning process, obviously after getting to the max real size of the 160GB hdd, dd gave an error. Am guessing a read/write error since there was no more blocks to write to since there was no more space left (Remember, they are copying 1TB total space to 160GB.) So they pressed CTRL+C to cancel the process.
They went to test the system and yes the system showed the GRUB boot menu and could select from there any of the kernel images but the system did not correctly boot. At least it did not get to loading lightdm or the Unity Desktop.
What I did was just do a
fsck and found the following error:
cyrex@cyrex:~$ sudo fsck /dev/sdb2 fsck from util-linux 2.20.1 e2fsck 1.42.5 (29-Jul-2012) The filesystem size (according to the superblock) is 39046656 blocks The physical size of the device is 36136448 blocks Either the superblock or the partition table is likely to be corrupt!
So my idea is, I either do some kind of superblock reset to tell it the correct amount of blocks (Or lower then resize) or I change the filesystem to read the actual amount of blocks. So how can I correct this state of how the HDD was left in?