-
Notifications
You must be signed in to change notification settings - Fork 898
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
Failure to install on Windows #2203
Comments
Update: I tried this on my machine today and got something normal-looking:
|
IIRC Azure's setup is very odd and breaks rustup quite badly because of how they do layering for preinstalled stuff. I've had fewer issues with github actions, so perhaps they fixed things in there? |
Reverted experiments, seems like others are having the same problem. rust-lang/rustup#2203 https://github.com/anderejd/cargo-geiger/issues/86
FYI: I had this on a personal project as well. Adding explicit host triple made it work again:
|
That flag seems to have worked for us, as well. Is there any chance the host detection changed in 1.21 either for better or worse that could be making this necessary? Alternatively, I wonder if the builders were changed in some way (e.g. from 32-bit to 64-bit) without clearing any caches. |
@nikodemus Thank you! Your solution works for me as well. |
is your curl an x86-64 curl? |
Are you running from a “script” block or “bash” block? |
This is what I have now (which works, with the explicit
|
What’s weird about this is how it ever worked 😄 From all I have read it should have always been downloading and installing the 32-bit version... 🤔 As of this, the right thing should be happening: |
We do this in a
So it seems likely it's a 64-bit |
If you're using win.rustup.rs then it will always download a 32 bit installer which should pick an installer which matches your platform but may incorrectly select a 32bit one instead. In CI it's recommended to install with explicit host triples or perhaps even to set it in a separate action and then install the toolchain. That protects you against changes in the underlying infrastructure more effectively. |
@rustbot label: +O-windows |
Problem
Rocket's Windows CI (Azure Pipelines) started failing between 27 and 4 days ago. We run this command:
And the output looks like this:
In a previous successful run, this was the output:
Steps
I have not attempted to reproduce this yet. I'll try locally first, but I would not be surprised if there's some kind of caching going on from a previous installation that will make reproduction difficult.
Analysis
Two things about this seem really odd to me:
i686
(maybe related to #2179?) andstable
when the requested version wasnightly
. I don't know if it's trying to find the stable toolchain before or during a self-update, assuming it is trying to do one.Any hints before I go and try this on bare metal?
The text was updated successfully, but these errors were encountered: