Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sysupgrade preserving lime-defaults config problems #706

Closed
spiccinini opened this issue May 5, 2020 · 4 comments
Closed

Sysupgrade preserving lime-defaults config problems #706

spiccinini opened this issue May 5, 2020 · 4 comments

Comments

@spiccinini
Copy link
Contributor

spiccinini commented May 5, 2020

Currently using sysupgrade (or safe-upgrade) to upgrade a firmware while preserving configurations overwrites unexpectedly the firmware /etc/config/lime-defaults with the current lime-defaults so it is not possible to provide a new default without using -n option of sysupgrade.

This happens because /lib/upgrade/keep.d/base-files provided by openwrt contains the following line /etc/config/. So all all /etc/config files are backup and preserved (including lime-defaults).

This leads to the following error after upgrading:

WARNING: Attempt to access undeclared default for: system.root_password_policy
stack traceback:
    /usr/lib/lua/lime/config.lua:78: in function 'get'
    /usr/lib/lua/lime/system.lua:26: in function 'setup_root_password'
    /usr/lib/lua/lime/system.lua:59: in function </usr/lib/lua/lime/system.lua:55>
    [C]: in function 'xpcall'
    /usr/lib/lua/lime/config.lua:206: in function 'main'
    /usr/bin/lime-config:55: in main chunk
    [C]: ?
/usr/lib/lua/lime/system.lua:47: attempt to concatenate local 'policy' (a nil value)
stack traceback:
    /usr/lib/lua/lime/config.lua:206: in function </usr/lib/lua/lime/config.lua:206>
    /usr/lib/lua/lime/system.lua:47: in function 'setup_root_password'
    /usr/lib/lua/lime/system.lua:59: in function </usr/lib/lua/lime/system.lua:55>
    [C]: in function 'xpcall'
    /usr/lib/lua/lime/config.lua:206: in function 'main'
    /usr/bin/lime-config:55: in main chunk
    [C]: ?

There are multiple ways to fix. Some ideas:

  • Moving /etc/config/lime-defaults to a /usr/share/lime/config directory (to more clearly imply that this file should not be edited).
  • Edit the keep.d/base-file removing the /etc/config line (explicitly declaring file per file which must be preserved)
  • Do not use the backup facility of sysupgrade and provide another way.
@spiccinini spiccinini added the bug label May 5, 2020
@ilario
Copy link
Member

ilario commented May 5, 2020

First proposed solution sounds good.
The new location should be pointed out in the comments in lime-node, lime-community, lime-example, and on the website.

@dangowrt
Copy link
Member

dangowrt commented Jun 2, 2020

Yes, first proposal is the way to go imho. You can easily tell UCI to use an alternative configuration directory (we are already doing that in places, ie. for /var/state/) and have lime-defaults loaded from an alternative location.
Also note that sysupgrade only preserves files in /etc/config if they have actually been modified.

@spiccinini
Copy link
Contributor Author

spiccinini commented Jun 3, 2020

Yes, first proposal is the way to go imho. You can easily tell UCI to use an alternative configuration directory (we are already doing that in places, ie. for /var/state/) and have lime-defaults loaded from an alternative location.

great (yes, in the unittests we are also faking the config directory creating an empty environment for each test)

Also note that sysupgrade only preserves files in /etc/config if they have actually been modified.

Ah, didn't know that. Anyway this is a problem because not only we are modifying them from lime-config but also some are created durin first boot. This leads to many problems while upgrading to different versions of openwrt.

With @germanferrero we worked in a proposal to aproach configs in libremesh that will allow easier maintenance and it is related to this issue #719

@ilario ilario added this to Mid priority - Worth to fix in LibreMesh 2020.2 release Jun 5, 2020
@spiccinini
Copy link
Contributor Author

Fixed in #738

LibreMesh 2020.2 release automation moved this from Mid priority - Worth to fix to Closed Sep 16, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Development

No branches or pull requests

3 participants