It seems that you're using an outdated browser. Some things may not work as they should (or don't work at all).
We suggest you upgrade newer and better browser like: Chrome, Firefox, Internet Explorer or Opera

×
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'.
This looks very fishy:

getcwd("/opt/games/grim_fandango/game/bin", 255) = 34
openat(AT_FDCWD, "/opt/games/grim_fandango/game/bin", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 14
getdents(14, 0xc60207c, 32768) = -1 EOVERFLOW (Value too large for defined data type)
close(14) = 0
openat(AT_FDCWD, "/opt/games/grim_fandango/game/bin", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = 14
getdents(14, 0xc60207c, 32768) = -1 EOVERFLOW (Value too large for defined data type)
close(14) = 0
open("_system.lua", O_RDONLY) = -1 ENOENT (No such file or directory)

At the first glance it looks like they have integer overflow there. 32 bit mess.

I'll test running it on a small virtual partition to confirm.
Post edited January 27, 2015 by shmerl
avatar
shmerl: This looks very fishy:
Did you check the note about Linux installations in the minimum requirements specifications?
Maybe it has something to do with that?
Quoted here:

Minimum system requirements - Linux:
Ubuntu 14.04 / Mint 17
Processor: Intel® Core™ 2 Duo 2.4 GHz, AMD Athlon™ X2 2.8 GHz, or higher
Memory: 4 GB RAM
Graphics: ATI Radeon HD 4650 / NVIDIA GeForce GT 220 / Intel HD 4000 Graphics
Hard Drive: 6 GB available space
Additional Notes: GPU that supports OpenGL 3.3 or higher


Linux ATI/AMD Compatibility Notice: Grim Fandango REQUIRES the proprietary ATI/AMD graphic drivers. Open source ATI/AMD drivers are NOT supported.

Requires the following packages to be installed: libc6:i386, libasound2:i386, libasound2-data:i386, libasound2-plugins:i386 and dependencies.

Notice: this game comes with a 32-bit binary only
Also from the known issues thread over on Steam:

* If you are on a 64-bit machine, run this command in Terminal to get some missing 32-bit files: sudo apt-get install libglu1-mesa:i386

* If you are on an AMD card, do not use the open source drivers. Those do not work for running Grim Fandango Remastered.
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.
Post edited January 28, 2015 by shmerl
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.
avatar
PraetorianWolfie: I put it here just to clarify that the bug that shmerl found is not a general issue with the Linux build.
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.
Post edited January 27, 2015 by isolationism
avatar
isolationism: 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/
avatar
PraetorianWolfie: I put it here just to clarify that the bug that shmerl found is not a general issue with the Linux build.
avatar
shmerl: 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.
Not a multiterrabyte one, for sure. It is somewhere about 100 GB.
avatar
shmerl: I reported the bug here: http://www.doublefine.com/forums/viewthread/16251/
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!
avatar
Stoikheion: 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.
Post edited January 28, 2015 by shmerl
avatar
shmerl: 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.
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.