This is just a typo from my side. I resized the partition with correct device. But still, it is not enough to do it, you need to fix file system for partition to be usable. It is not mentioned in FAQ so maybe it needs to be added?
If you see anything that needs to be added to or clarified in @NC1's guide, make sure to post it on the thread @d687r02j8g mentions above so it can be updated!
Indeed. I am thinking of putting out the next edition in April or maybe May (in other words, whenever I have some time to put into it). Found an interesting issue (that, upon some Googling, has apparently been around for a while), which can be easily avoided by a slightly different resizing routine.
After resizing a UEFI/SquashFS system, the boot partition fails to automount at boot (even though resizing doesn't affect it). Everything still works, routers still boot, but the boot partition is not accessible to the root user unless mounted manually.
The workaround turns out to be pretty simple: rather than edit the grub config to reflect the renaming of the root partition that happened during resizing, we can give the resized and renamed root partition its original UUID back (there are options for that in fdisk) and leave the grub config be... So I am thinking of changing to this approach and throwing out everything grub-related...
And yes, I should probably spell out more explicitly that sda is not the only naming possibility; eMMC and NVMe storage devices do go under different names... After all, I do claim to target less experienced users, for whom this would be good to know...
Guess what. My chinese miniPC NVMe died after three years, forcing me to reinstall everything from zero. And boy are NVMe drives expensive nowadays. I failed expanding ext4 file system twice, until I remembered to read my own thread. gparted "fixed" it again. What do I do with 1TB NVMe OpenWRT drive (it was all I had lying around).
cat > /tmp/resize-nvme.sh << 'EOF'
#!/bin/sh
set -e
apk update
apk add parted losetup resize2fs lsblk partx-utils
# Derive the disk and root partition from the mounted /boot, not from parted -l
BOOT=$(awk '$2=="/boot" {print $1}' /proc/mounts)
[ -n "$BOOT" ] || { echo "No /boot mount found. Aborting."; exit 1; }
DISK="/dev/$(lsblk -no PKNAME "$BOOT")"
BOOTNUM=$(echo "$BOOT" | grep -o '[0-9]*$')
PART=$((BOOTNUM + 1))
ROOT="${DISK}${PART}"
case "$DISK" in *mmcblk*|*nvme*) ROOT="${DISK}p${PART}" ;; esac
FSTYPE=$(lsblk -no FSTYPE "$ROOT" | head -n1)
echo "Disk: $DISK Partition: $ROOT Type: ${FSTYPE:-unknown}"
parted -s "$DISK" print || true
case "$FSTYPE" in
ext4|squashfs) ;;
*) echo "Unsupported filesystem '${FSTYPE:-none}' on $ROOT. Aborting."; exit 1 ;;
esac
# Bail out if there is nothing to claim (avoids a pointless table rewrite)
FREE=$(parted -sm "$DISK" unit MB print free | awk -F: '/free;$/ {gsub("MB","",$4); f=$4} END {print int(f+0)}')
if [ "${FREE:-0}" -lt 16 ]; then
echo "Less than 16MB unallocated. Nothing to do."
exit 0
fi
echo "Unallocated space available: ${FREE}MB"
# Repair the GPT backup header (it sits mid-disk after an image write), then grow
echo fix | parted ---pretend-input-tty "$DISK" print >/dev/null 2>&1 || true
parted -s "$DISK" resizepart "$PART" 100%
# Make the kernel re-read the table without rebooting
partx -u "$DISK" 2>/dev/null || partprobe "$DISK" 2>/dev/null || true
sleep 2
if [ "$FSTYPE" = "ext4" ]; then
resize2fs "$ROOT"
df -h /
echo "Done."
exit 0
fi
# squashfs: partition 2 is read-only, the writable overlay is a loop device
# backed by the free space inside that same partition.
LOOP=$(losetup -n -O NAME,BACK-FILE 2>/dev/null | awk -v r="$ROOT" '$2==r {print $1}' | head -n1)
if [ -z "$LOOP" ]; then
echo "Partition grown, but the overlay loop device was not found."
echo "Reboot and re-run this script to finish the overlay resize."
exit 0
fi
losetup -c "$LOOP"
OVFS=$(lsblk -no FSTYPE "$LOOP" | head -n1)
echo "Overlay: $LOOP Type: ${OVFS:-unknown}"
case "$OVFS" in
ext4)
resize2fs "$LOOP"
df -h /overlay
echo "Done."
;;
f2fs)
echo "Overlay is f2fs and cannot be grown while mounted."
echo "Partition resize is complete and persistent."
echo "Finish offline: boot the initramfs image, then run"
echo " resize.f2fs $LOOP"
;;
*)
echo "Unrecognised overlay filesystem '${OVFS:-none}'. Partition resize is complete;"
echo "the overlay was left untouched."
;;
esac
EOF
chmod +x /tmp/resize-nvme.sh
sh /tmp/resize-nvme.sh
I am thinking of putting out the next edition in April or maybe May (in other words, whenever I have some time to put into it). Found an interesting issue (that, upon some Googling, has apparently been around for a while), which can be easily avoided by a slightly different resizing routine.
(it was all I had lying around).