There are still reports of GL-MT2500 being bricked, e.g.:
The original post says (without a date for when the note was added):
Is the consensus that there currently is not a safe Uboot update for the MT2500? And is there an ongoing effort to sort those issues out?
OK, my MT2500 Brume 2 was not Bricked. It did take the UBOOT just fine apparently, but since I was not on firmware version 4.7 before applying the UBOOT file, it seemed to be. I had to use pre-boot again to also upload the 4.7.bin firmware file which updated successfully, and after that reboot, it was factory fresh. So, I restored the configuration from my backup, and everything is back to where it was before I started.
I'm going to answer at least for me. I have a Brume 2, running the latest firmware, 4.7.4.
I went ahead with the Boot upgrade process, using Chrome, on a Mac. Everything went smoothly, and I'm back up and running without a hiccup.
Is it possible to update MT2500 on 4.6.8 to 4.7 without updating the bootloader? Not clear yet...
Upgrading bootloader in first units looks like a lottery, and the risk of malfunctioning in still to be seen... But I would like to upgrade to latest firmwares.
@bruce : Is GL.iNet working on a bootloader that does not brick our MT2500s when upgrading? Should we expect a solution coming? It has been quite a lot of time since reports of high chances of bricking were published, but we do not have a clear solution yet... It is a bit disappointing...
Glinet have already stated that if the devices brick that you can get a replacement. Follow the steps carefully and use Microsoft edge browser / chrome with zero plugins enabled and you should be okay.
You would be best to upgrade the bootloader as that's where the problem lies.
The bootooader takes a few seconds to update. I actually updated the bootloader twice by mistake with zero issues.
I upgraded the bootloader before flashing 4.7 firmware. Im not sure if the firmware has any bearing on the bootloader but ideally you want to be running the latest bootloader and latest firmware anyway, if the device can't do that then would you want it??
Tldr. Just upgrade both via edge or chrome with zero plugins enabled (adblockers)
Thanks j2zero,
I updated one MT2500 and one MT2500A, following those instructions (chrome, no plugins), and it worked for both of them.
Quite tricky to enter into uboot mode (make sure to keep one, and only one cable plugged in LAN, power USB connected and plugging the power source, or otberwise it will not enter into uboot mode).
For the rest, I guess I was lucky...
Thanks.
@bruce
Just got X3000 from UK Amazon. Firmware was 4.7.1 (I think) and was prmopted to upgrade to 4.7.4 which I have done. Do I still need to do the Uboot upgrade? If so can I do it on top of now 4.7.4 firmware or do I need to do factory reset then Uboot then upgrade to 4.7.4?
If I need to Uboot upgrade is it still the February 2025 version? Please send me a link where I can download the correct version from.
Tom
Hi,
We would like to know the following to confirm whether need to upgrade uboot. Just provide one of two ways.
If need to upgrade uboot:
There is no need to downgrade the firmware, just follow the above tutorial to flash uboot.
After updating to the latest uboot, please flash the v4.7.4 firmware in uboot again.
Kindly note, you can backup your current configuration in Luci, since flashing firmware on uboot is equivalent to factory reset.
Can somebody please tell me what a bricked router actually looks like (I.E. What LED’s come on etc?)
I’ve got a bricked Spitz that won’t boot (only the power LED comes on) but I can access Uboot. Unfortunately, flashing the new Uboot or firmware file results in a failed message.
I’m just wondering if this might be an ethernet/tablet problem (I am using a UBC C > ethernet adapter), rather than a router failure.
Anyone have any ideas or views on this?
There is two different bricks.
a soft brick:
this means somewhere the startup is interupted after the initial u-boot started, but is easier recoverable by doing a new flash via u-boot see debricking guide.
Or a hard brick:
This means the u-boot partition is also wiped, or partly, which mean the device is zerod, on my brume it had no lights anymore.
It is extremely unlikely a hard brick occurs, this only happens if you tried to upgrade u-boot, or you tried to install a image which overwrites the u-boot partition, usually on normal OpenWrt upgrade images U-boot is never touched.
If it happens you should contact support for it to RMA, or... what I do not advise is trying a UART connection or at worst using a chip programmer with clips, you need someone with a dump cap file, and the chances are very low, because most people don't want to share 1:1 mac adresses hardcoded in the router.
Yes, I appear to have a soft brick. I was wondering what the normal state of bricking is when the hardware fails as per the Critical Problem referred to in this thread (what part of the router hardware fails?).
well to nuance the situation for Brume2:
there was a bug which made the tearing of EMMC faster which could turn into a hard brick, because they made a misconfiguration in the bios (u-boot) which cannot be fixed in just a OpenWrt upgrade.
EMMC is the flash chip which acts as the main harddrive for the router, where also U-boot is on on a different partition.
this same bug was also found on the other models like yours.
So there are two megitations in place:
When the hardbrick happens nothing will work, basicly the partitions are died out and the cpu on the router does basicly nothing, the same effects would have happen on the critical bug, maybe a little different that the router becomes fully read only, but basicly it comes down to the same brick, I don't think it can recover when rebooting.