OpenWrt 23.05.0 - First stable release

I used the image builder.
https://downloads.openwrt.org/releases/23.05.0/targets/ipq40xx/generic/openwrt-imagebuilder-23.05.0-ipq40xx-generic.Linux-x86_64.tar.xz

What you are showing is the image selector, which is not be yet updated.

Has anyone managed to create or find LXC image for 23.05 (used in proxmox container). The images mentioned in the official docs are outdated.

https://openwrt.org/docs/guide-user/virtualization/lxc
https://blr1lxdmirror01.do.letsbuildthe.cloud/images/openwrt/

Upgraded Meraki MR-24 access points from 22.03.5 to 23.05.0, keeping configs. Everything worked perfectly except for one minor glitch, easily fixed: I'm using four of the status LEDs to indicate activity on 2 VLANS x 2 radios, and this config didn't pick up new device names like, for example, phy0-ap0 replacing wlan0. Helpfully, when editing each LED's configuration from the LUCI LED Configuration page, the 'Device' drop-down menu identifies the old device name as an 'Absent Interface', and identifies the BSSID and VLAN corresponding to the correct new device names, making it easy to do the correct fixes.

Many thanks, devs!

Did that and up and running.

So, is attendedsysupgrade not that dependable, or it couldn't handle the upgrade between RC's and stable?

1 Like

I submitted pull requests to add the new release in the relevant lxc github repos today, but assume it will take a few days to percolate.

"It depends."

Standard sysupgrade simply installs a pre-built configuration with a collection of default packages, which vary by platform and target (for instance, x86 does not include any WiFi packages), and then optionally reapplies your current configuration.

The Attended Sysupgrade duo (LuCI Attended Sysupgrade and CLI auc) both use the standard sysupgrade image, augment it with the extra packages you've installed and reapplies your current configuration.

Both of the above can fail at the "reapplies your current configuration" step, as the config files can change between releases. If, for example, the wifi device name is changed between two releases, then you see, "Oh, no! Wireless doesn't work when I upgrade to X from Y!"

ASU-based upgrades can also fail if packages have been split (mt7622 extracted from the mt7915 stuff), are replaced with different ones (wolfssl to mbedtls) or simply are dropped.

There's not yet any infrastructure to deal with the above in a standard way, so it's sort of a crap shoot and there are attempts to ease upgrades all over the place. Sometimes it's handled internally, like when ifname was replaced with device in the network config, it was translated on read of the file if I remember right. For the mbedtls replacement, auc (somehow) knows about the right thing to do and prompts you, while LuCI ASU does not. The ASU server knows about the mt7622 mod and silently includes it, so that one is transparent. But, sometimes the solution is just "do a sysupgrade without config and start from scratch".

Making all of this work seamlessly across not just minor versions, but releases, too,, is what ASU is all about. But, it needs some helping hands to mature into something closer to what major Linux distros provide with their release upgrade tools.

4 Likes

Thank you for the clarification, the online image builder was being incorrectly referenced.

Successfully installed! When doing opkg update however, I get the following:

Failed to send request: Operation not permitted
Collected errors:

I am running on RPI4. Is it a problem on my part? I did a fresh install.

That is typically/often caused by an incorrect network configuration from a local software point of view (which differs from it working correctly as a router from other connected devices).

Things to check:

  • is default gateway set correctly (if not main router)
  • is dns set correctly on your interface(s)? Check /etc/resolv.conf and try a local “ping OpenWRT.org” just see what happens.

If those things works, opkg should work too.

1 Like

MX60W crashes at boot before kernel starts loading

This could likely be the known issue with missing default gateway: https://github.com/openwrt/openwrt/issues/13598

Easiest way to check would be if you ssh into your pi device and type ip route. If the output doesn't have any lines starting with default then that is your issue.

I don't have complete understanding of when that happens but I think it is likely to happen in any openwrt 23 installation using wifi as a client (as opposed to an AP).

Edit is not available anymore so I'll use reply..."full sysupgrade" did the work (thanks to badulesia for pointing that out.)...tried twice attended sysupgrade and both radio's were gone after update. After "full sysupgrade" everything works...well except the LEDs - LAN1-3 still have green LEDs on even though previously v22.03.5 was able to keep all the lights off.

Ok, I've made a bit of progress on this.

It seems that all of the packages are downloaded with IPv4 except the telephony package which is attempting to be delivered over IPv6 and that's failing for some reason. Why just this one package when they're all coming from the same host, I have no idea. At least now I have some sense of what problem to look for though.

To debug this, I needed to see the detailed output of wget when invoked by opkg. Unfortunately, opkg passes a the -q quiet flag to wget unconditionally (even when run in verbose mode).

So I made a shell script to intercept the wget invocation and strip the first argument.

vim /tmp/wget

#!/bin/ash
shift
/usr/bin/wget $@

Then we run it!

chmod +x /tmp/wget
export PATH=/tmp:$PATH
opkg update

<snipped for brevity>

Downloading 'https://downloads.openwrt.org/releases/23.05.0/packages/mipsel_24kc/routing/Packages.sig'
Connecting to 168.119.138.211:443
Writing to '/tmp/opkg-MaejNh/Packages.sig'
/tmp/opkg-MaejNh/Pac 100% |*******************************|   142   0:00:00 ETA
Download completed (142 bytes)
Signature check passed.
Downloading https://downloads.openwrt.org/releases/23.05.0/packages/mipsel_24kc/telephony/Packages.gz
Downloading 'https://downloads.openwrt.org/releases/23.05.0/packages/mipsel_24kc/telephony/Packages.gz'
Connecting to 2a01:4f8:251:321::2:443
Connection error: Connection failed
*** Failed to download the package list from https://downloads.openwrt.org/releases/23.05.0/packages/mipsel_24kc/telephony/Packages.gz

At least I have some idea where to look. This device isn't sending neighbor solicitations for IPv6 addresses across the bridge but it started working after I restarted the network interface. Could be a regression (race condition on startup?) but it needs further investigation.

No issue noticed on EdgeRouter-X, airCube-AC and Archer A6 v3, all devices keeping configs. Will update my Archer C7 v5 and E8450 at a later time.

Thanks for all the work everyone.

1 Like

Thank you for your effort. Looking forward to the LXC build of OpenWrt.

Now I can't download sysupgrade through the firmware selector for Linksys E8450 (UBI)- error 404.
Where did you get it?

@hauke please can you amend your opening post above to further include this warning for the Zyxel users:

The prebuilt images for Zyxel NR7101 are currently broken and will brick your device. PLEASE DO NOT INSTALL. (bug already fixed but require SNAPSHOT or self-compile).

It worked at the time I downloaded the image. Now I get a 404, too:
https://firmware-selector.openwrt.org/?version=23.05.0&target=mediatek%2Fmt7622&id=linksys_e8450-ubi

But: the images are available:
https://downloads.openwrt.org/releases/23.05.0/targets/mediatek/mt7622/

Just be careful to pick the right image matching your device and partitioning.

2 Likes

I found it there too, updated everything. Everything is cool.
Thanks.

2 Likes

upgraded WAX206 using auc without issue from rc4 to final:

auc -b 23.05 -B 23.05.0

thanks

1 Like