[BUG] - R2MM won't open on linux (tried using .deb and appimage on latest and second latest release)

[FFFluoride]

Describe the bug
I open r2modman, the window opens. After a couple seconds it closes again. when I ran it in the terminal, it gave the error message:

[10898:0223/000144.125829:FATAL:gpu_data_manager_impl_private.cc(445)] GPU process isn't usable. Goodbye.

To Reproduce
Steps to reproduce the behavior:

1. Install latest release
2. run it on linux (I'm using pop os specifically)
3. Running it in terminal gives you a small log. Running it using the launcher fails silently

Expected behavior
It runs r2modman

[LiamDroog]

Having the same issue on Ubuntu (22.04 jammy)
Appimage dies quietly with no log or output. Installing .deb and running from the CLI gives:

starting server on /tmp/app.r2mm starting TLS server false starting server as Unix || Windows Socket [243248:0222/195403.782001:FATAL:gpu_data_manager_impl_private.cc(445)] GPU process isn't usable. Goodbye. Trace/breakpoint trap (core dumped)

[zackwhit]

From the appimage, try running it with the '--in-process-gpu' argument added in the command line. Worked for me to get it to start when I got the "GPU process isn't usable" error. @FFFluoride

Ubuntu 22.04.

[FFFluoride]

I tried it with the .deb package and it worked thanks.

[Shamamo]

I got the appimage to work with the --no-sandbox argument.

[Aerodin]

I had it start up and close with no error or message showing up. I eventually determined that it was the profile name. In my case I had a profile name with a space in it that wouldn't launch. The same setup with no spaces worked fine.

I'm assuming spaces are not a good thing to have in file path parameters so something to keep in mind. Perhaps R2ModManPlus on Linux should also enforce no spaces in the profile names or some kind of warning this could be an issue.

[BloodyIron]

From the appimage, try running it with the '--in-process-gpu' argument added in the command line. Worked for me to get it to start when I got the "GPU process isn't usable" error. @FFFluoride

Ubuntu 22.04.

Same problem for me on 22.04, this launch flag worked for me for .deb version

[attemptedhippo]

From the appimage, try running it with the '--in-process-gpu' argument added in the command line. Worked for me to get it to start when I got the "GPU process isn't usable" error. @FFFluoride

Ubuntu 22.04.

installed using the .pacman file on manjaro, this worked for me as well

[ebkr]

--no-sandbox (or --in-process-gpu) are required because an older version of Electron is used. Updating Electron would drop support for Windows 7.

[BloodyIron]

And how long is that expected to be that way for?

[ebkr]

I don't really have a timeframe for updating Electron.

As far as I'm aware, these args aren't required for every distro and I don't know why it's only required on some. Could be wayland related, could be GPU related.

Either way, I currently see it as the lesser of two evils given the alternative is locking out a large portion of users. I do plan to update Electron eventually however at the very least it'll be next year.

I'm aware Win 7 is EOL but when I last tried to upgrade it turns out there's quite a few users who still use it.

[BloodyIron]

So you would rather non-Win7 users have a worse experience just so that Windows 7 users need to be supported? Why not make it so that --in-process-gpu be on by default, and Windows 7 users need to run a flag to disable it, or something equivalent? I myself don't use Wayland, I use X11.

[ebkr]

So you would rather non-Win7 users have a worse experience

Well, understandably I’d rather the larger user-base had the better experience. This isn’t reported too frequently and only affects a small portion of Linux users.

So yes, I’m happy for this to remain an issue over dropping Windows 7 support.

Obviously overall I’d rather all platforms had a good experience, but the focus is on where the users primarily are.

I’m not sure how I could provide default commands to be applied to the appimage though.

[BloodyIron]

So you would rather non-Win7 users have a worse experience

Well, understandably I’d rather the larger user-base had the better experience. This isn’t reported too frequently and only affects a small portion of Linux users.

So yes, I’m happy for this to remain an issue over dropping Windows 7 support.

Obviously overall I’d rather all platforms had a good experience, but the focus is on where the users primarily are.

I’m not sure how I could provide default commands to be applied to the appimage though.

I'm not familiar with the best method either, but perhaps an inverse function is in-order whereby "in-process-gpu" is on-by-default, and the launch parameter be replaced with "--not-in-process-gpu" (or something equivalent) for when you want to disable that functionality.

The reason to me this is noteworthy is because as it stands running the application out of the box looks like it just 100% fails. There is zero feedback to the user if you just run it (not from a CLI) and naturally without the launch parameter. So it gives the user the impression that the software just doesn't work at all. Which will probably result in an immediate uninstall/deletion of the software. Users should not be expected to know about this launch parameter for baseline operations of the software.

Again, I'm not necessarily advocating for the dropping of support for any particular group (Win7 or otherwise), more that those that "need" this launch parameter are having such a bad UX that it's effectively a toxic experience. And I'm trying to say useful things that might help you... help us ;)

[Aerodin]

As some have mentioned it is a user design issue. One being no notice and a program that appears to just not work. The other being all users regardless of system should have a smooth experience.

It seems like some detection/load process needs to determine if the fall is needed or just have it run the most common one and watch for an error and try the other flag if the original argument approach fails so everyone gets a loading program they can use. The temporary solution would be to have a graceful fail indicator with an error message in the mean time so at least instead of "Software just doesn't work" some feedback can be provided. If the software can't help the user troubleshoot they won't bother communicating the issue forward or at least their feedback isn't as helpful.

[neilunger]

I am also experiencing this issue. Using the .deb version of R2MM on Pop!_OS 22.04, I had to work around it by using superuser privileges to edit the line Exec=/opt/r2modman/r2modman %U to Exec=/opt/r2modman/r2modman %U --no-sandbox in /usr/share/applications/r2modman.desktop

@ebkr Since Windows 7 users are probably okay with using outdated software (they are on W7 after all...), why not just update Electron and then tell W7 users to download an older release of R2MM? Edit(s): I guess you'd have to either point them to the portable, non-autoupdate version of R2MM, or add an option to R2MM's settings for "update channel" or "disable auto-updates". But that may be a useful feature anyway, as it would address #1037 and/or #405

The Electron updates should have security, performance, and QoL updates that affect Windows 10 and 11 too, they don't just help linux. I'd expect the Electron/Chromium teams to have good reason for deciding to drop W7/8/8.1 support.

Edited for clarity

[MartenBE]

I have this issue also on Fedora 39. W7 is end of life and a big security risk, we shouldn't encourage or endors it ... Forcing the update may even force them off W7 to a safer Windows version or other OS.

[gmes78]

Steam has recently dropped support for Windows 7/8/8.1, so it's probably fine to do so here as well if it's blocking issues like these.

[IAmTheRealGoof]

Following up. Linux Mint 21.2 running 6.5.0-26-generic kernel
Geforce 4060ti with nvidia-driver-535 535.161.07-0ubuntu0.22.04.1 showed this problem, both work arounds listed above worked independently, (--no-sandbox or --in-process-gpu, though I do not know what they mean) Same box running AMD 480 or AMD 6600 did not have this problem.

personally, I would like to see r2modman to work without requiring steam, since steam revoked win xp/7 games from playing.(not cracked, just not required to launch steam, but the game directly)

I mean I can manually mod the game and run games directly but one loses out from the niceties of a mod manager.

[sfjuocekr]

If you are on Wayland try:

GDK_BACKEND=x11 ./r2modman-3.1.50_f3cfa1fcc8651a86e0dd2ff7126ae2fb.AppImage --no-sandbox