Completely lost as to why WINE will not work across envs

[tmrwthumbdown]

So I am completely losing my mind regarding WINE. To preface, I used to use Void Linux with glibc and had wine and wine-32bit alongside mesa-dri-32bit installed, and every single game and launcher I used worked perfectly fine with no issues. I used wine-ge-8.26, and they all worked with this custom version.

Over time, I changed over to Gentoo and enjoyed my stay, so I decided to install wine in musl to see if the new experimental WOW64 mode would allow me to game using musl or, at the very least, a no-multilib installation. I was able to setup everything successfully in Gentoo except wine itself. Upon installing wine in musl, I was unable to get quite literally ANYTHING to work properly. For example, the Rockstar Launcher used to have a memory leak on Linux and required an old version. Over time, they fixed this, and now the actual launcher download from Rockstar themselves works perfectly fine for most. I know this because with wine-ge-8.26 on Void, I was able to launch, install, and play games through it. Furthermore, I installed Skyrim via GOG, and that was another game that worked perfectly fine.

After installing Gentoo on musl, I am unable to get ANYTHING to work as I said previously. I have tried wine-ge-8.26, wine-vanilla, and wine-staging. I've tried all three of these differing WINE versions under musl, nomultilib glibc, and glibc. Under all environments and different WINE versions, I receive the same errors and am unable to successfully launch any games. With this confusion in mind, I decided to go back to Void for some testing, and low and behold, the exact same environment I used with success previously no longer works and, in the same way, returns the same warnings and errors preventing me from gaming on Gentoo. Once again, I tested both musl and multilib glibc on Void and still had no success. I would greatly appreciate any help, as I've read multiple posts of people with extremely similar issues and hope that if this is solved for me, it will also allow others to not experience these issues anymore.

To get into specifics exactly, I have tried both compiling custom kernels and gentoo-kernel-bin, and in both, I used the config options CONFIG_IA32_EMULATION=y, CONFIG_IA32_FEAT_CTL=y, CONFIG_COMPAT_32=y, and CONFIG_COMPAT_32BIT_TIME=y. This does not seem to be a kernel config issue. Furthermore, this does not seem to be a multilib 32bit library issue as under Gentoo, I built the entire system with ABI_X86="64 32" from the initial installation, plus WINE itself and all dependencies required of it, and in Void, I installed the same 64bit and 32bit packages required to play that worked for me previously. I have also tested this across multiple versions of WINE, as stated previously, vanilla, staging, and GE, across versions 8.0, 8.02, 8.26, 9.0, 9.12, 9.13, and 9.14 (and, interestingly, 9.13 and 9.14 won't compile for me on Gentoo, but that's a different topic entirely).

After providing all this pretext, I will now provide the entire logs and errors/warnings I presume to be the issues, and I hope others can help me solve this.

With both RDR2 and Skyrim, and with both the new and old versions of the installer, I become stuck on 'Preparing to install' or with Skyrim, the initial cinematic cutscene will not load, and clicking new game causes an infinite loading screen. This is NOT an issue with wine-ge-8.26 with the old launcher version or any version of Skyrim; however, previously under Void, I was able to install the new version of the installer and all Skyrim versions with no issue. Now, I receive preparing to install and new game forever, and with the logs, I have some confusion. It seems as if, for whatever reason, all 22000 lines of warnings indicate that WINE cannot find and subsequently load any important system libraries. To truncate the entire 22k lines, every single error is the same (c0000034), just with different libraries failing to be found.

[Chiitoo]

I have no experience with musl, but disregarding that, here are some initial thoughts.

Do you get these warnings when running something like 'winecfg' as well?

What does creating a fresh, new prefix look like terminal output-wise?

WINEPREFIX ('$HOME/.wine' by default) should be pointing to the 'root' of a Wine prefix, not a game or any other directory, and when creating a new one, the directory must not exist.
_________________
Kindest of regardses.

[tmrwthumbdown]

Upon creating a brand new, completely fresh prefix via wineboot -i, I receive the same error messages:

[Hu]

What does strace report about the process that prints these error messages? That would show us what paths it is actually passing to the kernel, and what value the kernel returns.

[tmrwthumbdown2]

So after spending a few hours reading over the strace output, I am even more stumped than I was before. I noticed that I was receiving vfat ioctl errors and, over time, narrowed it down to my efi partition. For some reason (I'm assuming maybe a BIOS update???) the behavior of mkfs.fat changed for me. Beforehand, I could do mkfs.fat, and it would always automatically select FAT32; however, for some reason now it automatically selects FAT16, and I was not aware of this. Normally, you shouldn't have to specify it since it automatically determines the best fit for the drive and sector size (mine being 4096); however, since it's now choosing FAT16, obviously something external has changed causing this issue. Regardless, upon trying to set it to FAT32 manually, I received an error I have never seen before, basically saying that there aren't enough clusters to satisfy the filesystem creation and, therefore, would not let me boot off my EFI partition even when it said it was set to FAT32. Now this may sound weird, but for a few reasons I have always chosen to make my EFI partition 10M, and regardless of how silly some may think that is, it has never been a problem for me with a custom kernel. Apparently, to reach the FAT32 required minimum cluster size, I had to set my EFI partition size to not 128M, not 256M, but exactly 257M or higher; otherwise, it would not let me create a FAT32 filesystem properly without the error. I hope to understand and resolve this over time, but as of now, I'm stumped on that end.

So moving forward with my 257M FAT32 EFI partition, I thought that logically, that was the solution, as Windows 10 and up don't support FAT16. However, upon reinstallation of both Gentoo and Void again, I still receive the same issues, now with a different but functionally identical ioctl error (not a TTY). Anyway, I'm still lost and am more confused than I was hours ago. Here is the strace log. I don't doubt you or others here will be able to isolate the issue from the log better than I could.

It seems like the specific call that fails is:

[Chiitoo]

I know nothing about EFI, but what file system are you using Wine itself on? Or rather where the prefix directories live.

I'll look into the strace later, but here's what I was typing before the most recent post.

As a sidey-note, a pastebin with no JavaScript requirement will be preferred by many users around here. :]

[tmrwthumbdown2]

Basically, I have done some more testing and figured out a few things. Basically, I can run 64-bit games, it seems like, as Outer Wilds works perfectly fine on glibc and musl using wine-vanilla on Gentoo. Furthermore, winecfg works perfectly fine yet still shows the same error messages in the output log as any other game. Interestingly, the Rockstar Launcher actually opens up to preparing to install, then freezes, and Skyrim will skip the opening intro cutscene, and I can see the main menu alongside hearing the music; it's just when I click on a new game that it also infinitely loads like the Rockstar Launcher.

Also, here is the wine version information.

[pietinger]

It was a long time ago and it may not help you, but for some (crude) Windows programs it was necessary to activate an option in the kernel that is no longer needed today (for "normal" programs). Check if you have activated this in the kernel:

[tmrwthumbdown2]

Unfortunately, no dice with uselib enabled. At this point I am genuinelly stumped, because, like I said, it was working perfectly fine on Void before switching to Gentoo, and now I can't even get it to work back on Void with (what I assume to be) no changes to my installation or system configuration.

[tmrwthumbdown2]

Sorry, I also forgot to add that I'm using XFS as my root filesystem, with no separate home partition. I've also tested this under ext4 and have still had the same results, along with downgrading my BIOS version to the one I was on when Wine worked and still no luck. I don't want to give up, but at this point I am genuinelly completely and utterly confused as to what could be causing this. It could be that the errors about being unable to find, open, or create files could be caused by something else, but to me it seems as if Wine (or maybe something else causing Wine to have said issues) is having problems with permissions or file r/w/x access for whatever reason.

I also have an interesting update. Gaming works fine via Lutris even though it doesn't detect my 32-bit Vulkan libraries. I guess this may seem like a solution to some; however, I shouldn't have to use Lutris just to use Wine as I had previously.

[Hu]

To pursue this further, I think we need more information. The strace requested above might help (but privatebin fails to render due to JavaScript, so I cannot see it). You could also check mount options, though your latest post makes me doubt that as the explanation.

It might also be helpful if you could reproduce the fault with an open source tool. You said winecfg warns, but works properly. Are there any Wine-native programs, such as winemine, that fail in a way they can be used as a test case?

[Chiitoo]

Sorry, only just now got back to this, and got pretty tired eyes right now... but, I saw in the 'file' trace something that may or may not be relevant:

[tmrwthumbdown2]

Thank you for the recommendation of wgetpaste; I will use that going forward! I read your message about inodes, and that's something I researched previously; however, after having the same issue on ext4, I don't believe that's the issue. It's now clear, given the fact that Lutris actually works, that Wine itself isn't broken, per se, but I firmly believe there is an access issue regarding the required Wine libraries.

I've tested winemine, and while it works, it elicits the exact same result as winecfg does. It works properly yet still warns about missing libraries. I had to make major truncations on the output file to create a paste for it, but the important details should still remain in the first part of the file. http://dpaste.com/A4GP7C92H

[Chiitoo]

Right, forgot the 'ext4' part...

Kind of wondering now what happens if you try to create a new, 32-bit only prefix using WINEARCH="win32"?

Also wondering about

[tmrwthumbdown2]

Unfortunately, same result with Win32 as regular Win64. The failed to resolve your host name IP error isn't related, as I used to see that when Wine worked. I thought that my custom installations of Void and Gentoo could have contributed in some way; however, I recently reinstalled Void using the regular void-installer and still, no dice. I'm going to do some more testing in the mean time, but as of now, still no luck, sadly.

[tmrwthumbdown2]

Alright, so I figured out what the issue was, and it's kind of weird as this never used to be an issue. Apparently the reason Lutris worked and command-line Wine didn't was because in Lutris' launch scripts, they specifically set the working directory to the same directory as the executable and then change into said directory. By simply changing my Wine command from the absolute path, I instead changed into the directory and ran the command with just the exe name instead of the absolute path (i.e., test.exe from inside /home/user/Games/test/drive_c/Program Files/test, NOT /home/user/Games/test/drive_c/Program Files/test/test.exe from /home/user). Regarding the change in usage of desktop files, I simply added the path term to them and set said path to the root exe directory so that way I can have them cd into them and then just run the exe from there, which for some reason allows the exe to access the necessary dll files from its relative path.

I don't know if (and am leaning towards not believing) this has anything to do with it, but from the wine console, the root wineprefix is essentially invisible (i.e., the wineprefix test at /home/user/Games/test is not visible from any directory under Z:\, including it's parent at /home/user/Games).

I've also tested once again, letting Wine create the wineprefix itself with no change in behavior, so I can safely say that isn't the cause of the issue. I guess this is technically solved, although I'd like to learn if this is change is actually an issue on my end or if this requires a bug report to be filed at WineHQ. As I stated previously, Lutris changes into the root exe directory before running the Wine command, and this wasn't an issue a few months ago.

[Chiitoo]

That is somewhat strange.

I think I was going to mention here (or maybe it was some other thread...), that I always recommend to indeed change the work directory to where the executable is, but not because of what is being seen here.

I recommend it because some Windows applications may actually require that due to the differences in how Windows and Linux handle current work directory. I can not remember ever seeing it cause what is being seen here, though, especially if the default "drive Z" link is has not been removed, in which case the prefix indeed should "see" everything under the '/' mount point.

It's entirely possible there is a Wine bug there, and since I picked up the "cd to the exe" habit some ages past, especially since I tend to remove the links to '$HOME' and '/' (mind you, that is still not really sandboxing the processes), I may very well not have seen this new behaviour. I'd think many others would have, however.

In any case, I haven't forgotten this issue and have been wanting to find the time and energy to look into it more, and indeed, will do that hopefully sooner rather than later... and find something helpful!

Thank you for the update!
_________________
Kindest of regardses.

[tmrwthumbdown2]

Of course, and thank you guys for the help. I'm going to keep testing to see if I can find a root cause for this, and if not, I will probably file a bug report just to rule out any issues on my end that could be producing this odd change.

The good news is that this confirms to me that gaming with the new WoW64 mode on Wine does allow for games to be played on both no-multilib glibc and EVEN musl, which in my opinion is huge for people trying to game using a more secure libc implementation. The only roadblock is that you have to make a choice about whether or not you want to play native Linux games that were built against glibc, so this won't be possible for the foreseeable future.

And momentarily after posting this, I did some testing with 'wine start /unix', which does the same thing as the path term in desktop entries, i.e., setting the working directory. Therefore, wine start /unix "/home/user/Games/test/drive_c/Program Files/test/test.exe" does work so long as you use 'wine start /unix' instead of wine. Additionally, starting Wine with a proper Windows C:\ path will work as well. So it's very clearly an issue with the environment only properly being detected from inside the exe's working directory and nowhere else.

I'm further suspecting this to be the root cause of the issue, however.