OpenWRT on x86, advise on selecting an image that will retain a data partition yet make updates easy

For my RPi4B, I am using the *rpi-4-ext4-sysupgrade.img.gz which does not modify my data partition which is after the boot and root partitions on the uSD card. I am interested in having the same setup on my x86/64 box except that has a SSD not uSD.

Is there a x86 image that will behave like this? I imaged the device the openwrt-x86-64-generic-ext4-combined-efi.img.gz image, but according to gdisk, I have no free sectors available to create the large data partition.

EDIT: so I ran fdisk and created a new partition new partition. It seems to remain after I reflashed openwrt-x86-64-generic-ext4-combined-efi.img.gz... is what I am doing safe and sane? As I build a new image, will the data on my /dev/sda3 be safe or will it eventually get overwritten by the image flash?

# fdisk -l /dev/sda
Disk /dev/sda: 238.47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: FPT310M4SSD256G 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 15B308CE-4936-BD9D-31B4-60558C932A00

Device        Start       End   Sectors   Size Type
/dev/sda1       512     66047     65536    32M Linux filesystem
/dev/sda2     66048   1114623   1048576   512M Linux filesystem
/dev/sda3   1116160 500117503 499001344 237.9G Linux filesystem
/dev/sda128      34       511       478   239K BIOS boot

Partition table entries are not in disk order.

It's far from what you describe but you should look at

https://openwrt.org/docs/guide-user/installation/attended.sysupgrade

I use this on a Beelink U59 Pro with OpenWrt on a external flash disk.

If Openwrt ever decides to extend the size of the default x86 image, it'll be lost, until then, you should be safe.

Or use a dual version setup with larger default partitions, like I've described in Sysupgrade help for x86_64 - #14 by frollic

Is this precedented? I believe the CONFIG_TARGET_ROOTFS_PARTSIZE dictates this, no?

Yes. It's one reason why devices with low storage and RAM (e.g. 4/32, 8/64) are no longer supported. The product has grown in capability and size, so occasionally the filesystem size increases to accomodate it.

I guess my method is dangerous/requires backups and willingness for downtime. There must be a more reliable and easy method...

there is no better method ...
owrt default x86 image size is ~100MB root + 16MB boot, sysupgrade or dd'ing combined-efi.img will overwrite the partition table ... so you can do the followings:

  1. you create your own image to have a usable root (> 100MB), let's say 512M
  2. install your image as should
  3. leave a gap at least your image size (512MB) and create your own partition

this likely will give you some safety if ever default image will expanded (which is unlikely to take the leap from 100MB to 1000MB, but just in case).

  1. repeat steps 1-2 for new image releases, and remount your own partition/fs.
  2. for better system upgrade you may utilize your gap as second root, with minimal changes you can selectively boot into root1 or root2. and then system upgrade can be reduced to dd rootfs.img + kernel copy instead of overwriting the parition table.

Just start building your own images with a bigger rootfs. For example mine has 5 GB (probably overkill). Then just create/mount another partition with the remaining space via fstab.

@grrr2 @Hudra - yes, I have been building with:

CONFIG_TARGET_KERNEL_PARTSIZE=32
CONFIG_TARGET_ROOTFS_PARTSIZE=512

For my use, that is plenty of space (29% root FS usage).

Did either of you guys try to reorder the partitions or is that just asking for problems?

# fdisk -l /dev/sda
Disk /dev/sda: 238.47 GiB, 256060514304 bytes, 500118192 sectors
Disk model: FPT310M4SSD256G 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 15B308CE-4936-BD9D-31B4-60558C932A00

Device        Start       End   Sectors   Size Type
/dev/sda1       512     66047     65536    32M Linux filesystem
/dev/sda2     66048   1114623   1048576   512M Linux filesystem
/dev/sda3   1116160 500117503 499001344 237.9G Linux filesystem
/dev/sda128      34       511       478   239K BIOS boot

Partition table entries are not in disk order.

why would reoder? this is totally ok
if you wonder why there is sda128 that's totally ok, that's the first ( ! ) physical partition to store BIOS boot code which is called partition 128. sda1 is boot, sda2 is root, sda3 is your own, sdaX is your own etc. that's the normal order.

OK, I will ignore that. It does seems to function fine as-is. Thanks.