> -----Original Message----- > From: Daniel Golle [mailto:[email protected]] > 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 > > > [email protected] > > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > > > > > _______________________________________________ > > openwrt-devel mailing list > > [email protected] > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
