There it compares in the repository linked to the tag and non in master. Otherwise it would be as you say and would be unusable. I know it because I use master and the packages I have there I can't have them in stable branches unless the packages themselves are placed in those repositories. I hope you can make me understand better.
i just say .... you can also use userspae wireguard called wireguard-go
link is : https://github.com/WireGuard/wireguard-go
well this is weird to use this under linux instead of using kernel module but if you cant install wg-module then try this way ...
compiling source for mips arch (you dont need to install golang on your router ... compile source on onother device and move binary to router)
you should edit Makefile and use this to compile for mips arch :
GOOS=linux GOARCH=mips GOMIPS=softfloat go build
Yes, master and branches are separate. Sure.
But there can also be package incompatibilities inside a release branch due to package updates in the branch.
Opkg only checks the package version/release (in the specific branch), but does not make any evaluation of "safe update" as you claimed:
That part is still wrong.
Most of those listed can usually be updated, but there can be incompatibilities especially related to low-level core packages like ubus, ubox, libubox, libiwinfo, busybox etc.
Of course, the mistake I admit is that I didn't use the quotes and I would have done it willingly. I understand that opkg cannot know if updating the package will divorce or destroy my router or kill me. But to say that updating is absolutely to be avoided seems to me equally wrong. Any system when updated can create problems, any distribution of Linux or Windows or macOS etc. I use archlinux which is a rolling release, so my PC should burst. Not updating can be a vulnerability. At this point I keep the manufacturer's firmware, which updates automatically and is perhaps more secure, because it overcomes my prejudices. In addition I do not find any point in the official documentation that recommends not to update. You should propose to insert or insert it yourself if you are sure that updating is dangerous.
You can add on the opkg page: update only in case of extreme necessity. Use with caution. I've been updating on different devices for years and I've always had a lot of luck.
Now apart from the funny superstitions we exchanged, the error message is clear: the wireguard module you are trying to install is not compiled for the kernel you have installed. Under normal conditions this is not normal. Of course if you update a module for a version of kernel now and you don't update the system and leave the old kernel, it will never work. Then do a clean installation of a stable version, then check which is the current kernel version installed on the router and what version is proposed to you for wireguard (to do this you must run simple commands and you can refer to the excellent package guide opkg on the official OpenWrt pages). If kernel and wireguard are already in the corresponding version, then simply install and it will work, otherwise update the system and then install wireguard to align kernel and module. Don't worry, the update doesn't break anything, quite the contrary. If something goes wrong it is the very rare exception and not the norm. Not updating is dangerous.
Nobody is telling you that updating is to be avoided. What we are telling you is that opkg update is not a safe way to update OpenWrt. Instead, the (only) recommended method is to use sysupgrade tool and update an entire image at once, rather than attempting to upgrade the component packages within.This ensures that all the kernel versions and dependencies are consistent throughout and therefore should work without issue.
For those who choose to use opkg update in an extremely careful and selective manner (and after checking all of the commits related to the specific packages of interest), upgrades can sometimes work without an issue. But those people should also be aware of the risk and accept the fact that if they have strange results, they may need to reset to defaults and start over again.
The package managers on the 'big' releases have the resources to check for incompatibilities. OpenWrt is designed for devices with very modest hardware specifications (when was the last time you ran a full linux distro on a device with 8MB of storage and 64MB of RAM??), and therefore has been optimized for a minimal memory/storage footprint. It does not have the ability to check for compatibility. So yes, large OS upgrades can be risky at times, even with the compatibility checks. We have been explaining to you that these checks do not exist in the opkg package manager, so the risk is much higher that something will go wrong. Why take that risk?
Good luck with that. I mean, if you have a new router (<2 years old), it may still be within the support horizon for the original vendor firmware. However, the rate at which the vendors actually patch and update their devices post-launch is glacially slow and it is almost certainly more of a risk than waiting for a maintenance release of OpenWrt (in the case where there is actually an exploitable security threat -- and OpenWrt has been pretty good about patching high priority vulnerabilities in a reasonable timeframe). But you weren't suggesting a selective update of specific packages with known security issues -- you were proposing that the OP just blindly update everything. That is very risky when you understand the limitations of an embedded OS like OpenWrt.
I do not know which source you base your statements on and nowhere is it not recommended.
It is not a "complete" distribution, but it is, albeit in miniature. If whoever makes the changes, as for the kernel and the modules, makes them for that tag, in that position of the development tree, he knows what he is doing. It is not a random operation. With risks?!? It can happen (maybe!?!), But I don't find feedback on the real use nor on any official document. I have also used a few Mb distro at the beginning of linux (I'm old) and I have always updated. Of course, if bad code is written it will do damage. But I give confidence to the developers of the project, because it seems to me that they have gained enough with the facts and not with the small talk. Then everyone is free to update only the whole image. For example, I compile a master image every night (if there have been changes) and I flash it preserving the settings (if you read the documentation, you can do it between masters) and I am still very much alive. And the router is in place and shoots this WiFi.
@tmomas - please let me know if Iām incorrect or out of line in any of my comments. Wanted to bring this thread to your attention for technical reasons (are there any other ways we should explore to ensure users are aware of the risks of opkg upgrade).
We have an infobox for this: https://openwrt.org/meta/infobox/upgrade_packages_warning
It can be included in any page on the wiki via the standard page include function of the wiki:
{{page>meta:infobox:upgrade_packages_warning&noheader&nofooter&noeditbtn}}
It can currently be found on these pages:
- https://openwrt.org/docs/guide-user/security/openwrt_security#i_have_custom_packages_installed
- https://openwrt.org/docs/guide-user/additional-software/show_upgradable_packages_after_ssh_login
- https://openwrt.org/docs/guide-user/installation/sysupgrade.cli#post-upgrade_steps
- https://openwrt.org/docs/guide-user/installation/generic.sysupgrade#extras
Do you know of other pages where this infobox could be helpfull?
Should it also be included in the opkg info page (generally and/or linked into the upgrade argument description)?
Not sure where to put the infobox.
https://openwrt.org/docs/guide-user/additional-software/opkg#package_manipulation already contains two links to a yet to be created page https://openwrt.org/docs/guide-user/additional-software/upgrade_packages
My hope was that someone would create and fill this page with more than just the infobox, but until today, that didn't happen.
After revisiting the opkg page, I think we could just create a new section "Upgrading packages" which contains the infobox and additional information like forum links.
Thanks everyone for the information. I will personally continue to update and will not complain. I would know how to solve, even with my poor knowledge. I had never noticed that infobox and at the same time I never had problems.
Is using only capital letters for a proposition normal? Let me know, because it could be useful to me.
I suggest something sober: **Do not update if not in an emergency. The function is there, but it should be used with caution. If you know the package to update and you know what you are doing, do it, otherwise do not touch anything.** This could be 70% of the opkg page and at the end put the command syntax, just for info or for the more adventurous. Maybe the page could only be written in capital letters and would certainly be more effective.
Like I said before, nobody is telling you not to update OpenWrt, we are telling you that you should only do it via the sysupgrade path. And we are telling you not to use (or recommend) opkg upgrade to do any upgrades. That is why I said in that earlier post to "absolutely do not do this" -- it was referring to to method that is prone to cause issues.
My hope is that you now understand why users are urged not do use the opkg upgrade method. If you still decide you want to do it for your own systems, obviously nobody is going to stop you. But please do not suggest that people use this method on the forums as it really can cause more harm than good (an certainly complicates troubleshooting).
I understand and will not continue to suggest it. Or better yet I have not completely understood: when I update with opkg and update the list of packages, I take them from a single cauldron valid for OpenWrt master to go down or the update is related only to the branch / tag that I use? If it were the latter case, as I seem to have understood, the risk would be only to code problems that can create internal incompatibilities and not to completely incompatible versions. But in the case of this thread, if the module is updated and the kernel is "old" what should we do? Will the system have to build?
I see 2 ways of looking at this issue:
- Fresh install of OpenWrt (19.07.1 as of this moment) +
opkg update; opkg install wireguard
or - following #1 with a subsequent
opkg upgrade wireguard
In the case of #1, I literally just did this yesterday (as part of my own checking for this thread) using an ar71xx device and it worked flawlessly. So unless there is some device-specific issue (very unlikely) that is affecting the OP's wndr3700v2, there really should be no issue.
With respect to #2, I have not tried it and I don't plan to. If it breaks wireguard, that only reinforces the idea that opkg upgrade is rarely a good idea. Unless there is a very good reason to try the upgrade (a specific bug fix, feature addition, or security patch that is absolutely necessary in the immediate term), there really is no reason to even try upgrading this way. However, that said, if this is the case, the best way to do this would likely be to move to snapshot builds that should pickup the latest and greatest for everything. Keep in mind, though, that snapshots have their own issues, too -- they are work-in-progress and may contain new bugs/regressions, and the packages may go out of date just a few hours after the main image download (therefore, it is advisable to install everything needed immediately, or keep local copies of the repo or just update snapshots images regularly).
Or do as I do that compile the image with the packages and changes that suit me most.
Sure, compiling packages and including them in your own custom images is a great way to handle it. I'd still recommend avoiding opkg upgrade, though, for the same reasons as we've already covered.