> -----Original Message-----
> From: openwrt-devel [mailto:[email protected]]
> On Behalf Of Bjørn Mork
> Sent: Donnerstag, 16. Juli 2020 10:10
> To: Paul Spooren <[email protected]>
> Cc: Adrian Schmutzler <[email protected]>; openwrt-
> [email protected]
> Subject: Re: [PATCH v2 3/6] base-files: fwtool: implement compatibility check
> for images
> 
> Paul Spooren <[email protected]> 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 

Attachment: openpgp-digital-signature.asc
Description: PGP signature

_______________________________________________
openwrt-devel mailing list
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to