Cant Re-Shrink. Error already smallest size

[thetechknight]

So, there is a bug in this script. I have a PiShrink image I had created but I wrote it to an SD card, expanded the file system and had to make a bunch of changes with scripts, etc in my image. Then I re-read the SD card back to an image file, and tried to run PiShrink again. Bam Failed.

Any reasons as to why you cant re-shrink a pishrink image that has been expanded once?

[npaisnel]

As a random thought ..does the card have another error that is being created by the imaging and writing process.

I randomly get this "Error already smallest size" error.

In my case, this occurs when my image, as written to an SD card has this error Error: Can't have a partition outside the disk!” I create my image using dc3dd and then use pishrink.

For some reason once writing an image back to a card using gEtcher, something is screwed with the sizing of the partitions. Even Raspberry Pi OS itself wont mount it, GPARTED / parted from the CLI shows errors Error: Can't have a partition outside the disk!”

When I get this error, on a card, pishrink wont shrink the image. that created that card.

I have all my errors shown on here: https://www.raspberrypi.org/forums/posting.php?mode=quote&f=28&t=231283&p=1416489

[thetechknight]

No it has nothing to do with SD card corruption. There is some kind of flag, or filesystem thing or something that gets changed during the initial PiShrink. Even fsck comes out good afterwords. Once a PiShrink image gets expanded on a target new SD card, Reading it back and trying to shrink it AGAIN results in this error.

[npaisnel]

Yes. I was not implying SD card corruption, my error is file system related too, hence why I commented.

Fsck shows as ‘dirty’ flagged and unable to clear it.

Like you, my SD card that I am trying to re clone and pishrink is also a product of a previous pishrink operation.

[sickboy2711]

Hello, I have the same problem When I run, I get this message: root @ rpi-Pi-Ager: / home / pi # sudo /usr/local/bin/pishrink.sh -s / home/pi/backup/betarelease_Denni.img Skipping autoexpanding process ... rootfs: 47483/118560 files (0.2% discontinuous), 371045/471040 blocks resize2fs 1.43.4 (31-Jan-2017) ERROR: Image already shrunk to smallest size I use: Rasbian Jessy Lite and have mounted my NAS

[Drewsif]

It only gives that error if the filesystem is at its smallest size what's the output from df -h on the pi?

[TingDingChing]

Hello, I have same problem, It occur when I shrink an RPI image that use previously shrink-ed image on a new microSD card. I believe @mbates14 point out the problem, but how to solve it ? df - h result Filesystem Size Used Avail Use% Mounted on /dev/root 59G 14G 43G 24% / devtmpfs 433M 0 433M 0% /dev tmpfs 438M 0 438M 0% /dev/shm tmpfs 438M 13M 425M 3% /run tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 438M 0 438M 0% /sys/fs/cgroup /dev/mmcblk0p1 253M 40M 213M 16% /boot tmpfs 88M 0 88M 0% /run/user/1000

[prithvirajkadiyala]

Same issue with mine too. I shrink my image every time I create a new build in order to preserve the changes made. Now If I want to go back to one and create another backup of the expanded image, It gives me an error.

pishrink.sh: ERROR occured in line 269: Image already shrunk to smallest size

If I do "df -h" My SD Card has atleast 2GB of free space available.

I would really love to see a fix or go around.

[npaisnel]

I came across all this a year or so ago The whole cloning / shrinking process is very flaky at best I gave up on getting it to work in the end Either buy plenty of spare cards and /or create a very detailed step by step/ line by line set of notes as to how you create your working image so you can rebuild from scratch each time.

Cloned and or shrunk images always seem to fail one way or another. After wasting a few weeks every day trying (while I was laid up in bed with a broken leg), I gave it up as a bad job

I wasted more time trying to create shrunk backups, than I ever would have spent just re creating from a blank card each time.

[framps]

I added some more debug logs statements in my fork of pishrink. Maybe somebody can use this version of pishrink to provide two debug logs:

1. Debug log pishrink.log which is created with additional option -d for an image which was not shrinked by pishrink before.
2. Then start up the shrinked image to get the image expanded and shrink the expanded image again with pishrink using option -d and provide the debug log for the image shrinked a second time.

[thetechknight]

I figured out the problem.

PiShrink does something to the filesystem that causes the size to be reported incorrectly, Even after the Pi re-expands it.

After shrinking an image and reloading it to a new SD card, I had to let the Pi re-expand it. But systemctl shows the operation fails with an error, even though doing a disk info check shows the filesystem as being a full size filesystem, IT IS NOT.....

So I have to remount as rw (adafruits readonly mod) and redo it again and do a check disk. It find an issue and fixes the filesystem, and then using systemctl to rerun the expand operation "resizefs" manually again, it will work without error.

After this, PiShrink WILL allow me to shrink again!

[framps]

But systemctl shows the operation fails with an error,

Sounds like there is an issue in the expansion code executed by pishrink. Should be possible to catch the issue when an image is created with option -s (don't expand filesystem during boot). Then, when started up, the following script has to be executed manually and has to be checked for error messages.

[thetechknight]

Ah, so PiShrink replaces the stock resize script on the SD card image? That explains that then...

[framps]

That explains that then...

Would you please elaborate a bit more on this statement :wink:

[Drewsif]

This is definitely a use case I've not explored. I'll have to test it and see if I can reproduce the error but I'm not sure what would be causing it to be stuck as dirty...

[Kikix969]

I figured out the problem.

PiShrink does something to the filesystem that causes the size to be reported incorrectly, Even after the Pi re-expands it.

After shrinking an image and reloading it to a new SD card, I had to let the Pi re-expand it. But systemctl shows the operation fails with an error, even though doing a disk info check shows the filesystem as being a full size filesystem, IT IS NOT.....

So I have to remount as rw (adafruits readonly mod) and redo it again and do a check disk. It find an issue and fixes the filesystem, and then using systemctl to rerun the expand operation "resizefs" manually again, it will work without error.

After this, PiShrink WILL allow me to shrink again!

Can you please describe the way in a little more detail?

[gamagalhaes]

I am also facing this error. The error happens even using "-s"

Using the "-s" sudo ./pishrink.sh -s batocera.img pishrink.sh v0.1.2 pishrink.sh: Gathering data ... Skipping autoexpanding process... pishrink.sh: Checking filesystem ... SHARE: 78307/3653632 files (2.7% non-contiguous), 14380072/14597632 blocks resize2fs 1.45.5 (07-Jan-2020) pishrink.sh: ERROR occurred in line 335: Image already shrunk to smallest size

Not using the "-s" sudo ./pishrink.sh -v batocera.img pishrink.sh v0.1.2 pishrink.sh: Gathering data ... pishrink.sh: /etc not found, autoexpand will not be enabled ... pishrink.sh: Checking filesystem ... SHARE: 78307/3653632 files (2.7% non-contiguous), 14380072/14597632 blocks resize2fs 1.45.5 (07-Jan-2020) pishrink.sh: ERROR occurred in line 335: Image already shrunk to smallest size

Here is the log of the attempt. pishrink.sh v0.1.2 pishrink.sh: Gathering data ... Line 304 beforesize: 60G parted_output: BYT; /mnt/g/PiShrink/batocera.img:64087916544B:file:512:512:msdos::; 1:1048576B:4296015871B:4294967296B:fat32::lba; 2:4296015872B:64087916543B:59791900672B:ext4::; partnum: 2 partstart: 4296015872 parttype: primary tune2fs_output: tune2fs 1.45.5 (07-Jan-2020) Filesystem volume name: SHARE Last mounted on: /media/SHARE_1 Filesystem UUID: 75d9e510-9364-4624-9b8c-46b98390fa0f Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file dir_nlink extra_isize metadata_csum Filesystem flags: signed_directory_hash Default mount options: user_xattr acl Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 3653632 Block count: 14597632 Reserved block count: 0 Free blocks: 217560 Free inodes: 3575325 First block: 0 Block size: 4096 Fragment size: 4096 Group descriptor size: 64 Reserved GDT blocks: 57 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8192 Inode blocks per group: 512 Flex block group size: 16 Filesystem created: Thu Jun 10 16:42:34 2021 Last mount time: Mon Oct 11 16:55:03 2021 Last write time: Mon Oct 11 16:55:03 2021 Mount count: 0 Maximum mount count: -1 Last checked: Mon Oct 11 16:55:03 2021 Check interval: 0 (<none>) Lifetime writes: 55 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 32 Desired extra isize: 32 Journal inode: 8 Default directory hash: half_md4 Directory Hash Seed: c321d65b-156f-46d4-9c46-99e18f0b6b6f Journal backup: inode blocks Checksum type: crc32c Checksum: 0x3fbb56d8 currentsize: 14597632 blocksize: 4096 pishrink.sh: /etc not found, autoexpand will not be enabled ... pishrink.sh: Checking filesystem ... SHARE: 78307/3653632 files (2.7% non-contiguous), 14380072/14597632 blocks resize2fs 1.45.5 (07-Jan-2020) Line 333 currentsize: 14597632 minsize: 14597632 pishrink.sh: ERROR occurred in line 335: Image already shrunk to smallest size

[guysoft]

I had an image that I wanted to dd, then shrink again, without it actually regrowing.

So I got an error:

ERROR occurred in line 335: Image already shrunk to smallest size

My workaround was to comment out this exit error line: https://github.com/Drewsif/PiShrink/blob/master/pishrink.sh#L360

Then I could shrink the image. The error still showed - perhaps its worth adding --force flag or something else for these use cases.

[amitchell056]

I had an image that I wanted to dd, then shrink again, without it actually regrowing.

So I got an error:

ERROR occurred in line 335: Image already shrunk to smallest size

My workaround was to comment out this exit error line: https://github.com/Drewsif/PiShrink/blob/master/pishrink.sh#L360

Then I could shrink the image. The error still showed - perhaps its worth adding --force flag or something else for these use cases.

Thanks for the workaround idea, however the line I had to comment out is https://github.com/Drewsif/PiShrink/blob/master/pishrink.sh#L336 (exit 11)

[MiakuAL]

I had the same issue, but somehow managed to fix it ? I was trying to redo an image from an image I created named myimg (sudo pishrink.sh -Z myimg.img), and was getting this error. My system partition is smaller than my full sd card I took the sd card out , put it in my pc, opened G-Parted and did the following (I don't know which step fixed it)

• Check flags on the ext4 partition (it resulted in an error, I ended up closing Gparted because I thought I was locked in the error message)
• Change the partition size (in my case I made it bigger using what was left on the sd card)
• Make it back to the smaller size
• Verify

After this, I didn't get any error when trying to check flags. I put it back in the rpi, and I no longer have the error from PiShrink.

I hope this help, and I apologize if my english is incorrect

[Drewsif]

Does the unshrunk image also throw the errors in gparted when checking the flags?

[MiakuAL]

No idea, I haven't tried sorry Sadly, I switched project and I don't work on my rpi anymore, but if I get back to it, I'll try and let you know

[Drewsif]

I'm going to close this for now then. It seems like one possible fix is in #231

[ThomasNittel]

I got the same problem. pishrink.sh reports: "ERROR occurred ... Image already shrunk to smallest size" (see ErrorMessage.jpg below). I was able to solve it the following way.

Reason: The partition size doesn't match the file system size. If the file system is made about the same size as the partition, the file system can be shrinked again.

The problem exists if "df -h /" and "sudo fdisk -l /dev /mmcblk0p2" display significantly different sizes (see OriginalRaspian.jpg and MyRaspian.jpg below).

Explanation: dd makes a copy of the partition. resize2fs changes the size of the file system due to the file system size, but not due to the partition size.

If the partition size doesn't match the file system size, dd creates an image of the partition e.g. of 8 GB but resize2fs cannot shrink this image because the file system has already the minimum size of 2 GB.

"sudo fdisk -l /dev/mmcblk0p2" shows the partition size, e.g. 8 GB. "df -h /" shows the file system size, e.g. 2 GB.

This situation can emerge if expanding the file system failed in the past because of for example read only file system.

Remedy: Place the MicroSD card in card reader ls /dev -> device of the 2nd partition of MicroSD card, e.g. /dev/sdb2 sudo mkdir /tmp/extra sudo mount /dev/sdb2 /tmp/extra sudo fdisk -l /dev/sdb df -h /dev/sdb2 -> Compare the size of the partition and the file system in order to check if this is the problem.

sudo umount /dev/sdb2 If automount runs, /dev/sdb2 might be repeatedly mounted. Then stop automount service or enter "sudo umount /dev/sdb2" until "mount" command doesn't list /dev/sdb2 anymore.

sudo fsck -vfy /dev/sdb2 sudo resize2fs /dev/sdb2

Check: sudo mount /dev/sdb2 /tmp/extra sudo fdisk -l /dev/sdb df -h /dev/sdb2 -> If both commands display around the same size, the operation was successful. sudo umount /dev/sdb2

ErrorMessage.jpg

OriginalRaspian.jpg

MyRaspian.jpg