-
Notifications
You must be signed in to change notification settings - Fork 892
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
rustup-init hangs in armv7 docker container running on an arm64 Linux with reqwest
backend
#3122
Comments
Do they select the same sort of connection to the host? e.g. ipv4 or ipv6 ? |
I chatted with @kinnison and he sugggests that the failure is due to reqwest, which has a TLS implementation which uses per-CPU features, getting the wrong CPU type from your /proc/cpuinfo. Then the actual CPU doesn't handle things and it all just burns up in fire. A starting point would be to compare your cpuinfo to the expected one for the hardware it is running on (or qemu is emulated, if you have cross-arch docker stuff happening). |
Host $ cat /proc/cpuinfo
processor : 0
BogoMIPS : 50.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x3
CPU part : 0xd0c
CPU revision : 1
processor : 1
BogoMIPS : 50.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x3
CPU part : 0xd0c
CPU revision : 1
$ lscpu
Architecture: aarch64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Vendor ID: ARM
Model name: Neoverse-N1
Model: 1
Thread(s) per core: 1
Core(s) per cluster: 2
Socket(s): -
Cluster(s): 1
Stepping: r3p1
BogoMIPS: 50.00
Flags: fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs
NUMA:
NUMA node(s): 1
NUMA node0 CPU(s): 0,1
Vulnerabilities:
Itlb multihit: Not affected
L1tf: Not affected
Mds: Not affected
Meltdown: Not affected
Mmio stale data: Not affected
Retbleed: Not affected
Spec store bypass: Mitigation; Speculative Store Bypass disabled via prctl
Spectre v1: Mitigation; __user pointer sanitization
Spectre v2: Mitigation; CSV2, BHB
Srbds: Not affected
Tsx async abort: Not affected Docker armv7 $ docker run --rm -it --platform linux/arm/v7 ubuntu:22.04 cat /proc/cpuinfo
processor : 0
BogoMIPS : 50.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x3
CPU part : 0xd0c
CPU revision : 1
processor : 1
BogoMIPS : 50.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp ssbs
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x3
CPU part : 0xd0c
CPU revision : 1 |
That certainly looks like docker is providing the host's cpuinfo through. This is the issue we had on reqwest - seanmonstar/reqwest#642 which eventually boiled down to lxc/lxcfs#553 which is what eventually fixed it in that case - I wonder if Docker needs equivalent help. |
Using |
It does look like it's able to get a bit further when using
It stays there until the CI job eventually times out. |
@rochdev Does our new 1.27 version (https://internals.rust-lang.org/t/seeking-beta-testers-for-rustup-1-27-0/20352) work for you? |
@rami3l Not sure if I'm doing this right, but I added The command in question: curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --verbose --default-host armv7-unknown-linux-gnueabihf --default-toolchain nightly --component rust-src Environment variables set before running the above command:
|
@rochdev Thanks for your report! The thing here is that we're currently considering the removal of the cURL backend (possibly as early as in 1.28), so it's a must that we minimize the number of functionalities being broken in that change. I happen to have an ARM64 Mac so I'll probably be able to look into this issue more deeply. |
Without the cURL backend rustup hangs even sooner, basically even before it starts downloading any dependencies. Using cURL allows it to at least get past the downloads after which it hangs at trying to install cargo.
I just tried locally on an M1 Mac and it works properly. The issue seems to be isolated to Linux aarch64 hosts. |
Oops, ARMv7 support is not available on ARM64 Macs (https://news.ycombinator.com/item?id=27278019), my bad. |
I tried to disable cURL and use the default reqwest backend instead with the 1.27 beta, and it also didn't change anything compared to before. Here is the output:
|
I tried to get the most minimal reproduction that I could, and I ended up with this which reproduces the issue: FROM arm32v7/ubuntu:16.04
RUN apt-get update && apt-get -y install curl
RUN curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y --verbose \
--default-host armv7-unknown-linux-gnueabihf |
For good measure I also tried the same Dockerfile but with Ubuntu 18.04, 20.04 and 22.04 and I see the exact same behaviour across all of them. |
Reported this against reqwest after checking with its maintainer that this is not a known issue: |
@djc I'm not sure it's actually an issue with reqwest though. While it hangs on reqwest when reqwest is used, it still hangs when cURL is used, but at the install step after the downloads have completed. So it seems to me like either something rustup or rust is doing that doesn't work with that setup. |
@rochdev that's fair... would still like to figure out why reqwest fails to download here. |
@djc For sure, the more eyes on this the better, but something tells me it might be the same thing that makes both hang 🤔 rustup hangs and reqwest hangs, both of which are in Rust, yet cURL works perfectly every time. Maybe there is an issue with Rust itself, or some other library than reqwest? |
@rochdev to be clear, it could definitely be that there is an issue in rustup still. If you're able to dig in more, that would be great. Maybe try enabling trace-level logging and see if you can pinpoint where the hang is happening? |
@djc Can you provide more detailed steps on how to capture the additional information you're looking for? I tried using |
Try using |
@djc Sorry yes that's what I tried, edited. |
@rami3l do you know if release builds are built with otel support built in? |
@djc No, I don't believe so, I'm afraid a custom build is required: Lines 11 to 26 in b4b9a2e
|
@rochdev would you be able to build your own with |
You'd have to clone this repo, run |
@djc Was there any change recently in the dev version? I can't seem to be able to reproduce even re-running builds that were clearly failing 100% of the time. |
@rochdev We didn't do anything explicit on our side regarding Maybe you can use > rustup --version
rustup 1.27.0+1 (46327d7ff 2024-03-11) dirty 1 modification
... ... and according to your report, neither v1.26.0 nor v1.27.0 (beta) is working for you. Is that correct? |
A month later I was never able to reproduce again, so I don't know what was causing the issue for us. It just started working properly one day. |
@rochdev In that case I'm closing this issue as incomplete. Please feel free to let us know if something goes wrong again on your end. Have a nice day! |
Problem
Running
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
in armv7 docker container running on an arm64 Linux hangs.Steps
Run a docker container with
--platform linux/arm/v7
on an arm64 Linux, install curl and run the sh.rustup.sh scripthangs forever at the
verbose: downloading with reqwest
step, useRUSTUP_USE_CURL=1
works finePossible Solution(s)
No response
Notes
No response
Rustup version
rustup-init 1.25.1 (bb60b1e89 2022-07-12)
Installed toolchains
N/A
The text was updated successfully, but these errors were encountered: