OpenWrt 21.02 status

[Adrian Schmutzler]

> -----Original Message-----
> From: Daniel Golle [mailto:daniel at makrotopia.org]
> Sent: Montag, 19. Juli 2021 10:13
> To: Adrian Schmutzler
> Cc: 'Luiz Angelo Daros de Luca'; 'Hauke Mehrtens'; 'Rich Brown'; 'OpenWrt
> Development List'; 'Jo-Philipp Wich'; 'Kevin 'ldir' Darbyshire-Bryant'; 'John
> Crispin'; 'Rafał Miłecki'
> Subject: Re: OpenWrt 21.02 status
> 
> On Sun, Jul 18, 2021 at 10:30:20PM +0200, Adrian Schmutzler wrote:
> > > 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.
> 
> I believe what he meant to say was to make another 19.07.x point release
> with an updated sysupgrade mechanism which would improve the situation
> when upgrading to 21.02.x and, for example, allow flashing with non-
> matching DEVICE_COMPAT_VERSION already when specifying the '-n' flag to
> not keep configuration, but not require the '-F' flag which is scary for regular
> users (for good reasons).

I see the point of this approach, and I also considered it already when I started this thing. It should work like that if done properly.

However, I really do not like to backport fundamental features/feature changes like that.

It probably wouldn't even be much work as the code changes itself are few; but changing the sysupgrade mechanism in a .8 point release that might be the last one really does not feel right to me.

I will give it a few days of thought...

Best

Adrian

> 
> >
> > >
> > > 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.
> 
> Not saying that I'm fond of it, neither that I'm volunteering to do it, but we
> **could** also update 19.07.x....
> 
> >
> > >
> > > 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
> 
> 
> 
> > _______________________________________________
> > 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/20210719/6f754f55/attachment.sig>