Steam for Linux

Steam for Linux

CodAv Nov 1, 2014 @ 7:49am
Steam on Linux: Many games won't start? Read this!
Dear fellow Linux users,

some of you might have run into the same issue I did: many games, mostly Source and Unity3D games, don't start at all or come up with weird error messages like "file XY not found". It took me some time to sort out the cause of the issue, and I want to share my findings with the community. First of all, if the following aspects fit your system configuration, you'll be most probably affected.

Affected system configuration
  • You're running a 64 bit Linux Distribution with a 32 bit compatibility layer (Multilib/Multiarch)
  • You've got a hard disk with a size of more than 1 TB on the partition you're using for Steam
  • You're using a file system which uses 64 bit inodes (most probably XFS) on that partition

Some affected games
  • Among the Sleep
  • Anna Extended Edition
  • Awesomenauts
  • Counter-Strike Source
  • Crusader Kings II
  • Half Life 2
  • Left4Dead 2
  • Portal 2
  • Sid Meier's Civilization V
  • Team Fortress 2

Solution / Workaround
The most simple and easiest solution to the problem is to install your games on a hard disk using a filesystem which always works with 32 bit inodes, e.g. ext4. You can limit this to non-working games, as 64-bit titles and correctly compiled games are not affected.

Using the "inode64" option to mount XFS will not solve the issue.

Other workarounds are going deeper into your system, telling your kernel to wrap 64 bit inode numbers down to 32 bit, or creating a small extra library which uses the 64 bit filesystem functions, and wraps the return values and structures down to the 32 bit variants, which are injected to the application using the LD_PRELOAD environment variable. These solutions might work, but can cause REAL trouble like overwriting other files in your partition.

The best solution would be to compile the offending application using some special compiler definitions (see technical explanation below), but this is up to the developers, and in case of the Unity3D player, even requires a recompilation of the 3rd party software.

Why is this actually causing my games to crash?
Warning: lengthy technobabble!
In most cases, file system access is abstracted by the system kernel and the operating systems standard C library (glibc on most Linux distributions). So applications don't have to know which file system or what kind of hard drive you're using, they just call a set of functions to read, write or get information about files. Historically, these functions work with 32 bit numeric values, which limits the maximum size of a file which can be accessed to about 4 GB. Some other limits apply, but in most scenarios, these limits are scarcely scratched. But there are some functions which work on files using the filesystem-specifc file number, called "inode". Most UNIX filesystems store inodes with 32 bit numbers, which means you can have up to 4.2 billion files in a single filesystem, which should be enough in most cases. But some filesystems are using these numbers differently, or support very large filesystems up to exabyte ranges where the number of inodes could go above this limit. XFS is one of those, on partitions larger than 1 TB, it uses 64 bit inodes.

If you've got a 32 bit application compiled with no special definitions, the C library IO functions return inode numbers, file offsets and sizes as unsigned 32 bit numbers. If the kernel puts a 64 bit number into some of these values, the data structure will get corrupted, either by overlapping fields (one half of a number filling the next field in the structure) or causing an overflow, the numbers are wrong. Depending on what the application uses these values for, many different errors can occur, e.g.:

  • A file or folder can't be found
  • Creating a new file fails
  • The application might use the file size reported by stat() to allocate memory

To overcome the issue, developers have to use the filesystem-specific types defined in the standard library (size_t, off_t, ino_t etc.), make sure these values are not cast to int or long values, and then provide the two extra glibc macro definitions "_FILE_OFFSET_BITS=64" and "_LARGEFILE64_SOURCE" while compiling each source file.
Last edited by CodAv; Nov 1, 2014 @ 7:55am
< >
Showing 1-5 of 5 comments
all games start normal, so this is a pointless thread.
Zyro Nov 1, 2014 @ 8:19am 
Originally posted by REB Lady From Hell:
all games start normal, so this is a pointless thread.

For everybody or for you?

I didn't yet use partitions that large, so I didn't meet the problem either,
but thanks to the OP for sharing his findings!
CodAv Nov 1, 2014 @ 8:28am 
Originally posted by REB Lady From Hell:
all games start normal, so this is a pointless thread.
Well, for, let's say, more than 99% of all Linux users, this thread is indeed pointless, as the described system configuration is far off from standard, as most distributions use ext4 or btrfs by default, and both aren't using 64 bit inode numbers. But for affected people, this might save a lot of time and frustration. Not everyone reads through Valve's GitHub bugtracker, understanding the quite technical discussions. Even there, it took people several months to sort out the real cause.
Last edited by CodAv; Nov 1, 2014 @ 8:29am
Dusk of Oolacile Nov 1, 2014 @ 8:35am 
Originally posted by CodAv:
the described system configuration is far off from standard
Indeed it is. I think Steam is for the casual gamer. You also can't run games if you set up a very strange Windows configuration.
Zyro Nov 1, 2014 @ 8:39am 
You might mention something in the title like "... for large HDs with unusual file systems" or something along the lines.
< >
Showing 1-5 of 5 comments
Per page: 15 30 50

Date Posted: Nov 1, 2014 @ 7:49am
Posts: 5