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

1 Like

Asked myself about the full backup and ready to reply - this is how I duplicate the devices (did it already 3 times with 3 different devices - total time to restore the device is about 15 minutes).

Why? Because I simply want to swap the dead device with a new one and dont waste any time to set it up and such - I also want to make sure that it will behave exactly as the old one.

Since I keep AdGuardHome, BanIP, nlbmon, syslog and rrd (plugin used by collectd) on a MicroSD in case of AXT1800 or an external USB flash drive in case of other devices the procedure is a bit complicated but it guaranties that I always have my data stored outside of the device which can fail any time.

Original device that will die in future:

1: attach external USB flash, it will be automatically mounted in /tmp/mountd/diskX_part1 - will it be disk1 or disk2 is big mystery to me, see below;

2: set up AdGuardHome, BanIP, nlbmon, syslog and rrd to be stored on the external USB disk (if you care otherwise dont);

3: copy to the external USB disk the firmware used by your current device;

4: run the script /bin/list_my_installed_packages.sh - you have to find it on the forum and put it in there in advance;

5: copy /root/backup/ dir (created by list_my_installed_packages.sh) to the external USB disk;

6: copy /etc directory to the external USB disk;

7: DO STEPS 4-6 every time when the settings have been changed/packages were installed by simply updating your existing directories on the external USB disk;

if everything works just forget about it.

The device stopped working - get a new device first.

  1. move the external USB disk to the new device - CHANCES ARE THAT IT WILL BE MOUNTED NOW as a different disk - no problem, see below;

  2. if you care about original domain name (Gl calls it hostname) (XXXXX.glddns.com) of your new device (every router updates its domain name by using a unique username and password) then enable DDNS in the GL GUI first and after that copy /etc/config/ddns to the external drive (you may need it later). I dont care about new DDNS because I want the new device use the same old DDNS - there is a reason for that;

  3. if you care about mac addresses of the new device (to use them later) - copy the original /etc dir to the external USB disk - you will find them later - I dont because I want the new device to be a copy of the old device;

3)reinstall on the new device all packages using the list of packages generated on the old device and stored on your external USB disk;

4)copy /etc dir from your external USB disk to your device basically overwriting the content of the original /etc dir.

  1. modify /usr/bin/@AdGuardHome symlink to point to external USB disk if you keep AdGuardHome on the external USB disk;

Pay attention to one moment: was the external USB disk mounted exactly as it was mounted on the old device (i.e. "disk1_part1 vs disk1_part1" and not "disk2_part1 vs disk1_part1"?

If not then search for "disk1_part1" in /etc and replace with with the correct string (for example disk1_part1), otherwise do nothing

REBOOT - your new device behaves yourself exactly as the old, dead one.
KEEP the data on the external USB disk updated.

--
Why I did not modify the Openwrt backup and did not use the backup instead? Because last time I knew for sure that I was making regular backups. But when the device died I could not find any recent backups - dont ask how it could happened.

QUESTION for GL.iNet Staff: if there any logic in how disk numbers are assigned to attached USB disks? If I attach FAT32 formatted disk it will become disk2_part1. if I format it as ext4 it will become disk1_part1. It would be nice to make sure that disk labels will be identical on both devices - then no edit of symliks would be required.

Thanks.