thank you!
This is the wiki page I found, where it would have been super-helpful to have your example on that page, e.g.
By default auc by only checks for newer releases of whatever branch you're currently running on the device. You can use -b to change the release branch, by invoking
$ auc -b 22.03
to get the latest version on branch 22.03, or
$ auc -b snapshot
to get the latest snapshot release.
You can also use -B to jump around a specific branch, so if you already have 23.05.2 installed, but for some reason need to downgrade, you'd invoke
$ auc -b 23.05 -B 23.05.0
I tried to edit the wiki, but apparently I don't have an account and can't auto-register.
Thanks again!
Running 23.05.2 on a Raspberry Pi4 - I've set it up to be a client on radio1 (dongle) LAN and Access Point on radio0 (the built in wifi chip) wwan. The AP didn't work with the upgrade from 23.05.0 and I traced the issue to the auto channel selection option. If you select 'auto' in Luci or editing /etc/config/wireless for the Pi's built in wifi radio it will start, but then disable itself. You have to specify a channel number in the luci or /etc/config/wireless file or it won't enable. Is there any specific place I can report this bug? I worked around it by just picking a channel and not using auto but maybe others will come across this on other devices.
I have always just left them sit in the overlay until my next upgrade. I guess my rationale is "don't wear out the flash", but that's probably not going to happen on modern silicon. On the other hand, if you find that you are running out of "disk" space in the flash, doing an auc -y -f can free up the overlay so you can install more packages.
1 Like
Yeah, we're in the midst of recruiting new wiki managers, so registration is difficult right now.
Check out my additions, let me know if I missed anything that would have helped you (my "I know how it works!" eyes don't see things that might jump right out to you). https://openwrt.org/docs/guide-user/installation/attended.sysupgrade#from_the_cli
2 Likes
That's perfect - thanks so much, again!
IPv6 suffix is now limited to 8 characters which is wrong, it should allowed up to 16 characters. I used a 16 character hex suffix using DHCPv6 for my Debian servers and it worked fine until 23.05.0
1 Like
Luci sysupgrade failing on two Linksys EA8500 with official 23.05.2 sysupgrade firmware image
At page /luci/admin/system/flash I click "Flash image..." button, pick the file, click "Upload" button...
I see the progress bar as it uploads, oddly slow on both APs, and then get error "XHR request timed out".
Neither AP ever displays the SHA256 checksum page after upload.
No new entries in the System log or Kernel log pages between attempts.
Any ideas? Anybody else?
Is it possible that it's a browser related issue?
I've only tested it on Chrome without any extensions or restrictions, and the sysupgrade seems to work for 23.05.2 via luci
As suggested by the error message, slow uploads can cause the upgrade to abort. Try improving your wireless connection, switch to a wired connection, or copy the sysupgrade file to the device and upgrade using the CLI.
This came from this commit, with no explanation for the change in accepted input format.
Maybe @systemcrash can explain the rationale (or @jow)?
We should continue here for this issue Bug in IPv6-Suffix (hex) max 8 characters?
1 Like
I referenced the wiki which is generally the source of truth.
As @jow wrote in 2020:
32 bits = 4 bytes = 8 (hex) characters FF-FF-FF-FF.
If you @openwrtforever have experimental evidence to the contrary, I would be interested to see it. ( Things may have changed internally since @jow wrote the above).
I used a 16 character suffix which is provided by DHCPv6 to my Debian server and it worked fine but now the suffix field is red now.
Please allow upto 16 hex characters.
Its not 32 bits now it is 64 bits.
Look at my old post What's with the 32-bit restriction with IPv6-Suffix for static leases?
Now it is 64 bits and it worked for me.
1 Like
In 2021, the max hostid length was increased to 64 in odhcpd, which would be handling the IPv6 static leases.
1 Like
I'm wondering how this is possible:
WNDR3800 (22.03.5 upgrade to 23.05.2): MemAvailable essentially unchanged.
Archer C7v2 (22.03.5 upgrade to 23.05.2): MemAvailable dropped from a longtime average around 60000 to around 40000, even after another reboot.
In each case, the configuration is the same as before because it was an upgrade and the subsequent package installation is scripted.
If v23 is just bigger than v22 (though that seems like an unrealistic amount), then why only one router? They're similar ath79 routers though of course not identical. Is it possible that the c7 family underwent a major change in v23 to account for this while the other didn't? If so, any idea what?
Hmm, I don't recall seeing my C7v4 do that. Only "extra" service I've got is adblock (~70k domains) and it shows about 60M available. Hard to remember, as I wasn't much paying attention, but I thought it was about like this with 22.03, too. (I did use auc to update, so as to minimize footprint on the packages.)
1 Like
My C7 v5 (dumb AP on 23.05.2) only has the extra packages luci-app-attendedsysupgrade, auc and htop....
Seems a little bit on the low-side but am not sure.
On the c7v2 issue, I'm noticing that if I check very soon after reboot the memory is in the vicinity of what it used to be, if not quite as high, so a more plausible figure.
But what's happening is a slow, steady drop, so a leak of sorts (it's a very active router, but it always has been). I know the wireless driver can have a big effect, so I guess I'll try a different one. Right now I'm on the same one as I've been using for at least a year, kmod-ath10k-ct-smallbuffers, which has been fine.