Initial flashing over "OEM-OpenWrt"

Adrian Schmutzler mail at adrianschmutzler.de
Sat Feb 6 14:18:19 EST 2021


Hi,

> -----Original Message-----
> From: Andreas Ziegler [mailto:dev at andreas-ziegler.de]
> Sent: Samstag, 6. Februar 2021 19:23
> To: Adrian Schmutzler <mail at adrianschmutzler.de>; openwrt-
> devel at lists.openwrt.org
> Subject: Re: Initial flashing over "OEM-OpenWrt"
> 
> Hi,
> 
> wouldn't this solution stop to work as soon as some OEM-OpenWrt is
> rebased on OpenWrt and knows about compat_version?
> 
> If i'm wrong, please enlighten me.

What I was thinking of were devices where firmware is built once based on a particular version and then updates don't touch that anymore.

Indeed, if a vendor cares about keeping stuff in sync with us, this won't work. However, note these aspects:
- The vendor would probably not want to adopt a version change from upstream OpenWrt during the product lifecycle, as this would annoy the user with no reason
- Many vendors would remove our compat_version deliberately as they probably have their own mechanisms for versioning in place

But even if none of the two applies, it still would not be worse than before, it would just not help anymore.

Thanks for widening the discussion with this aspect.

Best

Adrian


> 
> Regards
> 
> Andreas
> 
> 
> 
> Adrian Schmutzler wrote on 06.02.21 17:42:
> > Hi,
> >
> > when reviewing device-support PRs, I frequently encounter the case that
> initial flashing means sysupgrading from an OEM-modified OpenWrt.
> >
> > This obviously means that the config of this OEM-OpenWrt should be
> wiped to prevent config-clashes, but since we only provide sysupgrade in this
> case we can only tell the user to do so.
> >
> > In this context, I wonder whether we should exploit the compat_version
> for that purpose, i.e. make the initial "proper" OpenWrt image version 1.1.
> > Since the OEM-OpenWrt won't know about compat_version, this
> technically will have the same effect as removing SUPPORTED_DEVICES, i.e.
> the user will need to use -F (and we still can't check whether he uses the
> necessary -F -n).
> > However, the compat_version approach will give us the chance to show an
> additional message, and thus at least will allow to instruct the user during the
> upgrade itself, and not just in the Wiki or in the commit message (which he
> might or might not read).
> >
> > The purpose of this e-mail is thus to ask:
> > 1. Do we need this, or do we just expect the user to care, i.e. if he breaks
> the device by keeping config it's his fault?
> > 2. Is the compat_version solution acceptable?
> > 3. Does somebody have a better idea, or are there already other solutions
> to the problem I don't know?
> >
> > Recent example is e.g. this one:
> > https://github.com/openwrt/openwrt/pull/3816
> >
> > Thanks
> >
> > 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/20210206/ed02c847/attachment.sig>


More information about the openwrt-devel mailing list