Initial flashing over "OEM-OpenWrt"
Paul Spooren
mail at aparcar.org
Tue Feb 9 01:16:41 EST 2021
Feb 8, 2021 5:06:28 AM Piotr Dymacz <pepe2k at gmail.com>:
> Hi Adrian,
>
> On 06.02.2021 17:42, Adrian Schmutzler wrote:
>> 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?
>
> Users are supposed to read flashing instructions provided by the author
of device's support and follow them. In case of a soft-brick, we have
failsafe and factory reset which is definitely enough to fix this
"problem". Let's give our users a little trust here.
Ack
>
>> 2. Is the compat_version solution acceptable?
>
> Definitely not, but do we really want to introduce more bloat and magic
just to prevent some extremely rare users mistakes? Please, don't.
>
>> 3. Does somebody have a better idea, or are there already other
solutions to the problem I don't know?
>
> Personally I don't consider it as a problem at all.
>
> I believe you should also look at this from the other side. There are
vendors which are up to date with our code base and updating with
preserving setting is doable and safe (I'm assuming stable releases
here).
>
> --
> Cheers,
> Piotr
>
>> Recent example is e.g. this one:
https://github.com/openwrt/openwrt/pull/3816
>> Thanks
>> Adrian
>>
>> _______________________________________________
>> 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
--
More information about the openwrt-devel
mailing list