Lutris hang when extracting files
I’m on Bazzite deck image most recent stable. Whenever I try to install a game, Bazzite infinitely spins during the extract files stage.
23 Replies
This is happening to me as well, so apparently it's not just on my system. I ran Lutris through the terminal using "Lutris -d", and the debug info shows that it goes into this weird loop when it's stuck on the "extracting --- exe" message:
So I really can't make heads or tails of this on my own.
The difference in my case is that I'm on the KDE desktop version instead of Steam Deck.
Huh, is Lutris trying to run some script in a terminal emulator but since it can't, then it's stuck in a loop?
GitHub
Lutris install scripts are broken in fedora 43 · Issue #6213 · lu...
Bug description After upgrading to fedora 43 i noticed that any install scripts would get stuck during the archive extraction step never actually starting the extraction process to begin with. More...
This might be related to our issue.
There was something important here: https://bugzilla.redhat.com/show_bug.cgi?id=2411739
User Sebastian Keller said:
"I think this is due to Fedora 43 shipping Python 3.14 and this now defaulting to "forkserver" instead of "fork". So this probably does not affect the Flatpak version that would use an older version of Python. Not sure how that's causing the issue though. It looks like all the newly started processes run "LutrisApplication::do_command_line()" and then exit before running the command they were spawned to run. Then the next attempt is started, and so on...
I was able to work around this by adding this code to "/usr/bin/lutris" to force using "fork" again:
import multiprocessing
multiprocessing.set_start_method('fork')"
Unfortunately you can't easily modify that file in Bazzite due to the immutable nature of the system.
But aspacegamer said:
"Change has been merged in upstream
https://github.com/lutris/lutris/commit/4cef2407288fd0219eba684c7b24451eeaf35fef "
GitHub
Force the use of the 'fork' start method on Python 3.14; this isn't...
… thing that should change on us.
Fixes #6213
So apparently it's being fixed ~
One final note, I installed the flatpak version of Lutris just to try installing games on it, and it works. It's using older code apparently.
and here I went calling lutris a piece of crap software again.... I went with Faugus Launcher instead this time
Good to see that it's being fixed. Had the same problem
So when do we expect the update to land for Bazzite? I'm still experiencing this, sadly.
So is anyone else still experiencing this?
Yup, the issue is still around. Dunno when the fix is applied to Bazzite. I'm afraid it will first have to be updated to Fedora 43 in general before it comes to its variants including Bazzite.
It's kinda frustrating because it's such a simple fix :D
Almost makes me consider switching to a non-immutable distro lol
Was kinda hoping it would land already. But yeah, they probably have to fix it at the Fedora level. Which is really unfortunate.
I imagine Bazzite could incorperate the fix, then ditch it once Fedora is updated.
Losing Lutris scripts is a big functionality hit for the distro.
There's nothing to land
Lutris has not been updated in any way in months
Ah, it seems I still misunderstood where the issue was. So the issue is that Fedora 43 was shipped with updated Python, but Lutris is still using old code which creates a conflict with this forkserver/fork thing. So the code in Lutris itself needs to be updated. But I got the impression that it is being updated to Lutris (at some point):
"Change has been merged in upstream
https://github.com/lutris/lutris/commit/4cef2407288fd0219eba684c7b24451eeaf35fef "
GitHub
Force the use of the 'fork' start method on Python 3.14; this isn't...
… thing that should change on us.
Fixes #6213
So, if I understand:
1. Python decided to change its syntax/aliases.
2. This broke a thing in Lutris. It can be fixed by updating the Lutris code, or by individual users (though not in immutable distros).
3. Lutris has already made a commit that fixes this.
4. Bazzite pulls from Lutris. Therefore, the next Bazzite image should fix this for Bazzite users.
What do I have wrong here? I'm still a novice to all of this.
This is what I thought so too! But it seems that it's not guaranteed that Lutris will even get updated even though a commit was made.
Is that commit the only thing required? If so, I can ask about it.
Alternatively... if there were a way to use Lutris flatpak to do installs, but native otherwise, we'd cover a lot of our bases.
I know it's a bit redundant with the integrated version.
Apparently it's updated now! There was an update to Bazzite and an update to Lutris was added as well:
I'll test it immediately.
The install scripts work again! :) I managed to install Unreal Gold "GOG+OldUnreal" but ironically the game didn't run. But I managed to install and run Tomb Raider "GOG+AtiHD" just fine.
It's nice that they implemented the update relatively fast. Just after I think I found a temporary solution. :D
For future reference, you apparently can make temporary changes to immutable files using the terminal command "sudo ostree admin unlock". It's supposed to create a writable overlay that gives you the ability to change immutable files, but the changes are undone at reboot.
I was planning to try it to make the necessary changes to the usr/bin/lutris files and then try installing something, but now I don't need to anymore. 😛
AWESOME!
Looking forward to testing this when I get a chance.
I imagine that if you can do that, you can probably set something in system.d in order to execute those changes on boot, so they will be reinstated each time.
But thankfully unnecessary. Needing to do things like that defeats the entire point of immutable distros.
No, I don't think it defeats the purpose. On the contrary, it's good that you're able to make some temporary changes to test stuff without breaking the system.
But I gotta say, even if executing Lutris install scripts work now, some scripts just aren't functional. 😅
But that's a problem with Lutris instead of Bazzite. I hear more people discussing Bottles these days, though.
Yep, appears resolved now.
Bottles is dead software
No UMU support, no winetricks
And the 2.0 update is both vaporware and changing to a prefix model we refuse to support it it does come out
Avoid it for games
I understand your perspective. That said, I was concerned that it looked like software updates were slowing for Lutris, and it was currently unusable for many things I wanted to use it for. Now that it is updated, that is no longer the case.