Raspberry Pi Asked by mina on January 19, 2021
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.
after that I used Disks
to create the image:
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
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.
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:
image-backup
& USB HDD I/O (USB-3 port).resize2fs
and e2fsck
on the finished ext4
partition - part of image-backup
$ echo $(date) && sudo ./image-backup && echo $(date)
image-backup
produces a small raw image file:
dd
)-->
4.05GB$ 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.
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.
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
:
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-*
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 ofresize2fs
to reduce the image file to its smallest possible size, and upon completion,e2fsck
will be run to verify the integrity of the filesystem.
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.
Correct answer by Seamus on January 19, 2021
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 ~$
Answered by Ingo on January 19, 2021
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
Answered by YVbakker on January 19, 2021
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP