ACME installation breaks apk on x86_64 ext4‑combined image (missing apk fetchers)

Hi everyone,

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

  1. Is the missing /usr/libexec/apk/ directory on the ext4‑combined image expected or a bug?
  2. Should the ext4 image include the apk fetchers by default?
  3. Is ACME supposed to work on ext4‑based x86_64 installations?
  4. 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.

Best regards, Dirk

You have to install wget-ssl after you link away non-ssl symlink.

ln -sf  /bin/uclient-fetch /usr/bin/wget

Sorry but I think this is not a solution for me. I have checked and the link is already existing.

lrwxrwxrwx 1 root root 18 Jan 21 01:20 wget -> /bin/uclient-fetch

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?

$ ll /usr/bin/wget
lrwxrwxrwx    1 root root   18 Jan 28 09:07 /usr/bin/wget -> /bin/uclient-fetch*

$ apk add wget-ssl
(1/1) Installing wget-ssl (1.25.0-r2)
  Executing wget-ssl-1.25.0-r2.post-install
  * add alternative: /usr/bin/wget -> /usr/libexec/wget-ssl
OK: 68.1 MiB in 293 packages

$ ll /usr/bin/wget
lrwxrwxrwx    1 root root   21 Jan 28 09:08 /usr/bin/wget -> /usr/libexec/wget-ssl*

$ apk del wget-ssl
(1/1) Purging wget-ssl (1.25.0-r2)
  Executing wget-ssl-1.25.0-r2.pre-deinstall
  * add alternative: /usr/bin/wget -> /bin/uclient-fetch
OK: 67.7 MiB in 292 packages

$ ll /usr/bin/wget
lrwxrwxrwx    1 root root   18 Jan 28 09:08 /usr/bin/wget -> /bin/uclient-fetch*

Unfortunately not – the problem also occurs when only one package is installed. The APK crashes, and I have to restore the backup in Proxmox.

root@OpenWrt:~# ll /usr/bin/wget
lrwxrwxrwx 1 root root 18 Jan 21 01:20 /usr/bin/wget -> /bin/uclient-fetch*
root@OpenWrt:~# apk add wget-ssl
(1/2) Purging uclient-fetch (2025.10.03~dc909ca7-r2)
Executing uclient-fetch-2025.10.03~dc909ca7-r2.pre-deinstall
add alternative: /usr/bin/wget -> /bin/busybox
(2/2) Installing wget-ssl (1.25.0-r2)
wgetwget: applet not found
ERROR: wget: exited with error 127
ERROR: wget-ssl-1.25.0-r2: remote server returned error (try 'apk update')
1 error; 46.0 MiB in 284 packages
root@OpenWrt:~# ll /usr/bin/wget
lrwxrwxrwx 1 root root 12 Jan 31 08:26 /usr/bin/wget -> /bin/busybox*
root@OpenWrt:~# qpk update
-ash: qpk: not found
root@OpenWrt:~#