Running on Raspberry Pi - container starts but iPhone can't find Altserver

[cwells427]

I tried connecting via a USB cable to the pi and trusting it, then inputting the 6-digit code on my phone when prompted, but the iPhone still can't find Altserver. My apps are already installed via AltServer on Windows - do they need to be reinstalled via this server?

[dreth]

do they need to be reinstalled via this server?

As far as I know they don't need to be reinstalled, you can just refresh them as soon as your altserver is up.

but the iPhone still can't find Altserver.

what's the specific error message you're getting?

Can you post your altserver error logs? they should be under logs/altserver.err.log file, if you want you can also post your logs/altserver.out.log file to check it out

[cwells427]

what's the specific error message you're getting?

On the iPhone, AltStore reports 'Failed to Refresh AltStore : AltServer could not be found'

Logs attached. Thanks for the help!

[deleted the logs for privacy reasons]

[dreth]

I deleted the logs after downloading them as I have a feeling they might contain personal information of your device (i don't know if they do but better safe than sorry).

Do the logs for netmuxd show you device being added/removed?

[cwells427]

Only thing in either netmuxd log is

Starting netmuxd
Starting mDNS discovery for _apple-mobdev2._tcp.local with mdns
Listening on /var/run/usbmuxd

[dreth]

Yep, this means the device is not being detected by netmuxd, are you running usbmuxd in the host machine? are the idevice and the machine in the same wifi network?

[cwells427]

Sorry - still pretty new to Linux and Docker generally - I haven't set up usbmuxd separately, and doesn't look like it was contained in the docker image (at least doesn't show in /bin/)?

Both devices are on the same network

[dreth]

usbmuxd is installed in the building process of the image:

# Install necessary system dependencies
RUN apt-get update && apt-get install -y \
    libavahi-compat-libdnssd-dev \
    libusb-1.0-0-dev \
    libclang-dev \
    libusbmuxd-dev \
    libimobiledevice-utils \
    ideviceinstaller \
    usbmuxd \
    avahi-daemon \
    avahi-utils \
    libnss-mdns \
    avahi-discover \
    curl \
    screen \
    dbus \
    jq \
    supervisor \
    xz-utils \
    && apt-get clean

So it won't show up in bin, it should be running if you didn't make any changes to this. My question is regarding the host system, so not the container, but the raspberry pi itself.

I wouldn't know which OS is installed in your rpi but I believe rpi OS is based on debian, so you should be able to check if usbmuxd is running in the host by running systemctl status usbmuxd (I'm assuming you're running rpi OS).

If it's not running, that's good, it's not supposed to be running in the host OS.

However, the host OS should be running the avahi daemon, so check if it's running with systemctl status avahi-daemon.service

[cwells427]

Can confirm, running rpi OS - usbmuxd is not found, avahi-daemon is running

[dreth]

Can you spot any errors when you check the container logs? Did any of the services fail to start?

You can check with docker logs altserver, post those logs here if possible, they should contain no information about your device.

If nothing seems out of order, then try a clean slate:

1. Close altstore on your device (don't leave it running in the background, close it)
2. Bring down the container stack, if you're using docker-compose (which i recommend), bring it down with docker compose down, otherwise you can docker stop altserver && docker rm altserver && docker compose up -d (which also brings it up again at the end)
3. Open altstore on your device and try to refresh
4. Receive the code to re-authorize the device and let the refresh happen (fingers crossed it works)

[cwells427]

Brought down the stack just in case, then brought back up and retried on my phone, got the popup for iCloud code, entered it, still getting 'AltServer could not be found'

altserver docker logs :

Getting binaries...
AltStore is up to date.
AltServer is up to date.
netmuxd is up to date.
anisette-server is up to date.
Making scripts executable...
Starting avahi-daemon service...
Purging logs...
Decompressing required libs for Provision...
tar: lib/aarch64: Not found in archive
tar: Exiting with failure status due to previous errors
lib/x86_64/
lib/x86_64/libstoreservicescore.so
lib/x86_64/libCoreADI.so
Starting supervisord...
2024-08-09 22:44:04,153 INFO Set uid to user 0 succeeded
2024-08-09 22:44:04,162 INFO RPC interface 'supervisor' initialized
2024-08-09 22:44:04,162 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2024-08-09 22:44:04,163 INFO supervisord started with pid 1
2024-08-09 22:44:05,167 INFO spawned: 'usbmuxd' with pid 65
2024-08-09 22:44:05,172 INFO spawned: 'anisette-server' with pid 66
2024-08-09 22:44:05,177 INFO spawned: 'netmuxd' with pid 67
2024-08-09 22:44:05,183 INFO spawned: 'altserver' with pid 68
2024-08-09 22:44:06,827 INFO success: usbmuxd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-08-09 22:44:06,828 INFO success: anisette-server entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-08-09 22:44:06,828 INFO success: netmuxd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-08-09 22:44:06,828 INFO success: altserver entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

[dreth]

Hmm interesting, I see that your architecture doesn't match any in the provision dirs

Just to check and see if it makes sense to make this addition and if it helps fix the issue, can you (temporarily) modify the scripts/docker-entrypoint.sh script to add:

# Detect the system architecture
ARCH=$(uname -m)

# in case of aarch64, map it to arm64-v8a
if [ "$ARCH" = "aarch64" ]; then
    ARCH="arm64-v8a"
fi

after line 26 and start from a clean slate again? I doubt this is the issue, but can't hurt to try

[cwells427]

Added that in, still getting 'Altserver could not be found' unfortunately. Again, thanks for the help diagnosing this

[dreth]

I think I didn't tell you you should sudo rm ./lib (be very careful to INCLUDE the dot) and ideally post the logs from the container (docker logs altserver) when you run it again: docker stop altserver && docker rm altserver && docker compose up -d

And it's no problem ✌🏼

[cwells427]

removed ./lib then rebuilt the stack (do you prefer that written route or compose down? Used that command set just in case)

logs here:

Getting binaries...
AltStore is up to date.
AltServer is up to date.
netmuxd is up to date.
anisette-server is up to date.
Making scripts executable...
Starting avahi-daemon service...
Purging logs...
Decompressing required libs for Provision...
tar: lib/aarch64: Not found in archive
tar: Exiting with failure status due to previous errors
lib/x86_64/
lib/x86_64/libstoreservicescore.so
lib/x86_64/libCoreADI.so
Starting supervisord...
2024-08-09 23:17:45,387 INFO Set uid to user 0 succeeded
2024-08-09 23:17:45,396 INFO RPC interface 'supervisor' initialized
2024-08-09 23:17:45,397 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2024-08-09 23:17:45,397 INFO supervisord started with pid 1
2024-08-09 23:17:46,404 INFO spawned: 'usbmuxd' with pid 65
2024-08-09 23:17:46,413 INFO spawned: 'anisette-server' with pid 66
2024-08-09 23:17:46,421 INFO spawned: 'netmuxd' with pid 67
2024-08-09 23:17:46,430 INFO spawned: 'altserver' with pid 68
2024-08-09 23:17:47,530 INFO success: usbmuxd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-08-09 23:17:47,530 INFO success: anisette-server entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-08-09 23:17:47,530 INFO success: netmuxd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-08-09 23:17:47,530 INFO success: altserver entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

[dreth]

Okay i see that the line we added didn't really change anything, try to bring it up using docker compose up -d --build --force-recreate and post the logs here. Also docker compose down is fine too, should have the same effect, so up to you