Can you see if there's any spew in your ~/.local/share/Steam/logs/content.log?
Here is a portion of it. I can upload the whole file, or if there's a better way to copy the whole thing to this thread I can do that too.
[2016-10-18 07:00:30] Current download rate: 10.140 Mbps
[2016-10-18 07:00:30] Created download interface of type 'CS' (1) to host valve514.steampipe.steamcontent.com (valve514.steamcontent.com)
[2016-10-18 07:00:30] HTTP (CS,514) - valve514.steampipe.steamcontent.com (valve514.steamcontent.com): AuthenticateDepotID (373301) - Success!
[2016-10-18 07:00:40] AppID 570 update canceled : Failed updating depot 373301 while unpacking bad chunk "3d6c26ee37dc145c5799e07acdbbb0b28da800e6" (Unpack failed (c:140240,u:0,b:0)) (Corrupt download) "valve506.steampipe.steamcontent.com/depot/373301/chunk/3d6c26ee37dc145c5799e07acdbbb0b28da800e6?l=14&e=1477379137&sid=17201278&h=4cd32a36c7b8ec9383ba1e8013211dceafb22350"
[2016-10-18 07:00:40] AppID 570 update changed : Running,Downloading,Staging,Stopping,
[2016-10-18 07:00:40] AppID 570 update changed : Running,Stopping,
[2016-10-18 07:00:40] AppID 570 update changed : None
[2016-10-18 07:00:40] AppID 570 state changed : Update Required,Update Started, (Corrupt download)
[2016-10-18 07:00:40] AppID 570 scheduler finished : removed from schedule
[2016-10-18 07:01:30] HTTP (CS,507) - valve507.steampipe.steamcontent.com (valve507.steamcontent.com): Received 0 (Invalid) HTTP response for depot 373301
[2016-10-18 07:01:30] HTTP (CS,507) - valve507.steampipe.steamcontent.com (valve507.steamcontent.com): Closing connection
[2016-10-18 07:01:31] Current download rate: 0.000 Mbps
[2016-10-18 07:01:40] HTTP (CS,506) - valve506.steampipe.steamcontent.com (valve506.steamcontent.com): Closing connection
[2016-10-18 07:01:40] HTTP (CS,514) - valve514.steampipe.steamcontent.com (valve514.steamcontent.com): Closing connection
[2016-10-18 07:01:40] HTTP (CS,520) - valve520.steampipe.steamcontent.com (valve520.steamcontent.com): Closing connection
Having the same issue with Counter Strike Go and DoTA 2.
Maybe of interest: I've installed the games on an SSD using F2FS.
Same error (but different files) for DoTA 2.
I've tried to delete the downloads folder, change the download area, checked the files multiple times. Everything short from redownloading the whooping whole 16GB of the game.
~/.local/share/Steam/logs/content_log.txt
https://paste.pound-python.org/show/cVgLwRPklYaYnISDk9Kx/
Computer Information:
Manufacturer: Unknown
Model: Unknown
Form Factor: Desktop
No Touch Input Detected
Processor Information:
CPU Vendor: GenuineIntel
CPU Brand: Intel(R) Core(TM) i5-4670K CPU @ 3.40GHz
CPU Family: 0x6
CPU Model: 0x3c
CPU Stepping: 0x3
CPU Type: 0x0
Speed: 4000 Mhz
4 logical processors
4 physical processors
HyperThreading: Unsupported
FCMOV: Supported
SSE2: Supported
SSE3: Supported
SSSE3: Supported
SSE4a: Unsupported
SSE41: Supported
SSE42: Supported
AES: Supported
AVX: Supported
CMPXCHG16B: Supported
LAHF/SAHF: Supported
PrefetchW: Unsupported
Network Information:
Network Speed:
Operating System Version:
"Manjaro Linux" (64 bit)
Kernel Name: Linux
Kernel Version: 4.7.7-1-MANJARO
X Server Vendor: The X.Org Foundation
X Server Release: 11801000
X Window Manager: Fluxbox
Steam Runtime Version: <Runtime disabled>
Video Card:
Driver: NVIDIA Corporation GeForce GTX 770/PCIe/SSE2
Driver Version: 4.5.0 NVIDIA 370.28
OpenGL Version: 4.5
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 60 Hz
VendorID: 0x10de
DeviceID: 0x1184
Revision Not Detected
Number of Monitors: 2
Number of Logical Video Cards: 1
Primary Display Resolution: 1920 x 1080
Desktop Resolution: 3840 x 1080
Primary Display Size: 23,54" x 13,23" (26,97" diag)
59,8cm x 33,6cm (68,5cm diag)
Primary Bus: PCI Express 16x
Primary VRAM: 2048 MB
Supported MSAA Modes: 2x 4x 8x 16x
Sound card:
Audio device: SigmaTel STAC9750,51
Memory:
RAM: 32128 Mb
Miscellaneous:
UI Language: English
LANG: en_US.UTF-8
Microphone: Not set
Steam Controller Cable and Base: Not set
Total Hard Disk Space Available: 49086 Mb
Largest Free Hard Disk Block: 25811 Mb
VR Headset: None detected
Recent Failure Reports:
Mon Oct 17 22:44:58 2016 GMT: file ''/tmp/dumps/crash_20161018004457_17.dmp'', upload yes: ''CrashID=bp-9ddacb3e-8db0-4a6b-9d6f-79d402161017''
Mon Oct 17 22:52:02 2016 GMT: file ''/tmp/dumps/crash_20161018005201_17.dmp'', upload yes: ''CrashID=bp-671d9479-e285-4fa1-8375-a9a9e2161017''
Non-Ext filesystems are currently unsupported, so that would explain your issue. Lacent, what type of filesystem are you using on this Ubuntu distro?
How would a non supported file system that always worked be an explanation for anything? I've been using steam for linux for quite some time now.
Non-Ext filesystems are currently unsupported, so that would explain your issue. Lacent, what type of filesystem are you using on this Ubuntu distro?
Both my SSD and Storage drive are formatted in ext
The question is... how does the steam client register a corrupted file? What would that look like. I mean "autobuy.txt" should be unreadable... garbled if it was corrupted. Might that be an UTF8 issue? It's all clear text files that ought to be corrupted regarding to steam?
same error F2Fs file system
Related to #4660.
I don't think it's related, as that issue said he could download the whole game, just not install. This seems to be a downloading issue.
I can confirm in my case that switching to ext4 resolved the issue. My 'corrupt' file was for dota2 located at game/bin/motionmapper.rtf. The file contents were basically a readme and opened and looked totally normal and readable). Interestingly, if I manually copied the files from the downloading/570 folder to their proper place in dota 2's folder, I could play the game just fine by launching dota.sh directly. I played maybe 5-6 games this way over a week or so. Every update required a solid 15 min of copying files though.
I had tried everything to resolve it ranging from changing DLCs (Vulkan and beta), changing DL servers, deleting files, etc. and nothing worked.
Once I made an ext4 partition and added it to steam as a library location, I could download and install Dota 2 to it just fine.
Stupidly, I have been running steam and Dota 2 nearly since their release on Linux and have never had an issue with any my other games like this before. Suddenly, TF2, Payday 2, CS:GO and Dota 2 all started getting corrupt download errors around the same time. I haven't looked into the other games having the issue yet, but I suspect that they are having the exact same issue.
In my case, I am running Arch Linux w/ my filesystem being ZFS.
Computer Information:
Manufacturer: Unknown
Model: Unknown
Form Factor: Desktop
No Touch Input Detected
Processor Information:
CPU Vendor: AuthenticAMD
CPU Brand: AMD FX(tm)-9370 Eight-Core Processor
CPU Family: 0x15
CPU Model: 0x2
CPU Stepping: 0x0
CPU Type: 0x0
Speed: 4414 Mhz
8 logical processors
4 physical processors
HyperThreading: Supported
FCMOV: Supported
SSE2: Supported
SSE3: Supported
SSSE3: Supported
SSE4a: Supported
SSE41: Supported
SSE42: Supported
AES: Supported
AVX: Supported
CMPXCHG16B: Supported
LAHF/SAHF: Supported
PrefetchW: Unsupported
Network Information:
Network Speed:
Operating System Version:
"Arch Linux" (64 bit)
Kernel Name: Linux
Kernel Version: 4.7.6-1-ARCH
X Server Vendor: The X.Org Foundation
X Server Release: 11804000
X Window Manager: GNOME Shell
Steam Runtime Version:
Video Card:
Driver: X.Org Gallium 0.4 on AMD HAWAII (DRM 2.45.0 / 4.7.6-1-ARCH, LLVM 3.8.1)
Driver Version: 3.0 Mesa 12.0.3
OpenGL Version: 3.0
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 144 Hz
VendorID: 0x1002
DeviceID: 0x67b1
Revision Not Detected
Number of Monitors: 2
Number of Logical Video Cards: 1
Primary Display Resolution: 1920 x 1080
Desktop Resolution: 3840 x 1080
Primary Display Size: 20.91" x 11.73" (23.94" diag)
53.1cm x 29.8cm (60.8cm diag)
Primary VRAM: 4096 MB
Sound card:
Audio device: Realtek ALC898
Memory:
RAM: 24077 Mb
Miscellaneous:
UI Language: English
LANG: en_US.UTF-8
Microphone: Not set
Steam Controller Cable and Base: Not set
Total Hard Disk Space Available: 3955645 Mb
Largest Free Hard Disk Block: 2875215 Mb
VR Headset: None detected
Recent Failure Reports:
Sun Oct 9 18:58:34 2016 GMT: file ''/tmp/dumps/assert_20161009115833_31.dmp'', upload yes: ''CrashID=bp-32d44a00-2573-4636-8e46-ac2e02161009''
Sun Oct 9 19:33:43 2016 GMT: file ''/tmp/dumps/crash_20161009123342_58.dmp'', upload yes: ''CrashID=bp-09aad3d9-0856-42c0-a128-ad27c2161009''
Wed Oct 12 00:14:18 2016 GMT: file ''/tmp/dumps/assert_20161011171417_69.dmp'', upload yes: ''CrashID=bp-45a11503-ffde-4a83-9497-7f2be2161011''
Sat Oct 15 05:12:43 2016 GMT: file ''/tmp/dumps/crash_20161014221241_106.dmp'', upload yes: ''CrashID=bp-39a93e2b-67f1-4c06-8b2c-e3b7b2161014''
Wed Oct 19 01:06:26 2016 GMT: file ''/tmp/dumps/crash_20161018180624_85.dmp'', upload yes: ''CrashID=bp-cc516c9e-8e52-41c3-a2ae-4c9a02161018''
Wed Oct 19 01:55:27 2016 GMT: file ''/tmp/dumps/assert_20161018185526_115.dmp'', upload yes: ''CrashID=bp-e68541e2-f736-4de1-90ad-44bbc2161018''
My exact steps taken:
Uninstall Dota 2 via client
Removed left over 'dota 2 beta' folder in steamapps/common
run shell commands:
sudo zfs create -V 1000gb ultron/steam-ext4
sudo mkfs.ext4 /dev/zvol/ultron/steam-ext4
mkdir ~/.steam-ext4
sudo mount /dev/zvol/ultron/steam-ext4 ~/.steam-ext4/
sudo chown $USER:$USER .steam-ext4/
Via Steam:
Added new SteamApps folder, set as a new library location
Installed Dota 2 to new library location
Was using Steam on ZFS for a while now, but last week it started to fail while updating TF2, CS:GO and Dota2. Corrupt Update Files.... But all my other games still update properly.
Processor Information:
CPU Vendor: GenuineIntel
CPU Brand: Intel(R) Core(TM) i7-5930K CPU @ 3.50GHz
CPU Family: 0x6
CPU Model: 0x3f
CPU Stepping: 0x2
CPU Type: 0x0
Speed: 3700 Mhz
12 logical processors
6 physical processors
HyperThreading: Supported
FCMOV: Supported
SSE2: Supported
SSE3: Supported
SSSE3: Supported
SSE4a: Unsupported
SSE41: Supported
SSE42: Supported
AES: Supported
AVX: Supported
CMPXCHG16B: Supported
LAHF/SAHF: Supported
PrefetchW: Unsupported
Network Information:
Network Speed:
Operating System Version:
Ubuntu 16.04.1 LTS (64 bit)
Kernel Name: Linux
Kernel Version: 4.4.0-44-generic
X Server Vendor: The X.Org Foundation
X Server Release: 11804000
X Window Manager: Compiz
Steam Runtime Version: steam-runtime-beta-release_2016-09-02
Video Card:
Driver: NVIDIA Corporation GeForce GTX TITAN X/PCIe/SSE2
Driver Version: 4.5.0 NVIDIA 370.28
OpenGL Version: 4.5
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 60 Hz
VendorID: 0x10de
DeviceID: 0x17c2
Revision Not Detected
Number of Monitors: 4
Number of Logical Video Cards: 1
Primary Display Resolution: 1920 x 1080
Desktop Resolution: 5280 x 2160
Primary Display Size: 20.47" x 11.42" (23.43" diag)
52.0cm x 29.0cm (59.5cm diag)
Primary Bus: PCI Express 16x
Primary VRAM: 12288 MB
Supported MSAA Modes: 2x 4x 8x 16x
Sound card:
Audio device: Realtek ALC1150
Memory:
RAM: 64342 Mb
Miscellaneous:
UI Language: English
LANG: en_CA.UTF-8
Microphone: Not set
Steam Controller Cable and Base: Not set
Total Hard Disk Space Available: 330394 Mb
Largest Free Hard Disk Block: 136851 Mb
Experiencing the same issue, CS:GO on SSD with F2FS (Arch Linux).
depotreconstruct.cpp (490) : Assertion Failed: pInfo->nNumWritesFinished > 0
Assert( Assertion Failed: pInfo->nNumWritesFinished > 0 ):depotreconstruct.cpp:490
ZFS (Linux) has been working fine for well over a year. What changed in the CFileReader? Error here is:
../tier1/fileio.cpp (3897) : Assertion Failed: CFileReader::Read must be called with a cubData value that is a multiple of the sector size when using unbuffered IO
ZFS "sector" size is actually record size in this case which would be 128k vs the 512/4096b normally seen in EXT FS'. Why not map file extents in bytes as intended by the OS?
@Plagman does this mean EWONTFIX?
It clearly is an issue with the file system. I've replaced F2FS with ext4 and games are working again. This is a major regression imho.
We're looking into solutions; in general EXT3/4 are our primary testing focus so it's possible this will regress again in the future, but we'll try to make the code more resilient to different filesystem behaviors.
Maybe a dumb question, but why does the filesystem type have any consequences here at all? It's just a container and Steam shouldn't even be aware of it. Are you writing your own file handling routines, and if so, why?
Steam does quite a bit of IO; it could chose to not be aware of the underlying filesystem's caching behavior, but it would probably be slower to patch a 60GB game that way.
I guess I understand that, but it does have me a bit concerned. As a customer and user, I'm worried that all this patching and stitching going on now to keep things running is going to all fall apart sometime in the future. Perhaps it's time to consider containerizing or vertualizing the current Steam client to freeze it, and start working on a new system for future games. I, for one, wouldn't mind having two Steam clients, one for legacy (current, as of now) games, and another, better, faster, easier for you guys to maintain, client.
I know this isn't the place for this conversation, I'm just venting Steam... ;/
Pretty sure the file system isn't at fault when software atop it starts making assumptions about sector sizing... @devs, any chance whatever change was made to hit that assert could be rolled back?
Sounds like the ideal resolution to this would be to use the micro-optimized IO method, but if it fails log a warning once, mark the storage directory as fast-path incompatible, and fail-over to a low compexity, easy to maintain IO method for the rest of the running session. Steam does not need to remember between times being run. Relatively slower is definitely better than dead.
@Tele42: agreed, the reasons for the fast-path failure are likely to be lower level optimizations anyway, and we're not likely to IO-starve a game engine, this isn't RTC after all :-).
I mean, detecting which filesystem is in use is fairly trivial (statfs(2)), no need to detect failure (that approach would be nice for people who have some directories are on different filesystems (linked with symlinks), but miniscule ammount of people do that).
Just supporting ext4 (and presumably btrfs since these people are not complaining) sucks imo.
I do have Steam installed on my ext4 formatted SSD and symlinked the steamapps folder to a folder in my ZFS pool....
I have the same problem with ZFS on /home.
Moving ~/.steam to the ext4 filesystem on top of zvol has solved this issue for me.
I'm on F2FS and CS:GO an TF2 can't be installed.
Linux lazur 4.8.4-desktop-1omv #1 SMP PREEMPT Sun Oct 23 18:43:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
Please fix it soon.
My 200 MB Dota 2 update is taking forever, it will go into queued after long idle ...
UPDATE
I Opt out from beta and now my downloading are working as normal.
After today's beta update (31-0ct) i have now this error on all games which are downloading: Error writing to disk.
I'm still on F2FS file system.
So I just got the update today and in the update notes, it specifically called out fixing ZFS related issues.
I can confirm it does not fix anything and actually seems to have made the problem significantly worse as now I can no longer update or install any games, including the ones I installed to my ext4 partition that sits on top of ZFS. Every time I attempt to update or install any game (even if that install is on my ext4 partition), I get a 'Disk Write Error' on the Downloads page.
EDIT: This appears to be an intermittent issue (although still very common, ie 90% of the time it fails with disk write error, 10% of the time, it succeeds). If I keep attempting to update/install, it will eventually complete without error.
With the 2016-11-01 steam beta client update, I am seeing:
clientjobupdatedepots.cpp (622) : Assertion Failed: m_uIOCurrentCacheSize == 0
Assert( Assertion Failed: m_uIOCurrentCacheSize == 0 ):clientjobupdatedepots.cpp:622
in the stdout log while steam is attempting to update Dota 2 on ext4.
Saying "but it would probably be slower to patch a 60GB game" is a bit vague. Is it really so much slower that it's worth fiddling around with filesystem details ?
We're working on fixing the more general regression; if you need to update or download games you can either temporarily opt-out of the Beta or keep requeuing the download until it succeeds.
Finally some useful workaround, why haven't you just said "opt out of beta" in first place (two weeks ago).
The general regression issue only surfaced in the Beta yesterday and is different from the ZFS/F2FS issue. That issue was in the main client, but if now fixed in the Beta. Opting out of the Beta is most likely going to re-introduce the issue for you if you're using a non-ext filesystem
This should be fixed in the current beta client
I have the same issue with the actual stable client
but with NTFS and the library ntfs-3g.
I will move csgo to the ext4 partition and then i will check if it works.
output of content_log.txt:
AppID 730 update canceled : Corrupt staging file "csgo\autobuy.txt" size 1433/1433, first corrupt chunk at 0 (1433 bytes), total 1 (Read Error) (Download corrupt) "/mnt/Datos/Steam/Linux/steamapps/downloading/730/csgo/autobuy.txt"
Steam client version Jan 19 2017
Distribution Gentoo x64
Opted into Steam client beta?: No
Have you checked for system updates?: Yes
Edited:
moving the game from NTFS to EXT4 solve the problem.
(i would like to have my game in any file system anyway)
Thanks for your product :+1:
Hello @mercuriete, the current NTFS compatibility issue is being tracked at #4800.
@kisak-valve sorry for spam this closed ticket and thanks for your quick answer.
Nice product :+1:
Solution in issue from @kisak-valve solve problem with NTFS! The problem was in disk mount setting.
Nothing extracted yet.
System info:
Intel Core i5 3.1GHz
8gb RAM
GeForce GTX 760/PCIe/SSE2
128gb SSD boot drive, 2TB HDD storage
After a fresh install of both Ubuntu and Steam, whenever I try to install any game, it stops downloading after a minute and gives an error that the download is corrupt. Sometimes it stops downloading and has no error, but schedules the download for another time. I have opened steam in a terminal to see if it shows anything useful when the download stops, and this is all it shows:
Here are the things I've tried to fix this issue:
Steps for reproducing this issue: