Upgrade Process for x86-64 ext4 builds [large-disks and data]

A number of reasons

  • I use glibc. It works a lot better on master than on 19.07 as many compilation and bug fixes were made
  • I use a number of additional packages I ported to Openwrt that in some cases require more up-to-date versions of the libraries than exist in stable.
  • On 19.07, I required 95 commits on top of the base repos, whereas on master it's only 10. I contributed a good number of the fixes back, but these fixes make it into master and rarely are backported into stable unless it's a serious security fix
  • Other security fixes tend to find their way into master much quicker; for example, it's generally only a matter of days for a serious openssl CVE to be fixed in master
  • I like tinkering and experimenting with new functionality. And if something is broken I can usually fix it and I contribute the fixes back. Most of the breakage tends to happen in the packages repo as opposed to the base repo, although to be fair, the base repo is affected sometimes.

My particular use and upgrade style has taught me over a decade that I'm better off using master. I wouldn't recommend master for the average user.

I have a git repo of my config files already

I have similar to the OP, x86 ext4 with multiple partitions on a single SSD, in my case:
sda1 is a 16MB /boot
sda2 is a 1024MB /root
sda3 is remainder of the available space on the drive, around 29GB

The sda3 partition is a user data partition, and I wish it to be untouched across upgrades

I do my own builds so I set the build target size for root at 1024MB so it matches across upgrades.

From the thread above, it sounds like all I need to do is sysupgrade the squashfs-img.gz build output with this command:

/sbin/sysupgrade -c /tmp/xxx-squashfs.img.gz

And that would update the /boot and /root and leave the data in sda3 alone, right?