I am currently working towards this feature. I have a solution for GL.iNet devices but it feels fragile. I am looking for something i can target that is found in some/most/all? oem (qdsk ..) firmware metadata, not found in openwrt metadata, that i can target. If you think you know of something or want to help.. all opinions are welcome here in this thread but please refrain from muddling up the pr with non-related post. thxs
pr description
some new devices are now able to flash oem
images from luci, fwtools erroneously marks
firmware as incompatible and does not warn
of keeping configs during update for this condition.
this patch aims to add both oem detection
and trigger the existing warning msg, advising firmware is compatible
but the configuration is not
The current approach seems to work well, on my= devices anyhow. But i wonder if there is any type of standard used among venders (QSDK) in regards to board_name.
the current approach chops off the model from the board_name ..ie
yah kind of what i figured. This solution works and is benign .. but not a very practical solution for more than a handful of devices ... back to the drawing board
remittor's approach for several ASUS routers might be a better approach, in the sense of adding an (optional) package helping with installing the OEM firmware for specific devices. Be it by 'converting' an OEM firmware to sysupgrade format XOR a dedicated (non-sysupgrade) OEM installer script.
Ideally, the OEM has a working/ reliable bootloader based recovery mechanism, taking the OEM firmware image as-is.
yes, luci has no problem handling them (.img) now as well, just the ui is not ready for it ... functionality wise everything works a treat. this is just to correct the erroneous warnings faced when executing the upgrade/revert via luci or cli.
yes thats a much more suitable approach ,i was just trying to short cut i think ... 4 lines of code, who was i kidding
It seems he keeps a list, and compares against it. I will do the same in an external script and just call it from fwtool.sh. The list is short at the moment so it won't be much work. Than just update the list in the external script as new devices discover and or existing devices adopt the method where possible.
Stands a better chance of getting looked at than the current approach.
It is very unlikely that your fixes will be accepted by the maintainers.
There is no guarantee that the OEM manufacturer will use a different flash layout or different kernel/rootfs images (FIP/FIT/UbiFS) in their firmware implementation.
ya i realize its an up hill slope. but i don't think 2 extra evaluations in fwtool.sh is too invasive. I think as long is the additional evals are benign there no issue with it.
My plan ... after some sleep and a morning coffee, add the evals to fwtool.sh. It will check /tmp/sysinfo/oem_name. If found it will use the evaluations, if not , its business as usual. To use it with a device, there will need to be a uci-default script for the device to create the oem_name file with the proper oem name.
so in total 1 check for the oem_file, and if found, 2 additional evaluations are performed.All but 4 extra lines of code to fwtool.sh is all that is really required . i think i can sell this idea with a little more polishing ... i am persistent if nothing else
this would cause more far more head aches than the fwtool.sh considerations ... besides if they didn't change the model name, none of that would affect what I am proposing anyway. And beyond all that ... from my experience. vendors tend to do very little, or perhaps the very least they must , after the devices made it to market, unless there is a greater issue.
just so its clear ... nothing is done to modify the oem image. And we can already flash the oem from luci with no problem (on supported devices), it works a treat. I am just trying to correct the erroneous warnings presented by luci sysupgrade while upgrading.
If the vendor makes some drastic change to the oem .img it should not matter on this end, as long as the fit format ... part 0 bootscript part 1 ubi image..does not change.
To elaborate a little, the way it works for these devices, the ubi is extracted from the fit image, leaving just a plain old ubi for sysupgrade to deal with.
I think the new commit is a winner ... you barely even realize its there, I introduce 4 new evaluations, only one is evaluated if the /tmp/sysinfo/oem_name is not present with an entry, it does not impede on default functionality in anyway, and is up to the user whether or not to use it... but why wouldn't you if you have the option ...
oem (without /tmp/sysinfo/oem_name .. or valid entry within )
The creation of /tmp/sysupgrade/oem_name should be the authoring developers responsibility to include a uci-default script to produce the file and proper entry during firstboot. Should the oem for some reason change the oem name (model name) it could be patched/changed by user pre-upgrade .. until uci script is updated by the dev,
Does anyone see any negative effects ..programmatically ? as we all know, opinions vary, but they should not supersede the logic or needs of the end users.
I feel if the use case is proven and it can be done, neatly, without impeding default functionality, there should be no issue testing a new feature in snapshot.
this kind of flew by me, you make a good point here. But i feel this again lends to the benifits of some sort of check for these devices currently using this method.
perhaps the new file entry should be name oem_info or similar, and contain the not only to oem name, but also, the/a version that is supported and safe for use with sysupgrade. This would add an extra housekeeping item onto the dev but is minor.
On the other hand, for my experiences, from my small device pool, this has not happened ..yet. Not to mention there is 2 sanity checks performed before the image ever gets to _do_upgrade. In considering all that ..even if the later is the case and this is extra info is not currently needed, the file would already be there to hold the pertinent info if/when this in fact becomes an issue. So i see no real downside
