Need some advice regarding restoring a backup on a different device

Hello,

Yesterday one of my GL-iNet routers (MT2500) died. I invested a lot of time into configuring this device (it uses the USB flash drive to extend the FS, runs a lot of extra packages etc), I have the latest backup (from luci, i.e. the archived copy of etc directory).
I am going to get a new MT2500 ASAP but there are 2 problems:
a) I dont remember the exact version of the firmware that the dead MT2500 was running (Ideally I would restore the backup on the same version of the firmware);
b) I dont have a list of all packages running on the dead MT2500;

So I wonder if I can figure out answers to those questions just having the backup (i.e. the copy of etc folder).

Thanks!

The exact firmware version isn't needed, mostly the 4.x.y version is enough, so 4.6.1 should be compatible with 4.6.3 as well. Even 4.5 could work, but need to try.

I doubt that the backup file really contains a list of the installed packages because they are not handled as "backupable" information. Next time you should create some opkg backup as well: HOW-TO: Script: List My OPKGs (to a file for backup)

1 Like

Thanks!
I opened MT2500 and I think I probably found the problem. Do we have access to the schematic to get to know what is the replacement for the burned out element (circled in red)?

@bruce Something for you, I guess :wink:

1 Like

Sorry, we cannot provide the circuit diagram, but can let you know the model of this part.

Winding power inductor, Sunlord Electronics, /1uH/±20%/2.6A/WPN201610U1R0MT

If you can find a replacement and have hardware capabilities, you can also try to replace it. If not, please contact cs@gl-inet.com.

1 Like

Hello Bruce,

Sorry, we cannot provide the circuit diagram, but can let you know the model of this part.

Excellent, thank you very much. I am quite lucky, I will get (with priority shipping) the inductors (had to order 5 there is no point in ordering just one 0.5$ item) in a day from Digikey and we will see if the inductor replacement is going to help. Without the circuit diagram it will be more time consuming to fix the problem (but still possible provided that the info about the components without marking can be obtained (for example from you)) .
Yesterday I ordered 2 more MT2500 (they are on sale right now) from GL.iNet CA but I would really want to restore this particular device because restoring from backup does not work the way I expected - there are 2 (at least what I already figured out) problems (I already found a new MT2500 temporary replacement to play with):
a) OpenVPN server uses the port 443, after restoring from the backup the file gl.conf is being overwitten and the port 443 is used by the GUI again (I fixed that);
b) OpenVPN client certificates somehow cannot be restored (access rights/ownership related problem?) from the backup (but I can copy them manually) - I want the new router behave exactly as the old one and all certificates, auth/private keys must stay the same allowing OpenVPN clients to access the new device without any modifications of the clients' config files.

Plus there are strange messages in the log related to missing firewall rules and this is very odd (I managed to figure out the version of the firmware used by the dead device i.e. I am restoring the backup on the same version of firmware).

One more question please (I can figure out the answer by myself but just to save time): the new router uses the new host name (xxxx.glddns.com). If I install ddns-luci I can see in ddns service configuration and now it uses the old host name (yyyy.glddns.com) restored from backup while the GL GUI still shows the new host name (xxxx.glddns.com) in Applications->Dynamic DNS. Is there an easy way to force the new MT2500 to use the old host hame (inherited from the backup) just to avoid changes in the openvpn client's config files?

Thanks!

The hostname is hardcoded into the firmware and will change if you change the device. So you will need to use the new hostname or you need to change to another DDNS provider.

Hello,

Thanks for the confirmation.

This is just one among several other problems related to restore from backup and have a working copy of the dead router right away. Like I said I cannot change opvn files on the openvpn clients (those are installed in remote locations which cannot be easily accessed) .
It is clear now that I had to avoid using Gl-Inet hosthames for DDNS in openvpn configs (and in all other places) in the first place if I wanted to have a portable configuration - live and learn.

So, the replacement of the inductor did not fix the problem. When powered on, I see one short blink and 2 longer blinks and the led goes solid blue and stays like that.
Reset (the button, 10 sec) does not work and I suspect that booting is not completed. While booting the router gets 140 mA and it seems to be normal (compared with the good MT2500, today I received 2 MT2500, GL.iNet CA was extremely fast to deliver the routers (fedex)), the check of the board with a thermal camera does not show any abnormality.
So, unless you can suggest some troubleshooting steps I am not aware of, I will try a ttl adapter method and if it does not work then give up - that would be really sad!

Does the router try entering the uboot mode?

If not, use TTL to check the startup process.

If there is OS booted and no network from the router's WAN, the LED should be blinking blue, if it stays blue solid, it may did not start up.

Hello,
two logs are attached, with and without USB drive attached. The same USB drive attached to the new router mounts just fine, can be accessed without any issues.

mt2500.txt.zip (5.7 KB)
mt2500_with_with_USB.txt.zip (6.2 KB)

Sorry. Do you mean USB driver issue different in the 2 good MT2500, or that 1 bad MT2500 and 1 good MT2500?

both logs were received from the bad MT2500 and both logs end with the error messages
:
[ 0.978244] mmc0: error -110 whilst initialising MMC card
[ 1.085619] mmc0: error -110 whilst initialising MMC card
[ 1.207959] mmc0: error -110 whilst initialising MMC card
[ 1.375250] mmc0: error -110 whilst initialising MMC card
[ 3.975955] block2mtd: error: cannot open device /dev/mmcblk0p1
[ 3.982041] hctosys: unable to open rtc device (rtc0)
[ 3.987614] Waiting for root device PARTLABEL=rootfs...

I am not even sure if you checked the attached logs.
There is a similar thread regarding MMC0 errors and MT2500 unable to boot:

https://forum.gl-inet.com/t/repeat-kernel-panic-in-gl-mt2500a/39828

There probably other hardware issues.
Please contact support@gl-inet.com and send the device back for inspection.

Hello Bruce,
I am pretty much sure that there is a problem with eMMC chip, I can access from U-Boot only 3 out of 6 partitions. When trying to upload the firmware, despite the flashing LED the progress bar stays at 0% for days i.e. no data is being written to flash memory.
I will contact the support today and see how they can help.

I am including the log for people who may find the themselves in a similar situation - when U-Boot is booting, press 'gl' and you will be presented the U-boot shell - you can read eMMC/dump data via UART, start httpd etc using U-Boot commands. In my case I listed all available partitions and tried to access each of them:


MT7981> mmc list
mmc@11230000: 0 (eMMC)

MT7981> mmc part

Partition Map for MMC device 0 -- Partition Type: EFI

Part Start LBA End LBA Name
Attributes
Type GUID
Partition GUID
1 0x00001000 0x00001fff "log"
attrs: 0x0000000000000000
type: 0fc63daf-8483-4772-8e79-3d69d8477de4
(linux)
guid: f8a2819e-2e86-11ed-bfe7-1fb0721adcb3
2 0x00002000 0x000023ff "u-boot-env"
attrs: 0x0000000000000000
type: 0fc63daf-8483-4772-8e79-3d69d8477de4
(linux)
guid: 19a4763a-6b19-4a4b-a0c4-8cc34f4c2ab9
3 0x00002400 0x000033ff "rf"
attrs: 0x0000000000000000
type: 0fc63daf-8483-4772-8e79-3d69d8477de4
(linux)
guid: 8142c1b2-1697-41d9-b1bf-a88d76c7213f
4 0x00003400 0x000043ff "fip"
attrs: 0x0000000000000000
type: 0fc63daf-8483-4772-8e79-3d69d8477de4
(linux)
guid: 18de6587-4f17-4e08-a6c9-d9d3d424f4c5
5 0x00004400 0x000143ff "kernel"
attrs: 0x0000000000000000
type: 0fc63daf-8483-4772-8e79-3d69d8477de4
(linux)
guid: 971f7556-ef1a-44cd-8b28-0cf8100b9c7e
6 0x00014400 0x00e8ffff "rootfs"
attrs: 0x0000000000000000
type: 0fc63daf-8483-4772-8e79-3d69d8477de4
(linux)
guid: 309a3e76-270b-41b2-b5d5-ed8154e7542b

MT7981> mmc dev
switch to partitions #0, OK
mmc0(part 0) is current device

MT7981> mmc dev 0 1
switch to partitions #1, OK
mmc0(part 1) is current device

MT7981> mmc dev 0 3
switch to partitions #3, OK
mmc0(part 3) is current device

MT7981> mmc dev 0 6
switch to partitions #6, ERROR

MT7981> mmc dev 0 5
switch to partitions #5, ERROR

MT7981> mmc dev 0 4
switch to partitions #4, ERROR