Restoring (old) config backups and

[mail at adrianschmutzler.de]

Hi,

> -----Original Message-----
> From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org]
> On Behalf Of Paul Oranje
> Sent: Samstag, 1. August 2020 16:06
> To: mail at adrianschmutzler.de
> Cc: Alberto Bursi <bobafetthotmail at gmail.com>; openwrt-
> devel at lists.openwrt.org
> Subject: Re: Restoring (old) config backups and
> 
> 
> 
> > Op 21 jul. 2020, om 11:06 heeft mail at adrianschmutzler.de het volgende
> geschreven:
> >
> >> -----Original Message-----
> >> From: openwrt-devel [mailto:openwrt-devel-
> bounces at lists.openwrt.org]
> >> On Behalf Of Alberto Bursi
> >> Sent: Dienstag, 21. Juli 2020 09:48
> >> To: openwrt-devel at lists.openwrt.org; mail at adrianschmutzler.de
> >> Subject: Re: Restoring (old) config backups and
> >>
> >>
> >> On 20/07/20 19:32, Henrique de Moraes Holschuh wrote:
> >>>
> >>>
> >>> Any thoughts on this?  I am certainly to have overlooked a lot of
> >>> stuff, especially if it is present only on master.  Also, handling
> >>> of an uci-defaults "reset" (so that they'd run again) in
> >>> non-initramfs/overlayfs based system is likely to pose some
> >>> challenges depending on how it is implemented...
> >>>
> >>
> >> Adrian Shmultzer has been recently adding some infrastructure in the
> >> sysupgrade to stop it if there are incompatible features that would
> >> break core functionality, so that the user won't just sysupgrade with
> >> the same config and land in an inaccessible device. Maybe his work
> >> can/should be extended to alter the creating/restoring config backups
> >> logic too, as it's really doing more or less the same thing already.
> >
> > Actually, my solution implements the config "on device" as a uci parameter,
> so the "on device" version is actually not the version of the firmware
> installed, but of the config installed. Therefore, one may indeed go that road
> to prevent flashing an incompatible backup. However, I don't think you can
> use it for much else.
> >
> > Despite, I still have received no positive feedback about that change at all,
> so I'm not sure whether it will go in at all.
> Good reason to chime in. That proposal for compatibility checks seemed very
> well thought over and as such I would welcome its implementation.

I've already merged this a few days ago and added some documentation here:
https://openwrt.org/docs/guide-user/installation/generic.sysupgrade#upgrade_compatibility

Note that with the different manuals on the sysupgrade process, I haven't really found a natural place for that, so if somebody has a better idea, I'm open to suggestions.

However, this only remotely touches your initial subject, of course.

Best

Adrian

> Bye,
> Paul
> 
> >
> > Best
> >
> > Adrian
> >
> >>
> >> -Alberto
> >>
> >>
> >> _______________________________________________
> >> openwrt-devel mailing list
> >> openwrt-devel at lists.openwrt.org
> >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> > _______________________________________________
> > openwrt-devel mailing list
> > openwrt-devel at lists.openwrt.org
> > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.openwrt.org/pipermail/openwrt-devel/attachments/20200803/0cad2cdd/attachment.sig>