Uv install script cannot detect glibc inside WolfiOS base image.

[KhazAkar]

When trying to install uv inside container with cURL'd script, when using wolfi-base from chainguard, cannot detect glibc version.

#8 [stage-0 4/7] RUN curl -LsSf https://astral.sh/uv/install.sh >install.sh && sh install.sh
#8 9.598 head: /proc/self/exe: Bad file descriptor
#8 9.645 ERROR: unknown platform bitness
#8 9.647 sh: bad number
#8 9.653 install.sh: line 911: ldd: not found
#8 9.701 System glibc version (`') is too old; checking alternatives
#8 9.814 downloading uv 0.4.18 aarch64-unknown-linux-musl-static
#8 38.24 installing to /home/nonroot/.cargo/bin
#8 38.34   uv
#8 38.39   uvx
#8 38.39 everything's installed!
#8 38.79 
#8 38.80 To add $HOME/.cargo/bin to your PATH, either restart your shell or run:
#8 38.80 
#8 38.80     source $HOME/.cargo/env (sh, bash, zsh)
#8 38.80     source $HOME/.cargo/env.fish (fish)
#8 DONE 38.9s

(slow because I'm building aarch64 container on x86 host)
It installs musl python variant, when it's glibc here.
More info about Wolfi OS - https://github.com/wolfi-dev

[mistydemeo]

Looks like the inability to detect glibc comes from ldd being missing; I'll look into adding support for other methods to detect the glibc version. The "unable to detect bitness" one is interesting - I hadn't expected us not to have access to /proc/self/exe.

[KhazAkar]

Probably because access to it was removed or restricted as part of WolfiOS security model, around which they revolve whole "OS" around. Like secured to the brim alpine with glibc instead of musl.

[mistydemeo]

I've been doing some local testing and wasn't able to reproduce the /proc/self/exe issue, though I can reproduce the ldd issue. Any chance you're able to share what the previous steps in your dockerfile look like?

[KhazAkar]

Sure, no problem, I can share even whole Dockerfile. Adding posix-libc-utils fixes missing ldd and now glibc is detected.

FROM cgr.dev/chainguard/wolfi-base:latest
RUN apk add curl build-base posix-libc-utils
USER nonroot
WORKDIR /home/nonroot
ENV UV_COMPILE_BYTECODE=1 UV_LINK_MODE=copy
RUN mkdir -p .cache/uv
RUN curl -LsSf https://astral.sh/uv/install.sh >install.sh && sh install.sh
ENV PATH="/home/nonroot/.cargo/bin:/home/nonroot/app/.venv/bin:$PATH"
RUN uv python install 3.11.9 && uv venv
RUN --mount=type=cache,target=/root/.cache/uv \
    --mount=type=bind,source=uv.lock,target=uv.lock \
    --mount=type=bind,source=pyproject.toml,target=pyproject.toml \
    CC=gcc uv sync --frozen --no-install-project --no-dev
COPY app .
EXPOSE 19110
ENTRYPOINT []
CMD ["fastapi", "--host", "0.0.0.0", "--port", "19110", "/home/nonroot/app"]

[KhazAkar]

Interesting observation on the side - if I use /root/.cache/uv - step with mount works fine. If I want target cache to be in /home/nonroot/.cache/uv - it doesn't work with 'permission denied' error. Either I don't understand how something works, or is a bug.