[PATCH v2 3/6] base-files: fwtool: implement compatibility check for images

[mail at adrianschmutzler.de]

> -----Original Message-----
> From: openwrt-devel [mailto:openwrt-devel-bounces at lists.openwrt.org]
> On Behalf Of Bjørn Mork
> Sent: Donnerstag, 16. Juli 2020 10:10
> To: Paul Spooren <mail at aparcar.org>
> Cc: Adrian Schmutzler <freifunk at adrianschmutzler.de>; openwrt-
> devel at lists.openwrt.org
> Subject: Re: [PATCH v2 3/6] base-files: fwtool: implement compatibility check
> for images
> 
> Paul Spooren <mail at aparcar.org> writes:
> 
> >> Major version increment:
> >> This is meant for potential (rare) cases where sysupgrade is not
> >> possible at all, because it would break the device.
> >> In this case, a warning will be printed, and -n won't help.
> >
> > What are those rare cases? I just can't think of anything where not
> > even a clean sysupgrade would be possible. Would it mean to go back to
> > stock firmware and then upgrade a 2.x version? If there isn't a
> > scenario maybe a single integer is easier to handle than a pseudo
> > float.
> 
> Changing partition layout maybe?
> 
> I don't think it's necessary to specify the exact upgrade method for every
> possible device/scenario.  The important part is to prevent semi-bricking and
> issue a warning, which should make the user go look for further upgrade
> instructions.

Indeed, this is not really designed with a precise case in mind already.

The honor for the initial idea of having X.Y versions actually goes to Paweł Dembicki:
http://lists.infradead.org/pipermail/openwrt-devel/2020-June/029508.html
He even provided links for the major revision case there.

I picked it up thankfully, as this makes the concept more powerful and general without having a real downside.

An easy way of reflashing without sysupgrade for many devices could be e.g. TFTP, where you are able to just flash the factory.bin again without caring about really going back to vendor firmware.
Of course, what's actually recommended here depends on the situation and will be very specific to the devices affected, and one could even provide instructions via COMPAT_MESSAGE then (e.g. flash via TFTP).

After all, it may also be possible that we will never need this, but I still think it makes sense to put it in place when we are touching this now anyway.

Best

Adrian 
-------------- 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/20200716/75a8c54b/attachment.sig>