I’ve run into a reproducible issue on OpenWrt 25.12-rc3 (x86_64) when using the generic‑ext4‑combined image inside a Proxmox VM.
Problem
Installing ACME:
Code
apk add acme acme-dnsapi
causes apk to break completely:
wget: applet not found
unexpected end of file
apk update no longer works
no further packages can be installed
After this point, apk is essentially unusable.
Findings
On the ext4‑combined image, the directory:
Code
/usr/libexec/apk/
is missing entirely, including all fetchers (fetch-curl, fetch-uclient, fetch-wget). apk still works initially because curl is installed and apk falls back to curl internally.
When ACME is installed, it pulls in wget‑ssl, which tries to update or replace apk fetcher symlinks. Since /usr/libexec/apk/ does not exist, this operation fails and apk loses its working fetcher backend.
Questions
Is the missing /usr/libexec/apk/ directory on the ext4‑combined image expected or a bug?
Should the ext4 image include the apk fetchers by default?
Is ACME supposed to work on ext4‑based x86_64 installations?
Would using the squashfs‑combined image avoid this issue, or is that not the intended workaround?
Thanks for any clarification — I’d like to understand whether this is a packaging issue, an ext4‑image limitation, or something misconfigured on my side.
I would think that it is indeed a packaging issue.
wget's symlinks are handled by the uninstaller scripts. Those seem to work fine in "atomic" mode (just doing a single package without dependencies). I wonder if there's some issue with order of operations when several packages get installed all at once?