I want to hear good reasons why I shouldn't. I'll start this off.
*It wears out your flash.
-In some instances I use emmc or SSD, is this still a problem? In other instances i have 128-256MB flash, I don't really care if some of it gets corrupted. If its mostly corrupted flash at this point (RIP my old netgear 8500, d-link dir-825, and cisco ea4500 devices) I will upgrade my device completely and im ok with that.
*You may get bad updates.
-This happens to me and as long as it is only on my local items(don't test in production), im ok. I just flash the firmware and cancel out the bad updates i find on my own.
**Even worse, the bad update may permanently brick your device.
It hasn't happened to me yet and I have been updating everyday since you changed from lede back to openwrt.
*you should just compile your own snapshots
I do for the devices I encounter daily. I need a solution for the stable devices i remote into daily that I've not touched in years. Grandma had strict covid restrictions but I was still able to keep her internet connected to the family because it was running a stable version.
Now the reasons I have for updating:
-I need to install security updates. what if I told you not to update or patch your OS? I dont want to have another heartbleed or something similar because I didn't update my packages. That may have been openlede though. heartbleed is when i promised I'd upgrade my router packages often. heartbleed is old but the lesson is relevant.
*Old platform, newer users
-I have an openwrt 18.xx still in use 2,000 miles away and noone can upgrade it for me. I'm actually scared to run updates on it now but it was required to upgrade wireguard on it to keep it operational at some moment 2 years ago. once I got that old 18.xx router upgraded to latest wireguard and wireguard-tools, it connected back to my new openwrt wireguard server and hasn't failed me since. I upgrade wireguard and wireguard-tools mostly. My point is I have openwrt 18, 19, and 20 in the field and occasionally if i don't update, the wireguard versions would get mismatched and I'd be SOL on the old openwrt because I didn't run command opkg update && opkg install wireguard wireguard-tools
*If you are going to post dangerous updates on a stable release, don't you need a tester?
-I'm just trying to help because I can find the bad packages within 2 hours of detection or notification if you need me.
The biggest problem is probably for us here at the forum that tries to help people like you get your router up and running again and it is always “emergency and disaster” when this happens.
But no one will actually stop you from doing this but is it our problem to help you after you brick your router voluntarily in this way?
Heartbleed bugs…well maybe but when we had the dnsmasq bug on 19.07.5 it was only a couple of days for a new release to fix that bug and a couple of weeks after that 19.07.7 to fix the problems in the bug fix problems.
So if there are a actual issue there will be releases pretty fast.
18.06…that is EOL so there is no meaningful point of upgrading packages anyway on that one.
Upgrading packages (via the CLI opkg upgrade command or the LuCI Upgrade... button) can result in major problems. It is generally highly discouraged, unless you know what you are doing or if there is specific instruction to do so.
I hope these explanations cover your concerns. Subscribe to the advisories page to get notifications as soon as something is published.
I think we should be on the same page about that. We set up the infobox and the canned reply to deal with the increased number of users opening new topics seeking help to salvage their broken router from an upgrade gone wrong. If there is no reason to warn users anymore and everything works fine with the upgrades, we would have to remove the infobox and tell everyone to file a bug report.
The issues mentioned above are still relevant and nowhere near to be solved.
Also don't forget that we have plenty of devices with limited flash, which may not even have enough space in overlay to fit the upgraded packages, so upgrading those is asking for factory reset when the process fails, and it can very well result in soft-bricking when some critical packages are involved.
By the way, I personally experienced soft-bricking a few times due to failed upgrades.
the users who experienced (severe) issues due to upgrading packages
the users who are regularly upgrading their packages and who are asking "What are you talking about, I've been upgrading my packages for years without any issues!"
Although I hear @jow's words, I also have my personal experience and I'm seeing reports here in the forum about issues after upgrading packages, hence thinking that warning users about $bad_things that can happen is appropriate.
This is a deliberate setup to allow for upgradable packages. If we do not want that because it is too dangerous we could scrap that infrastructure and only build branches on release points. That will also mean though that package updates only become available with new point releases and whatever package fails to build on release time will remain unavailable until the next release.
Also no more out of band security fixes for things like OpenSSL, people simply need to upgrade to the next release.
I think (opinion) that most people probably don't need to upgrade packages, but they do so because they believe it is necessary to keep the router secure and "up-to-date."
There are some scenarios where this is very dangerous -- notably situations where there is some change to the underlying API/ABIs or when users run out of space. There are other times when it is just fine. Upgrading non-core packages that have known and useful improvements can be useful -- think bug fixes or feature additions to something like TravelMate or similar.
How do we balance these things? Can we disable the LuCI upgrade button selectively such that all core/included packages (within the ROM) do not have upgrade options in LuCI, but user-installed packages would have the capability to upgrade? Upgrades would still be available via CLI for more advanced users.
I really think this tactic would hurt openwrt more than help, and that must require a very periodic release of service releases.
And to wait a couple of months because the build robot fail, I don’t see that as an option.
I would say if someone want a fully updated release installation then the release snapshot is probably the best way forward if you want the most compatible solution.
By educating package maintainers (that includes base) to be sensible about the kind of updates they merge into stable release branches and to pay more attention to binary packaging, strict dependencies and properly planned and orchestrated feature upgrades, especially when these involve multiple core components and the usage of new or deprecation of existing APIs.
This would prevent us from publishing important fixes (security or functionality wise) out of band, not an option imho.
That used to be the normal scheme of things until the release of LEDE 17.01. You can't have the cake and eat it, really. Either you continuously deliver package updates (and delegate responsibility for smoothness of operation to packagers and testers) or you simply don't update packages to ensure that everything remains relatively static and the only way forward is fully reflashing to the next release.
Somehow having package updates while also not wanting to actually update packages will not work.
I see your point, but in my idea, only the LuCI interface would prevent upgrades to core packages. An OOB security/functionality upgrade could still be achieved with CLI. What my proposal would aim to do would be to provide just enough friction that the average user wouldn't think they need to upgrade just because an upgrade is available. But in the documentation/notice of an important OOB upgrade, we could instruct users to do this via an ssh session.
My goal is not to treat them as 2nd class citizens, but rather to use this as a safety mechanism. Based on what we see, often if a user is not comfortable with the CLI, they probably shouldn't be hitting those upgrade buttons except in rare instances. The same could be said for CLI users, too, of course, but it does signal a bit more experience in many cases. I'm thinking of it more like big OSs like Mac OS -- the UI allows almost everything, but there are some things that are hidden in CLI based commands because messing with them could cause issues if you don't know what you're doing. A super simple example is the idea of the GUI trash (which is recoverable until emptied) vs issuing rm -r or rm -rf.