I get such error at startup (up to date Debian testing x86_64):

Running Grim Fandango Remastered
Command line arg: ./GrimFandango
Absolute executable path: /opt/games/grim_fandango/game/bin/GrimFandango
Leaving working directory as: /opt/games/grim_fandango/game/bin
Not found: 'x86/shaders/compiled/deferred_light_v.glsl'
Not found: './Saves/registry.sav'
Unable to find '_system.lua'.

Did you check the note about Linux installations in the minimum requirements specifications?
Maybe it has something to do with that?
Quoted here: Also from the known issues thread over on Steam: http://steamcommunity.com/app/316790/discussions/0/620703493334148904/

I'll try this game myself tonight.
I have smaller ext4 partitions so if your earlier suspicions about large XFS partitions and stuff are correct I shouldn't have that problem. Can't really say anymore than that, it's too deep stuff for me :D

OK, it's exactly like I expected. Large partition problem. Nasty 32 bit stuff.. Their QA really should expect modern hard drives already. I created a small virtual loop XFS partition like this:

mkdir -p ~/tmp/image
cd ~/tmp
dd if=/dev/zero of=loop.img bs=1024k count=6500
mkfs.xfs loop.img
sudo mount -o loop loop.img ~/tmp/image
sudo chown $USER:$USER image

Then copied the game in ~/tmp/image (which placed it into that loop partition) and run it. Game launched just fine. Bug confirmed. I'll report it to Double Fine when they'll enable my account on their forum.

For GOG QA: please make one computer with multiterabyte XFS partition for your tests (or just attach an external hard drive - it will do). It can help you catching such bugs before users are hit by them.

Just adding here that on Linux Mint 17.1 64bit with an AMD HD 7950 (latest proprietary drivers) and ext4 FS, the game seems to launch ok. I went through the first cutscene and a bit of gameplay/ interacting with objects and moving around the office so far. The only issue I have so far seems to be that the game in full screen still leaves a stripe on the left where the desktop is visible (some mis-detection of my resolution in combination with a borderless fullscreen window perhaps? )

This is not the case for shmerl (he mentions that the issue is with the XFS file system -I think).

I put it here just to clarify that the bug that shmerl found is not a general issue with the Linux build.

Seems to work fine for me too.

How large is your ext4 partition? The issue can be general for size larger than certain limit, or it may be XFS specific. I didn't test it with ext4.

Cheers shmerl; I had the same problem and was sent to your post by GOG technical support. Game launches fine using your fix.

Glad it helped as a workaround. I still can't make any posts on the Double Fine support forum, but I'll let them know as soon as they'll enable posting there. Hopefully they'll fix it and GOG will get an updated build.

I reported the bug here: http://www.doublefine.com/forums/viewthread/16251/

Not a multiterrabyte one, for sure. It is somewhere about 100 GB.

I tried reproducing the issue by copying the GOG build onto a 1TB xfs partition I made on a 64-bit Ubuntu 14.04 machine. Unfortunately I couldn't reproduce the crash that you got, so I'm not sure if I'll be able to test a fix very easily.

It sounds like we might just need to recompile our 32-bit binary with the -D_FILE_OFFSET_BITS=64 flag? Unfortunately we can't make a native 64-bit binary at the moment because we ran into numerous crashes in graphics drivers, so the 32-bit build seemed to maximize compatibility.

Otherwise the fix for now would be to use a different partition format, but with more info we might be able to update the build. Do you think the problem might be limited to xfs partitions >= 2TB in size?

Thanks for your help!

There is obviously some size overflow. Unity3D was also bugged by it (see here).

My hard drive is 2 TB, with XFS partition taking most of it (it's 1.9 TB) and this bug happens with that size already. I can run a test on 1 TB XFS partition (I have another hard drive like that) and let you know the result. But if it worked for you I suspect the tipping size is somewhere between 1 and 2 TB. So try testing it at least with 2 TB HDD.

From strace it seems that failures happen with getdents call. So it might be something XFS / 32 bit specific about it. I can look around.

It's interesting that the Unity bug also occurred on a 1.9 TB drive, like yours. Sorry to make you do more testing, but it would be great to hear if it works on a 1TB xfs partition for your OS. If that works for you, then we'll try to get our hands on a 2TB drive to test a fix.