Hello! Lutris been working perfectly fine and it won’t launch suddenly. Tried some troubleshoot and it doesn’t work, I’m running it in ubuntu.
This is the messages i got when trying lutris -d
This is happening to me after the latest update to the Vulkan drivers (23.3~git2308290600.639bda~oibaf~j). If I force the drivers back to the previous release, everything works ok. I created a script to run Lutris without the client (lutris -b sc battlenet), then ran the script (./sc) from the command line, and battlenet and starcraft come up fine. So it is the Lutris client itself that has the problem with the latest Vulkan drivers. So I’m guessing that it is the startup.check_driver:77 call causing the problem, or something just after that. I don’t have the Lutris client sourcecode, so I can’t tell what exactly is causing the issue. I’m going to try to change various configuration options in Lutris to see if it is one of those, but that is a lengthy process as I have to keep downgrading the Vulkan drivers on each test to be able to set the Lutris config options. Will see how it goes. Anyone else have a fix?
I might add that this exact thing is happening on three different Linux Mint (latest version) machines (two laptops and a desktop), and I can duplicate everything I said above on all three machines.
For those interested: I’m running Lutris 0.5.12 from the Linux Mint repositories and Linux Mint 21.2 Victoria 64-bit with Kernel Linux 5.15.0-82-generic x86_64 with desktop MATE 1.26.0.
Update: So I obtained the Lutris 0.5.12 source code and ran it using gdb (debugger). The following is the backtrace that I get from the run. It doesn’t show the actual call that is causing the problem because it is in another module, probably the Mesa Vulkan module. I don’t have the Vulkan source code, so not sure I can get any further. And Lutris/Vulkan folks out there?
ThinkPad-T420s:~/Documents/Software/Lutris/lutris-0.5.12$ gdb -ex r --args “/usr/bin/python3” “./bin/lutris”
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04) 12.1
For help, type “help”.
Type “apropos word” to search for commands related to “word”…
Reading symbols from /usr/bin/python3…
(No debugging symbols found in /usr/bin/python3)
Starting program: /usr/bin/python3 ./bin/lutris
[Thread debugging using libthread_db enabled]
Using host libthread_db library “/lib/x86_64-linux-gnu/libthread_db.so.1”.
[New Thread 0x7ffff2d52640 (LWP 16274)]
[New Thread 0x7ffff2551640 (LWP 16275)]
[Detaching after vfork from child process 16276]
[Detaching after vfork from child process 16277]
[Detaching after vfork from child process 16282]
[Detaching after vfork from child process 16283]
[Detaching after vfork from child process 16291]
[Detaching after vfork from child process 16292]
[New Thread 0x7fffebfff640 (LWP 16293)]
2023-08-29 14:52:59,835: Starting Lutris 0.5.12
[Detaching after vfork from child process 16294]
[Detaching after vfork from child process 16295]
2023-08-29 14:53:00,209: Running Intel Mesa driver 294.1.8 on Mesa Intel(R) HD Graphics 3000 (SNB GT2) (0x126)
2023-08-29 14:53:00,210: GPU: 8086:0126 17AA:21D2 (i915 drivers)
Thread 1 “python3” received signal SIGSEGV, Segmentation fault.
0x00007f296170702d in ?? ()
(gdb) bt #0 0x00007f296170702d in ?? () #1 0x00007ffff0008e4c in ?? () from /lib/x86_64-linux-gnu/libVkLayer_MESA_device_select.so #2 0x00007ffff0009687 in ?? () from /lib/x86_64-linux-gnu/libVkLayer_MESA_device_select.so #3 0x00007fffeb7b4765 in ?? () from /lib/x86_64-linux-gnu/libvulkan.so.1 #4 0x00007fffeb7c5592 in vkEnumeratePhysicalDevices () from /lib/x86_64-linux-gnu/libvulkan.so.1 #5 0x00007ffff7455e2e in ?? () from /lib/x86_64-linux-gnu/libffi.so.8 #6 0x00007ffff7452493 in ?? () from /lib/x86_64-linux-gnu/libffi.so.8 #7 0x00007ffff1c3a3e9 in ?? () from /usr/lib/python3.10/lib-dynload/_ctypes.cpython-310-x86_64-linux-gnu.so #8 0x00007ffff1c39a00 in ?? () from /usr/lib/python3.10/lib-dynload/_ctypes.cpython-310-x86_64-linux-gnu.so #9 0x00005555556aa5eb in _PyObject_MakeTpCall () #10 0x00005555556a31f1 in _PyEval_EvalFrameDefault () #11 0x00005555556b470c in _PyFunction_Vectorcall () #12 0x00005555556a28a2 in _PyEval_EvalFrameDefault () #13 0x00005555556b470c in _PyFunction_Vectorcall () #14 0x000055555569ce0d in _PyEval_EvalFrameDefault () #15 0x00005555556b470c in _PyFunction_Vectorcall () #16 0x000055555569ce0d in _PyEval_EvalFrameDefault () #17 0x00005555556b470c in _PyFunction_Vectorcall () #18 0x00007ffff716b54f in ?? () from /usr/lib/python3/dist-packages/gi/_gi.cpython-310-x86_64-linux-gnu.so #19 0x00007ffff74557ec in ?? () from /lib/x86_64-linux-gnu/libffi.so.8 #20 0x00007ffff7456050 in ?? () from /lib/x86_64-linux-gnu/libffi.so.8 #21 0x00007ffff6db1701 in ?? () from /lib/x86_64-linux-gnu/libgio-2.0.so.0 #22 0x00007ffff6fdc700 in g_signal_emit_valist () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #23 0x00007ffff6fdc863 in g_signal_emit () from /lib/x86_64-linux-gnu/libgobject-2.0.so.0 #24 0x00007ffff6e165d3 in ?? () from /lib/x86_64-linux-gnu/libgio-2.0.so.0 #25 0x00007ffff6e18d59 in ?? () from /lib/x86_64-linux-gnu/libgio-2.0.so.0 #26 0x00007ffff6e18f46 in g_application_run () from /lib/x86_64-linux-gnu/libgio-2.0.so.0 #27 0x00007ffff7455e2e in ?? () from /lib/x86_64-linux-gnu/libffi.so.8 #28 0x00007ffff7452493 in ?? () from /lib/x86_64-linux-gnu/libffi.so.8 #29 0x00007ffff7169722 in ?? () from /usr/lib/python3/dist-packages/gi/_gi.cpython-310-x86_64-linux-gnu.so #30 0x00007ffff7167826 in ?? () from /usr/lib/python3/dist-packages/gi/_gi.cpython-310-x86_64-linux-gnu.so #31 0x00005555556c312b in PyObject_Call () #32 0x000055555569f2c1 in _PyEval_EvalFrameDefault () #33 0x00005555556b470c in _PyFunction_Vectorcall () #34 0x000055555569cf52 in _PyEval_EvalFrameDefault () #35 0x000055555578de56 in ?? () #36 0x000055555578dcf6 in PyEval_EvalCode () #37 0x00005555557b87d8 in ?? () #38 0x00005555557b20bb in ?? () #39 0x00005555557b8525 in ?? () #40 0x00005555557b7a08 in _PyRun_SimpleFileObject () #41 0x00005555557b7653 in _PyRun_AnyFileObject () #42 0x00005555557aa41e in Py_RunMain () #43 0x0000555555780cad in Py_BytesMain () #44 0x00007ffff7c67d90 in __libc_start_call_main (main=main@entry=0x555555780c70, argc=argc@entry=2, argv=argv@entry=0x7fffffffdf68) at …/sysdeps/nptl/libc_start_call_main.h:58 #45 0x00007ffff7c67e40 in __libc_start_main_impl (main=0x555555780c70, argc=2, argv=0x7fffffffdf68, init=, fini=, rtld_fini=, stack_end=0x7fffffffdf58) at …/csu/libc-start.c:392 #46 0x0000555555780ba5 in _start ()
(gdb)
I run Mint 21.2-Xfce (with 5.15 kernel) and I have no issues installing Lutris v0.5.12 (from Dec 2022) through the ‘.deb’ file (i.e. Releases · lutris/lutris · GitHub ). but I have a NVIDIA GPU, 1050 Ti 4GB (currently running NVIDIA v525 driver). so I would imagine this is more of a AMD specific issue(?).
you can update to the newest Lutris v0.5.13 (from May 2023) and see if it fairs any better but I have two games (Mafia: Definitive Edition/Mafia III) with major regressions on that version (basically the game is outright not playable), which is why I uninstalled v0.5.13 and went back to v0.5.12 (and the game works well as expected once again). I ‘might’ have found a work-around (by manually installing DXVK etc) if I have to use a newer version of Lutris in the future if v0.5.12 fails to work in the future, but I have not tested it yet.
I’m also running 5.15 kernel. It isn’t the kernel, it is the latest version of the Vulkan drivers that is causing the seg fault. I tried Lutris v0.5.13 and it crashed too. Lutris v0.5.12 is what is coming out of the Mint repositories. What version of the Mesa Vulkan drivers are you using? And how did you “manually” install DXVK?
If you upgrade to 0.5.13 you need to use the GE 8.13 or newer from the lutris wine manager. This ensures that the newer dxvk and vkd3d will launch,
You need to confirm for each game that the Vulkan ICD loader on the System Options tab is correctly set to your gpu (should not be unspecified, auto or default). if the gpu name does not appear, you are missing the vulkan-tools package which you should install.
Unless you are a tester and reporting issues back to Mesa, don’t use oibaf git on Ubuntu. If you are, rollback to a build prior to Aug 21 or switch to 23.1.6 (kisak ppa). Right now there is an issue with git and vulkaninfo leading to a Segmentation fault when vulkaninfo is called (lutris also calls it).
And would recommend seeing if you can use a newer kernel for Ubuntu than the 5.15 - 5.19 or 6.2 (not 6.4 if you are AMD gpu)
Apparently I am not using MESA which probably explains why I don’t have any issues. I think that’s a AMD GPU thing where as NVIDIA does not use it, at least to my knowledge as I ran…
glxinfo | grep -i mesa
and nothing shows up on my Mint 21.2-Xfce system with a NVIDIA 1050 Ti 4GB running NVIDIA v525 driver through Mint’s ‘Driver Manager’.
that’s the general idea on how I can run at least the game I tested there without Lutris installed as normally the game won’t work on stock Wine at all but with that DXVK applied I can run just Wine/DXVK to get it working (although I still prefer Lutris because then I can force FSR 1.0 and a custom res of 1477x831 and is automatically upscaled to my monitors native 1080p(1920x1080) res (‘fullscreen = on’ has to be used otherwise that FSR 1.0 stuff won’t work).
I tried that and it did not fix my issue on Mafia: Definitive Edition etc. but… whatever happened, I was just experimenting a moment ago, when I used PlayOnLinux to create a clean Wine v8.0.2 profile (as my system installed Wine is the newest ‘development’ version, which is currently v8.14) it now works on Lutris v0.5.13 with GE 8.13, then I even reverted to a old 7-28 from Sep 2022 I think, which is what I was using, and that’s fine to. then just to make sure that’s okay I deleted the Wine profile and created a fresh one and still used GE 7-28 and even that still works.
so while I thought there was a regression in Lutris v0.5.13, because reverting to v0.5.12 cured the major issue, I currently am on Lutris v0.5.13 from a clean Wine v8.0.2 (my system installed Wine is the newest ‘development’ version, which is currently 8.14 and on that it’s like DXVK is not active as while the game starts, navigating the main menu of the game is dead slow like frame rate is next to nothing and even the ‘MANGOHUD = 1’ does not even take effect but when the game is working normally I can see the DXVK and frame rate etc in top left corner area of screen) profile created with PlayOnLinux and adjusted it so Lutris uses that profile and now the game is back to normal/expected.
I might start playing with newer development versions of Wine from a clean Wine profile state to see if I can get this issue to trigger on Lutris v0.5.13 or not where the game no longer works as it should. but if not, I wonder if loading a bunch of other games from same Wine profile can potentially get things out of whack and cause Lutris to stop working on the two games I play (Mafia:DE/Mafia III, which both use same graphics engine and use DXVK) while others work.
either way, it appears I can pretty much stop claiming there is a regression in Lutris v0.5.13 given with a clean Wine profile the game is back to working as expected.
p.s. I don’t mean to hi-jack the OP’s thread but I am going to look into this stuff a bit more as at this point, worst case, I can probably just run a separate Wine v8.0.2 profile specifically for Mafia: Definitive Edition/Mafia III as those are the two games effected by the bug (which for whatever reason only seems to act up on Lutris v0.5.13 where as, like I said, when I reverted Lutris back to v0.5.12 the issue disappears when using the system Wine profile with the issue) as my others still seemed to work okay etc.
EDIT: I noticed on Red Dead Redemption 2 (build 1436.28), in short, you can’t use a GE runner any newer than 8-12 otherwise it will create a ‘vulkan-1 (native)’ entry in the ‘Libraries’ tab and stops the game from starting up. but, in short, it appears I can stick with Lutris v0.5.13 now as my games seem to work (even though I might have to tweak profiles a bit etc as I can use GE 8-13 on Mafia: DE for example but if I do it will screw up RDR2 build 1436.28 from working on the same profile but at least things seem to work on Lutris v0.5.13 now even if I had to tweak things a bit).
Yeah, I heard that when it comes to AMD GPU’s even if ones CPU is supported, if your AMD GPU is fairly recent, you might need a newer kernel than v5.15 which 5.15 is from Oct/Nov 2021. so if his AMD GPU is from around that time or newer, I suspect a newer kernel ‘may’ help with gaming performance etc.
but he can install the 6.2 kernel in Mint currently… ‘Update Manager > View > Linux Kernels’ has the option of ‘5.19’ (which is supported until Aug 2023, so it’s not a real option for him at this point) and then ‘6.2’ which is supported in Mint until Feb 2024 etc.
Vulkan-tools are installed and Vulkan ICD Loader is set to my AMD GPU.
I’d been using kisak ppa all along, but when I upgraded the OS recently, I was in a hurry, and when it downgraded or removed foreign packages or repositories, I prolly wasn’t paying attention, and that is when it switched from kisak ppa to oibaf. Switching back to kisak solved the whole issue. My bad! Thanks for pointing that out!
Will prolly stick with the default 5.15 kernel for now as Starcraft, Starcraft II, and WOW are working.
Thanks again!
another key thing I just noticed on Lutris v0.5.13 that, if I recall correctly, does not seem to be a factor on Lutris v0.5.12(?), which would have saved me a lot of trouble if I set it in the first place.
basically it’s to make SURE to set… right click game, select ‘Configure > Game options’ and on ‘Wine prefix’ make sure to set it to your wine profile (by default would be “/home/user/.wine/” (where ‘user’ is swapped with whatever yours is set to)) regardless if you are using the default one or a custom one as for example with frame rate…
-Mafia II (2010) WITHOUT setting ‘Wine prefix’ = 45-50fps average based on games benchmark (even after a second run to make sure there is no stutter due to caching in ‘GLCache’ folder).
-Mafia II (2010) WITH setting ‘Wine prefix’ = 85.7fps average based on the games benchmark (that was on the second run as on the first run there was a bit of stutter etc due to apparently the game caching stuff in the ‘GLCache’ folder as on the first run the frame rate was noticeably lower for the average but even then was still a improvement over not setting the ‘Wine prefix’).
point being… seems like a good idea to always manually set that for each game you use as that’s no small performance gain
on Lutris v0.5.13 below that ‘Wine prefix’ section it has a yellow warning exclamation point saying, “Some Wine configuration options cannot be applied without an explicit prefix.” ; apparently that’s unwise to ignore ; once I set that, that warning disappears (and given the game example I used above gave me a solid performance improvement!)
but that also seems to be the key reason my stock Wine profile was not not using DXVK on Mafia: Definitive Edition as once I manually set it, the game works as expected. on Lutris v0.5.12 one did not have to specifically set that apparently, which should explain why the game ran well on Lutris v0.5.12 and the main menu was a slide slow (near dead slow keyboard reaction) on Lutris v0.5.13.
p.s. but if your 5.15 kernel is working well (which it appears to be for you currently), I would stick with it since the Mint team recommends people stick with the default 5.15 kernel unless they have a specific need to use a newer kernel for newer hardware etc.
Setting the game wine prefix to your system wine prefix is considered bad practice. With lutris, the prefix field is intended to point to a non-system wine location (normally ~/Games) where lutris will create the wine prefix for you. Yes, this means that you can have a much larger install and consume more disk space. Many of the scripts in lutris include specific tweaks to make a game work, and may be incompatible with other games. Win 10 vs win 7 is one such setting.
You can share the prefix across a number of games if you are certain they will not be impacted.This is preferable to using ~/.wine.
Also Mint recommending 5.15 - not everything gets backported to the older kernel. I use Mint and run 6.5 kernel, but moving forward if you are not running the oldest hardware, 5.15 offers no advantages. 6.2 is a good balance - not bleeding edge, but most of the critical improvements are included. It is the equivalent of using kisak for mesa vs the mesa from repos.
Thanks for the proper way to setup things (you actually simplified things for me a bit since I can use Lutris now and don’t have to mess around with setting up Wine outside of anything Lutris can completely control), which appears to be totally separate from the system installed Wine as I would assume the Lutris ‘GE 8-12’ I got setup must use a base Wine 8.0 (apparently ‘staging’ version to) as it appears that way in the ‘About’ in the ‘Wine configuration’ screen as I don’t explicitly have Wine 8.0 installed on my system at all, so it must be using the Lutris only stuff.
anyways, trying to set it to a random location with nothing there at all actually worked well. so thanks for that information! ; I just did the following as a test… “/home/user/.lutrisTEST/” (setting ‘user’ to whatever yours is on your setup) in the ‘Wine prefix’ on Lutris and then started Mafia: Definitive Edition and it started right up and everything worked as expected as I got to main menu and then exited game and the basic “.lutrisTEST” prefix folder shows “410.3 MiB (430,186,435 bytes)” currently), which ain’t bad. I suspect ill be able to combine a fair amount of my games into a single location using same GE version to help cut back on storage space a bit (my guess is I probably won’t have to create more than four of of those (I currently have about 11 games or so tops setup in Lutris).
I just never realized Lutris could completely create it’s own prefix like that as I thought it had to have a pre-created one and then just uses that data in combination with it’s own to work, but apparently I was wrong given my testing here a moment ago, which just further confirms what you told me.
but I think I figured out the rest as normally I use ‘winecfg’ (or ‘Configure Wine’ through PlayOnLinux) to setup certain dll’s like ‘dinput8.dll’ etc and then even for the drive letter stuff it took me a while to figure out where it was at in Lutris, but it’s pretty obvious where it’s at once you know where it’s at as it’s right on the main Lutris window when you highlight the game then it’s just to the right of ‘Play’ (in bottom left center area of Lutris) where you can click the ‘wine’ icon (or “^” just to the right of it) and select ‘Wine configuration’ and then adjust stuff accordingly ‘if’ needed like usual.
alternatively, for DLL setup in Lutris… ‘Configure > Runner options’, scroll down to ‘DLL overrides’ section where ‘key’ is, for example, input ‘dinput8.dll’ and ‘value’ you set to ‘b,n’ (built-in or native) or ‘n,b’ (native then built-in), or ‘b’ (built-in only) ‘n’ (native only). but doing it through the GUI (i.e. ‘Wine configuration’ is a bit easier I would think).
now that I know how to ‘properly’ setup stuff in Lutris now with it’s own prefixes, trying RDR2 build 1436.28, with GE 8-12, from a clean profile created strictly through Lutris it works (no Wine configuration needed (I even checked it after wards and it already has Windows 10 there for Windows version which is normally not the case with Wine 8.0). trying the same with ‘GE 8-13’ and this fails as I see the ‘vulkan-1 (native)’ entry there like usual in the ‘Wine configuration’ screen. so in terms of ‘easy’ with Lutris, it appears for RDR2 build 1436.28 one cannot use GE’s any newer than ‘GE 8-12’.
now that I know all of this thanks to you ‘jhu’, I am going to transfer stuff to their own Lutris folders with saved game data etc and then just wipe the “.wine” folder back to a clean state and not even use Lutris with it at all since apparently it’s not proper to do so. so the system Wine ill probably only use for a very limited amount of games that might not be Lutris friendly but work on stock Wine.
so thanks for improving/correcting my Lutris knowledge so it’s more strictly proper now
p.s. also, I have been generally using my system installed Wine for games (which I generally won’t need now) where as for the limited amount of Windows programs I use, I just set them up through their own wine prefix through PlayOnLinux.
Correct me if I am wrong, but I don’t think one can install anything newer than the 6.2 kernel on Mint currently, at least not kernels that the Mint team would officially support even though I am aware of the basic idea of a person being able to install a newer kernel (I never tried it though as I would not want to risk potential system instability especially if there is no obvious/major benefits).
because, at least to my knowledge, the only ways to get kernels officially supported by the Mint team are pretty much one of two ways…
1)‘Update Manager > View > Linux Kernels’ section.
or…
2)from the terminal… stuff like ‘sudo apt install linux-oem-22.04c’ (which the newest here is 6.1 currently, which was newer than the Option 1 listed above until Mint team added in 6.2 not all that long ago now)
but just on a personal level… all of the hardware I use is older than the 5.15 kernel quite easily. my CPU is from 2012, my GPU is basically 2016 tech and other hardware I have is well before the Oct/Nov 2021 time frame of the 5.15 kernel release.
so I assume for you to get the ‘6.5’ kernel you are venturing outside of what’s officially supported by the Mint team? (like I heard stuff like that may work okay, but it’s more of a risk for stuff to break if people go outside of what the Mint team officially supports).
but I see your point of trying to find a balance of not being too old but not running too recent and risk issues. but personally, I like to play things a bit safer/conservative and in that regard, I think the 5.15 is a safe bet on Mint if your stuff works chances are it will continue to be okay for the life of the Mint installation. even if someone started to have issues, I suspect by then a newer version of Mint will be released and someone could switch to that since each major version is released 2 years apart (mid-2022 (supported until April 2027) to mid-2024 (supported until April 2029) and so on).
Linux is not like Windows or Mac OS - you can have many different kernels installed and boot into which ever one you want during start up. The simplest way to add a new kernel is to compile your own from source which will use the libs associated with your install during the binding. I use xanmod kernel which has some custom packages to improve performance, add fsync and change a few other parameters in the kernel I need with what I do. It is actually a good gaming kernel as a result of these patches. It has the edge, main and lts kernels plus a real time kernel. I also use the TKG kernel which I compile myself with the cpu optimizations. Liquorix is another custom kernel that is quite good.
Again, it is not an all or nothing - if you have issues, like anything, you can rollback to a different version during boot. If you are using a build for a store app, sign, kiosk where you need it to run 24/7, this is where you want LTS. If you are using it for an office with low tech savvy people, use LTS. But if you use it heavily for gaming, this is where you can use sites like phoronix to see how different kernels perform. Sometimes a custom kernel can add improved control over cpu scheduling and power management which can increase performance and reduce temps. Just always use timeshift and have a boot USB for Mint around cause even regular updates (nvidia 535 drivers as an example) can create problems, and if you don’t know the workarounds, timeshift restore is your life saver…
With that said, the question is… what kind of performance improvements? ; if it’s maybe 2-3fps tops (or slightly less CPU load) over Mint’s default kernel, it’s probably not even worth ones time to mess with and potentially risk system instability, especially if you already got passable/good gaming performance with the default kernel in Mint.
so to mess around with that stuff, I would probably figure one would need closer to a 10fps gain (or at least 5fps+ bare minimum (especially if this 5fps+ gain is when one is around 30fps since it will tend to be more noticeable vs if your already at a higher frame rate it will be next to nothing)) to be worth ones time of using something over the default Mint kernel.
p.s. I am aware of booting into a different kernel upon boot on Mint (I think it’s either SHIFT or ESC during a certain part of the boot process which brings you to a menu so you can select say the previous kernel if a kernel update is acting up, or to remove a newer kernel so it stops booting after reboots since it appears Mint defaults to loading the newest kernel upon boot). but I never did anything like you mentioned with compiling ones own kernel etc, as I would be pretty much a total newbie in that regard.
Yeah, I was aware of the NVIDIA v535 driver issue recently on Mint, as it even effected me (which is why I am still using v525 driver), but I had a Clonezilla image just prior to installing so I just restored from that so it’s like the NVIDIA v535 driver was never installed on my system in the first place.
I know people on Mint generally opt for ‘Timeshift’ but I don’t even use that on my system as I prefer Clonezilla since it’s a more rock solid reliable way to get back to a working system should something get totally out of whack since it basically wipes your previous install and restores it to the exact state it was at the time you imaged it (so anything changed/deleted/added since will be removed after Clonezilla image restoration).
p.s. but generally I don’t have issues with updates and I have been on Mint over 4 years now (like off the top of my head… that NVIDIA v535 issue which is a recent issue and a while ago quite a few people where having a issue where when first powering on ones PC from a cold boot, ones DVD drive tray would eject and stay open (I get many have moved on from DVD tech, but I still think it’s a reliable way to backup a limited amount of data for long term storage as it’s a good alternative to typical hard drive storage). luckily that drive tray eject issue got fixed though in a kernel update). so basically, while I know there is no guarantee’s updates won’t mess stuff up, at least so far for me, they rarely do on Mint, especially any more show stopper level of issues. that’s one of the reasons I prefer Mint is it’s geared more towards stability over the latest-and-greatest stuff. but at the same time, it’s not too conservative like say Debian etc are that seems to run even older stuff than Mint(Ubuntu). so Mint strikes a decent balance, but errs on a side of stability over the latest-and-greatest.
thanks for your time (and sharing your knowledge a bit as that proper prefix setup on Lutris definitely helped)
…