PiAware image to be flashed on new SD card

I made an image of my PiAware card (32G). When I try to flash it back on another SD card (also 32G) it tells me that it needs more space. If I run this command: df -h / I get

Filesystem Size Used Avail Use% Mounted on
/dev/root 29G 5.7G 22G 21% /

So obviously there’s plenty of free space available. Is there an easy way to make an image of the used space only? Or can I just copy and paste the PIA files directly onto the new SD card?

Maybe you should change the imaging software ? Balena ectcher, Rufus, take your pick. The Piaware image even fits on a 8Gb card so that shouldn’t be an issue :wink:

I used Balena etcher to flash the image. Unfortunately the image was already created and was 29 Gb. It seems that when you create an image the whole SD capacity is taken into account, not just the files (5.7 Gb).

1 Like

This software allows you make clones with ease :wink:

(1) OPENING POST - INITIAL ATTEMP, NOT PERFECT, HAD DRAWBACKS:

 

(2) POST #17 - FINAL SUCCESSFUL SOLUTION:

 

.

The ARM release of Debian 12 (bookworm) (that applies to the Raspberry Pi OS release as well) has a breaking change in the mountpoint of the first (vFat) partition - it is now mounted in /boot/firmware and NOT in /boot - this causes the rpi-clone utility to break.

DietPi ARM images choose to retain the old behavior of mounting the first partition in /boot.

If you have actually created a direct copy image of the SD card, pishrink might be useful:

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.

I have not tested this on images based on Debian 12, be aware it might not work as expected.

P.S. I have found the Raspberry Pi Imager the best tool for writing images to SD cards as well as SSDs and other boot media. The tool replaces custom and other similar tools in my toolbox. It’s open source, doesn’t ‘phone home’ as far as I can tell, gives the ability to create working out-of-the-box Pi installations, and is available on Windows, Mac, and Linux.

2 Likes

Your sentence reminds me of the 1982 movie “E.T. the Extra-Terrestrial” which had a famous dialogue “E.T. Phone Home:slightly_smiling_face:

 

1 Like

Unfortunately, Not all cards are the same size in terms of capacity. One 32Gb card could be a ‘slightly smaller’ in capacity’ to another so when it tries to copy to a ‘same size card’, if the card you are copying to is even a ‘smigen’ smaller in terms of what the system reports, it won’t copy no matter what the system tells you about free space.

How I get around this is the same as what AhrBee says above and has worked perfectly for me in situations like this. I take a backup copy of the ‘master’ image in its raw size (in case I mess something up! LOL!) and use a system called PiShrink from:

PiShrink is a bash script that automatically shrinks 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. In addition the shrunk image can be compressed with gzip and xz to create an even smaller image. Parallel compression of the image using multiple cores is supported.

I have a ubuntu desktop (I use Oracle VM Virtualbox) with Pi Shrink installed. Works perfect for me if I get that message about the card needing more space. I had an image from one 16Gb card that wouldn’t install on another 16Gb card as it ‘needed more space’. I ran PiShrink on the image which shrank it down to about 10Gb then used BelenaEtcher, Raspberry Pi Etcher or whichever is your choice of image writer to write the ‘shrunk’ image to my 16Gb card then inserted it into my Pi and started it up. It automatically resized the SD card and the Pi is happily doing what it it was supposed to do.

Hope this maybe helps

Declan

3 Likes