Nov 5th 2024 update Linux not working w/Valheim : Unable to launch game via a mod manager with mods. #708
Comments
|
@smcv As suggested, new issue opened. |
For easy reference: this appears to be an Arch derivative.
Please assume that I don't know anything about Valheim or this mod manager (I don't currently have access to a copy of Valheim). What modifications does it direct you to make? We cannot really support modded games and third-party tools, especially if they insert arbitrary code into the critical path of launching a particular game. Obviously it would be nice if we can make this work transparently, but we can't guarantee anything. From your system report, it seems that the
but according to the diagnostic tool, the container runtime ends up removing this directory from the search path (because the purpose of the container runtime is to present the game with a more predictable runtime environment, without application-level libraries from the host OS). What libraries exist in that directory? Depending on what's here, this could be overriding a system/container library in ways that could interfere with correct functioning of various components. Or, if it contains libraries that are required by a component that is in |
As a first diagnostic step, please try this:
There are several items of diagnostic information you will be able to get from this. One item is that
Please copy/paste that log line here. And, in If the mod tool redirects stdout/stderr from the actual game to some file, then please look there for output instead. I don't know any specifics of how this mod tool behaves, so I'll have to leave it up to you to find what redirections it does (if any). Another important piece of debugging information is whatever information you can get about the crash, for example a backtrace. Usually the easiest way to collect this is to enable a system-wide core dump collection facility like systemd-coredump, corekeeper, apport or abrt, and let that collect and analyze the crash dump. Please see your distribution's documentation for how to collect backtraces, or if your distribution does not document this, Arch might. If the launch procedure gets far enough to be starting the container, then and I'll need to see all output up to and including the crash, which might look something like this: |
|
As a secondary (less important) thing, after getting details of the original crash, please describe what was involved in your workaround to "trick the script into starting the bin file instead of the wrapper", and then show me the same debug output that I asked for in the previous comment, but with that workaround re-applied. I think that your workaround is actually having a side-effect of making the game not run in the container environment, because this stack trace does not look like the container: If it was running in the container, on a fast-moving rolling-release OS distribution, I would have expected to see |
You are absolutely right, a SteamoOS cousin :).
Basically, when the game is launched from steam, in order to invoke the mod manager a script file is executed, as per: This wrapper analyse the command line and either starts the server or the game with or without mods. linux_wrapper.sh
r2modman, the mod manager, is installed as a flatpak and not a native arch package. All flatpaks are archives mounted as such, and this specific folder contains libraries used by it. I take this moment to thank you for the reply, or should I say replies. I am genuinely surprised, and very happy, by the questions. I will reply diligently to each of them. |
Right, so I have modified the previously mentioned launch options as:
Note I still use the beta version of Steam Soldier to fix the PlayFab problem Here is the long command line, from the console_log.txt file: BepInEx is the key mod that allows for mods in the game, which seems to be refered to as "doorstop". Is is not present when the game is launched as vanilla, even by r2modman. The "profile" is the folder into which there are mods. In R2modman we can define different profiles depending on what mods we want for specifig map/server. Here "Takers_Underworld" server has 93 mods, from which for the sake of speed I only enabled two, BepInExPack_Valheim and MoreGatesExtended, just so there are mods and it does not take minutes to validation before showing the main screen of the game. In both situations, it has the same beharior of crashing at start. I am afraid there is not much content leading to the crash here. This is the full remainder of the log file:
I am not aware of any logs by r2modman, given the fact that scripts actually starts the game and I don't see any redirects.
Hmm I can't find any information about core dumps on my computer. When the game actually launches, there is a crash file in the Valheim folder, multiple if I start and game multiple times, but there are none right now as the process seems to not have reach the game binary being launched, or long enough to create any log. The Player.log file is the previous, vanilla one, it created in my first test before launching with mods, and it has no errors in it. [Update] I am reading about core dump and backtrace right now, will follow through. |
It was simple enough to do. The secondary launch script start_game_bepinex.sh which starts the bepinex by prepending the library tests is the steam wrapper variable is set or not: To trick it, I simple negated the check with a Now with the log output. The command line and rest of the log as it's more or less the same output: What's new here is that the Player.log file from Valheim was populated, and there is a dump file named 'mono_crash.mem.814551.1.blob'
This migh as well be right.. The game itself in this condition could be.. unreliable.. and as such does crash. Thus the main issue would be 'steam-launch-wrapper' crashing without a trace I can find... Any other specific log files are created/stuffed with more content when 'STEAM_LINUX_RUNTIME_VERBOSE=1' is set ? As a former QA analyst and actual functional analyse, I do such for work when bugs arise, but unrelated to games hehe |
|
So the issue here is that you're putting a custom wrapper around the Your top-level wrapper script receives the rest of the command line in the special shell array From your start_game_bepinex.sh:
This is making a big assumption about the structure of the command-line that Steam uses to launch the actual game: it's assuming that if the second argument is Without having done the analysis, I'm 99% sure that this assumption is no longer true: the Steam Linux Runtime 1.0 compatibility tool takes up more items in the command-line than the older legacy runtime. Sorry, if you're going to modify the command-line in-place like this, then it's up to you to figure out how to do it without making assumptions that will go wrong over time. Looking for the main executable by identifying an argument that starts with I see that this script is writing various things to This is also going to do the wrong thing if any of the items on the command-line contain spaces. Shell script is an awful programming language, mostly consisting of sharp edges, and you might find that writing logic in Python using the Similarly, linux_wrapper.sh is not robust against items in I can't provide a complete tutorial on writing robust shell scripts (that would take weeks, if not years) but the tl;dr version is "always use
There's no specific log file as such, the extra information goes to wherever the There is another variable you can set, But if you're bypassing SLR completely (as I suspect you are when you Similarly, if something "outside" SLR is crashing, then we'll never get far enough for that redirection to happen: the crash could well be happening before SLR gets involved, in which case SLR never gets the opportunity to redirect output. |
Hmmm the behavior is: If the 2nd argument is But as it is, this is not executed on my machine,
Sorry, this was not obvious in my previous posts, but this is in fact my log file, I did add those echo redirection lines. R2Valheim.log with the variables was in the last post, but quoted as 'home [log]' I insist, those are not my scripts, they are provided by r2modman 😄
Oh.. I didn't think of that, will add a redirect to check if there are lost outputs.
Ah! I will also enable and check these. [Edit]
True, and as we kinda agreed in a previous post, this is not the way as it's launched out of the container. I did that earlier in hope for this to go farther, but it seems to only mislead the search as it's evaluating the host's libs and bins instead of the container's, resulting in the mono-related crash so I won't do that anymore -- the goal is to fix, and also hopefully understand, |
|
I see you're passing
but you should not add |
|
Yes, quite the misunderstanding from I'll dig some more through the weekend, as whatever I did today didn't give me any new information. |
|
Well.. The most craziest thing is happening.. The [default_old] version of the game actually works out of the container / by bypassing the wrapper. Player.log I was trying to set the game as the server (long story short, a lot of mods even though they have been updated by their modders to the latest version of the game, have issues so we reverted to the last backup and old version the mods while they are being fixed) and I could not get it to work with the wrapper.. So it's been a while since the wrapper stopped working, and it just happened that the newer version of the game has issue with my Linux distro's current libraries.. 🤣 I will remove and reinstall Steam completely because.. that's not normal and you would have a lot of opened issues from linux users if it was a real Steam issue.. I think.. I can't believe only Valheim does not work with the wrapper, but it'S my only native game .. so I can't really test more widely. Will keep this posted. |
|
I'm having the same issue, unable to launch the modded game with Soldier. Starting Steam with After digging through logs and manually logging things inside Soldier's scripts, I found out that this is what Soldier receives: Notice the This is consistently happening for me with every single attempt to run the game with mods. I start the game directly from Steam instead of through r2modman, that's why I have all those arguments in the launch options after I'm using Steam Beta and Soldier beta, and starting game without mods works as expected. |
If some component of this mod manager emits arbitrary strings on standard output ( Components that emit arbitrary diagnostic information should use standard error (
If some component of this mod manager is injecting this |
|
I think I found the problem, I believe it's this line of code that causes the issue. This is where it's called with the string from above. I'll try and build a version with changes to logging and see if that helps. Will report back with results. |
Yes, logging via A side benefit of redirecting that logging to |
|
I found out that BepInEx used for Valheim uses an old version of Doorstop libs for Unix found here. After I removed this line of code, built the lib myself and replaced the one used by BepInEx, the game was launching and loading mods without a problem. |
|
@stele95 there is a pull request dating Nov28 2021 about this file! Thanks for your input, it seems to show that, as I was starting to think, the problem has nothing to do with Steam itself.. But BepInEx is mandatory for mods geez. Are you going to open an issue on the UnityDoorstop git ? Leave a link here, I will hop in. You are better placed than me to do so I think. You found the problem in the code. I'm quite astonished, however, that I could run the game for so long out of the container, with mods, and it would just work! It took the "Bog witch" update to break it. I did not re-try starting Steam with the command line option until now but it still does not fully work. So until the server I play on updates to the latest version, I might be able to play.. |
|
@AngelQC That PR is basically what needs to be done so BepInEx works in the new Steam runtime. If I understand correctly, it wasn't the Bog witch update that broke the game, it's Steam forcing their runtime that exposed a problem that was always there but wasn't detected since games were starting in a different way before. As for the fix, in case you want to do it yourself now, in case BepInEx for Valheim doesn't get updated to a new version anytime soon, here are the steps:
This worked for me and I'm launching Valheim now without any problems and mods that I use work as expected |
Yes, I think so. The container runtime involves more processes during its startup, and is more reliant on |
|
@stele95 thanks for this, I am reviewing the code and building as I write. Worked with a previous version, not the latest. StateWith stele95's lib build solution, I could start the game, modded, but not the latest version. The game, however, now starts within the Soldier container and the game's Player.log file shows path from Steam: And despite the logging command line arguments, I somehow do not have any new Soldier logs since the 15th... what ever means I use to launch the game. Setup: Game v0.219.14 - Small patch after Bog Witch update
Results:
Setup: Game v0.218.21 - Last stable before Bog Witch update
Results:
* Note: r2modman does launch through Steam as well, adding options to the The last error line, which has a hint of relevancy, is |
If you run Steam as You can check this by running the game in a configuration that doesn't crash (for example, without enabling any mods), and looking at the process list with If the game is running in the SLR container, you'll see a
If the game is not running in a SLR container, then you will not get any new SLR logs. SLR logs are only recorded when you run something via SLR. If you are not running the game via a SLR container, then any problems you are still having with the game presumably can't be SLR's fault.
To me, this sounds like one of the mods you are running is not compatible with the new game update. This is out-of-scope for the Steam Runtime: we do not control mods' code or whether they crash the game. |
Wow.. I just realized now what the And suddenly, I have logs now.. Geez.. Ok then lets look at that with a proper Soldier container.. lol
All the previous execution were out of the container, so anything that went wrong then is out of scope I agree. Now I got Soldier logs, so it should be more obvious to the keen eye. Not my eye as I cannot be certain what errors in the log is causing the issue. Some files not loaded are sometime okay/we'll not use the feature, others are more important..
Then pressure-vessel tries to regenerate ld.so.conf and can't process libgpg-error.so.0 from a couple of locations and that's pretty much the end of it.. In the game log, no error regarding the two mods I left, the BepInEx which I rebuild a library for, and CursorSwapper, both for the current game's version with no pending update. |
|
Someone else opened a ticket with BepInEx, the main mods library. Not sure so far where the trouble lies, so I'm trying to monitor both sides.. |
|
The problematic script snippet pointed to here: #708 (comment) can be replaced with this: This still depends on the actual game executable being named |
Your system information
steamapps/common/SteamLinuxRuntime/VERSIONS.txt?steamapps/common/SteamLinuxRuntime_soldier/VERSIONS.txt?steamapps/common/SteamLinuxRuntime_sniper/VERSIONS.txt?Please describe your issue in as much detail as possible:
I have been paying Valheim exclusively on linux, various distributions, since march 2021. I have been using Arcolinux now for close to a year without a hitch. Since the November 5th patch, I have been unable to launch the game with mods through my usual method, r2modman. This is a mod manager for launching Unity-engine games with, or without, mods.
At first the game wasn't launching at all, even vanilla, until this tip was given into another thread, using a newer version of the steam soldier. With this version the game launches without mods, not having PlayFab-related problems anymore.
Then launching the game with any amount of mods will not make it to recreating the player.log file, so I basically do not have a working log to work with.
Being the tech that I am, I digged into the two scripts used by r2modman to launch the game, and saw two different methods/executables
The former crashes without generating the expected Valheim log file,
The later goes further, so I tricked the script into starting the bin file instead of the wrapper and I get the log, which ends with :
..
Here is the full log
Normally, this execution ends with the game screen being shows.
I am still browsing through ~/.steam/steam/log files, trying to find some hints as to what Valheim could leave behind when exiting, no luck so far..
Steps for reproducing this issue:
The text was updated successfully, but these errors were encountered: