Feel free to send any amount of money my way ;P

I honestly doubt GOG still has anything even remotely looking like a Linux team…

---

They do not make WINE wrappers any longer.

then how gog does their versions?

I think there is a misunderstanding here: it is GOG that no longer makes WINE wrappers.

Hi guys,
i've got a problem : bought a game (Pathfinder:Kingmaker) for Linux. Tried to install it on a fresh Kubuntu Studio 20.04. As it didn't work (install crash), i tried on a fresh install of Kubuntu 20.04, Ubuntu 20.04 and Kubuntu 18.04. Same crash.

But my biggest complaint is that i can't contact support for help, because i just can't create the file report as the --sysrep command doesn't work. When i enter ./pathfinder_kingmaker_2_0_8_gog_36208.sh --sysrep, it gives me this answer :

Unrecognized flag : --sysrep
Makeself version 2.2.0 combined with MojoSetup

I have attached a screen capture of that. May someone help me to at least manage to create a report file ?

I've never created such a system report for GOG. But I think you are supposed to run the gog-system-report.sh script in the support folder of the installed game.

Thank you, but where can i find this script ? I've only followed the GOG support page instructions. And i haven't any folder for the installed game because the installer erases everything when it crashes.

Ah, when already the installation of the game fails then I guess you have to send the output of the installer to GOG. You can also post it here, maybe someone has an idea what's going wrong. Perhaps the downloaded file is corrupt, when the installation fails on all your systems.

I think the problem's here, but i have downloaded it a few times. It always crashes when it comes to install files named "something_bundle". Each installer i've downloaded crashes with a specific file. For example, 1st was crashing when installing something like "plainriver_encounters_bundle", but another installer will crash at another file. Is it possible to find the md5 sum of the file somewhere ?

And thanks a lot, your help's greatly appreciated.

Unfortunately md5 sums for the downloadable files are not listed on GOG. You can add your vote for them here. But they can be downloaded from XML files (see edit below). I do not own the game, so I cannot create a checksum, but maybe one of the game owners can create one for you. You also can try to use one of the community downloaders, which use a chunk checksum system to verify the downloaded installers, either lgogdownloader (which might be available from the Ubuntu repository, but I'm not sure as I do not use Ubuntu) or gogrepo.py .

Edit: You also can try to manually download the XML file with checksums (which the downloaders use internally), see this post. The first checksum seems to be the one for the complete file.

I've just tested a demo installer. The installer already verifies the integrity of the archive, as the first step. On the terminal where I've started the installer I get the following log:

$ bash gog_butcher_demo_2.0.0.1.sh
Verifying archive integrity... All good.
Uncompressing Butcher DEMO (GOG.com) 100%
Collecting info for this system...

Don't you get any output on the terminal where you start the installer?

Also you maybe should try to explicitly start the installer with bash, as I did in the above example. The installers declare /bin/sh as the program to run them. But at least some of them fail to execute when your system shell (/bin/sh) is a dash.

I've installed lgogdownloader and i'm downloading the .sh. I will give your batch method a try. Since now, i was just following GOG's instruction (cd to go to installer directory, then ./installer_name) . I don't know the difference between bash and dash....


Edit : you're right, i have verified that the installer checks archive's integrity.

dash is a rather minimal implementation of a bourne shell (sh) and is smaller and faster than bash. That's why it has replaced bash as the default system shell on some distributions. But bash understands more commands. And when the script in an installer uses one of the commands which only bash understands, but wrongly declares /bin/sh instead of /bin/bash for execution, it will fail.

In particular, the switch from bash to dash as /bin/sh greatly sped up boot times, as every time init had to spawn a shell, bash would take a moment to start, whereas dash would not.

bash is still better for interactive use, as it has features like being able to edit the command you're typing (even pressing left doesn't work as expected in dash), tab completion, and command history. Furthermore, I note that the default login shell for ordinary users is still bash, so it still gets used; it's just that it's a bit too slow for boot-up purposes.

If you write a shell script, either test it in dash (and/or "busybox sh", which is also a smaller shell implementation, but I believe isn't as bad as an interactive shell), or explicitly put "#!/bin/bash" (without the quotes) at the top of the script.

Here's an exercise for the reader: What does the following script do when made executable and then executed?

OK, thank you for the explanation (and thanks to @dtgreene too). For the script, i don't really know... Goes to /proc directory and displays the kmem file before exiting ?

But here's the important thing : i've finally managed to install the game, using a weird trick. As said, i have a few installer files because i have downloaded it several times. Each installer has its own crash time. I began the install with one, and when it crashed, i made a copy of every single file installed so when the crashing installer erased them, i could put them back in their directory. Then i run the second installer and told him to never overwrite files. So it installed the files coming after the files installed. Then it crashed, so copy/paste, then run the 1st intaller until it crashes, rinse and repeat until the game's fully installed. And it works !! Had a lot of crashes at the beginning, but setting down the graphics options seemed to make it good.

But it might be the longer install i ever done !

No, it doesn't actually do that.

You see, the first line of the script is
#!/bin/cat

This line of the script is telling the kernel that the script is to be interpreted by the cat program. Therefore, when you try to execute it (via a command like "./script.sh" after setting the executable bit), the kernel will run the cat program on the script, which will just output the script without executing the commands in it.

So, the actual output of this script, when executed, is the same as the script. Or, in other words, the output is and it will exit successfully (despite the "exit 1" command).

Now, if you instead explicitly run it through the shell (like with "bash script.sh"), then it will try to display the /proc/kmem file, and will likely display an error message before ending in failure.