When trying to install a game from lutris with no custom wine runner installed, and just the system one, it fails because it can't find wineboot, so it can't make the prefix. A couple of weeks ago ionen suggested that maybe it initially finds the wine binary with $PATH in /usr/bin and then it looks for all the other wine bits there too, but on gentoo they are not really there. Steps to reproduce: 1. Install wine and lutris 2. Make sure there are no "custom" wine runners installed from lutris itself by going to the "hamburger menu" in the top right > Preferences > Runners > Scroll down to Wine. All of the runners should say "Install" which means they are not installed. 3. Try to install a game in my case "Grand Theft Auto V" using the "Rockstar Games Launcher" script 4. It will end up with OSError('Invaid Wine prefix path /home/your username/Games/grand-theft-auto-v, make sure to create the prefix before saving to a registry') Below is the complete output of lutris -d when ran from the terminal INFO 2023-07-26 10:29:01,091 [startup.init_lutris:209]:Starting Lutris 0.5.13 INFO 2023-07-26 10:29:01,092 [startup.check_driver:73]:Running AMD Mesa driver 23.3.0 on AMD Radeon RX 6800 (navi21, LLVM 16.0.6, DRM 3.52, 6.4.3-gentoo-thp-lto) (0x73bf) INFO 2023-07-26 10:29:01,092 [startup.check_driver:85]:GPU: 1002:73BF 1DA2:E437 (amdgpu drivers) DEBUG 2023-07-26 10:29:01,127 [xrandr._get_vidmodes:16]:Retrieving video modes from XrandR DEBUG 2023-07-26 10:29:01,140 [lutris.get_missing_game_ids:191]:Checking for missing games DEBUG 2023-07-26 10:29:02,904 [application.show_window:339]:Showing window AddGamesWindow{} DEBUG 2023-07-26 10:29:06,864 [http._request:88]:GET https://lutris.net/api/games?search=grand+theft+auto+v&with-installers=True DEBUG 2023-07-26 10:29:10,677 [api.get_game_installers:171]:Fetching installer https://lutris.net/api/installers/grand-theft-auto-v DEBUG 2023-07-26 10:29:10,677 [http._request:88]:GET https://lutris.net/api/installers/grand-theft-auto-v DEBUG 2023-07-26 10:29:11,445 [application.show_window:339]:Showing window InstallerWindowgrand-theft-auto-v DEBUG 2023-07-26 10:29:11,445 [application.on_app_window_destroyed:357]:Removed window AddGamesWindow{} DEBUG 2023-07-26 10:29:14,089 [xrandr._get_vidmodes:16]:Retrieving video modes from XrandR DEBUG 2023-07-26 10:29:14,840 [interpreter.get_runners_to_install:264]:Default wine version is system DEBUG 2023-07-26 10:29:15,546 [downloader.start:67]:⬇ https://gamedownloads.rockstargames.com/public/installer/Rockstar-Games-Launcher.exe DEBUG 2023-07-26 10:29:18,944 [downloader.on_download_completed:170]:Finished downloading https://gamedownloads.rockstargames.com/public/installer/Rockstar-Games-Launcher.exe INFO 2023-07-26 10:29:19,050 [file_box.on_download_complete:239]:Download completed DEBUG 2023-07-26 10:29:19,051 [files_box.on_file_available:108]:launcher is available INFO 2023-07-26 10:29:19,051 [files_box.on_file_available:114]:All files available INFO 2023-07-26 10:29:19,051 [installerwindow.on_files_available:635]:All files are available, continuing install DEBUG 2023-07-26 10:29:19,052 [interpreter.create_game_folder:218]:Creating destination path /home/k/Games/grand-theft-auto-v DEBUG 2023-07-26 10:29:19,052 [interpreter._iter_commands:361]:Installer command: {'task': {'arch': 'win64', 'name': 'create_prefix', 'prefix': '$GAMEDIR'}} INFO 2023-07-26 10:29:19,057 [wine.create_prefix:98]:Creating a win64 prefix in /home/k/Games/grand-theft-auto-v ERROR 2023-07-26 10:29:19,057 [wine.create_prefix:121]:No wineboot executable found in wine, your wine installation is most likely broken DEBUG 2023-07-26 10:29:19,066 [interpreter._iter_commands:361]:Installer command: {'task': {'app': 'corefonts arial vcrun2019 win10', 'arch': 'win64', 'name': 'winetricks', 'prefix': '$GAMEDIR'}} DEBUG 2023-07-26 10:29:19,074 [wine.detect_prefix_arch:89]:Prefix not found: /home/k/Games/grand-theft-auto-v INFO 2023-07-26 10:29:19,074 [wine.create_prefix:98]:Creating a win64 prefix in /home/k/Games/grand-theft-auto-v ERROR 2023-07-26 10:29:19,074 [wine.create_prefix:121]:No wineboot executable found in wine, your wine installation is most likely broken INFO 2023-07-26 10:29:19,077 [wine.use_lutris_runtime:126]:Using system wine version, not using runtime WARNING 2023-07-26 10:29:19,079 [wine.prelaunch:900]:No valid prefix detected in /home/k/Games/grand-theft-auto-v, creating one... INFO 2023-07-26 10:29:19,079 [wine.create_prefix:98]:Creating a win64 prefix in /home/k/Games/grand-theft-auto-v ERROR 2023-07-26 10:29:19,079 [wine.create_prefix:121]:No wineboot executable found in /usr/bin/wine, your wine installation is most likely broken ERROR 2023-07-26 10:29:19,079 [registry.__init__:85]:No registry file at /home/k/Games/grand-theft-auto-v/user.reg ERROR 2023-07-26 10:29:19,079 [jobs.target:36]:Error while completing task <bound method CommandsMixin.task of <interpreter.ScriptInterpreter object at 0x7f0af1371e80 (lutris+installer+interpreter+ScriptInterpreter at 0x5610973c70b0)>>: <class 'OSError'> Invalid Wine prefix path /home/k/Games/grand-theft-auto-v, make sure to create the prefix before saving to a registry File "/usr/lib/python3.11/site-packages/lutris/util/jobs.py", line 34, in target result = self.function(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/lutris/installer/commands.py", line 431, in task command = task(**data) ^^^^^^^^^^^^ File "/usr/lib/python3.11/site-packages/lutris/runners/commands/wine.py", line 379, in winetricks return wineexec( ^^^^^^^^^ File "/usr/lib/python3.11/site-packages/lutris/runners/commands/wine.py", line 309, in wineexec runner.prelaunch() File "/usr/lib/python3.11/site-packages/lutris/runners/wine.py", line 910, in prelaunch self.set_regedit_keys() File "/usr/lib/python3.11/site-packages/lutris/runners/wine.py", line 864, in set_regedit_keys prefix_manager.clear_registry_subkeys(path, key) File "/usr/lib/python3.11/site-packages/lutris/util/wine/prefix.py", line 131, in clear_registry_subkeys registry.save() File "/usr/lib/python3.11/site-packages/lutris/util/wine/registry.py", line 157, in save raise OSError( ERROR 2023-07-26 10:29:19,080 [interpreter._iter_commands:346]:Last install command failed, show error
> No wineboot executable found in /usr/bin/wine, your wine installation is most likely broken does it work if you use /usr/lib/<your wine version>/bin as the wine prefix?
I don't wanna change the permissions outside of my /home folder, and i don't see how that would change the outcome of the prefix creation. My current workaround is changing the Exec= line in the .desktop file of lutris to Exec=env 'PATH=/etc/eselect/wine/bin:$PATH' lutris %U
(In reply to Kostadin Shishmanov from comment #2) > I don't wanna change the permissions outside of my /home folder, and i don't > see how that would change the outcome of the prefix creation. What I meant is to use '/usr/lib/<your wine version>/bin/wine' or '/etc/eselect/wine/bin/wine' as "Custom Wine executable" in the "Configure Wine" window. Sorry, my previous comment was super unclear. > My current > workaround is changing the Exec= line in the .desktop file of lutris to > Exec=env 'PATH=/etc/eselect/wine/bin:$PATH' lutris %U This is something we can probably sed in the ebuild without any unwanted side effects. I'll look into it if the "Custom Wine executable" setting doesn't do the trick.
(In reply to Andrew Ammerlaan from comment #3) > What I meant is to use '/usr/lib/<your wine version>/bin/wine' or > '/etc/eselect/wine/bin/wine' as "Custom Wine executable" in the "Configure > Wine" window. Sorry, my previous comment was super unclear. This seems to have worked? I changed it from the Configure Wine submenu in hamburger menu > Preferences > Runners and setting it there. Now, when installing a game or program that doesn't have a custom "pre-set" wine runner from lutris itself in the installer script, it uses the system one properly. > > My current > > workaround is changing the Exec= line in the .desktop file of lutris to > > Exec=env 'PATH=/etc/eselect/wine/bin:$PATH' lutris %U And.. This was a lie, it doesn't seem to work when setting it in the desktop file, journalctl just reports /usr/bin/env: ‘lutris’: No such file or directory, I think what I actually did was run "PATH=/etc/eselect/wine/bin:$PATH lutris" from the terminal. Sorry for the confusion.
(In reply to Kostadin Shishmanov from comment #4) > (In reply to Andrew Ammerlaan from comment #3) > > What I meant is to use '/usr/lib/<your wine version>/bin/wine' or > > '/etc/eselect/wine/bin/wine' as "Custom Wine executable" in the "Configure > > Wine" window. Sorry, my previous comment was super unclear. > > This seems to have worked? I changed it from the Configure Wine submenu in > hamburger menu > Preferences > Runners and setting it there. Now, when > installing a game or program that doesn't have a custom "pre-set" wine > runner from lutris itself in the installer script, it uses the system one > properly. Great! > > > My current > > > workaround is changing the Exec= line in the .desktop file of lutris to > > > Exec=env 'PATH=/etc/eselect/wine/bin:$PATH' lutris %U > > > And.. This was a lie, it doesn't seem to work when setting it in the desktop > file, journalctl just reports /usr/bin/env: ‘lutris’: No such file or > directory, I think what I actually did was run > "PATH=/etc/eselect/wine/bin:$PATH lutris" from the terminal. Just to double check, is '/etc/eselect/wine/bin' already in your PATH? And this just "fixes" the problem by moving '/etc/eselect/wine/bin' to the front?
Created attachment 866640 [details, diff] Respect eselect-wine patch Does this patch also fix your problem? If this works it is a more elegant solution then sed'ing '/etc/eselect/wine/bin/wine' to the front of PATH.
Created attachment 866641 [details, diff] Respect eselect-wine patch v2 Actually, this only works for the live 9999 version. For version 0.5.13 we need this v2 patch instead. Could you verify that lutris can successfully start the system wine with this patch? What would be even better is if we could somehow make lutris find *all* system wine versions (not just the one we selected with eselect). However, this would require a significantly bigger patch.
I did indeed have /etc/eselect/wine/bin in $PATH and i just moved it to the first option. v1 of the patch does use the system wine runner, but the "System Wine" selection is gone and only "Custom" is listed. On v2, it lists it and is used properly, also verified this with a "fresh install" by removing ~/{.cache,.config,.local/share/lutris}. So, I think it's good regarding it using at least the currently selected version fine.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=362740388ae05b23a50d785ffc37513674a0e7db commit 362740388ae05b23a50d785ffc37513674a0e7db Author: Andrew Ammerlaan <andrewammerlaan@gentoo.org> AuthorDate: 2023-07-29 21:02:38 +0000 Commit: Andrew Ammerlaan <andrewammerlaan@gentoo.org> CommitDate: 2023-07-29 21:02:38 +0000 games-util/lutris: fix use of system wine Bug: https://bugs.gentoo.org/911245 Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org> .../files/lutris-0.5.13-find-eselected-wine.patch | 22 ++++++++++++++++++++++ ...is-0.5.13-r1.ebuild => lutris-0.5.13-r2.ebuild} | 4 ++++ 2 files changed, 26 insertions(+)
(In reply to Kostadin Shishmanov from comment #8) > I did indeed have /etc/eselect/wine/bin in $PATH and i just moved it to the > first option. v1 of the patch does use the system wine runner, but the > "System Wine" selection is gone and only "Custom" is listed. On v2, it lists > it and is used properly, also verified this with a "fresh install" by > removing ~/{.cache,.config,.local/share/lutris}. So, I think it's good > regarding it using at least the currently selected version fine. Awesome, Thanks for testing! @wine team: From the eselect-wine ebuild: # not required, but useful for e.g. binfmt that's not looking in PATH # (not doing this for everything as it gets troublesome to track) dosym -r /etc/eselect/wine/bin/wine /usr/bin/wine This is the root of our problem here, is this something that we could do differently (i.e. either symlink all wine executables or none)? Or move '/etc/eselect/wine/bin/' higher up in PATH so it "overrides" the wine in 'usr/bin'?
(In reply to Andrew Ammerlaan from comment #10) > (In reply to Kostadin Shishmanov from comment #8) > > I did indeed have /etc/eselect/wine/bin in $PATH and i just moved it to the > > first option. v1 of the patch does use the system wine runner, but the > > "System Wine" selection is gone and only "Custom" is listed. On v2, it lists > > it and is used properly, also verified this with a "fresh install" by > > removing ~/{.cache,.config,.local/share/lutris}. So, I think it's good > > regarding it using at least the currently selected version fine. > > Awesome, Thanks for testing! > > @wine team: From the eselect-wine ebuild: > > # not required, but useful for e.g. binfmt that's not looking in PATH > # (not doing this for everything as it gets troublesome to track) > dosym -r /etc/eselect/wine/bin/wine /usr/bin/wine > > This is the root of our problem here, is this something that we could do > differently (i.e. either symlink all wine executables or none)? Or move > '/etc/eselect/wine/bin/' higher up in PATH so it "overrides" the wine in > 'usr/bin'? All would be messy given not the same things get installed depending on USE or wine versions, that would leave either dead or missing symlinks. And ideally do not wont to back to live-modifying /usr/bin, also not overly fond of moving a side PATH to a higher priority either (wouldn't hurt, but being before most other paths would likely look strange to users). Not the first I hear of this, ideally I feel lutris should look for all binaries in PATH rather than assume they are relative to where it happened to find wine. That aside, removing /usr/bin/wine is not out of the question w/ at least postinst elog in eselect-wine to warn about it. Added it so changes would have a lower impact with the assumption it shouldn't cause other issues. Ultimately end design made /etc/eselect/wine/bin/wine a reliable static path (no PATH env-update needed unlike e.g. llvm) that should be usable for binfmt too if configs are updated. So to be clear, removing the file would solve this issue, right? (I never used lutris)
(In reply to Ionen Wolkens from comment #11) > That aside, removing /usr/bin/wine is not out of the question w/ at least > postinst elog in eselect-wine to warn about it. fwiw it has caused problems with other obscure wine "managers", that's why I'm considering it at this point.
(In reply to Ionen Wolkens from comment #11) > So to be clear, removing the file would solve this issue, right? (I never > used lutris) It would, this will make os.find_exec return /etc/eselect/wine/bin/wine instead of /usr/bin/wine. Then lutris can find the other executables it needs in the same directory.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=128b13f15d285daec216c6092bf0eab189743d6d commit 128b13f15d285daec216c6092bf0eab189743d6d Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2023-07-29 21:39:20 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2023-07-30 16:17:04 +0000 app-eselect/eselect-wine: revbump without /usr/bin/wine symlink To ~arch for now in case this end up having unexpected consequences, albeit will not wait all that long. Also adjust messages (both first merge and update from -r0) to advertise the full path if users need it. Closes: https://bugs.gentoo.org/911245 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> .../eselect-wine/eselect-wine-2.0.2-r1.ebuild | 91 ++++++++++++++++++++++ 1 file changed, 91 insertions(+)
(In reply to Andrew Ammerlaan from comment #7) > What would be even better is if we could somehow make lutris find *all* > system wine versions (not just the one we selected with eselect). However, > this would require a significantly bigger patch. Lutris 0.5.14 can now find all installed wine versions in addition to the eselected one. See also: https://github.com/lutris/lutris/pull/4997
