<div dir="ltr">Todays sysupgrade fixed my problems now :)<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 28, 2018 at 5:25 AM, Luna Jernberg <span dir="ltr"><<a href="mailto:droidbittin@gmail.com" target="_blank">droidbittin@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Having problems installing luci at all on latest NIGHTLY on a Linksys WRT 1200 <h1><a href="https://downloads.openwrt.org/snapshots/targets/mvebu/" target="_blank">mvebu</a> / <a href="https://downloads.openwrt.org/snapshots/targets/mvebu/cortexa9/" target="_blank">cortexa9</a> / </h1>The peopel on irc told me to send an email: <br></div><div><br></div><div>05:18 < luna> There is problems installing luci in the latest NIGHTLY releases<br>05:18 < luna> root@RainbowDashv2:~# opkg install luci<br>05:18 < luna> Unknown package 'luci'.<br>05:18 < luna> Collected errors:<br>05:18 < luna>  * opkg_install_cmd: Cannot install package luci.<br>05:19 < DonkeyHotei> did you do "opkg update" ?<br>05:19 < Ziginox> luna: did you-<br>05:19 < Ziginox> yeah that<br>05:20 < luna> yes<br>05:20 < DonkeyHotei> is the luci line perhaps commented out in /etc/opkg/distfeeds.conf?<br>05:21 < luna> nope<br>05:21 < DonkeyHotei> hmm<br>05:21 < DonkeyHotei> which target is this?<br>05:22 < luna>  mvebu / cortexa9 /<br>05:22 < luna> a Linksys WRT 1200<br> <br></div><div><div class="h5"><div><br></div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 24, 2018 at 1:23 PM, Paul Oranje <span dir="ltr"><<a href="mailto:por@oranjevos.nl" target="_blank">por@oranjevos.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hyjacking on what <a href="mailto:luizluca@gmail.com" target="_blank">luizluca@gmail.com</a> wrote on 18 aug. 2018 at 01:49,<br>
with subject [OpenWrt-Devel] [PATCH v3 0/4] base-files: add new backup options<br>
<br>
> Today, every file listed in /etc/sysupgrade.conf, /etc/config,<br>
> marked as changed conffile and others will be in backup. Some of<br>
> these files from previous OpenWrt version might break something.<br>
> /etc/profile is a good example of what should not be in backup if<br>
> unchanged. Also, any conffile that has a new required parameter<br>
> might break after restore.<br>
> <br>
> When the user changes a file, it is expected that he/she knows that<br>
> he/she is doing. The problem is when OpenWrt replaces a file with one<br>
> from a previous version that the user might not even know that it exists.<br>
> <br>
> The new '-u' option asks backup to (oportunisticly) skip any file that<br>
> is equals to /rom. If a system does not have /rom, it simply does<br>
> nothing. /rom does not need to actually be squashfs. If the user is using<br>
> ext4, he/she could simply copy files into /rom before the first change<br>
> is made. IMHO, it should even be the default behavior.<br>
> <br>
> A backup might also miss important files for the user. The user must<br>
> insert every single file needed in /etc/sysupgrade.conf in order to get<br>
> it into a backup. However, it is easy to simply miss one. '-c' option<br>
> does try to save everything, but limited to /etc, probably to skip code<br>
> files. Saving /overlay also works but only when restoring to an<br>
> identical OpenWrt version. The new '-o' is equivalent to saving<br>
> /overlay, but it skips any files that came from a package, except those<br>
> marked as a changed config file, sysupgrade.conf or /lib/upgrade/keep.d.<br>
> It does work with '-u', skipping files touched but reverted to the<br>
> original state.<br>
> <br>
> After the user seeded a new OpenWrt with a backup generated with '-o'<br>
> and '-u', the next natural step is to reinstall all previously installed<br>
> packages. '-k' adds a file into the backup containing the list of<br>
> installed packages and also its origin (rom or overlay). It is a one-line<br>
> script to reinstall them all.<br>
> <br>
> My normal upgrade procedure is:<br>
> <br>
> # sysupgrade -o -k -u openwrt-new-version.img<br>
> # <auto reboot><br>
> # opkg update<br>
> # grep "\toverlay" /etc/backup/installed_packages<wbr>.txt | cut -f1 | xargs -r opkg install<br>
> # rm /etc/backup/installed_packages<wbr>.txt<br>
> # reboot<br>
> <br>
> Those options could be used by Luci, exposed to user during an upgrade.<br>
> The (re)installation step could even become automatic (on demand) or<br>
> offered to the user when Luci detects /etc/backup/installed_packages<wbr>.txt<br>
> presence.<br>
> <br>
<br>
Very nice, but having read the mail thread around Luiz' his patch, I want to ask for a discussion, but outside of that patch.<br>
<br>
AFAICT from the discussion it follows that sysupgrade, opkg and UCI should be kept (as much as possible) orthogonal. From the thread: opkg cannot always be assumed to be available, external config management may need all configuration files, not just those that changed and not just diffs, config files may need changes, etc.<br>
<br>
The backup functionality in sysupgrade serves a common case of keeping config files over upgrades where that's needed because the rootfs/overlay is re-created. Cases where sysupgrade does not destroy the (overlay) filesystem contents also exist and obviously config files aren't lost than.<br>
<br>
After/during a sysupgrade a normal step is the restoration of the previous configuration, i.e. of config files *and* extra previously installed packages - currently sysupgrade does not handle re-install of extra user installed packages. This functionality could also serve cases where a certain configuration is to be put on a new or other device. Where the filesystem its contents is not lost during sysupgrade, this would just amount to an opkg upgrade of all outdated packages after sysupgrade has upgraded the kernel and possibly the rootfs.<br>
<br>
In the more common sysupgrade case though (overlay contents are lost), some means is needed to preserve configuration data in order to be able to restore the configuration. Where this data is preserved during sysupgrade depends completely on the device specific sysupgrade mechanism; *what* data is saved and *how* it is re-applied is preferably opaque to, and independent of, sysupgrade.<br>
<br>
Also, during upgrades new versions of packages may require updates to the config files. Preserving customisations of the config files cannot just be handled with back-up/restore and may require applying a diff or user intervention. How to deal with that can really only be determined by the package maintainer and so must be handled by the package itself. Anyhow, this clearly is in the domain of opkg and applies to upgrades outside of sysupgrade as well.<br>
<br>
In short, factoring out the configuration management functionality (CM) seems a good idea. The sysupgrade subsystem handles with upgrading kernel and rootfs and may invoke CM functions to preserve the user configuration. CM can could also take care of user installed packages. CM calls opkg to install and/or upgrade additional packages. Truly general back-up (e.g. as a defense against data loss) is outside the scope of sysupgrade.<br>
<br>
Quite a few efforts have already been made toward some kind of CM, notably by offering this as an external service. The task to factor out generic CM  functionality that can be called upon in different contexts is probably quite complicated and comments on that idea are welcome.<br>
<br>
What would be a practical API, if any, for CM ?<br>
What (minimum) configuration data would be needed by CM, i.e. what's needed besides config files to store user install selections ?<br>
What's needed to enhance opkg so that it can handle in a general way updates to config file while preserving user settings ?<br>
Compatibility issues ?<br>
<br>
Paul<br>
______________________________<wbr>_________________<br>
openwrt-devel mailing list<br>
<a href="mailto:openwrt-devel@lists.openwrt.org" target="_blank">openwrt-devel@lists.openwrt.or<wbr>g</a><br>
<a href="https://lists.openwrt.org/mailman/listinfo/openwrt-devel" rel="noreferrer" target="_blank">https://lists.openwrt.org/mail<wbr>man/listinfo/openwrt-devel</a><br>
</blockquote></div><br></div></div></div></div>
</blockquote></div><br></div>