OpenWrt 21.02 status

[Adrian Schmutzler]

> The last time I tried it was very confusing. When I first read about "new fresh
> installation", I thought: "install without keeping settings".
> However, OpenWrt returned an image check failure, even when I did not
> keep the settings (sysupgrade -n). It was the same type of error (image
> validation failed) that would happen if I selected the wrong firmware (but
> maybe with a different content). The only way to install it was forcing the
> operation, which might also allow an incompatible image to be installed
> (bricking the device). Please reconsider some form of upgrade path that
> validates the image and allows the user to upgrade without a force or going
> back to factory before reinstalling OpenWrt with DSA. Something like
> "update package foo to version n.m.z or upgrade to 19.07.9 before installing
> 21.02 for proper image validation". Most users will not be confident to apply
> a forced installation.	

That would be nice, but unfortunately it's not so easy. The problem is that the upgrade mechanism is baked into the _old_ image.
Any upgrade can only do what the old firmware supported. Thus, I was really glad that I was able to hack this message into the device detection mechanism at all. Otherwise, we would not have any message at all for old installations.

> 
> From wiki upgrading to 21.02 page:
> 
> "Don't worry - If you try to upgrade with the wrong target, sysupgrade will
> refuse to proceed with an error message like this:
> Image version mismatch. image 1.1 device 1.0 Please wipe config during
> upgrade (force required) or reinstall. Config cannot be migrated from
> swconfig to DSA Image check failed"
> 
> My experience and the message content indicates that it will show for all
> migrations from "swconfig" to "DSA" and not only for "wrong target".

Yes. For the old sysupgrade, we simply match two strings (the board name from the device against SUPPORTED_DEVICES from the image). Either it's successful, or it's not. If it's not, the message displays the name of the SUPPORTED_DEVICES. That's what we got. So I have to hack all of the message into the SUPPORTED_DEVICES string.

> 
> I tried to start a discussion about it in an email "Usability issues for DSA
> upgrade" (jun/28) but I got no answer.

We can discuss this for the future, i.e. for updates starting at 21.xx, and we can discuss the exact wording of the message.

> 
> It would also be great if we could detect a config from a pre-dsa system and
> restore everything but skipping or renaming DSA relevant files (nework,
> wifi?) DSA) with a suffix like '.pre-dsa'.

We had a very long delay due to DSA and nobody was even slightly interested in creating a migration script.
For partial migration, I suspect that implementing something here that is general will be much more complicated than just having the user select what he wants/needs.

Best

Adrian

> 
> DSA is missing a lot of docs. For example: is there a simple, secure way to
> detect a system is using DSA for a specific switch (or device)?
> Is it possible to exist a device with two switches and only one of them uses
> DSA?
> 
> Regards,
> 
> _______________________________________________
> 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/20210718/8da262b9/attachment.sig>