GL-MT2500 upgrade from 4.6.8 to 4.7.0 fails

Technical Support for Routers
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.

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

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

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

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

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

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

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

1 Like
20

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

1 Like
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: