I update my packages on stable everyday

If a user wants to upgrade all packages, he will find a way around the safety mechanism and do it. It's not too hard to find one or more scripts that just do that.

1 Like

Could a warning about upgrading packages be added to luci? (or has that already been done)

1 Like

It might be a good idea to disable opkg installing upgrades by default, while providing a --force-upgrade parameter.
A more optimal solution: disable updates by default for critical repositories like core and base, and provide updates by default for general application repositories like packages and luci. But packages also contains base packages like wget, so I think a more detailed categorization may be needed.

What @tmomas said...

A lot of time wasted only to find out at the end that the user was upgrading packages.

3 Likes

Yes, the bug of package upgrade overlooked.

I found out the hard way and think that I should upgrade everything before I start doing what I wanted.

When things gone wrong at luci with package, the router start doing things wrongly.
even I flash the firmware or factory reset the router, then default strangely does not work.

Either you test your luck by
Upgrading package in CLI / ssh
OR
don't upgrade at all.

This is my recommendation.

1 Like

The thread does not look as conclusive to me as you claim. Also instead of continuing the „omg never upgrade packages“ narrative it would be a lot more helpful to figure out which update exactly, if any, broke things.

3 Likes

Fair enough. But…

I totally agree. I’m an engineer and I always want to root-cause the issue. The problem is that, especially with blind upgrades, it is really hard to pin that down. And it is made more difficult when people don’t mention that they have done package upgrades until a whole bunch of additional stuff has been done to try to resolve the issues.

I think part of the issue is that the (blind/bulk) package upgrade process can add so many additional variables to the equation and it is extremely difficult and time consuming to pick it apart. I go back to my main statement of ‘just because there is an upgrade doesn’t mean it should be applied.’ Targeted package upgrades for security/bug fixes or known new features are reasonable. But broadly applying upgrades just because they are available is risky.

3 Likes

Good point. That's the reason why I upgrade my packages, to find out if something breaks and what causes the breakage.

Not sure if this was supposed to be irony. Anyway to reiterate my points:

  • I only refer to stable branches, snapshots give no guarantees
  • if an update is available in a stable branch it should be a bugfix or a security fix or a well isolated feature update
  • if an update is present which breaks things it should be reverted or fixed
  • installing updates on stable releases are not expected to cause issues or to break operation (flash issues aside, LuCI tries to protect against that somewhat)

I suppose that all the recent issues are caused by the cluster of netifd/hostapd-common/wp ad updates. These have to be fixed. They shouldn’t have been applied like that to the stable branch in the first place.

1 Like

Not at all!
I have been in a situation where upgrading packages broke my system.
Since then I'm aware of the situation, and I'm interested to see if upgrading breaks again, and if it does, what specific package caused the breakage.

1 Like

How many times have we had this standard forum scenario:
-my router broke!!!!!
-what did you do just before it broke?
-nothing!

Like 50posts later…

-ohh, I forgot to mention that I upgraded the packages but I didn’t think it was important info.

Each time it is expected that we are supposed to know this without the client telling us.

3 Likes

In practice, many targets are potentially affected by flash issues, and more or less advanced users tend to upgrade packages in bulk with CLI to automate the process, so it's difficult to ignore entirely.

1 Like

i think it's a normal question, but should not be at same time. The whole trend of frenetic update are mostly due to android. Before i was on Windows Chicago and then 7sp2 never update, all stable. But on linux side, is community and all push need to be done in order to 'publish' and then find bug by yourself the own developper and others. Centos is part of long and less updated, or was. But on router, the main package last version is considred beta and then all package 'update' are working on top and for that beta. If someone do install after stable image : this should be consider beta and then report to the main author of code package developper. Being user is different than being developper. if you update package without reading the code it's a different story. And if the upmost importance is rock solid and security people are at wrong place.. this is open source, just get a Cisco.

Fun fact: all releases from 9.4.4 to 9.16.2 are Interim.

1 Like

Could someone clarify if the image builder included with each release is subject to the "package upgrade" problem? I.e., will running the image builder at different points in time result in images with newer (maybe broken) package versions?

I've been using the image builder to make my own image with all the packages I want, and then I can flash it on my handful of routers. I've noticed the commit sha in the version number changes each time I do Example: OpenWrt 21.02.1 r16325-88151b8303 / LuCI openwrt-21.02 branch git-21.340.48972-61cc3b1 on an image I built today vs OpenWrt 21.02.1 r16325-88151b8303 / LuCI openwrt-21.02 branch git-21.327.65561-7f37a58 from an image I built a couple weeks ago. I'm not sure if that's meaningful or not. I'm assuming it tracks the stable branch and any fixes are likely fine, but just want to confirm...

Thanks in advance for your feedback!

the short answer is: the statement above is correct... the long answer is there are still some (very) rare situations where inadvertent issues may arise 1...

1) IB gives you an additional layer of insulation to some of these rare situations... and often the image creation process will spit errors at the build stage, saving you from whatever consequences may have eventuated performing similar tasks on the router itself 2) IB 'upgrades' bypass some of the 'in-place' complexities involved with upgrading core or interdependent packages... mostly only relevant for the master branch... 3) IB is mostly immune to upgrade induced disk space full related issues on small-flash/frequently-upgraded devices... you know what packages you want... and you bypass the on-device implications on space by 'upgrading' them at the build stage...
3 Likes

Perfect, thanks for the detailed reply!

1 Like

Since this continues to come up on a regular basis, it's clearly a tripwire that people can too easily fall over, costing themselves and others their time and attention. What would people think if the software page in Luci were changed to have something like this:

  1. Grey out (disable) by default the Upgrade buttons next to "upgradeable" packages
  2. Insert a line above the list that looks like this:

[ ] Enable package upgrades (I have read the warnings)

Where the phrase in parentheses is a link to the advice on the wiki. Checking the box would dynamically enable upgrade buttons. The choice would not be saved as a persistent preference: how hard it is to click a checkbox? Thoughts appreciated.

2 Likes