WPA8630(P) 2.0 does not retain config/etc when doing sysupgrade.
Logread post sysupupgrade 22.03->22.03
https://paste.debian.net/hidden/b1f06382/
Logread post sysupgrade 21.02.5->21.02.5
https://paste.debian.net/hidden/35395a9a/
The result is the same, "factory defaults" post sysupgrade. This happened just after wpa8630pv2 was moved to -tiny.
what is the output of the following:
df -h
mount
one moment, gotta boot up the test device
root@OpenWrt:~# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 4096 4096 0 100% /rom
tmpfs 62440 56 62384 0% /tmp
/dev/mtdblock5 884 80 804 9% /overlay
overlayfs:/overlay 884 80 804 9% /
tmpfs 512 0 512 0% /dev
root@OpenWrt:~#
root@OpenWrt:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 4.0M 4.0M 0 100% /rom
tmpfs 61.0M 56.0K 60.9M 0% /tmp
/dev/mtdblock5 884.0K 80.0K 804.0K 9% /overlay
overlayfs:/overlay 884.0K 80.0K 804.0K 9% /
tmpfs 512.0K 0 512.0K 0% /dev
root@OpenWrt:~#
root@OpenWrt:~# mount
/dev/root on /rom type squashfs (ro,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,noatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,noatime)
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,noatime)
/dev/mtdblock5 on /overlay type jffs2 (rw,noatime)
overlayfs:/overlay on / type overlay (rw,noatime,lowerdir=/,upperdir=/overlay/upper,workdir=/overlay/work)
tmpfs on /dev type tmpfs (rw,nosuid,relatime,size=512k,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,mode=600,ptmxmode=000)
debugfs on /sys/kernel/debug type debugfs (rw,noatime)
none on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,noatime,mode=700)
and no, this isn't due to the backup exceeding flash capacity, test case was to simply add a commented line to /etc/config/wireless. (also: dropbear keys get hosed)
This is coming from stock wpa8630pv2_eu-up-ver2-0-3-P1-20171018-rel36564.bin
This behaviour is documented in the device wiki page (https://openwrt.org/toh/tp-link/tl-wpa8630p_v2#installation).
i beg your pardon? where does it say that?
sorry, my bad. it does indeed say that 
Well, "doh" seems appropriate...
Is https://github.com/jwmullally/openwrt_wpa8630p_v2_fullmem "stable" for this device?
I have a working buildroot for this device, how would i go about mitigating this issue?
Yes, for reference here is the underlying issue:
https://lists.openwrt.org/pipermail/openwrt-devel/2019-December/026593.html
Very annoying. The only workaround is to backup configuration before upgrading, then restore it after upgrading.
I'm not sure how to tackle it, as it would affect all ath79/tiny devices and they have different constraints, but few of them are active any more. You would have to study the problem starting with this thread above, and come up with a well tested patch and test it on other ath79/tiny devices. Maybe there is a low-impact fix, not sure.
Re: why ath79/tiny in the first place,
I first tried removing packages and keeping it on "ath79/generic" here, but in the end had to move it to ath79/tiny here.
This doesn't help me, due to the nature of the configs I'll get locked out after sysupgrade (vlans). I'm doing a custom build with limited packages, can I somehow move the device back out of -tiny or adjust the block size?
Also: this was fine until the instant the device was moved to tiny. I get that stock openwrt did not fit post 22.03, but why move it to tiny when it's obvious this will only cause other issues?
also also: i have both wpa8630pv2.0 and wpa8630v2.0 with flash backups and i'm down with assisting you in refining the fullmem patch if this can get the device moved back to generic and solve this issue.
Read the PRs in the previous comment. The new releases were no longer building as they wouldn't fit. I first proposed cutting down packages to keep it fitting in ath79/generic, but this was rejected by the devs in favor of the "right solution" for this kind of issue which is moving to a "tiny" subtarget. I agree in principle. The problem is no-one has fixed the bug above. If someone else can, that would be great.
yes, but seeing as how i'm rolling my own images leaving me with about 780k (on tiny) and about 380K (on generic) of free flash anyway, can i get around this issue by building it for generic instead? how?
No, as it says in the docs:
!!! DO NOT USE - CURRENTLY BEING TESTED - WILL BRICK YOUR DEVICE !!!
A binary patch is needed for the 2nd stage OEM uboot loader to bypass the automatic HTTP recovery server when it reads a specific bit of the OEM firmware that shows the firmware install succeeded, which after this custom firmware is installed is preventing it from booting. I might have some time over the next few months to look at it again.
The difficult thing about moving between generic and tiny subtargets is that you need to move the device definitions between the subtargets. It would be much nicer if instead there was a single "tiny" flag that could be set on the profiles instead of moving them, but thats the way things are now.
To reverse this change on your own build and build this for ath79/generic, do the opposite of this patch.
You can combine that reverse patch with this Makefile (excluding the tplink-safeloader patches as they wouldn't be needed).
When building custom images, keep this warning from the wiki in mind:
you should avoid using snapshot images or customized ImageBuilder images, as both can result in unbootable images that can only be recovered by opening the device and re-flashing.
If you are OK with flashing the SPI flash memory directly, you should be OK.
Im not sure this will move back generic for the official OpenWrt release, unless there are easy ways of cutting down the image size that the devs support.
For this device, increasing the firmware partition size above what OpenWrt currently uses would need messy repartitioning and prevent reverting to OEM without flashing.
This was such a tricky device to get officially supported in the first place that its lucky it got in, and stability + small issues are much better than risk of bricking / no support at all.
So ideally the sysupgrade issue could be fixed
well, seems i have a project for tomorrow, thanks
Oh, it's not that I disagree, but patching sysupgrade is over my head. I'm willing to pay 100USD to whichever dev feels they're up for it.