0

I have a 32Gb SD card and I want to make a light copy of my os to make it work on a 16Gb SDcard.

I wanted to copy just the allocated space so I used gparted to resize my rootfs partition.

enter image description here

after that I used Disks to create the image:

  • I selected the rootfs partition
  • there is an option under settings Create partition image

and now I have .img of the rootfs partition

I did the same for my boot partition.

is it the right way ? I have just one SD card so I couldn't test because I don't want to lose my data so I wanted to make sure that it is correct.

If I execute this everything will work fine ? I intend to resize the root partition after copying the .img

sudo dd bs=4M if=PiOSrootfs.img of=/dev/mmcblk0p2
sudo dd bs=4M if=PiOSboot.img of=/dev/mmcblk0p1

Thank you for helping

4
  • This question makes no sense. You claim to want to copy SD Cards but not have a second. You claim to have done impossible things. – Milliways Jan 13 at 9:10
  • Assuming your using Raspberry Pi OS, why not use the ‘SD Card Copier’ application? – CoderMike Jan 13 at 10:40
  • @Milliways right now I just have a 32Gb SD card, and I don't want to lose my os .. I have also to test something on a fresh install of os . I forgot my 16Gb SD card so I don't have it now and I don't want to lose my time so I have to make a copy of my os before installing the new one on the 32GB SD card .. I want my copy size to be at maximum 16Gb .. – mina Jan 13 at 11:05
  • @CoderMike I am working on a lite version of os. is it possible to use it ? – mina Jan 13 at 11:06
4

Question:

I have a 32Gb SD card and I want to make a light copy of my os to make it work on a 16Gb SDcard.

Answer - use image-backup

Perhaps the easiest way to do this is with the image-backup utility - part of image-utils. If you are running RPi OS, image-backup has these advantages:

  • image-backup may be done on a "live" system: no need to shut down the system, or unmount the device.

  • image-backup is fast: 3min:55sec elapsed time to create a bootable image on RPi 4B from a 32GB SD card; activities included in elapsed time:

    • Includes interactive dialog w/ image-backup & USB HDD I/O (USB-3 port).
    • Includes 3x resize2fs and e2fsck on the finished ext4 partition - part of image-backup
    • On a RPi 3B: 13min:42sec from a 16GB SD card to USB "thumb" drive (USB-2 port).
    • Elapsed times measured as follows:
    $ echo $(date) && sudo ./image-backup && echo $(date)  
    
  • image-backup produces a small raw image file:

    • image file contains only actual data on SD card - not the entire partition (à la dd)
    • 32GB GB SD card --> 4.05GB
      For comparison:
    $ df -h
    Filesystem             Size  Used Avail Use% Mounted on
    /dev/root               29G  5.0G   23G  18% /
    /dev/mmcblk0p1         256M   47M  209M  19% /boot
    
  • image-backup produces an .img file that can be flashed to another SD card, USB drive, etc using common tools such as etcher and rufus.

  • image-backup is free (no cost) and open sourced bash script, currently less than 13kB in size. The author has not yet placed it under a "formal" license, instead stating recently, "Users are free to modify them for their personal use...".

As its name implies, the primary purpose of image-backup is making a live backup of an RPi. Coincidentally, it's also a good solution to shrinking the OS to fit on a smaller SD card.

You can download a copy of image-utils from this location. The instructions (in the README file) may be a bit fuzzy at first, but it's very simple to use. If you have problems, you can post questions to the author in the forum, or ask a specific question here. Alternatively, you can install on your RPi using git from here.

How will image-backup address my question?

Once you've "installed" it, you can make a complete backup of your entire system to an image file. By "image file", I mean a file that can be flashed to your (smaller) SD card using etcher or rufus (for example), and then booted in your RPi.

image-backup compresses the image file, and installing to a smaller (32GB->16GB) SD card will not be a problem based the info in your question.

Show me how...

There is no package for image-utils, so apt cannot be used to install it. However, image-utils is just a collection of scripts (text files), and very easy to install; you may install manually, or via git:

Manual installation of image-utils on your RPi:

Open a terminal window (or via SSH) in your RPi, and from your home directory (/home/pi):

$ mkdir image-utilities
$ cd image-utilities
$ wget -O image.zip https://www.raspberrypi.org/forums/download/file.php?id=39167
$ unzip ./image.zip 
$ chmod a+x image-*

run image-backup

At this point, image-backup is ready to use, but you will need to have a USB drive mounted (or any drive under /mnt) as a destination for the image file it will create. Once your USB drive is mounted, you may create the image file as follows:

$ sudo ./image-backup
  • image-backup will prompt you for the options needed:

    Image file to create? /mnt/Passport2TB/img_backups/20210113_Pi4B_imagebackup.img
    

NOTE: A full path specification to the image file you want to create. The drive must be mounted under /mnt or /media. I have embedded a date & machine id in my filename. Then, ↵

Initial image file ROOT filesystem size (MB) [5933]?

NOTE: Accept default ( ↵ )

Added space for incremental updates after shrinking (MB) [0]?

NOTE: Accept default ( ↵ )

Create /mnt/Passport2TB/img_backups/20210113_Pi4B_imagebackup.img (y/n)? y

NOTE: Enter y, then ↵

Starting full backup (for incremental backups, run: ./image-backup /mnt/Passport2TB/img_backups/20210113_Pi4B_imagebackup.img)

NOTE: The instructions for making an incremental backup are N/A here because you are running image_backup on a one-time basis.
Additional output will show 3 iterations of resize2fs to reduce the image file to its smallest possible size, and upon completion, e2fsck will be run to verify the integrity of the filesystem.

  • You should now have an image file that is ready to be flashed to your spare SD card.

Verify & inspect the image file

I have used an external drive mounted at /mnt/Passport2TB to store my backup image - in a folder named img_backups. Your external drive will likely be different than mine. You can verify your external drive is mounted by using the lsblk --fs command.

List the contents of /mnt/Passport2TB/img_backups to verify the image file is there, and check its size:

$ ls -l /mnt/Passport2TB/img_backups 
total 28533608

...

-rw-r--r-- 1 root root  3921674240 Jan 13 18:48 20210113_Pi4B_imagebackup.img

Note that the size of my image file is 3.92GB. Yours will likely be a different size based on which version of the OS you've installed (I use the Lite version of RPi OS). To provide some context for comparison, let's look at how much space is being used on my RPi 4B:

$ df -h -t ext4
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        29G  4.9G   23G  18% /

And so, in my case, image-backup reduced 4.9GB to a 3.92GB .img file - or about a 20% reduction.

2
  • Thank you that was helpful – mina Jan 16 at 22:19
  • 1
    I'm pretty certain the difference between 4.9 and 3.9GB corresponds to 5% of the entire filesystem size. That's the space which is reserved for the root user on an EXT file system. – Dmitry Grigoryev Feb 15 at 8:11
3

I assume you have a 32 GB SD Card with a productive installation that should be handled save and a spare 16 GB SD Card. You want to transfer the productive installation to the 16 GB SD Card. I would do it manual without special image copying programs. So you are free with partitions, filesystems and its sizes and you have control on each step to be sure that nothing goes wrong.

The idea is to take an uncompressed backup image of the 32 GB SD Card. That is always a good thing to save your productive installation. After copying the installation from it you can compress it for archival storage. We have to use a computer with a Linux operating system. I use one with Debian. I assume you can the SD Cards attach to the computer with a SD Card reader to e.g. device file /dev/sdb. For this example I also assume you are using a Raspberry Pi OS.

We will just partition and format the 16 GB SD Card to the sizes you want, mount its partitions, then mount the partitions of the 32 GB image and just copy it files to the 16 GB SD Card. Here are the steps just in short:

Backup card32 to an image and mount its partitions as following:

pc ~$ sudo -Es
pc ~# dd if=/dev/sdb of=./card32.img bs=4M conv=fsync

pc ~# losetup --show --find --partscan ./card32.img
/dev/loop0
pc ~# ls /dev/loop0*
/dev/loop0  /dev/loop0p1  /dev/loop0p2
pc ~# fsck -f /dev/loop0p1
pc ~# fsck -f /dev/loop0p2

pc ~# mkdir /mnt/card32
pc ~# mount /dev/loop0p2 /mnt/card32
pc ~# mount /dev/loop0p1 /mnt/card32/boot

Attach card16, partition, format, and mount it:

pc ~# parted /dev/sdb mktable msdos
pc ~# parted /dev/sdb mkpart primary fat32 2048s 257MiB
pc ~# parted /dev/sdb mkpart primary ext4 257MiB 100%

pc ~# mkfs.vfat -F 32 -n BOOT /dev/sdb1
pc ~# mkfs.ext4 -L rootfs /dev/sdb2

pc ~# mkdir /mnt/card16
pc ~# mount /dev/sdb2 /mnt/card16
pc ~# mkdir /mnt/card16/boot
pc ~# mount /dev/sdb1 /mnt/card16/boot

Copy the installation from card32 to card16:

pc ~# cp -a /mnt/card32/* /mnt/card16/

Because the installation is now starting from another SD Card, its PARTUUID has changed and it will not find the root partition. You have to correct this. By about 99 % it is the most critical modification if the new SD Card doesn't boot. If so, have a double check at the partitions name in /mnt/card16/boot/cmdline.txt and in /mnt/card16/etc/fstab. I don't use the PARTUUID, but instead the device name.

pc ~# sed -i 's/root=PARTUUID=[a-z0-9]*-02/root=\/dev\/mmcblk0p2/' /mnt/card16/boot/cmdline.txt
pc ~# sed -i 's/^PARTUUID=[a-z0-9]*-01/\/dev\/mmcblk0p1/' /mnt/card16/etc/fstab
pc ~# sed -i 's/^PARTUUID=[a-z0-9]*-02/\/dev\/mmcblk0p2/' /mnt/card16/etc/fstab

pc ~# umount -R /mnt/card16
pc ~# fsck -f /dev/sdb1
pc ~# fsck -f /dev/sdb2

Compress card32.img for the archive if you like:

pc ~# dd if=/dev/zero of=/mnt/card32/boot/nullfile bs=4M conv=fsync
pc ~# dd if=/dev/zero of=/mnt/card32/nullfile bs=4M conv=fsync
pc ~# rm /mnt/card32/boot/nullfile
pc ~# rm /mnt/card32/nullfile

pc ~# umount -R /mnt/card32
pc ~# fsck -f /dev/loop0p1
pc ~# fsck -f /dev/loop0p2
pc ~# losetup --detach-all

pc ~# gzip ./card32.img
pc ~# exit
pc ~$
13
  • Why do you mount a partition before you run dd on it? – Seamus Jan 16 at 18:34
  • @Seamus Where? Have I overseen something? – Ingo Jan 16 at 18:40
  • I don't use dd much, but I thought it was common knowledge that the dev/part used as if was to be un-mounted before using dd. This was due to the risk of data corruption. Like many things, risk depends on the situation. I posted the comment because it wasn't clear to me that mounting the drive was necessary to your solution. – Seamus Jan 16 at 18:58
  • @Seamus In my answer I find 3 lines with dd. What line do you mean? – Ingo Jan 16 at 19:23
  • You have a line that says: Backup card32 to an image and mount its partitions: – Seamus Jan 16 at 19:52
0

Copying one file system (that obviously doesn’t take up the entire disk) to another, smaller filesystem is quite a common problem, especially in these times where GB’s come in large quantities for no price at all.

I had to look for a bit but remembered a question on the Ubuntu stack exchange: https://askubuntu.com/questions/409204/how-to-clone-to-a-smaller-harddisk

Basically what you proposed is the right way to go but be careful to respect the original layout of your disk if you’ve set it up like this.

-hth

2
  • 1
    Thank you for helping – mina Jan 13 at 11:13
  • 1
    @mina no problem, I have struggled with this myself recently – YVbakker Jan 13 at 11:57

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.