FS of "root" partition remains 100% full after firing "sdm --shrink" tool

[carriba]

I have expanded the image file (using the "truncate" tool), have extended the embedded FS and have done a full upgrade of the RPi OS with the usual commands "DEBIAN_FRONTEND=noninteractive apt update ; apt -y upgrade ; apt -y autoremove ; apt -y clean".

After firing the command "sdm --shrink raspbian.img", and mounting the image file, I am getting the following result:

pi@raspberrypi:~ $ sudo systemd-nspawn -D /mnt/image
Spawning container image on /mnt/image.
Press ^] three times within 1s to kill container.
root@image:~# df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/loop0p2     3355816  3211152         0 100% /
/dev/loop0p1      261108    51630    209478  20% /boot

The FS of the "root" partition remains 100% full. Can the shrinking method be adjusted?

[gitbls]

Adjusted to do what?

If you'd like this to be looked into, please provide a repro that I can use to actually repro what you're seeing, along with a description of the desired behavior that you reference.

[carriba]

Being able to adjust somehow the shrink parameter that the function "sudo sdm --shrink" determines.

I have downloaded the latest "RPi 11 Bullseye" image file and saved to my USB thumb drive.

I have plugged the thumb drive to my RPi device, and unpacked it with the command: xz -k -d -c /media/usb_disk/raspbian_img.xz > raspbian.img

I have expanded the image file and extended the EXT4 FS of its 2nd partition with the described script that does the same as "sudo sdm --extend raspbian.img" (and am using it now).

Once the image has been expanded and the FS extended, I have fired the following sequence of commands:

sudo losetup --show -P -f raspbian.img
sudo sh -c 'mkdir -p /mnt/image ; mount -v /dev/loop0p2 /mnt/image ; mount -v /dev/loop0p1 /mnt/image/boot'
sudo systemd-nspawn -q -P -D /mnt/image /bin/bash << EOF
DEBIAN_FRONTEND=noninteractive apt update ; apt -y upgrade ; apt -y autoremove ; apt -y clean
EOF
sudo sh -c 'umount -v /mnt/image/boot ; umount -v /mnt/image ; rm -rf /mnt/image'
sudo e2fsck -pf /dev/loop0p2
sudo zerofree /dev/loop0p2
sudo losetup -d /dev/loop0

After these steps, I shrank the image file with the command "sudo sdm --shrink raspbian.img"

Once the image file got shrunk, I have re-associated the corresponding partition of the updated image file to the same block device, mounted to the same directories, and have fired the same commands as above to inspect the contents of the shrunk image file.

[gitbls]

I'm not sure I understand exactly what you're trying to do, and I think you left out what may be the main point.

My best guess is that you want to shrink the IMG to the minimum PLUS some additional amount that you'd specify. For instance, in sdm terms: sdm --shrink --xmb 2048 file.img would shrink the IMG to the minimum size with an additional 2GB of space.

Would this meet your need? If not, please describe it in English without any code.

Thx

[carriba]

Let me rephrase it from the beginning:

I have been using the "sdm --shrink" command to shrink the image file. Have burned the image file onto an SD card, and the RPi device did not boot up for some unknown reason.

I double-checked the image file and have discovered that the "root" partition of the image file was 100% full.

You have asked above to

provide a repro that I can use to actually repro what you're seeing

I did provide the sequence of steps to enable you "repro" the issue.

Thus, from this learning, I believe, the "sdm --shrink" command should not automatically shrink the image file to such an extreme that the "root" partition results to a 100% full FS.

Leave some margin, like 2% to 4% so that log files and other temporary files can be created, when booting up a RPi with this image.

[gitbls]

Thank you for the clear, codeless explanation. Will look into this as part of the next release.

[carriba]

I went ahead modifying my local copy of the /usr/local/sdm/sdm-cmdsubs file, and have updated in function sdm_shrink() the calculation of the newsize variable.

I am using now newsize=$((newsize+(5*4096))), and upon launching "sdm --shrink" I am getting a 98% full FS for the "root" partition.

I burned the resulting image file on a SD card, and the 1st time boot works fine now.

[gitbls]

In the next release of sdm the --shrink command will leave --xmb MB of additional space, which addresses your goal in a more flexible way. The amount of free space in the file system after this will not be precisely what was requested, but you will be able to sort out what to specify for --xmb if you want more precise control.

FYI, I do not like "mandatory defaults" (which is what you have implemented) unless there's no other way. In other words, I would not consider your approach. But, you're welcome to take the code and do whatever you want with it.

[gitbls]

sdm V11 implements --shrink honoring --xmb additional MB of space. Please give it a try, I appreciate your feedback.

[gitbls]

Closing due to lack of activity.