Open jjfoerch2 opened 11 months ago
(This is jjfoerch2, just my other github account.)
I was able to achieve a desired partition size by making the following change to pishrink. I just hard coded the size that I wanted for my project, but I would be interested in helping to develop this into a proper option.
diff --git a/pishrink.sh b/pishrink.sh
index f16af49..9eb74cb 100755
--- a/pishrink.sh
+++ b/pishrink.sh
@@ -111,18 +111,7 @@ do_expand_rootfs() {
[ "$PART_START" ] || return 1
# Return value will likely be error for fdisk as it fails to reload the
# partition table because the root fs is mounted
- fdisk /dev/mmcblk0 <<EOF
-p
-d
-$PART_NUM
-n
-p
-$PART_NUM
-$PART_START
-
-p
-w
-EOF
+ echo ",4GiB" | sfdisk --no-reread -N $PART_NUM /dev/mmcblk0
cat <<EOF > /etc/rc.local &&
#!/bin/sh
@@ -144,7 +133,7 @@ else
exit
fi
}
-raspi_config_expand
+#raspi_config_expand
echo "WARNING: Using backup expand..."
sleep 5
do_expand_rootfs
There are a couple of points to work out, were this to be developed into an option:
I commented out the use of raspi_config_expand
so that it only uses the backup expand method, to allow me to specify the desired partition size because raspi-config does not support specifying a partition size. Would we want to use conditionals to still use raspi-config to perform the resize if it is available, or just remove it entirely? I don't see a reason to keep the call to raspi-config but others may know better.
I used sfdisk instead of fdisk to perform the resize. I ran into a problem with fdisk asking interactive questions, making it seem fragile and prone to breaking on different systems. sfdisk is intended for non-interactive use in scripts so it seems like the more appropriate tool in this case. But is sfdisk always available on the target platforms of PiShrink or should we retain a fallback to fdisk?
This warning is produced during the resize process - I don't think it is technically a problem but maybe there is a way to deal with it -
Thank you developers for any feedback on this idea.
raspi_config_expand was originally used because the expanding code broke once or twice. I'm not sure that its still that touchy and it could maybe be removed in favor of the "backup" option. This feels like a very niche use case, but I am open to the idea.
Hello,
Would it be possible to add an option to PiShrink that would allow one to specify the size for resize2fs to resize the partition to on the first boot?
This would be helpful in the case of backup procedures for a couple of Pi systems that my work has - the projects only need a few GB of their SD card, but small SD cards are increasingly becoming more expensive and harder to find than larger ones. To keep the backup procedure quick and efficient, and not require such a large USB drive to backup to, I would like to limit the filesystem size at the point that resize2fs performs the resize.
Thank you for the great tool.