Trying to run the VoVT Lutris install Script will cause it to get stuck at the extraction step of the 7zip archive while the logs are getting spammed with lutris[753082]: 2025-11-01 16:24:19,958: Starting Lutris 0.5.19 as well as the available gpu's. This will keep going without any progress beeing made until the user manually stops the process. Reproducible: Always Steps to Reproduce: 1.Search Voices of the Void lutris script in lutris 2.go trough the prompts to install Voices of the Void 3.When you reach the extraction step of the archive check logs and wait no progress will be made Actual Results: Installer will be stuck at the extraction step with no indication that it has even started to extract the files from the archive. Expected Results: Extraction step should go for about a minute or 2 and then move on the the setup of the wine prefix Modified: Extra Details: This issue only happens in the fedora native package the flatpak works fine.
Hi aspacegamer, Thanks for the report. This seems to be an upstream issue, probably with the script for voices of the void. Please file your bug report there, we cannot fix this.
(In reply to Chris King from comment #1) > Hi aspacegamer, > > Thanks for the report. This seems to be an upstream issue, probably with the > script for voices of the void. > > Please file your bug report there, we cannot fix this. Sorry i have forgotten to mention in the inital bugreport that this issue only appears in the native lutris package in the fedora repository not in the flatpak version of lutris.
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')
(In reply to Sebastian Keller from comment #3) > 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') that worked yeah
(In reply to Sebastian Keller from comment #3) > 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') tbh this sound like something that probably should be fixed upstream sadly upstream has locked their issue tracker down to only contributors. After all it shouldn't effect the lutris client with older python version to just set the methode to fork since thats the default there anyways.
(In reply to aspacegamer from comment #5) > (In reply to Sebastian Keller from comment #3) > > 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') > > tbh this sound like something that probably should be fixed upstream sadly > upstream has locked their issue tracker down to only contributors. > After all it shouldn't effect the lutris client with older python version to > just set the methode to fork since thats the default there anyways. nevermind i was now able to open the issue https://github.com/lutris/lutris/issues/6213
(In reply to Sebastian Keller from comment #3) > 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') Change has been merged in upstream https://github.com/lutris/lutris/commit/4cef2407288fd0219eba684c7b24451eeaf35fef
It would still be good to have a downstream backport of the fix.
I pushed the fix to rawhide, but it's super late for me. I'll push it to F43/F42 tomorrow and link this bug.
(In reply to Steve Cossette from comment #9) > I pushed the fix to rawhide, but it's super late for me. I'll push it to > F43/F42 tomorrow and link this bug. Sorry to bother you about this i kinda forgot but looking back it seems that the fix is still just available on rawhide.
Hi. I am experiencing this issue for some installation scripts in Fedora 43 as well. Lutris discord chat is also actively directing Fedora users to a forum thread where people are directly patching /usr/bin/lutris with the 'fork' mode upstream commit linked to in comment 7: https://forums.lutris.net/t/errno-104-connection-reset-by-peer/25137 I think a F43 release is therefore warranted. I can test out a build but need some guidance on how to use bodhi. Thanks!
FEDORA-2026-9a4812b83f (lutris-0.5.19-9.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-9a4812b83f
FEDORA-2026-d64bfbcd74 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-d64bfbcd74` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-d64bfbcd74 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-d64bfbcd74 (lutris-0.5.20-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.