0

I am currently running on my raspberry pi 3B+, a headless install of Ubuntu server 20.04 booting off a 32 GB USB drive.

However since i am only using around 4GB of the 32 GB Drive, I am hoping to clone my setup onto an 8GB SD card i have, thereby allowing me to use the USB for something else.

A couple things i have already tried are

  1. The Rpi-clone tool i found on another post. https://github.com/billw2/rpi-clone
  2. Using Win-32 Disk Imager to read the USB Drive and then write it onto the SD card.
  3. I also tried using gparted, to shrink the Partition but while the shrunked partition keeps booting off of USB, when run from SD, it doesnt boot

This makes me feel that there is something that needs to be changed in the FSTAB or Boot cmdline.txt file but I am not sure what to change.

I would really appreciate some help/advice on this.

Thanks.

2
  • Do you expect us to guess what is in fstab or cmdline.txt? I suspect Ubuntu server is using uboot. You need to provide more detail. Using Win-32 Disk Imager on any Linux image is a shot in the dark - use a proper tool.
    – Milliways
    Aug 2 at 12:26
  • @Milliways Could you please recommend such a tool. I will add a copy of the fstab and cmdline.txt file
    – mustafa
    Aug 2 at 13:25
1

Resizing is performed using the resize2fs command.

Ensure that you have an up to date backup of the filesystem

Shrinking a filesystem is a moderately high-risk operation, so if you take backups of the data at all then this is a good time to perform one.

Unmount the filesystem

If the filesystem that you wish to shrink is mounted then you will need to unmount it before proceeding further:

umount /dev/sda2

(At the time of writing it was possible to extend an ext3 or ext4 filesystem while mounted, but not to shrink it. An ext2 filesystem could be neither extended nor shrunk while mounted when using a current (2.6-series) kernel.)

Check the filesystem

One factor that would increase the risk of failure is if there are pre-existing errors in the filesystem. This risk can be reduced by checking the filesystem before resizing it:

fsck -f /sda2

resize2fs will refuse to run if it thinks the filesystem ought to be checked first, however there is no harm in running fsck regardless provided that you are confident the filesystem is not mounted.

Do not check the filesystem until after you have unmounted it, otherwise fsck may itself cause data loss.

Resize the filesystem

Use the resize2fs command to resize the filesystem:

resize2fs /dev/sda2 80G

You must specify the required final size of the filesystem when shrinking it. The suffixes K, M and G may be used to specify a size in kilobytes, megabytes or gigabytes. These are interpreted as traditional (binary) units, so 1G=1024M, 1M=1024K and 1K=1024 bytes.

The amount of time taken will depend on how much of the content needs to be relocated. The filesystems considered here tend to disperse data throughout the underlying block device, so a large amount of copying may be needed even if the filesystem has never been filled beyond the size it is being reduced to. Do not start resize2fs unless you are confident you can allow it to finish. You can request a progress bar using the -p option.

When resize2fs has finished it should report the new size of the filesystem in blocks:

The filesystem on /dev/sda2 is now 20971520 blocks long. Note that resize2fs does not change the block size, even if a freshly created filesystem on the same device would default to a smaller size.

Testing

You can obtain an approximate value for the new size of the filesystem using the df command once it has been remounted. The output should be similar to the following:

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda2   82569904    188292  78187308   1% /mnt

The number of 1k blocks reported (82569904 in this case) is slightly less than the full size of the device (83886080). This is normal. If you want to see the exact size, or do not want to mount the filesystem, then you can use the dumpe2fs command:

dumpe2fs -h /sda2

The output is quite lengthy, but should contain the following information:

Inode count:              5242880
Block count:              20971520
Reserved block count:     1048576
Free blocks:              20595403
Free inodes:              5242869
First block:              0
Block size:               4096
Fragment size:            4096
The block count should be the same as the value reported by resize2fs. The size in bytes is the block count multiplied by the block size.

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.