[0.16.16] Linux 'There is no package core in /usr/share/...'

[GodricSeer]

I auto-updated to 0.16.16, and factorio has failed to start since then. I also tried a fresh tar download.

Whenever I try to run factorio I get the error:

Code: Select all

   0.000  Error Util.cpp:49: There is no package core in /usr/share/factorio

------------- Error -------------
There is no package core in /usr/share/factorio
---------------------------------
   0.000  Goodbye

I have uncompressed the game into ~/games/factorio, so it should be looking at ~/games/factorio/data for the core package. Note that in config/config.ini in the directory that I auto-updated there are the lines:

Code: Select all

[path]
read-data=__PATH__executable__/../../data
write-data=__PATH__executable__/../..

so factorio should be looking in the correct location.

In the newly downloaded tar the config-path.cfg is such that it should generate config/config.ini, but it does not even get to this step and no config is generate.

[Oxyd]

Is ~/games/factorio or ~/games a symlink to some other directory or is it mounted on some other filesystem than ~ is? Or anything else that might affect the game's paths?

[GodricSeer]

No, my entire home directory is all on the same file system and ~/games/factorio is simply the location where I unzipped the downloaded tar, no symlinks involved. I am running factorio through a script that contains the commands from viewtopic.php?f=23&t=54654 because I am on RHEL 7.3, but that shouldn't affect it's handling of the config path.

[GodricSeer]

I just created a symlink /usr/share/factorio -> ~/games/factorio/data, which allowed the game to boot up, but it failed to find the mods I had installed, my login for updates or modes, or my saved games, since by default the read and write directories are different. As a work around, it would be okay, but it would seriously make a mess of the install directory.

[Oxyd]

It does affect its handling of the config path, because now the executable you're running is /opt/glibc-2.18/lib/ld-linux-x86-64.so.2 instead of factorio. Factorio calls `readlink /proc/self/exe` to determine its location, but in your case that points to /opt/glibc-2.18/lib/ld-linux-x86-64.so.2. And as you can see, the config file makes references to __PATH__executable which, as you've probably guessed, is supposed to be the path to the factorio executable.

Code: Select all

[ivy] ~ % /usr/bin/readlink /proc/self/exe
/usr/bin/readlink
[ivy] ~ % /lib64/ld-linux-x86-64.so.2 /usr/bin/readlink /proc/self/exe
/usr/lib64/ld-2.26.so

For 0.16.17 I've added command-line option --executable-path, so you'll be able to launch Factorio with `/your/custom/ld.so ~/games/factorio/bin/x64/factorio --executable-path /home/GodricSeer/games/factorio/bin/x64/factorio`.

The other option, which you can do now, would be to use patchelf to change the interpreter in the binary instead of overriding it on the command line.

And I guess a third option would be to remove all references to __PATH__executable from the config files and replace them with absolute paths to the executable.

[GodricSeer]

Ah, that makes sense, although why it worked fine in 0.16.15 is now a mystery. I'll change the config to use absolute paths. Thanks.

[HanziQ]

Ah, that makes sense, although why it worked fine in 0.16.15 is now a mystery. I'll change the config to use absolute paths. Thanks.

I think the game used argv[0] on 16.15 and earlier for determining the executable path.

[GodricSeer]

To anyone else who runs into this problem, I had to both change the config.ini file to use absolute paths, and use the -c command line option for factorio to tell it where the config file was.

[FossiFoo]

I think this or the fix for it also broke NixOS. Due to it's immutable structure, it runs steam games in what basically amounts to a chroot with only a more or less complete environment. I will try the exec-path thingy.

Edit1: Did not get it to run. I tried adding the path of lib to LD_LIBRARY_PATH and then ldd shows it correctly, but there seems to be other problems when running the steam version from the commandline. i'll try regression testing and figure out what libraries were linked how in the last working version.

[Zavian]

I think this or the fix for it also broke NixOS. Due to it's immutable structure, it runs steam games in what basically amounts to a chroot with only a more or less complete environment. I will try the exec-path thingy.

THere are a few linux related crashes do to in 0.16.17. There is a fair chance that your problem is related to one of them eg viewtopic.php?f=7&t=56934 viewtopic.php?f=7&t=56922 and viewtopic.php?t=56941 .

[FossiFoo]

Oh, thanks. It certainly seems to be more related to that then. Thanks again. Just saved me a big debugging round .

[mickael9]

Wow, it's impressive how hard it is to just reexecute a program on Linux.
I did suggest using /proc/self/exe instead of using argv because of this: viewtopic.php?f=11&t=53650

There seems to be another way to get the real executable path, using getauxval(AT_EXECFN)

Code: Select all

[mickael:/tmp] % ./aux
/proc/self/exe: /tmp/aux
     AT_EXECFN: ./aux

[mickael:/tmp] % /lib/ld-2.26.so ./aux
/proc/self/exe: /usr/lib/ld-2.26.so
     AT_EXECFN: ./aux

Of course, If you were to just execve that, it would switch back to using the default linker.
It seems that the only way to make this work would be to detect if a custom linker was used in /proc/self/exe and use the executable from getauxval(AT_EXECFN) but that's becoming really complicated.

[Mgis09]

Thanks a lot! This thread saved me.

I was very suprised when factorio faced me with this error:

01-error.png (5.57 KiB) Viewed 7073 times

after some time without playing. And it wouldn't even start. My Steam recently updated my selected 0.17.79 version with quite a few MBs of an update.

So exactly this tip

Ah, that makes sense, although why it worked fine in 0.16.15 is now a mystery. I'll change the config to use absolute paths. Thanks.

Thanks. I was kinda getting close to reconfiguring some config.ini's already...
But now I wonder why is this issue happening? Is this not a bug really?
So then I got the standard warning
Failed to load local achievement data. Local achievements might be lost.
But other than that it's fine.