LZMA data error on s390x

[nikita-fuchs]

Problem
I cannot find a working way to use rust's beta or nightly releases on an IBM mainframe running Ubuntu:

root@zla19054:~/.cargo/bin# ./rustup default nightly
info: syncing channel updates for 'nightly-s390x-unknown-linux-gnu'
info: latest update on 2019-08-21, rust version 1.39.0-nightly (bea0372a1 2019-08-20)
info: downloading component 'rustc'
 54.3 MiB /  54.3 MiB (100 %)  13.0 MiB/s in  4s ETA:  0s
info: downloading component 'rust-std'
221.3 MiB / 221.3 MiB (100 %)  16.9 MiB/s in 14s ETA:  0s
info: downloading component 'cargo'
  4.5 MiB /   4.5 MiB (100 %)   1.8 MiB/s in  1s ETA:  0s
info: installing component 'rustc'
info: rolling back changes
error: failed to extract package (perhaps you ran out of disk space?)
info: caused by: lzma data error

Steps

1. Connect to the IBM mainframe of your choice running Ubuntu (reach out to me if you need something here ;) )
2. Run rustup default nightly(if the link is not being created for you like in my case, directly run the binary: ~/.cargo/bin# ./rustup default nightly)
   2.5 same with with the beta
3. Receive error

Of course there is enough space available.

Possible Solution(s)
Is there a way to obtain these packages for s390xarchitecture somewhere directly and unpack the files / get them unpacked already, somewhere, and install them manually?

Notes

Output of rustup --version: rustup 1.18.3 (435397f48 2019-05-22)
Output of rustup show:

./rustup show
Default host: s390x-unknown-linux-gnu

stable-s390x-unknown-linux-gnu (default)
rustc 1.37.0 (eae3437df 2019-08-13)

[kinnison]

Hi,

Based on the info: caused by: lzma data error I'd guess that the s390x nightly archives are somehow damaged/corrupted and that it happened before the channel manifests were created. Are you able to install from a different nightly (e.g. one from a few days ago)?

Thanks,

D.

[pietroalbini]

@nikita-fuchs could you try running this command on your s390x machine?

rustup toolchain install nightly-x86_64-unknown-linux-gnu

[nikita-fuchs]

Thanks for the fast responses !

@pietroalbini that produces the same error, unfortunately.
@kinnison Sorry I can't seem to find a list of release dates for that (I'm no rust developer unfortunately, so maybe there is even a simple way that I've just not stumbled upon) , could you hint me a command?

[pietroalbini]

@nikita-fuchs then it's not an infrastructure problem, the packages in the archive are fine.

You could download Rust manually, but if there is a miscompilation in rustup I doubt it's going to be reliable anyway. It would be useful to see which nightly introduced the regression though: a nightly is released every day and has a toolchain name of nightly-YYYY-MM-DD (for example nightly-2019-08-21 for today's one), so you could try doing a (manual) binary search on them.

[nikita-fuchs]

@pietroalbini ./rustup default nightly-2019-07-05 works:

  nightly-2019-07-05-s390x-unknown-linux-gnu installed - rustc 1.37.0-nightly (24a9bcbb7 2019-07-04)

(note it installs the commit from the day before)

./rustup default nightly-2019-07-06 doesn't, throwing that out of space error. In the issue I've referenced this one in (see above) somebody mentioned, that this behavior would also appear in the next stable if it's not fixed?

Thank you very much for your help.

[kinnison]

The "maybe you're out of space?" is purely a hint because that failure mode is most common. The lzma data error thing is more likely that the lzma library is flakey on s390x and somehow the issue isn't tickled by the 2019-07-05 toolchain, or perhaps previous stables.

Are you able to try a local rustup build?

$ git clone https://github.com/rust-lang/rustup.rs
$ cd rustup.rs
$ cargo build --features vendored-openssl
$ target/debug/rustup-init --no-modify-path -y
$ rustup --no-self-update toolchain install nightly

[pietroalbini]

PRs merged between nightly-2019-07-05 and nightly-2019-07-06:

• Rollup of 13 pull requests rust#62419 - Rollup of 13 pull requests
• Rollup of 10 pull requests rust#62407 - Rollup of 10 pull requests
• Remove io::Result from syntax::print rust#62099 - Remove io::Result from syntax::print
• Switch master to 1.38 rust#62376 - Switch master to 1.38
• Update the rust-installer submodule rust#62153 - Update the rust-installer submodule

rust-lang/rust#62153 seems really suspicious, but I don't have time to investigate right now.

In the issue I've referenced this one in (see about) somebody mentioned, that this behavior would also appear in the next stable if it's not fixed?

That's correct.

[pietroalbini]

Oh, another thing that might be useful to debug: could you download this file and extract it manually?

[nikita-fuchs]

@pietroalbini it extracts without an issue, seems it's all there:

root@zla19054:~/.cargo/bin/nightly-manual-download/rustc-nightly-s390x-unknown-linux-gnu# ls -l
total 88
-rw-rw-r-- 1 buwd buwd     6 Aug 20 21:59 components
-rw-r--r-- 1 buwd buwd  9322 Aug 20 21:59 COPYRIGHT
-rw-rw-r-- 1 buwd buwd    40 Aug 20 21:59 git-commit-hash
-rwxr-xr-x 1 buwd buwd 27888 Aug 20 21:59 install.sh
-rw-r--r-- 1 buwd buwd 10847 Aug 20 21:59 LICENSE-APACHE
-rw-r--r-- 1 buwd buwd  1023 Aug 20 21:59 LICENSE-MIT
-rw-r--r-- 1 buwd buwd  9579 Aug 20 21:59 README.md
drwxrwxr-x 5 buwd buwd  4096 Aug 21 12:02 rustc
-rw-rw-r-- 1 buwd buwd     2 Aug 20 21:59 rust-installer-version
-rw-rw-r-- 1 buwd buwd    37 Aug 20 21:59 version

any chance to roll with that somehow?

[pietroalbini]

@kinnison suggested we could switch rustup to use gzip instead of xz on s390x, and that could work, but I agree with them it would be best to find out the root cause of this if possible.

cc @alexcrichton: apparently after rust-installer started using multithreaded compression it's not possible to extract any XZ tarball on s390x anymore using rustup (tar-rs and xz2-rs), while it works fine with the tar CLI. The error is just lzma data error and on x86 everything is fine. Do you have any idea on the cause for this?

[alexcrichton]

Hm interesting! This does indeed sort of sound like a bug in xz2-rs on s390x, although I wouldn't really know how best to track that down.

@nikita-fuchs would you be able to check out https://github.com/alexcrichton/xz2-rs on your s390x machine and run the test suite in debug/release mode? Or perhaps write a small example using XzDecoder to decode one of the bad tarballs?

[nikita-fuchs]

@alexcrichton I would love to do so, but my rust knowledge is near zero unfortunately, just trying to build an existing application on mainframe, but if you could give me the commands to try out what you suggested, I would do so. I'm talking to IBM about providing the community some means of access to mainframes, it's in their best interest.