2025-Feb-13: There are known intermittent issues generating custom images using the online image generator (firmware selector and sysupgrade servers). This affects Attended Sysupgrade (ASU), OWUT (OpenWrt Upgrade Tool), and the firmware-selector custom image tool. See this thread for more details.
Please do not open new threads on this topic as it has already been discussed in numerous threads (with the same answers each time).
While I cannot speak to the specifics (not my area of expertise), the issue is related to problems in the build system with mismatched checksum/hashes and the like.
In many cases, the errors that are surfacing will include...
* opkg_install_pkg: Checksum or size mismatch for package
I hope this is fixed for now, I disabled the Squid caching. It caused to use "old" packages, resulting in a checksum mismatch afterwards. I'm investigating how the Squid configuration could be improved. If anyone reading this knows things around Squid, please help me with the configuration.
STDERR:
Generate local signing keys...
Generate local certificate...
Package list missing or not up-to-date, generating it.
Building package index...
Downloading https://downloads.openwrt.org/releases/24.10.0/targets/x86/geode/packages/Packages.gz
Updated list of available packages in /builder/build_dir/target-i386_pentium-mmx_musl/root-x86/../../../../builder/dl/openwrt_core
Downloading https://downloads.openwrt.org/releases/24.10.0/targets/x86/geode/packages/Packages.sig
Signature check passed.
Downloading https://downloads.openwrt.org/releases/24.10.0/packages/i386_pentium-mmx/base/Packages.gz
Updated list of available packages in /builder/build_dir/target-i386_pentium-mmx_musl/root-x86/../../../../builder/dl/openwrt_base
Downloading https://downloads.openwrt.org/releases/24.10.0/packages/i386_pentium-mmx/base/Packages.sig
Signature check passed.
.
.
.
Downloading file:packages/Packages
Updated list of available packages in /builder/build_dir/target-i386_pentium-mmx_musl/root-x86/../../../../builder/dl/imagebuilder
Downloading file:packages/Packages.sig
Signature check passed.
Collected errors:
* opkg_install_cmd: Cannot install package libavahi-compat-libdnssd
make[2]: *** [Makefile:234: package_install] Error 255
make[1]: *** [Makefile:171: _call_manifest] Error 2
make: *** [Makefile:349: manifest] Error 2
After deleting the package ( couldn't this done by the upgrade?), there are possible memory errors signaled.
Doesn't ASU function with my ALIX (256MB) system?
Hi! I've been playing with OpenWRT 24.10.0 on an OpenWRT One and so far I've had great luck. Thank you so much to the OpenWRT team for all the hard work!
This evening, with a stock install of 24.10.0 on the OpenWRT One, I tried running this command:
Collected errors:
* opkg_install_pkg: Checksum or size mismatch for package screen. Either the opkg or the package index are corrupt. Try 'opkg update'.
* opkg_install_cmd: Cannot install package screen.
* opkg_install_pkg: Checksum or size mismatch for package tmux. Either the opkg or the package index are corrupt. Try 'opkg update'.
* opkg_install_cmd: Cannot install package tmux.
* opkg_install_pkg: Checksum or size mismatch for package libffi. Either the opkg or the package index are corrupt. Try 'opkg update'.
* opkg_install_cmd: Cannot install package python3.
* opkg_install_pkg: Checksum or size mismatch for package openssh-sftp-server. Either the opkg or the package index are corrupt. Try 'opkg update'.
* opkg_install_cmd: Cannot install package openssh-sftp-server.
The errors seem similar to those described in this thread, but the thread seems to be specific to custom images - which I am not running. Are they a symptom of the same root issue? Is there a way around the problem such that I can install these packages? I don't seem to be experiencing any other network-related problems that could explain these errors.
Sort of... It seems to be a delay between deployment of the package indexes and the corresponding packages, either one being updated while the other is older will give the same "checksum or size mismatch".
I believe what you are seeing here is what I describe at the bottom of this comment: Owut: OpenWrt Upgrade Tool - #535 by efahl, i.e., you are in that rsync window where things are not fully available yet.
These same symptoms were being generated by the ASU server caching the package indexes, so that there was an artificial delay between their being updated on the downloads server and what the ASU image builders were seeing.
Quite probably just waiting a bit for the build results to be fully populated on the downloads server. (This might also depend on where you are on the planet, and how long it takes for your local CDN endpoints to get the new/consistent files.)
If this persists for more than 8-10 hours, I'd say something is broken upstream, so try again and let us know either way.
I have been trying to upgrade my Bananapi BPi-R4 from 24.10.0 to SNAPSHOT using the Firmware Selector custom image tool since Thurday AM (GMT).
I successfully upgraded my bthh5 on the first attempt.
The server appears to successfully create an image, but the ouput page still shows all the radio buttons between "Request Build" and "Sysupgrade", though the checksum shown does change.
I also tried this with the default package list, getting the same result.
That is as expected. x86 and most breadboard images have that. There is meaningful data for the sysupgrade process attached to the end of the compressed archive.
You are meant to not decompress these and load them right into the sysupgrade process.
Only if you need to write an image to a new disk/sd-card, you need to uncompress the archive (and ignore the attached data error) to gain access to the img file.
I'm trying to use the squashfs image with FriendlyWRT's eflasher tool, but it refuses to boot.
As I already have a bootable image on the eMMC, I have to hold in the Boot button to mask for booting from the SD card, but it's not working.
I was thinking maybe that's because the image from the Firmware Selector displayed this behaviour, but it seems not.
The boot process for the NanoPi R5S is a little flaky IMO.
I think I will have to flash FriendlyWRT 23.05 and use that to write OpenWrt 24.10 instead.