Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failed to detect the operating system version on Rocky Linux 9.3 #1486

Closed
AtomBaf opened this issue Feb 16, 2024 · 2 comments · Fixed by #1493
Closed

Failed to detect the operating system version on Rocky Linux 9.3 #1486

AtomBaf opened this issue Feb 16, 2024 · 2 comments · Fixed by #1493
Assignees
Labels
bug Something isn't working

Comments

@AtomBaf
Copy link

AtomBaf commented Feb 16, 2024

Hi there,

Doing an uv venv or any of the command will lead to this error:

× Failed to detect the operating system version: Couldn't parse /bin/ls for detecting the ld version: Invalid magic number: 0x622f7273752f2123

Context:

  • Rocky Linux 9.3
  • ldd (GNU libc) 2.34
@BurntSushi BurntSushi added the bug Something isn't working label Feb 16, 2024
@BurntSushi BurntSushi self-assigned this Feb 16, 2024
@BurntSushi
Copy link
Member

I can reproduce this via the rockylinux:9 docker image:

$ docker run --rm -it --mount type=bind,src=/home/andrew/astral/issues/uv/i1486,dst=/host rockylinux:9 bash
[root@b6f41d07c55e /]# yum update --assumeyes --quiet
[..snip..]
[root@b6f41d07c55e /]# yum install which --assumeyes --quiet
[..snip..]
[root@b6f41d07c55e /]# curl -LsSf https://astral.sh/uv/install.sh | sh
[..snip..]
[root@b6f41d07c55e /]# . ~/.cargo/env
[root@b6f41d07c55e /]# uv venv
  × Failed to detect the operating system version: Couldn't parse /bin/ls for detecting the ld version: Invalid magic number: 0x622f7273752f2123

@BurntSushi
Copy link
Member

Ah the problem is that ls is not actually a binary:

$ cat ~/astral/issues/uv/i1486/ls
#!/usr/bin/coreutils --coreutils-prog-shebang=ls

We assume it is and parse it as an ELF file. This is related to the concern @zanieb brought up in #1433 where everything will fail if parsing ls fails.

It looks like sh is a true binary though. And I think it kind of has to be?

$ file ~/astral/issues/uv/i1486/sh
/home/andrew/astral/issues/uv/i1486/sh: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=7acbb41bf6f1b7d977f1b44675bf3ed213776835, for GNU/Linux 3.2.0, stripped

I'll put up a PR that reverts #1433 and just checks the /bin/sh executable instead of attempting /bin/ls.

BurntSushi added a commit that referenced this issue Feb 16, 2024
It turns out that /bin/ls can sometimes be plain text file. For
example, in Rocky Linux 9:

```
$ cat /bin/ls
#!/usr/bin/coreutils --coreutils-prog-shebang=ls
```

However, `/bin/sh` is an ELF binary:

```
$ file /bin/sh
/bin/sh: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=7acbb41bf6f1b7d977f1b44675bf3ed213776835, for GNU/Linux 3.2.0, stripped
```

In a related issue (#1433), @zanieb fixed #1395 where, on NixOS,
`/bin/ls` doesn't exist but `/bin/sh` does. However, the fix attempts
`/bin/ls` first and only tries `/bin/sh` if `/bin/ls` doesn't exist. If
`/bin/ls` exists but isn't a valid ELF file, then the entire enterprise
gives up and `uv` fails to detect the version of `libc` that is
installed.

Instead of tweaking the logic to keep trying `/bin/ls` and then
`/bin/sh` after even if parsing `/bin/ls` fails, we just switch over to
reading `/bin/sh` only. It seems like a more fundamental thing to sniff
and likely less error prone.

We can adjust this heuristic as needed if it provdes to be problematic.

I tested this fix manually on Rocky Linux 9 via Docker:

```
$ cross b -r -p uv --target x86_64-unknown-linux-musl
$ cp target/x86_64-unknown-linux-musl/release/uv ~/astral/issues/uv/i1486/uv
$ docker run --rm -it --mount type=bind,src=/home/andrew/astral/issues/uv/i1486,dst=/host rockylinux:9 bash
[root@df2baa65d2f8 /]# /host/uv venv
Using Python 3.9.18 interpreter at /usr/bin/python3.9
Creating virtualenv at: .venv
[root@df2baa65d2f8 /]#
```

Fixes #1486, Ref #1433
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants