0

I am building an openwrt firmware for an old mt7620 board for commercial purpose (captive portal)

I am encountering a strange behaviour when I try to save updated config files. I am trying to figure out the reason.

This is an example of what happens :

1 – FIRST TRIAL :

I compiled an old Chaos Calmer 15.01 openwrt version. From the console, I go to the /overlay/upper/etc/config:

  • Before reboot

    • I modify or delete the existing files in the [..]/etc/config/ folder
    • I create a new file for example "test" in [..]/etc/config/
    • I create a folder "new_folder" with a file inside

  • After reboot:

    • changes are not kept or deleted files are back in [..]/etc/config/ folder
    • the new file for example "test" is still there
    • the "new_folder" with its file inside are still there

  • Finally :

    • if I delete the new files "test" and "new_folder", after the reboot they are effectively deleted

So to sum-up : only pre-existing files in [..]/etc/config/ folder are reverted back at each reboot.

2 – SECOND TRIAL :

I compiled a firmware of the same version without UCI, when I modify the files in /etc/config/, changes made manually are kept after reboot, except 'wireless' which revert to its initial state.

It seems like some process involving UCI at startup use the original files and not the edited ones.

I took a look to the .sh scripts in /etc/init.d, /etc/rc.d, lib/config, lib/functions, lib/preinit... to see what is going on but its still not clear when and where config files are processed (even after looking at topics on the subject)

3 – THIRD TRIAL :

I managed to compile another firmware based on LEDE 17.01 to see if there are benefits. Unfortunately, I still have the same problem concerning the files in the /etc/config which always revert to their default value.

4 - FINALLY TO SUM-UP :

Is there a way to turn this behaviour off, or is it a kind of 'file protection' towards something that could be seen as 'currupted' by the system ?

Note :

I know that theses versions are very old and some people may recommend to upgrade it.

But, In regards to my constraints, I tried to update to openwrt versions >= 18.06. Each time I have kernel panics even by compiling with the custom changes I made that work with the previous versions (DTS file).

So, I am stuck with it for instance, I prefer having one problem at a time.

Sorry for the long post.

Thanks a lot, by advance, If someone have an idea or have already seen such a situation.

Best Regards.

Edit : Overlay at boot time

Overlay at boot time

Ced76
  • 1
  • 2
  • Instead of using editor to modify file. Can you try to use `uci` command to config the value and reboot to see the value remain in the config? If it works, there could be some overflayfs issue? Otherwise, can you check your partition mounting whether it is correct? – Justin Yu Oct 11 '22 at 02:24
  • Hello Justin, thank you for your reply. I tried with uci commands, with commit. I checked that it worked before rebooting. But whatever I do, if these config files where edited before compilation, they always revert to the same after each reboot. – Ced76 Oct 17 '22 at 08:49
  • Could you check with your mount with the overlayfs? It is because openwrt rely this to overwrite updated config for uci. I doubt your overlayfs is not working correctly so that updated config is not written to the system. Instead, it is wrote to tmp – Justin Yu Oct 18 '22 at 09:54
  • Hello Justin. I tried at boot time to see how the overlay is mounted. I typed 'df -h' and I have the results in the [link](https://i.stack.imgur.com/R8U5K.png). I noticed the overlay filesystem changed just after the' jffs2 notice' line. May be the problem is due to a bad jffs2 partition ? Best Regards. – Ced76 Oct 19 '22 at 12:54
  • I bet your `mtdblock6` is mounted in read-only. Please check whether you can write any files to the block. My guess is that it is mounted as read-only and then all updated UCI config only write to the tmp. After reboot, all "saved" config is lost. If it is the case, please check whether you config the driver `jffs2` correctly. – Justin Yu Oct 20 '22 at 03:46

0 Answers0