Linux-Wine USVFS compatibility thread

[jarrard]

OP Update: Current MO2 via WINE status;

(refer to end thread for current status)

At this point in time MO2 mostly works with wine5/staging5, people will experience odd problems where MO2 will fail to load the VFS+EXE (tools/game) randomly and need to restart MO2.

These issues are likely some odd permissions failure happening with WINE and could even be due to me using NTFS for these games/files.

I intend to upgrade to straight EXT4 partition in the future (waiting on new NVMe) and will be able to test under native conditions then.

NOTE: Some window managers will cause semi-messed up font (ie. XFCE)

The problem

At the moment Mod Organizer 2.1.1 standalone install appears to work find under Wine 3.8 Staging (and other versions) without any need for .net installation, however the usvfs component appears to not mount the files correctly. I can't quite determine whats going wrong but the console seems to suggest the usvfs is at least loading.

Note: V2.1.2 breaks Linux compatibility, as always is a wine bug but that doesn't mean changes made can't be done in a wine friendly manner and still do what they need to do.

Environment

• Mod Organizer Version : 2.1.1
• Desktop OS/version used to run Mod Organizer: Linux Antergos Wine 3.8++

Details

Link to Mod Organizer logs

USVFS

The log files appear to be all empty, I guess it never initialized so doesn't log things.

MO Interface

mo_interface.log

I will try and obtain those log files, no idea where they could have gone too unless its a specific option somewhere?

PS. Fallout4/SkyrimSE give 50-70fps at 4k and high detail under DXVK and wine, its 100% worth getting working under Linux now! (and script extenders work, with patch)

[jarrard]

Alternatively there could be made a option in Mod Organizer to just use direct write method of installing mods into the game directory as a backup.

That would be a temporary solution and help those who might have issues with usvfs under windows also? (some people just can't get it to work, but love everything else).

Perhaps even add a option to specify the direct write folder so someone can then symlink that folder manually themselves?

[Al12rs]

What you are proposing is not really doable. I would be much easier to fix usvfs than to make it possible for Mo to use the data folder directly. It's just un-thinkable. How can you have the single mods and all? You need to create an entire infrastructure etc. Fixing usvfs in comparison only takes the time needed to find out the problem. It's not that there are any obstacles or technical difficulties, we are simply missing the time and manpower to do it. Put simply we need more people to help the project and if we manage to get core functionality to a stable point we can look into expanding, but right now we are struggling and need more help

[jarrard]

Yeah I can understand. As for data folder directly perhaps just a option to copy files to a backup folder would do then it can be handled by the user from there.

For example if you look in the DATA column with the full file-structure, all that can be allowed to be directly copied to some place. (data backup even)

[Al12rs]

I guess that could be achieved with a plugin. A python plug-in would do it too.

[AnyOldName3]

The impression I have is that USVFS used to work under WINE and then it broke when we added compatibility for the 1709 build of Windows 10. That means that the issue is probably just that WINE doesn't implement some internal part of the Win32 API and that the issue can be fixed within WINE more easily than within USVFS.

Other alternatives include someone writing a Unix-friendly VFS from scratch which people could use. That's a huge amount of work, though, and no current MO dev is likely to do it.

[Silarn]

It shouldn't even have to. If it behaved properly and simply allowed the new ntdll hook to fail gracefully, as it does in Windows, there would be no problem.

[jarrard]

Is there a way to get log files from MO2? I have turned on debug mode but I can't seem to find any log files, I'd had assumed it would be in the programs folder but nothing gets generated.

[Al12rs]

Logs can be found in: \logs inside the ModOrganizer folder if you use a portable Instance, or in: appdata\local\modorganizer\<InstanceName>\logs if you have a global instance of MO. From MO2 v2.1.2 you can also open the logs folder from the new "Open folder" menu over the mod-list (Close MO before actually reading the Logs because those are written only after exiting the program).

[jarrard]

Under Linux they can be found in: $PREFIX/drive_c/users/theriddick/Local Settings/Application Data/ModOrganizer/Fallout 4/logs/

Here is what I have. I'll add them to first post.

Can probably do a apitrace, not sure if that will help.

[jarrard]

A. J. Ventor was kind enough to post a good work around and alternative more compatible method.

https://appdb.winehq.org/objectManager.php?sClass=version&iId=36189&iTestingId=100902

This would actually be much more friendly then the current usvfs system.

Some people are still getting dll usvfs errors when trying to run the newer versions of MO2, I don't atm, but Ventor for example can't run 2.1.3 due to it.

EDIT: Actually 2.1.1 still works, I didn't realize that I was running a older version. oops.

[jarrard]

At present in 2.1.3 usvfs gives these errors with wine.

0039:err:module:attach_dlls "usvfs_x64.dll" failed to initialize, aborting 0039:err:module:attach_dlls Initializing dlls for L"C:\Mod Organizer 2\ModOrganizer.exe" failed, status c0000005

However with version 2.1.1 works, but apparently Nexus login is broken in that version. I also can't help but wonder why MO2 needs to load the USVFS system this early at startup and not at launch time.

Trying to trick MO2 by copying older version of files from 2.1.1 into 2.1.3 does not work either, seems it just crashes.

[Silarn]

I could attempt to build it without the ntquerydirectoryfileex just to verify that's what's causing the failure. Though I believe there were a number of other changes to the dll but I'm not sure why they would have caused any breaks.

[jarrard]

Might get lucky, worth a try.

What about taking 2.1.1 build and just changing the nexusmod url from nmm.nexusmods.com to www.nexusmods.com? since that appears to only fail due to a bad url domain name?

[Silarn]

If that is the problem then wine has a bug because the hooking mechanism shouldn't crash the system if the function doesn't exist.

[jarrard]

2.1.2 doesn't work so it might be easier to just compare 211 with 212 for changes and see what is the cause.

I'm looking in the source for v2.1.1 and I found a few references to http://nmm.nexusmods.com, if these were changed to just www.nexusmods.com then it might resolve the problem in v211 of not being able to login to nexus mods website to query data.

Nexus no longer uses nmm url if that isn't obvious enough. Unfortunately I don't know howto build v211 under Linux, I may just need to boot into my windows install to do that and learn the process.

[jarrard]

References to NMM:

/src/nexusinterface.cpp:602: return "http://nmm.nexusmods.com/" + game->gameNexusName().toLower(); /src/nexusinterface.h:309: @param nmmVersion the version of nmm to impersonate /src/nxmaccessmanager.cpp:45: QString const Nexus_Management_URL("http://nmm.nexusmods.com"); /src/settings.h:146: returns the version of nmm to impersonate when connecting to nexus

There are two lines there that could be changed, this may at least allow the Query system to work normally, as for the rest I cannot be sure. But it would be at least an improvement to be able to query update meta information for mods correctly.

Note. There is a long winded discussion over at winehq about resolving this issue for linux users (link 6 above).

I'm now thinking of backporting fixes to v211 and making that work, and being Linux friendly at same time since v211 is the last working version for LINUX.

AT the same time look at substituting in the python symlink script which has Linux considerations such as case sensitivity (yes this would eliminate the need for the usvfs system which I know even windows users have issues with sometimes!!!!).

PS. I'm aware this is how NMM now works, imo its a more compatible method. As for back porting fixes, it's unlikely a newbie like me will get much success here, just thought I play around even if I hit a brick wall early on.

[Al12rs]

Have you talked with the wine guys about the ntQueryDirectoryFileEx function? That one was added in windows 10 build 1803. One of the changes between 2.1.1 and 2.1.2 is that usvfs received support for that new function windows introduced. The fact is that it also had a system in place to make sure that older versions of Windows which did not have the function would not crash. If wine crashes it's a problem they should look at because it works on windows. Also you keep saying people have problems running usvfs but we have reached a point where basically all instances of problems end up being due to Windows or Antivirus blocking files.

[Al12rs]

If Silarn has some time he could try to build a version of usvfs without the ntQueryDirectoryFileEx, if not I can do that maybe this weekend once I get back home.

[jarrard]

Sure, is the ntQueryDirectoryFileEx the only thing that was added that could be the issue?

Anyway I did manage to setup a virtualbox VM with all the development requirements, so at some point I will take a look and see what else I can tinker with. Really its a matter of comparing v211 with 213 and seeing what can be brought over without breaking it for Linux.

Since there is a solution for the vfs using python (v3 atm), usvfs can be disregarded for the most part. I can worry about integration later down the track, not urgent.

[Al12rs]

It would be much much easier to fix 2.1.3 to make it compatible than port over all the changes from 2.1.1 , I mean have you taken a look at the changelogs: https://github.com/Modorganizer2/modorganizer/releases ?

[Al12rs]

Usvfs has been changed a lot from 2.1.1 to today and you want those changes

[jarrard]

True, if v2.1.3 can be made to work, but sounds like that windows 10 update really broke everything.

[Al12rs]

I mean if you want to test you can try simply using the 2.1.1 usvfs over the 2.1.3 build. You will need to take al the usvfs files and overwrite. There was a pretty big change in the system at that time so it might not work

[jarrard]

No, I believe I've tried that a fair bit and it doesn't work. Seems every dll file in 213 is different then 211 to a point they can't just interchange out.

[Al12rs]

Then let's hope @Silarn has some time to build without the ntQDFEx function.

[Al12rs]

@jarrad could you test Mo2.1.3 with these files (overwrite the other ones)? https://mega.nz/#!tOxkxRxY!H0xXMSrHcpUN5XSJ9TB2fV-P1cN4A5zIJYxkxyefyuE Please don't link those externally or upload them somewhere else. Those are the newer type of usvfs but don't contain the ntQDFEx fix.

[jarrard]

Testing now.

I'll give you the full wine debug output. Don't think much has changed unfortunately.

Tested with v213 standalone.

000b:fixme:winediag:start_process Wine Staging 3.8 is a testing version containing experimental patches.
000b:fixme:winediag:start_process Please mention your exact version when filing bug reports on winehq.org.
0014:fixme:wer:WerSetFlags (2) stub!
0014:fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub
001c:fixme:heap:RtlSetHeapInformation 0x240000 0 0x23e830 4 stub
001c:fixme:wer:WerSetFlags (2) stub!
001c:fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub
0039:fixme:kerberos:kerberos_SpInstanceInit 65536,0x7fb378ec37a0,(nil): stub
0039:err:winediag:wined3d_dll_init Setting multithreaded command stream to 0.
0039:fixme:d3d:wined3d_dxtn_init Wine cannot find the txc_dxtn library, DXTn software support unavailable.
0039:fixme:file:RtlDosPathNameToRelativeNtPathName_U_WithStatus Unsupported parameter
0039:err:module:attach_dlls "usvfs_x64.dll" failed to initialize, aborting
0039:err:module:attach_dlls Initializing dlls for L"C:\\Mod Organizer 2\\ModOrganizer.exe" failed, status c0000005

I tried them with v211 and the same error occurred.

[Al12rs]

Do they work over 2.1.1?

[jarrard]

No, same error seems to pop up.

[Al12rs]

Then it's not the ntQueryDirectoryFileEx thing but the changes that erasmux made between 2.1.1 and usvfs beta 5 that made it no longer work.

[jarrard]

Well it could be multiple things for all we know. Shame we can't just pop v211 usvfs into v213.

[Al12rs]

In that case we can't do much more, it works on windows so it should work on Wine as well, if it doesn't it's a bug with wine. If it turns out that it was something that usvfs is doing wrong then let us know but we will not investigate ourselves.

[jarrard]

That's ok, you did your best. Maybe I can find a more detailed way of logging it. If only there was something like apitrace for this.

[Al12rs]

Did you try deleting all the 4 usvfs files in 2.1.3 and replacing them with the 3 usvfs files from 2.1.1?

[Silarn]

Right, the USVFS codebase is separate from the MO codebase. There's no real reason the 2.1.1 files wouldn't be compatible. Though there were a number of fixes to various functions that will be missing, but I guess that's probably okay with you.

[jarrard]

YAY that works, v211 usvfs files on top of v213 works. Nice.

We are getting pretty close to having this python3 symlink script working quite good.

Perhaps at some stage we will be able to inject it in as a replacement solution, making adjustments so it pulls variables from MO2 to do its bidding.

Might need conversion to python2.7 compatibility, not sure how that will go.

[ghost]

I tested the symlink script and it works good. However, it's not really a drop-in replacement. USVFS uses API hooking while the symlink script pollutes the game directory. A real solution would probably use FUSE (this particular implementation is case insensitive, which is convenient for our usecase).

[jarrard]

I was under the impression that FUSE was being used via mhddfs.

Maybe he abandoned that. Will need to check.

UPDATE: Seems FUSE has a performance issue and he wasn't sure about the case handling. Plus renaming of files would still need to occur apparently.

Maybe one day UNVFS will be made compatible. It's a real shame the compliance with windows10 broke Linux support. Pretty sure the vfs use to work once upon a time. (no idea if that version?¿ can be dropped into 213)

[ajventer]

I wrote movfs4l.py. it was only ever intended as a temporary work around until such time as wine supported uvfs again. That said: I wasn't aware of CIOPFS . I went for the symlink approach because mhddfs was causing serious issues. But it's entirely possible that what I had seen as serious performance degradation was actually caused by case sensitivity.

I can create an experimental version using CIOPFS easily. I'll do that tomorrow.

Only need to modify the addvfslayer function and comment out the call to the lowercase renamed.

That said I'm still not sure if it would easily provide a drop in replacement as fuse doesn't run on windows as far as I know. But not modifying the data directory at all would be better even for a work around version I agree.

[ajventer]

One problem will remain. You can't both read from and mount over a directory. So the real Data directory will have to be renamed, a new empty one created and then the mounts can be done, using the real one as the first layer of the mount.

It's also worth noting that the symlink approach is being used by Vortex. That's actually where I got the idea from.

[ajventer]

Okay, so I had a try. CIOPFS lets you create a case insensitive mount. But it doesnt' allow you to layer multiple source directories onto a single mountpoint like mhddfs does.

In theory one could combine the two - but that gets extra tricky because you can now end up with duplicated names before case insensitivity kicks in (so you can't do CIOPFS at the end of the process) - and frankly I haven't been able to figure out a way to do it that won't introduce major issues with the interaction.

Perhaps if somebody can suggest a multilayered FUSE filesystem which is also case insensitive I can pursue this idea further. In the meantime I've committed the experimental code in it's own branch, I'll link it in case somebody wants to play around with it - but I'm stumped.

https://github.com/ajventer/ksp_stuff/blob/ciopfs/movfs4l.py

[Metalhead33]

Not sure if it's a PlayOnLinux issue, but I gave the movfs4l.py a try - along with trying to use 2.1.1 USVFS DLLs together with 2.1.4 or 2.1.3 Mod Organizer, and the result was failure. In fact, overwriting the USVFS files muted the game - no sound at all. And the game doesn't load

Just for the record, here is my Play On Linux shortcut:

!/usr/bin/env playonlinux-bash

[ "$PLAYONLINUX" = "" ] && exit 0 source "$PLAYONLINUX/lib/sources" export WINEPREFIX="/home/metalhead33/.PlayOnLinux/wineprefix/sse" export WINEDEBUG="" cd "/home/metalhead33/.PlayOnLinux/wineprefix/sse/drive_c/./Program Files/ModOrganizer" echo "RUNNING!" python ./movfs4l.py UNVFS POL_Wine ModOrganizer.exe "$@" python ./movfs4l.py echo "EXIT!"

I did in fact modify movfs4l.py to match the proper folders, but still, no results. With or without movfs4l.py , using the old USVFS files just causes the game to be mute and refuse to load. However, using the up-to-date USVFS files causes the game to have sound, to be able to load, but refuse to load the mods at all, meaning that USVFS has failed.

I guess I am going to have to stick with Oldrim for the time being. Stupid Bethesda should have used PhysFS for their games.

EDIT: I tested ModOrganizer 2.1.1, and it does seem to work and probably load the mods... but the game now has no sound at all, and the game just freezes when I go to "New Game".

[Freso]

Another venue that could possibly be looked into is OverlayFS, which Linux has had in-kernel since 3.18 (2014), and is supported for Free and NetBSD. OverlayFS basically "overlays" directories on top of each other, which seems similar in effect to what MO's USVFS is doing (though with different implications, since I think USVFS technically "cherry-picks" files and compiles them together and then presents them as the "new" fs).

[AnyOldName3]

I'm pretty sure I looked into what that could do at one point, and it's not really intended for more than two layers. It's intended for stuff like running Linux off a live CD, so OverlayFS is used to put a writable RAM drive over the read-only CD so you can still use the filesystem.

[Metalhead33]

Absolutely no progress at all:

[jarrard]

Only the USVFS layer doesn't work (it pretends too)., The issue is more related to Wine then MO2 itself and is likely something the wine-staging team can apply a fix for.

I haven't tested USVFS with Wine-staging3.21 or Wine4.0 yet, but I doubt its been resolved.

[neVERberleRfellerER]

@AnyOldName3 OverlayFS works perfectly fine with many layers. I used it for FONV mod managing and it worked with 40 layers without any problems. With simple launcher scripts its possible to handle mod ordering (change of timestamps), such as in https://github.com/neVERberleRfellerER/FalloutNVLinuxLauncher (this is also proof that it works and can be used as temporary Linux alternative to MO2).

[ghost]

@neVERberleRfellerER Thanks for the great tool. I found the README a little confusing so I wrote additional instructions here.

[monyarm]

@neVERberleRfellerER great tool, but question, is there any way to get it to work with mod organizer ? Making it use MO2's mod order rather than one based on the folder names ?

[neVERberleRfellerER]

@monyarm It is not possible in it's current form.

1) MO2 supports decoupled mod load order and ESP/ESM load order (or at least it looks this way - I can drag one mod above another and ESPs are still in original order) which I have no idea how it works. 2) There are case sensitivity issues in pretty much every mod, so you would have to change directory and file names so mod updates wouldn't work, because file conflicts are unresolvable and they would cause silent corruption sooner or later. However, with per directory case-insensitivity support in EXT4 this might be viable, if this works properly with OverlayFS.

If we ignore point 1 and we assume that italic sentencte of point 2 is true, then it should be pretty straightforward - simple code to parse loadorder.txt (which for mods contains names of directories in MO2 mod directory; and parse means cat and grep and sed) and pass paths to these directories as arguments to OverlayFS (e.g. "replace contents of my LOWERDIRS variable" - really, replacing that one line with another shoudl do the trick) is all what is necessary.