OpenWrt 23.05.0 - First stable release

I'm attempting to upgrade a D-Link DIR-2660 A1 running 22.03.3 to 23.05.0 using attended sys
upgrade but the only available firmware for upgrade is 22.03.5?

Anyone know why this might be?

WRT1900ACSv2 successfully updated from RC4 to stable release. No observed issues. (As always multiple terminal package install attempts + reboot = limited storage size).


Still have a problem here.

Error building the firmware image

Server response: Unsupported target: ipq40xx/generic
Please report the error message and request

Request Data:

    "url": "",
    "revision": "r23482-7fe85ce1f2",
    "advanced_mode": "1",
    "sha256_unsigned": "",
    "branch": "23.05",
    "efi": null,
    "profile": "linksys,ea8300",
    "target": "ipq40xx/generic",
    "version": "23.05.0",
    "packages": [
    "diff_packages": true,
    "filesystem": "squashfs",
    "client": "luci/git-23.132.65998-fa9fb2f"

Sucessfully upgraded a Banana PI R3 and two Netgear WAX220 to 23.05 from RC4. Eveything is working without problems. Many thanks to the devs!

1 Like

Xiaomi AX9000(2), ax3600(3), ZyXel wsm20(6), Netgear wax206(3) and Qnap W301 upgraded from RC3 or RC4 with a image generated with Firmware selector. 802.11s, batman, adguardhome. All went well except Qnap, which had to be powercycled before the wireless started to work.

I also noticed that the ZyXel wsm20 image didn't iclude ssl for luci as default like the others included.

You need to perform a full sysupgrade.

Use the image builder. I have been able to build for the MR8300.

Thanks, why is that the case?

I thought the point of attended sysupgrade was to be able to upgrade between major versions, whilst preserving packages and config?

1 Like

attended sysupgrade only works within a release : e.g. 22.03 -> 22.03. To perform an update to another version (23.05) you need a full sysupgrade.

1 Like

Right...thank you :+1:

Issue has persisted both with (previously) and (now) without power saving enabled. The client does not show up as disconnecting (AP-STA-DISCONNECTED) in the hostapd logs when this happens, and there's nothing in the client-side journalctl/dmesg logs either about any disconnection. It's just that traffic is not flowing, resulting in host unreachable errors, until I force the new association/connection.


Confirming successful upgrade while keeping config for x86-64 and Netgear Wax 206 from RC3.

Thanks all contributors.

However for the most recent and release candidates 23.05.xx-xx the image builder reports a failure.

I used the image builder.

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.

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.


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