GL-MT2500 upgrade from 4.6.8 to 4.7.0 fails

Router
1

This seems to be identical to GL-MT3000 upgrade from 4.6.8 to 4.7.0 fails

30_uboot-envtools does not exist on my GL-MT2500.

The question is how is this possible to happen.

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.

2

Hi, the R&D is checking this issue. Including the berx's thread.

6 
/sys/module/boot_param/parameters/env_part

is empty.

ls -la /dev/ubi*
crw-------    1 root     root       10,  62 Jan  1  1970 /dev/ubi_ctrl

ls -la /etc/config/ubootenv
-rw-r--r--    1 root     root             0 Oct 17 13:17 /etc/config/ubootenv

cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00200000 00010000 "log"

difference to @berx

root@GL-MT2500:/dev# ls -la /dev/mmcblk*
brw-------    1 root     root      179,   0 Jan  1  1970 /dev/mmcblk0
brw-------    1 root     root      179,   8 Jan  1  1970 /dev/mmcblk0boot0
brw-------    1 root     root      179,  16 Jan  1  1970 /dev/mmcblk0boot1
brw-------    1 root     root      179,   1 Jan  1  1970 /dev/mmcblk0p1
brw-------    1 root     root      179,   2 Jan  1  1970 /dev/mmcblk0p2
brw-------    1 root     root      179,   3 Jan  1  1970 /dev/mmcblk0p3
brw-------    1 root     root      179,   4 Jan  1  1970 /dev/mmcblk0p4
brw-------    1 root     root      179,   5 Jan  1  1970 /dev/mmcblk0p5
brw-------    1 root     root      179,   6 Jan  1  1970 /dev/mmcblk0p6
brw-------    1 root     root      179,   7 Jan  1  1970 /dev/mmcblk0p7
crw-------    1 root     root      249,   0 Jan  1  1970 /dev/mmcblk0rpmb

Anyway, now lost

dmesg | grep "Kernel command line"
[    0.000000] Kernel command line: console=ttyS0,115200n1 loglevel=8                           earlycon=uart8250,mmio32,0x11002000                         root=PARTLABEL=rootfs rootwait rootfstype=squashfs,f2fs                          block2mtd.block2mtd=/dev/mmcblk0p1,65536,log
7

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.

8

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...

9

It's quite normal, because just a few people did test their Beta and Release Candidate, so when the firmware becomes "Stable" it wasn't tested enough.

10

I agree, GL need a testing beta firmware, a stable firmware and a long term support firmware.

11

I could but I'm going to wait for GL response before I manually start changing key system files.

13

adding that folder and script and running it has done nothing.

14

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.

15

@bruce shall I try uboot recovery mode or could I end up like @packetmonkey ?

16

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.

17

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.

18

:thinking: the R&D are checking about this.

19

Thank you for the update, tried 4.6.10 as well, cannot upgrade to this either.
If R&D want access over Goodcloud drop me a message.

20

it's been a good while what is the status? i still cannot update my mt3000 unit 4.68 to 4.70

21

Same here, I'm about to replace my Brume 2 with a Brume W as at least that's not got this issue.

22

Hi @Thomasshawn ,
as you seem to struggle with your MT3000 - did you try follow my path which I documented here?

If you struggle at any point, please create a new thread and tag me - so we can discuss your experience without any interference to others threads.

23

That's quite a bit of work for what should be an pretty simple update.

I think I'll wait till they get it resolved.

24

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.

You always can use this method:
DO NOT use FIREFOX.