3

I have an image of my home (/dev/sda3) partition, which I've created using the "dd" command.

dd if=/dev/sda3 of=/path/to/disk.img

I've deleted the home partition via gparted in order to enlarge my /dev/root partition. Then I've recreated the /dev/sda3 partition which is smaller in size then the one I've backed up to the image.

I was wondering since I have a 2TB external HDD, could it be possible to mount my backed up image on the external HDD and then copy the files into the /home directory. Since the external HDD would be already in a "mounted state", I'm unsure whether this is a good idea, mounting on a mounted device.

  • I'm running Slackware 13.37 (64bit).
  • used ext4 on all the partitions.
  • resized the root partition with gparted live cd.

I've tried:

mount -t ext4 /path/to/disk.img /mng/image -o loop

It gave me an fs error (wrong fs type, bad option, bad superblock on dev/loop/0)

Then I did

dmesg | tail

which outputs:

EXT4-fs (loop0) : bad geometry: block count 29009610 exceeds size of defice (1679229 blocks)

I have no idea what to do, I want to restore my /home data from the image I've backed up.

[Update]: * The disk.image is on my USB 16GB flash drive. The image size is around 6GB. The image was created from a deleted partition which was around 100GB and now it's reduced to around 80GB.

[Update]: I've tried this today: LQWiki: Some dd examples says:

You don't want to tell a drive it is bigger than it really is by writing a partition table from a larger drive to a smaller drive. The first 63 sectors of a drive are empty, except sector 1, the MBR.

dd if=/dev/sda skip=2 of=/dev/sdb seek=2 bs=4k conv=noerror

I tried then to mount /dev/sda3 to /home. dmesg | tail outputs an error "group descriptors corrupted!"

Then I tried:

fsck.ext4 -y -f /dev/sda3

It outputs a large amount of fixed issues and million of numbers going down at the speed of light.

After that I successfully mounted /dev/sda3 to /home, but there was no data present in the home directory. Only some directory named "lost+found" which is also empty.

  • Are you sure you got the whole thing? Did you try mounting disk.img before deleting the partition? – Paul Sep 4 '12 at 2:59
  • I've not seen this personally, but this page seems to describe a similar problem: linuxquestions.org/questions/linux-general-1/… Maybe you could try the resize2fs command? Do take a backup of the image file first though. – grifferz Sep 4 '12 at 3:34
  • @Paul I haven't tried mounting disk.img before I've deleted the partition :( – Keeper Hood Sep 4 '12 at 9:36
  • @grifferz I'm not sure i can resize the filesystem in this situation, since i have no free space to resize to. My root partition was 8GB, and home above 100GB. Then my X crashed and displayed no free space errors, after that I've done the resizing via gparted, and gave the root 32GB and the home what was left. So i cannot enlarge my partition, I'm looking for a way to copy the data from the disk.img. Isn't there any way to skip the empty blocks and just count the data? – Keeper Hood Sep 4 '12 at 10:37
  • In the article I linked to they are doing resize2fs on the block device giving them problems. So in your case that would be the image file disk.img. You'd be resizing the filesystem within it, not the file itself or any other part of your system. – grifferz Sep 4 '12 at 20:40
4

Why don’t you:

sudo losetup /dev/loop0 /path/to/disk.img
mkdir /mnt/image
sudo mount /dev/loop0 /mnt/image
0

Try to truncate the file to the exceeding block count and then remount.
In your situation:

EXT4-fs (loop0) : bad geometry: block count 29009610 exceeds size of defice (1679229 blocks)

truncate -o -s 29009610 /path/to/disk.img 
mount -o loop /path/to/disk.img /mng/image

Flavio

  • Warning this will modify the actual file and possibly lose data from it! – Chris Stryczynski Jun 13 '18 at 7:58
0

I know this is an old question, but I just ran into this same problem two days ago, and was able to somewhat solve the problem.

This issue basically happens when somehow or another an ext2/3/4 filesystem image isn't fully copied to an image file, essentially leaving a chunk of data missing off of the end. Because of this, you won't be able to recover all the files that existed in the original image, unless by some miracle no file data was stored in the missing part of the image.

In my case, I was unable to mount the image, but there is a utility that will scan ext2/3/4 filesystem images and dump all the found files to a specified location:

bash$ losetup -f ./corrupted.img # mounts to /dev/loop0
bash$ sudo debugfs -c /dev/loop0
debugfs: rdump / /path/to/dump/files/
debugfs: quit

The rdump command takes two arguments: path inside the corrupted image to recursively scan for files, and the path on the native filesystem to save the files to. Any files that were not recoverable will be created with a size of 0 bytes.

You'll probably need to chown the files since debugfs runs as root.

  • Careful with that. For me, losetup -f ./corrupted.img ate all available RAM plus swapspace. Unable to cancel it (as I had switched to another virtual screen and couldn't switch back due to the load), it froze my machine and I had to reboot, effectively losing all open windows and unsaved work (the latter was little, luckily). – Izzy Jun 13 '18 at 22:16
  • @Izzy I'm sorry to hear you had trouble. I find it odd that losetup ate up your RAM. I've mounted images in the 100's of Gigabytes without any problem. Is the "-f" switch the only one you used? – Gogeta70 Jun 15 '18 at 12:38
  • Yes, almost verbatim copied from your answer. It was a corrupted ext4 image in my case. No data lost, just the arrangement of open windows, so no real harm done. No idea what caused that. Looks like it tried to load the entire reconstructed image into RAM. Had I not switched to a different desktop, I probably could have Ctrl-C'd it in time. But 100% CPU load on all cores made switching back impossible. // TL;DR: no harm done, just wanted to left a note to keep eyes open and being aware when doing that. – Izzy Jun 15 '18 at 16:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.