While @berx has manually repaired this, I'd like a solution from GL staff please as I don't want to be instructing the average user to mess around with what is basically uboot environmental settings which could lead to multiple bricked devices.
All I have done is try the 4.7 beta, Openwrt and Immortalwrt.
I installed 4.6.8 over Openwrt without keeping settings. This can't have removed these files.
I have checked openwrt-mt2500-4.7.0-1205-1733363804 and openwrt-mt2500-4.7.0-1205-1733363804. in both the file root~/etc/uci-defaults/30_uboot-envtools/30_uboot-envtools exists.
I have attached it here: 30_uboot-envtools.zip (998 Bytes)
You can try and manually execute each step. It helped me at the end to understand the requirements.
Of course an "official" solution by GL is a long term solution. But even your analysis can speed up their work. Just please keep sharing here.
Okay... another update which has issues? Not a good sign, based on my latest Slate AX experience. Before never had any issues with updates and now it looks like there are again people with issues. I will wait updating my Brume 2...
Just another data point, I "upgraded" my Brume2 last night from 4.6.8 to 4.7.0 and it is bricked now. Light stays on blue solid after flashing a couple of times when I first power it on. No response from any IPs I tested, 192.168.1, .8, .9, either port. Also a note - I have it connected only via WAN port typically, so the security defaults to disable WAN access would have caused me an issue anyway - leading me to plug into the LAN port to try to re-enable those settings - but LAN port is not working obviously.
Luckily I have a backup of the wireguard server config file to help with recovery. everything else is easy to recover manually.
Edited to add: LED turns on blue, then off, then solid blue. Only 1 flash on startup.
I was able to uboot my device and I am up and running on 4.7.0. I am still working through recovery. Just wanted to close the loop. Note, though, the uboot update process did not like Firefox for me, but switching to Edge it worked fine.
from all I understand you need some reasonable value in /etc/fw_env.config or /etc/config/ubootenv - otherwise 30_uboot-envtools also is missing its starting point.
But it helped me guess what the proper content might be.
From all I understand, the problem is not in the update but in sysupgrade (more specific in the checks it does to ensure the system is safe to upgrade). This means there is a change to your current installation required, but the tool to do this change fails. Kind of a vicious cycle.
I'm interested if GL·Inet comes to similar conclusions.