It won't work.
Me too. Great software.
I only learned about the new release today as I got the announcement email today, 10 days later than it should've been.
This really should not happen, it's a security failure.
It's a security failure to rely only one one single source of information (in this case: the missing email).
There are multiple ways to get aware of a new OpenWrt release and get notified about it.
Visiting the OpenWrt forum more often helps to be up to date.
All theses packages were installed after the main installation. When performing an upgrade with an offical image, you will only get the default packages list. The best way is to make your own custom build with all the packages you need, than use it to upgrade. You can use the firmware selector for this.
Maybe I'm too old school because usually email works great for other open source projects (and it's also the first channel mentioned on https://openwrt.org/contact#important_changes_and_announcements).
It seems OpenWrt really loves its forum, so I'll keep that in mind.
I now see that you can subscribe to the Release and security announcements subforum via the bell and "Watching First Post", so that seems to be a good solution.
Thanks a lot for your hint, yes for the next update I will take more care about this custom build option beforehand.
You are welcome.
If you upgraded while keeping the settings, than the setting for your extra packages are still here. You can add these packages now and they will work as before (reboot meanwhile). Better idea, create your custom build with these packages, and perform another upgrade. It'll only need a couple of minutes.
Cool, thanks a lot, sounds like that's the way I will follow next time.
Wait, how did you do the upgrade? Did you use LuCI
auc, or just plain old
sysupgrade with "keep config"? Sounds like the latter... I've been using
auc on the command like for over a year now on a handful of different devices, and have been able to keep my installed packages, even when jumping between release and snapshots (and back -- I never jump too far, otherwise I'm sure I'd get bitten by things like fw3/fw4 diffs).
I did use LuCI standard release Sysupgrade from the downloaded openwrt-22.03.4-ramips-mt7621-totolink_x5000r-squashfs-sysupgrade.bin with keep config method to be sure, from the running system menu, under the impression that all of the individual made setup would remain like it would be with any other modern update made under any other OS available this days, be it M$, BSD, or Linux, which usually do nor require reinstalling any added software at all... well in most cases anyway
+1 I've seen this on 2 disparate devices (Archer c7 v2 and Turris Omnia). I'm tempted to drop the Candela drivers, but I've got enough other problems with my network at the moment.
Oh, that's interesting, because while several have mentioned the
ath10k_pci mac flush vdev errors, I didn't see mention of a correspondence with "disassociated / deauthenticated" events in the syslog.
I wonder if the previous reporters are are also seeing that event pairing?
Also, it's interesting that the prior report was about a TP-Link c2600, and you also mentioned another non-Archer. I was thinking this was an Archer issue, but maybe not. Maybe they all have something in common, like a chipset.
In my earlier post for Archer A7 you can see that I do get it preceded by a somewhat similar preceding event chain (essentially a jump from 2.4 to 5 GHz or vice versa, always of the same device actually) - but I also get many of those same band changes without the kernel info event
Also worth noting that I'm running non-standard kmod-ath10k-smallbuffers and ath10k-firmware-qca988x, so not related to -ct drivers (or not solely)
Probably more UBI-using devices are affected. Not all seem to be easily recoverable without serial cable. Could be a good idea, to broaden the “known issues“ text, just for caution. And from what I was reading in the forum, the 21.02.6 kernel could also show similar issues, but the 21 announcement has no such known issue text so far:
Hmmm, I haven't looked into pairing correlation, but to the point of what these different devices have in common, yeah: ath10k is the 802.11 wireless driver for the Qualcom Atheros QCA988x family of chips.
I am having the same issue with packet loss, throughput issues as reported in the Kirkwood testers.
Upgrading from 22.03.3 went without problems, no packet loss or throughput issues on my 100/10 connection from the previous service release 22.03.3.
Just reporting my experience with service release 22.03.4.
Why 22.03.5 Released so soon?
22.03.5 has NOT been released. A tag has been created in the repo, but until the devs tell you otherwise, DO NOT try to install it.
it is released
Your text only tell, it takes 2 days until all versions are build. It not change anymore or change again.
Building new version not happen every time. I only ask, what is fatal fail why new version need release.