After running owut upgrade, the config is not retained. EFI will also go to UEFI shell as default. After selecting UEFI os in EFI as boot priority 1 openwrt boots fine, and after restoring config im back online.
Also trouble with resizing the partition, the expand root script have a warning againt using it with nvme drive. After update ill use gdisk to delete and create new partition with the entire drive, change grub.conf to point root to nvme0n1p2 partition intead of PARTUUID, run e2fsck -f and resize2fs.
I "just" build the whole image, using dd on sda in the live system and reboot to boot I to the complete configured new system. The only hazzle maybe is configure the new system upfront. I do this in a VM and sync configs between this temp setup VM and my build dir.
Don't change the stock partitions, don't resize your root partition. If you really have to, build an image with an increased rootfs size. Keep that rootfs size identical for all subsequent updates. If the stock partitions and their sizes stay the same between what is on the disk and what is in the update, sysupgrade does not need to jettison the partition table and replace it with the default one.
Why? Assuming your nvme is more than a few gigabytes, how many times over do you want to install all the packages from the OpenWrt repository?
So you basically turn the whole partition table upside down and inside out until it's unrecognizable, and then you're wondering why sysupgrade barfs into the breakfast bowl?
Resizing the root partition and trying to use sysupgrade afterwards is the root cause of all the "x86 doesn't work" issues. Simply create the image with a big rootfs and never resize it to make upgrades completely transparent.
After reading this i guess the best route would be to setup imagebuilder, build images with bigger root partition myself with my config files from the current running version.
Ill se if i still need to login to EFI and change from UEFI Shell to UEFI os after upgrade though.
Your settings are retained if you use the same rootfs size.
I build myself with 16 MB kernel space (future proof) and 1024 MB rootfs size, i use ext4 combined.img
It is a 9 year old PC core-2 duo with 4 GB sata drive and 4 GB Ram
I wanted to bring it to the recycler but heck I thought just try it.
I installed a second $9 TP link ethernet card , I installed proxmox and on top of that a couple of VM's which are running different versions of OpenWRT, amazing it works quite nicely and is used for testing purposes
Well, I'm sure you can predict what I'm going to say: just set up your config with whatever size root partition works for you and run owut upgrade whenever appropriate.
I was using auc up through 23.05 (actually prototype owut was running on 23.05, but it used curl internally to do POSTs with JSON, so not fit for general use), and wanted the bigger root partition (among lots of other things), so owut came into being.
This is a known issue. There's something weird in how NVMe drives behave under Linux after repartitioning. It looks like the drive becomes read-only until the next reboot. This happens both during sysupgrade and when resizing the root partition. The only remedy at this point is to use a different type of drive (2.5" SATA, m.2 SATA, mSATA, eMMC, etc.).
I have never seen an NVMe drive become read-only when a namespace (much less a partition, of which the drive has no innate understanding of) size or configuration changed.
The only actual caveat with OpenWrt x86 images is that they cannot seem to boot, at least not on the machines that I tried that on, from drives that have a 4k LBA sector size configured (instead of the ancient default of 512b).
I've been upgrading my squashfs-based x86 installation regularly and at times frequently without hassle using the imagebuilder since at least 21.02, adopting CONFIG_TARGET_ROOTFS_PARTSIZE=512 (for good measure, not out of necessity) as soon as it became supported.
Yeah, the issue is this is how the Linux kernel enumerates devices. There's nothing wrong with the behavior. The PR you referenced is a separate issue. As long as you're running a snapshot you will have the fix which was merged a while ago. I don't have the commit handy.
