Does the restore function from a previously saved settings file work on this router? I tried to restore it several times, but the router goes into a bootloop and I need to restore it only through the bootloader.
I have never seen such a problem on any router.
Is that so, or am I doing something wrong?
v. 24.10.0
P.S.
I also checked on version 23.05.5, the situation is similar. I assembled both firmwares using the site https://openwrt.github.io/firmware-selector-openwrt-org
Are you restoring the setting from the same router and version?
Yes. Even the same firmware version. Replaced one package with another and flashed with a reset of the settings, after which I tried to restore the settings and the router died. Also does not respond to the RESET button. Only full recovery. I do not know how correctly this function works. It is restored only with the help of the bootloader with the sysupgrade file. It is not restored with the factory file. The bootloader writes an error when loading it.
The difference in file sizes is 2 times. 59 and 31 MB respectively.
I am wondering if there is something in the settings that you are restoring that is mixed up and causing the issue. I think I have had that a few times.
It might be best to start fresh and then re-configure it how you want without restoring from the backup.
Could be something here - but not really enough info...
I wonder if the backup file itself is either:
a) corrupt
b) missing needed files
c) a file that isn't needed
One thing I've noticed is that the MT6000 backup archive includes a file call fw_env.config, where the contents show
/dev/mmcblk0p1 0x0 0x80000
Not sure if this is a red herring or not...
Compared to my other OpenWRT targets running on snapshot, this is unique to MT6000, but note that MT6000 is the only one with MMC - the others are either NOR with JFFS or NAND with UBIFS...
& @ rygle
This can only happen if the router software creates an incorrect file.
I deleted 2 packages and installed 1 new one. On other routers, if you restore the settings, this never happens. I tried to restore the settings from the AX6000 on the AX3000t and vice versa. There are NO failures. Also, these settings contain configuration files from already deleted and unused packages. This also does not lead to a failure. I can also reset the configuration using the RESET button on these routers, unlike GL.iNet GL-MT6000.
Can you install an updated version of OpenWrt on this router and restore the settings from a backup copy and your router will continue to work and not fall into a coma? Can you hold down the reset button and the settings on your router will be reset to default? If the answer to these 2 questions is YES, then it makes sense for me to configure everything again, but I consider this not normal operation.
It should, although I don't have that device so I cannot test.
But let's go a bit deeper -- how are you creating the backup, and how are you trying to restore it?
What are the files you're dealing with here? These both seem very large (in general, but especially for the backup)... just to verify, these aren't the files you're trying to restore, are they?
These are the "Sysupgrade" and "Factory" firmware files created by the assembly site, as I wrote above. I have never seen such a difference in size either. +- a few hundred kilobytes...
This is not my first router on OpenWrt, but let's figure this out too.
I create the file using standard tools using the Luci interface, and I restore it using it.
Nothing supernatural.
If this function does not work, then it needs to be repaired.
I would like to get an answer from the owners of these routers, since theoretically everything should work, but in practice we have a brick and a lot of wasted time.
To be clear, these are not 'backups' and are not normally considered something to 'restore'. I'm not trying to be pedantic here, but just so that the terminology is clear, typically we talk about the configuration files as the things we backup and then restore later. (there can be other things included in the backups, but in most cases it's just the config files). The backup files are usually well under a megabyte (I'm looking at one now -- 34KB).
So... now that we know you are using the sysupgrade and factory images (firmware images), let's figure out why they're so big. And let's also talk about how you're using them.
The 24.10.0 sysupgrade image for your device is about 10.5MB when downloaded from the firmware selector site without any customization. It does seem like you're customizing things, so it may be totally fine for the size to be larger, but just to make sure we're not talking about something odd -- what are you adding to the images? And are you removing anything?
Next, you mention the two files (sysupgrade and factory) -- how are you using each of these files?
When restoring the router using its standard Uboot file, I tried to use the "Factory" file created by the OpenWrt assembly site and failed. Immediately after loading the file into the router's memory, I received an error message written in the Uboot window. I don't use it anywhere else. With all these same procedures, only with the "Sysupgrade" file, the router is restored normally and works, if you do not restore its settings.
The "Sysupgrade" file is so big because I add the packages I need to it. WG, openVPN, AdguardHome, etc. Then I compile it using the assembly site.
As you know, the site gives out several files after that and these are the sizes I got.
bla bla bla Sysupgrade - 31 MB
and
bla bla bla Factory - 59 MB, I have not seen such a difference in the size of these files in any other router. This is what confuses me and I suspect that this is some kind of incorrect assembly and perhaps because of this there is a failure when restoring the settings.
In terms of hardware, the similar Redmi AX6000 does not suffer from this disease and restores the settings and the files are generated with a not so huge difference in size.
Everything you’ve shown looks good.
The file size seems generally right given that you’re adding stuff. It should work as expected.
Does the default/standard image work properly for you?
Let’s take a look at the ‘recipe’ you’re using for the custom image.
The packages I use are tested on Redmi AX6000, Xiaomi AX3000t, Xiaomi AX3200, etc.
+- the same packages, sometimes I change 1-4 packages for experiments, but this has never caused failures.
I think we need to look deeper into what is causing the failures. Specifically, you didn't answer if the standard/default image works properly. I'm guessing it does.
Making that assumption, we can then guess that something introduced in your custom images is at fault for the problem. But we don't know what specifically.
So, it would be good to test adding just one package (it might be several when you count dependencies, but for example, just add wireguard alone and then try using that custom image). If that works, you could scale up to more of the packages that you're adding. Maybe add half your list and see if it still works. Then add half of the remaining half, and so on. The idea here is that you can narrow down what is causing the problem -- if it is a package issue -- almost like bisecting changes in source code.
If you get the whole list of packages installed and it still works, it might be your UCI changes... maybe there's a typo or a syntax issue or other invalid line in there. Those might be a bit harder to do in a bisect type method, but it should be possible to identify if something is wrong there.
Yes, but you can approach the troubleshooting yourself (and you might need to since I cannot test on comparable hardware).
I also own a MT6000 with custom made snapshots, but this doesn't seem to happen for me.
Although I read OP may use a modified version of OpenWrt is it self compiled?, it is possible something happens there.
I'm very interested to see if there are also contents in here which could give a clue to possible issues:
please post if any files are in:
/rom/etc/config (only if you know there is a files directory in the root folder of your build environment)
/rom/etc/uci-defaults
^ these two are more happening on upgrade/reset level, though it never hurt to check these.
from my own experience especially the uci-defaults one can have a bad script if it doesn't check it was already set it could fire uci commands at every upgrade and it can go more wrong if the code had no LF endings and spaces instead of tabs I learned this the hard way when it was generating malformed configs😋
And /etc/sysupgrade.conf and if present /rom/etc/sysupgrade.conf
^ these files in this config include untracked things into backups.
It would be possible, but I initially set everything up on the router, check that it works, does not give obvious errors and only after that I remove the list of packages from the working system with a script and use it when assembling from the site.
I also have one YUSI list for all routers, in it I only change the name of the router and the name of the Wi-Fi networks. But I also enter them in advance on the working router and check that it does not complain about the syntax.
So everything should be correct and work? I also make a backup of the settings from the working router.
In general, if this is my local problem and it works for you on exactly the same router without problems, I will look for a bug in mine.
Thank you for confirming the absence of such behavior of the router in yours.
And I did not see an answer to another problem of mine. The behavior when pressing the RESET button. Does it work for you? Resets the settings to default?
This works for me.
This one might be causing a problem unintentionally.
what I often notice in the package repository is, there are a couple of core packages which also append a build number behind their name each time OpenWrt gets build.
So if these packages are in the list you supply to the builder from the script, maybe that result into the package not being included in the final image?, the issue is, this name is always random everytime OpenWrt gets compiled.
Also if the script is used after flashing to install packages back, be aware that it is just like updating and upgrading packages which is not advised and could cause a brick, only if you know exactly the packages then it is fine, it are those core components you don't want to touch.
I believe libubox was a core dependency doing this, you could try a manual list leaving out most of these packages, and only keep user installed packages.
But I've been doing this for years with many routers and have never had any problems. So far I've only come across this one))).
Thanks again for confirming that it works.
I'll look for a solution on my side, since this is a local problem.
THANKS!!!
If you found a solution please post back 
, it would always be learnfull also for others comming accross similar issues.
Edit:
I realized, could it be you use a ext4 overlay perhaps ?
this could indeed cause some issues.
I completely forgot. Of the untested, newly added packages, there are packages related to working with USB. There are all sorts of mounts, file systems, etc. First of all need to try without them...
