hello @btuin,
Would you mind providing your steam logs for this? I don't know how easily you can reproduce, ideally we'd try to figure out where you got the corrupted download from if it's still in your logs.
@smcv it seems we're not able to recover from a corrupted sniper download, is this a problem with the types of checksums we are doing? That has been a problem in the past but of course we can never reproduce the actual corruption. We might have to force this for testing.
it seems we're not able to recover from a corrupted sniper download
I thought the Steam client bootstrap/upgrade machinery was responsible for validating and if necessary re-downloading ubuntu12_64/steam-runtime-sniper.tar.xz and other related files - certainly when I'm testing new proposed versions of sniper, I have to use the (intentionally undocumented) command-line option that turns off that validation, and when I stop using that option and restart Steam, it automatically re-downloads the production version for me.
Or does Steam do some sort of quicker but weaker validation, like checking that the sizes (byte counts) are correct but not looking at the actual content?
At the moment there is no channel that I'm aware of by which the sniper unpacking machinery can report back to the Steam client "file x is corrupt, please re-download". If Steam checks file sizes, a simple version might be to truncate ubuntu12_64/steam-runtime-sniper.tar.xz to 0 bytes long, to nudge Steam into re-downloading it? Or if there's some IPC mechanism available, like writing into ~/.steam/steam.pipe or communicating through an AF_UNIX socket, we could maybe teach steam-runtime-sniper.sh to be able to do that.
is this a problem with the types of checksums we are doing?
Any checksum would have the same effect: there are two reasonable results, "file is 100% correct" or "error". The only way to recover from corruption is re-downloading, unless we add significant redundancy (unlikely to be worth it in practice).
I believe the xz format has its own internal validation mechanism (which is why xz --test can work) and that will cause steam-runtime-sniper.sh to fail to unpack a corrupted archive most of the time (rather than silently unpacking the wrong things). I'm not sure whether it's a simple checksum like CRC32 (as used in zip files) or a cryptographic hash like SHA256, but either one would be good enough for our purposes.
@btuin we found the likely reasons why the bootstrap logic in steam is not able to detect and correct this. We will work on addressing in a future update, I don't think we need the logs I requested earlier.
If this happens again, running steam with -verifyfiles should fix.
Thanks! If you need the logs anyway, tell me which one you want.
By the way I'm not sure if this is obvious, but I provided the complete output of the terminal in my first message, is this what you wanted ("Ouput of flatpak run com.valvesoftware.Steam")?
The latest beta will now automatically force a full checksum verification if it is having problems with the expansion of the CEF runtime.
Closing per the last comment.
0x80070057x1 2024-12
Your system information
Ouput of `flatpak run com.valvesoftware.Steam`
Please describe your issue in as much detail as possible:
When I tried to run Steam the extraction of the runtime failed, Steam crashed and it immediately tried again with the same result in loop.
After some investigations it turned out that the archive
steam-runtime-sniper.tar.xzwas corrupted (running the commandxz --teston the archive gavexz: steam-runtime-sniper.tar.xz: Compressed data is corrupt.So I deleted the this file and started Steam again and everything worked like it should.
This file is located in the directory
~/.var/app/com.valvesoftware.Steam/local/share/Steam/ubuntu12_64when using flatpak, and I suppose in~/.local/share/Steam/ubuntu12_64otherwise.I don't know how that happened but it seems that I downloaded a corrupted version of
steam-runtime-sniper.tar.xz. After deleting it and starting Steam a sane one was downloaded. By comparing the corrupted version of the file and the sane version, it turns out that there is exactly one bit that is different:The corrupted version has the sha256
a6ab758945c52e60c17c02ad9dafd2b00b4e16c717da29532bd7ed6a72528516, the sane version hasbc5f9ff12b7c1901326945bce85f6dccca6c4e29f1bdc00d732f6306e903b100.In the end the issue here is not really that I got a corrupted version of the file, but that Steam is completely unable to recover in such case.
Steps for reproducing this issue: