19.07.7 for Linksys WRT1900ACv2 will not compile a custom build.
This maybe asked before but couldn't find it;
Is it possible to somehow (easily) compare the standard presented packages to the packages currently installed on your device?
Maybe some import/export functionality?
It's down for me
Seems that Chef was restarted a couple of days ago, but it has since gone down again by the looks of it:
curl -v https://chef.libremesh.org/
* Trying 84.88.85.38:443...
* TCP_NODELAY set
* connect to 84.88.85.38 port 443 failed: Connection timed out
* Failed to connect to chef.libremesh.org port 443: Connection timed out
* Closing connection 0
curl: (28) Failed to connect to chef.libremesh.org port 443: Connection timed out
Edit: now seems OK.
1 Like
The opkgscript.sh script in https://github.com/richb-hanover/OpenWrtScripts/blob/master/opkgscript.sh is designed to do exactly this.
More info: Script to list installed packages? (for simplifying sysupgrade)
2 Likes
The release snapshot builds have been removed now. 
1 Like
For latecomers - the (extremely cool) Firmware Selector is available at:
2 Likes
Would it be helpful to show the device page link in the result?
I can´t find to model TP-LINK EC230-G1 version 1.0
exist any compatible ????
Thanks
This is a convenient tool! It would be nice to be able to check the new version of OpenWrt for my device.
This device does not seem to be supported by OpenWrt.
The link to the wiki is there. But the link scheme is not consistent enough, as such, the link utilizes the wiki search.
Would have been nice if you finally added gpg-signed checksum files. Currently you only provide a raw checksum which at best ensures that the file was downloaded correctly yet does nothing to protect from malicious code in case someone gains admin access to your website.
2 Likes
Hello, thanks for the project!
May I add some suggestion?
It would be useful also to have accompanying luci plugin to check for updates from within the device itself, as it already "knows" it's own name for sure and it would free up humans from error-prone "best guess" work
1 Like
This has been cross posted multiple times. However I’m happy to answer it here again. Vanilla images aren’t aware that they are… vanilla. So the app can’t know if it should request the buildbot image (vanilla) or a custom image (because of a different package selection).
While it’s possible to offer two buttons saying “install custom” and “install vanilla”, people will end up installing vanilla images and losing modification without knowing.
The current implementation tries to be as user friendly as possible to make sure a sysupgrade doesn’t break things.
Now the argument is that the sysupgrade service can’t be trusted because it’s not the buildbots. For that we should work on the reproducibility of OpenWrt images so that whatever image the service (and buildbot really) creates, it’s verifiable.
3 Likes
How about a red !WARNING! along with “install vanilla” button?
That might be a long term task.
I tried to ask what's missing and how long would it take to fix it but didn't get even overage impression.
Maybe nobody even knows..
And until it didn't happen, the solution might be just a red warning along with additional button.