Re: OpenWrt 21.02 status
> > 2) I was pretty fuzzy about what people should do if their target did > > migrate to DSA. Do we have a guide to help those people through the > > transition? > > We do not support a migration and people have to start with a new fresh > installation. Doing a backup and restoring some settings manually works. 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. >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". I tried to start a discussion about it in an email "Usability issues for DSA upgrade" (jun/28) but I got no answer. 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'. 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@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: OpenWrt 21.02 status
> 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@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Usability issues for DSA upgrade
Hello, While upgrading from 19.07 to 21.02, there is an scary error message when target migrates to DSA (both Luci or CLI): root@OpenWrt:/tmp# sysupgrade -n openwrt-21.02.0-rc3-mvebu-cortexa9-linksys_wrt1900acs-squashfs-sysupgrade.bin Device linksys,shelby not supported by this image Supported devices: linksys,wrt1900acs armada-385-linksys-shelby linksys,shelby - Image version mismatch: image 1.1, device 1.0. Please wipe config during upgrade (force required) or reinstall. Reason: Config cannot be migrated from swconfig to DSA Image check failed. OpenWrt devs are probably confident that they can force an upgrade for that image. "force" means "I know what I'm doing, ignore the checks". However, for many users, sometimes non-technical ones, they do not really know what they are doing. There might be a wave of support requests about that message and another wave of bricked devices. Even knowing some OpenWrt internals, I'm not sure what "...or reinstall" means. Shouldn't '-n' be enough? Isn't sysupgrade already a reinstall? Or should it be the factory image? If it is really suggesting factory images, should I return to the original firmware before or use some emergency firmware recovery? Can we provide a 19.07 update to, at least, allow the upgrade without errors or "force" if confs are not kept? "Force" comes with great responsibility and it will overwrite other checks as board compatibility. The error message could be, instead of: "Please wipe config during upgrade (force required) or reinstall. Reason: Config cannot be migrated from swconfig to DSA" Something like this: "Configuration cannot be migrated from swconfig to DSA. To properly validate this firmware, please update OpenWrt at least to version 19.07.8 or pkgfoobar to version 1.2.3 and retry. Alternatively, if you are sure that this image is compatible, you can proceed not retaining the current configuration and forcing the process." I omitted the "...or reinstall'' as I'm still not sure what it means. I also used "not retaining the current configuration" as Luci (nor sysupgrade) does not mention wipe but "Keep settings and retain the current configuration" (which, by the way, seems to be two redundant sentences). Regards, --- Luiz Angelo Daros de Luca luizl...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
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). > > > > > 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@lists.openwrt.org > > https://lists.openwrt.org/mailman/listinfo/openwrt-devel > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: OpenWrt 21.02 status
> -Original Message- > From: Daniel Golle [mailto:dan...@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 a
