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.
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.
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:
you create your own image to have a usable root (> 100MB), let's say 512M
install your image as should
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).
repeat steps 1-2 for new image releases, and remount your own partition/fs.
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.
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.