I have another method that worked for me. I pulled the hard drive out of the Openwrt machine and connected it to a usb to sata adpater. I then plugged that into a Debian 11 machine and edited the partitions with G-parted.
This works, too. If you have the right adapter. I've done this on ext4 drives, but not on SquashFS drives. On my Mint machine, gparted recognizes SquashFS partitions, but doesn't want to do anything that involves writing with them. It's entirely possible that this can be overcome with the right software, but I have not researched this.
Also, on some x86 units (for example, Sophos XG 85[w] and 86[w]), the boot drive is an eMMC module soldered onto the motherboard. In those cases, the removal of the boot drive is simply not an option...
FYI, i build/adapt a fire and forget script (just execute and after reboot system is fine gain) for the ext4 version:
###March 2023 Edition, see https://forum.openwrt.org/t/howto-resizing-root-partition-on-x86-march-2023-edition/153398
BOOT="$(sed -n -e "\|\s/boot\s.*$|{s///p;q}" /etc/mtab)"
PART="${BOOT##*[^0-9]}"
DISK="${BOOT%${PART}}"
ROOT="${DISK}$((PART+1))"
###Custom Part
ROOTPART="$((PART+1))"
OFFS="$(fdisk ${DISK} -l -o device,start | sed -n -e "\|^${ROOT}\s*|s///p")"
echo -e "p\nd\n${ROOTPART}\nn\np\n${ROOTPART}\n${OFFS}\n\nn\np\nw" | fdisk ${DISK}
###March 2023 Edition, see https://forum.openwrt.org/t/howto-resizing-root-partition-on-x86-march-2023-edition/153398
LOOP="$(losetup -f)"
losetup ${LOOP} ${ROOT}
resize2fs -f ${LOOP}
reboot
As side note, after https://git.openwrt.org/7b7edd25a571 one can use ImageBuilder to prepare image with desired rootfs size.
2 Likes
I wish, auc could handle that… 
1 Like
when i press N i get this
Partition number (2-127, default 2): Command (m for help): d
Partition number (1,2,128, default 128): 2Partition 2 has been deleted.
Command (m for help): n
Partition number (2-127, default 2):
what should i do here?
Keep reading the HOWTO. The answer is just a few lines down:
Partition number (2-4, default 2): [[2]]
I think the best solution would be to:
1 - create a new partition with the rest of the disk
2 - use this partition to extend openwrt as it is possible to do using an external USB key
this would allow you not to touch the original firmware
this could be automatic whatever the size of the disk
i will tell you my secret, boot the usb stick or hard drive into linux it can be other pc or virtual box open gparted choose your hard drive with openwrt sda or sdb then choose root partition resize and chose all the unclaimed space, done
lots of memory now
its easy and fast
i tried windows partition manager but does not works well with ext4 format
1 Like
It's great that this works but there are so many steps involved. I would like to see a tool developed similar to growpart from https://github.com/canonical/cloud-utils which would be able to perform all of these steps automatically with a simple package install.
Next to developing an x86 installer (which I don't actually think is that farfetched!) this would really help a lot of people on this platform.
See also: https://openwrt.org/docs/guide-user/advanced/expand_root
What's stopping you ?
I know it can be nice to have a PR on-hand when providing feedback but experience has taught me that often times, it can be helpful to talk about new features before they're implemented. For example, to prevent duplication of work and to provide an opportunity for more diverse input of perspectives that may not have been considered.
Finally it worked! I did this on a Sophos SG115 rev 2 with BIOS (I tried EFI at first, but later I realized this model doesn't support UEFI anyway).
The only thing that I had to do different was I had to reboot before running "Resize the Root File System", otherwise I kept getting:
root@OpenWrt:~# echo $LOOP
/dev/loop0
root@OpenWrt:~# resize2fs -f ${LOOP}
resize2fs 1.47.0 (5-Feb-2023)
The filesystem is already 102272 (1k) blocks long. Nothing to do!
After a reboot, it worked:
root@OpenWrt:~# echo $LOOP
/dev/loop0
root@OpenWrt:~# resize2fs -f ${LOOP}
resize2fs 1.47.0 (5-Feb-2023)
Filesystem at /dev/loop0 is mounted on /overlay; on-line resizing required
old_desc_blocks = 1, new_desc_blocks = 477
The filesystem on /dev/loop0 is now 62501592 (1k) blocks long.
That expand_root script works fine for me. This step by step in some reason renders system read only after 3-4 reboots. I tried at least 20 times. Even check disk before mounting cant help.
x86/64 system with 8GB ssd.
OpenWrt 23.05.2 r23630-842932a63d / LuCI openwrt-23.05 branch git-23.306.39416-c86c256
Thank you.
just install virtualbox, then ubuntu live iso, plug the usb and then use gparted program there, it will appear the usb partition root you just have to slide and fill the space and is done
Or simply boot gparted off a flash drive.
1 Like
I'm running into a snag on x86-64 efi. Not sure what I'm doing that is causing this.
Command (m for help): w
The partition table has been altered.
Failed to remove partition 2 from system: Resource busy
Failed to add partition 2 to system: Resource busy
The kernel still uses the old partitions. The new table will be used at the next reboot.
Syncing disks.
root@OpenWrt:~# lsblk -o PATH,SIZE,PARTUUID
PATH SIZE PARTUUID
/dev/sda 10G
/dev/sda1 16M 80cdd189-4ce8-125d-9e5c-32a6bb5c6501
/dev/sda2 104M
/dev/sr0 1024M
/dev/sda128 239K 80cdd189-4ce8-125d-9e5c-32a6bb5c6580
The partition seems to still write, but doesn't show me a new PARTUUID. It also didn't ask me if I wanted to make it a primary partition
for comparison here is the old UUID:
root@OpenWrt:~# cat /root/lsblk_old.txt
PATH SIZE PARTUUID
/dev/sda 10G
/dev/sda1 16M 80cdd189-4ce8-125d-9e5c-32a6bb5c6501
/dev/sda2 104M 80cdd189-4ce8-125d-9e5c-32a6bb5c6502
/dev/sr0 1024M
/dev/sda128 239K 80cdd189-4ce8-125d-9e5c-32a6bb5c6580
EDIT: figured it out. I missed this step:
First sector (33280-31277231, default 34816): [[33792]]
I was using the default, so this was creating a conflict when trying to overwrite the actively used partition table
1 Like
for upgrading, normal sysupgrade will not work. Force upgrade will not work either. I basically have to reinstall from scratch.
what does your post have to do with the rest of the thread ?
I was just trying to find out a way to upgrade the system after resizing it a couple of months ago using this guide. the wiki on the x86 page doesn't seem to cover this type of modification (https://openwrt.org/docs/guide-user/installation/openwrt_x86#upgrading). I am trying to provide context if anyone is trying to do the same that normal sysupgrade procedure doesn't seem to work after this modification.
my system:
x86-64-generic-squashfs-combined-efi.img.gz upgrading from 23.05.2 to 23.05.3