5

My SD card corrupted itself but I have a back up image.

The partition table leave 1GB unallocated space at the end so that I can restore to any 8GB memory card regardless of memory fluctuations.

The actual img file is 8GB. How can I shrink this down to ignore the extra space at the end so that I can write it onto a slightly smaller memory card?

  • 2
    This is yet another reason why using dd as a backup tool is a very silly idea. If you copied the whole card, you can mount the individual partitions as described here. If you just copied one partition, you can just mount the image. Either way you can then use resize2fs (e.g.); this will leave unused space at the end of the image which you can shrink by dding it out only smaller. – goldilocks Mar 2 '15 at 14:18
  • 1
    If there is free space at the end, you can dd the whole card. If copying partitions you need to make sure you copy the first 512 bytes. – Milliways Mar 2 '15 at 22:16
  • @DJCrashdummy Truncating the image is actually not necessary in the OP's case, unless they want to reuse the backup multiple times. – Dmitry Grigoryev Dec 12 '18 at 10:03
  • @DmitryGrigoryev well... as you see at the accepted answer, taking care of dd-errors is also not necessary, but its better to do so! - and at the end of the OP it states: "The actual img file is 8GB. How can I shrink this down [...]" - thats what the duplicate is all about (with sightly better answers). – DJCrashdummy Dec 13 '18 at 12:24
0

After three days hands on researching with tools like fdisk, dd, resize2fs, lsblk and e2fsck, I find this VIDEO do the trick in a much faster and easier manner with gparted. I think you question is: "How to install a Raspberry pi linux system backup from a big SD card to a smaller one." :)

0

There is a nice tool available. Try pishrink

PiShrink is a bash script that automatically shrink a pi image that will then resize to the max size of the SD card on boot. This will make putting the image back onto the SD card faster and the shrunk images will compress better.

0

If you know for a fact that your 8GB image only has 7GB of allocated data (or less), you can tell dd to copy that exact amount to the new SD card. Here's a command to copy 7168 blocks of 1 Megabyte each:

dd if=/path/to/file.img of=/dev/sdX bs=1M count=7168

You should actually specify the exact size when creating your backups, which would also make them somewhat smaller.

There's absolutely no harm in not copying the unallocated data (i.e. garbage) from the image, as no sane system stores data outside the partitions.

-1

I ended up dd'ing it and ignoring the error about the destination being too small. Worked fine.

  • 1
    You should fsck and delete/replace the partition at the end. – Milliways Mar 3 '15 at 1:13
  • 3
    What partition at the end? There is a chunk of unallocated space at the end. There is nothing that got cut off – user2290362 Mar 3 '15 at 10:20
  • Another option would be to mount the backup (loop), shrink it down/adjust it, and then re-dd to a new .iso. – earthmeLon Mar 20 '15 at 20:07
  • 1
    This is like take a leap from a high altitude plane without a parachute and count on a team mate to catch you if something goes wrong! Only valid if you perfectly know what you're doing! There's no safety in doing that and it's only when it's too late that you can realize something went wrong and you'll never know if you lost files in the run. Take minimum precaution first, it's easy even in a hurry. – user29510 Dec 28 '15 at 11:41
  • @user29510 What "minimum precaution" are you talking about? – Dmitry Grigoryev Dec 12 '18 at 9:56

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.