2

If the command to replicate an SD card:

date; sudo sh -c 'pv /dev/mmcblk0 >pv sdcard.image'; date

images a fresh install of Raspbian sitting on a 128GB SD-Card, then sdcard.image file will be 128GB. Assume that a fresh install of Raspbian takes 10 GB of space. Most of the image would not contain data ('empty space'). It would be useful if the resulting image:

  1. is minimal in size (before any compression and not copy 'empty space')
  2. could be installed to a minimal SD-Card (16GB SD card or larger)

A minimal SD-card capacity is the smallest SD card that can accept a fresh install Raspbian: because there is no 10GB SD-Card, the next larger size (16GB) is defined as the minimal SD-Card.

Solutions preferences are for simplicity and standard Unix commands (scripts if necessary).

How can the 2 goals be achieved? Would a sensible strategy determine the amount of data (10GB) on the SD card and change the disk parameters a disk size slightly larger than 10GB: in this case 16 GB?

References:

gatorback
  • 1,384
  • 23
  • 48

2 Answers2

2

I would do it this way:

  • Shrink the partition(s) on the original card, or on a cloned copy of it, in order to make it (or all partitions if more than one) fit in the target size.

    I suggest using gparted which has a graphical user interface and is more user friendly and safer compared to command line alternatives.

    In this case I would suggest shrinking to 15 GB (with some margin smaller than the nominal size 16 GB because some drives are slightly 'undersized'). I would not make the size as small as possible (10GB) because that would make it difficult or impossible to run the system before the size of the partition is increased to use the remaining drive space.

  • Overwrite all free space in the file system(s) with zeros, because it makes compression much more efficient.

    I suggest zerofree for partitions with ext2, ext3 or ext4 file systems, and to create a file blank with dd for other file systems, and then remove that file blank. See man zerofree.

  • Create the cloned image file (and compress it if you wish).

    I suggest using Disks alias gnome-disks for this purpose. It is a tool with a graphical user interface and is more user friendly and safer compared to command line alternatives.

If you use the old style MSDOS partition table things will be easier to manage after cloning from the image to a target drive of different size than the original one.

With a GUID partition table, GPT, there will be problems with the backup partition table at the tail end of the drive. When creating a GPT, the main partition table is created at the head end of the drive and a backup copy of the partition table at the tail end of the drive. When you clone a drive that target drive will almost always have at least slightly different size, and it means that the backup partition table will either not be there at all (when the target size is smaller than the source) or displaced (not at the tail end (when the target size is greater than the source). This can be fixed with gdisk, but it is easier to avoid the problem and use the old MSDOS partition table.

sudodus
  • 6,421
  • Very good / insightful first step. Please consider adding one command example for each bullet point. References that explain why MSDOS partitions are better than GPT will enable newbies to follow the conversation – gatorback Feb 03 '20 at 14:09
1

Got here from google, and I just want to mention that the Rufus tool can do this, at least for Windows.

I just imaged a 64GB sdcard and the image file created was 3.56GB. Flashed it onto a 32GB sdcard again with Rufus without any issues.

The function for imaging a drive is hidden, you have to select show advanced drive properties and then there will show up a save icon next to the drop down menu where you select drive. Then just give it a name and voila! :) It takes some time, but no hassle.

TurboJens
  • 11