Yeah, it's a helpful answer that explains things. Using chroot did work at getting one step further, but as your answer states, that is just the first of many steps, most of which are way more complicated and specialized. And yes, those are outside the scope of this question. I'm not so sure if I can narrow it down to another question that suits Codidact. I need to run one or two games to test if my GPU is behaving similarly as it does without the live USB. The first is Apex Legends (Steam), and the other Battlefront II (Lutris --> EA App). Those aren't exactly simple, much because of Wine.

Yeah - sorry, I don't really know a way to run steam from inside a live OS. Like I said, you could fiddle with mounting graphics etc. but the problem is when things don't work you don't know if you've found the bug or if it's just because you forgot something in your chroot setup.

If your hypothesis is "Apex Legends and Battlefront 2 don't work on my Pop OS! install, but would work if I reinstalled or installed a different distro" then I recommend you create a separate partition, install a new Linux there as dual boot, and compare. That would be the easiest way to test it in the end.

Also, this is a separate hypothesis but, try:

• Install wine bottles through flatpak and try running through there with different runners (particularly, try: syswine, soda, proton, ge-proton)
• Try different runners in Steam's compatibility for both games. Different versions of stock proton, but also you can install glorious eggroll proton on Steam.

Did you check protonDB already for these games?

Did you check protonDB already for these games?

Yes, and they ran fine for over a month.

The problem is that Wine games no longer work in fullscreen (Reported here and here, in case you’re interested).

Anyway, thanks. Maybe the issue is with Wine. I do think it’s a broken Vulkan implementation in the driver, but I don’t know why it worked in the past. Maybe my hardware is somehow damaged. Strange that it works fine outside of fullscreen, though.

Is it possible to create an NTFS partition on an otherwise Linux-formatted 2TB drive (got around 1 TB free), install Windows, test the environment, then delete the NTFS partition again, so that I give it back to the main approximately 2TB partition?

Ah, I see why you think it's a configuration issue.

I don't so much suspect it's wine, that I think it's an update PopOS rolled out that works fine on a fresh install (which is probably how they test it) but breaks on a very specific configuration (such as the one you have). The idea is that other runtimes like proton might not be vulnerable to the same corner case.

For Vulkan, I think it's pretty easy to install old versions, because you manually install vulkan onto the prefix with a script. You could even have several different wine prefixes, each with a different vulkan.

BTW, have you already tried running the game from the terminal, and looking for errors in the terminal output when it crashes?

Is it possible to create an NTFS partition on an otherwise Linux-formatted 2TB drive (got around 1 TB free), install Windows, test the environment, then delete the NTFS partition again, so that I give it back to the main approximately 2TB partition?

Yes - the filesystem is per-partition. When creating, just select/format as NTFS not Ext4. In Linux, you need an NTFS driver to work with NTFS, and sometimes it's not installed by default since they don't want to promote non-free software but it's usually easy to install.

Be careful when installing Windows though. Sometimes Windows likes to overwrite the MBR/EFI so that the Grub menu never comes up, you only get a menu showing Windows, which conveniently fails to detect Linux. So then you need to restore the old MBR (not Linux, just the install-grub etc) so your computer will once again boot into a grub menu that lets you choose from Windows and Linux.

But what will you accomplish with this? The game surely works on Windows.

BTW, have you already tried running the game from the terminal, and looking for errors in the terminal output when it crashes?

No, I’m not very good with Linux, but I should be able to test that. However, the games generally don’t crash (freezing the application/system, and sometimes I need to shut down the computer with the case button), and I’ve looked at some logs from various places. I got nothing useful out of what I found thus far.

But what will you accomplish with this? The game surely works on Windows.

Dual-booting isn’t an option for me. I need everything to run side-by-side.

Anyway, I should be getting a new disk delivered in not too long. Was gonna copy stuff onto it from the old computer, but the enclosure I got with it fried it, so had to send it in return. I can install that on my motherboard before using it for a transfer, put Windows on it, and test there. Should be simpler than allocating a partition on the main drive.

The terminal isn't always useful, sometimes you just get a bunch of spam. But occasionally you get a specific error about some driver is missing etc.

Btw, I had a similar issue recently where many games would appear to freeze for certain Wine runtimes when running full screen. They didn't actually freeze, but slow down to the point of 5-10 s latency on everything. So if I pressed the key to switch from full screen to windowed, after some wait, it would switch and unfreeze. When I go back to full it would freeze again. I've changed other things in the meanwhile and it went away on its own, so I don't know exactly what the problem was. One thing I noticed was that if I have second monitor connected, the game would not freeze even when full screen on the first monitor.

Dual-booting isn’t an option for me. I need everything to run side-by-side.

You mean you want both the Linux and Windows to be running at the same time? That would be difficult.

You could boot into Windows, and install a Linux inside a VM. Or Boot into Linux and install Windows inside a VM. Normally VMs don't use GPU. On Linux, you can do GPU passthrough with Qemu etc but I never tried it because it sounded too complicated (and then I figured how do get Wine to work). On Windows, idk but you would think it's easier to set up than Linux.

But if the problem really is your hardware, the VM could hide that, because sometimes it provides virtual versions of your devices to the VM OS which don't have the same problems your hardware would.

Btw, I had a similar issue recently where many games would appear to freeze for certain Wine runtimes when running full screen. They didn't actually freeze, but slow down to the point of 5-10 s latency on everything. So if I pressed the key to switch from full screen to windowed, after some wait, it would switch and unfreeze. When I go back to full it would freeze again.

That is very familiar. It’s pretty much what I’m experiencing. Do you know approximately what you changed that may be relevant? Actually, I can try testing with my TV. Not gonna be fun moving stuff around…

You mean you want both the Linux and Windows to be running at the same time? That would be difficult.

No, I want just a single boot, with a single OS. So either Windows or Linux. I kind of have made a choice on Linux now, so if I can get this to work, I don’t wanna go back to Windows. A VM doesn’t solve any issues for me. Booting into Windows would only be for testing the hardware with different software.

Do you know approximately what you changed

Well, you're gonna love this: Around that time I coincidentally decided to make a new gaming computer instead of gaming on my workstation. On the new computer, I of course installed a fresh Manjaro (it was Arch before). Notably, I used the same nVidia GPU (I moved it from the workstation to the gaming PC). I ran all the games the same way as before, through steam or bottles, with vulkan where possible. The issue never happened on the new gaming PC.

As I recall though, the freezing only happened with Bottles for me, not when using Wine directly (don't remember about bottles with syswine). Notably, Bottles uses its own flatpacked nvidia drivers and not the system ones, and also I'm a lazy updater. I'm wondering if we got bit by the same graphics driver bug.

No, I want just a single boot, with a single OS. So either Windows or Linux. I kind of have made a choice on Linux now, so if I can get this to work, I don’t wanna go back to Windows. A VM doesn’t solve any issues for me. Booting into Windows would only be for testing the hardware with different software.

Ah. Well I know it's a thing to set up a Windows VM with GPU passthrough for games. That way you get ultimate compatibility, and almost native performance. It's complicated though, sometimes you even need a second GPU. But Wine got really good recently (your issue aside) so I think these days people don't bother.

I think you have the right idea. Make a partition in the empty space and install a second Linux as dual boot, and test the game there. I would try Manjaro, Fedora, Mint and Debian, always the latest "unstable" version.

As I recall though, the freezing only happened with Bottles for me, not when using Wine directly (don't remember about bottles with syswine). Notably, Bottles uses its own flatpacked nvidia drivers and not the system ones, and also I'm a lazy updater. I'm wondering if we got bit by the same graphics driver bug.

I wasn't aware about that. I never really understood how all this worked behind the scenes. There were generally zero explanations about it that I could find, and researching it with a lack of knowledge and Linux, wasn't easy. Since then, well, I got busy with getting it to work on the surface. Maybe I can figure out how to replace some of the components behind the scenes here, and test with that.

I've found other posts online where people describe somewhat similar issues. It's usually with a 1070, 1080, 3060, 3090, and any 40 series GPU. Personally, I have a 4080S. Not sure if any of the bugs are tied to a specific GPU model.

I built the computer with all fresh new components off the assembly shelves, back in May. Worked fine until sometime at the end of June/July. Didn't even open the case until a few days ago, so certainly didn't make a change there. There were updates popping in every other day, but nothing really stood out.

Well, the good news is that if your card is new, there's a good chance that it was just some half baked new feature that nvidia devs put in the driver, which they didn't test properly because they were rushing it out so that marketing could brag about it. But if so they'll fix it soon. You can try rolling back to older drivers. Downgrading is different for every distro, you'd have to check how PopOS does it.

If you use Bottles, that's all through flatpak, and it has its own way of installing old versions of both bottles and the flatpaked nvidia drivers.

I see eglinfo is printing:

EGL API version: 1.5
EGL vendor string: Mesa Project
EGL version string: 1.5
EGL client APIs: OpenGL OpenGL_ES 

Shouldn't that be Nvidia instead? Maybe that is why I'm having problems?

I don't know if that's the source of this particular problem, but I would be surprised if it worked at all. Mesa/Vesa are the open source drivers. They're nice in that they're free as in freedom and you don't have to install any mystery binary blobs. But Nvidia/AMD don't support them much so these are guys reverse engineering the driver in their own time, pretty much. They can have far less performance and features than the proprietary driver.

If you're trying to run any modern games/programs that are graphically demanding, unfortunately it is almost certain that you will need to install the proprietary driver to make it work. It's not hard to do and most distros should have good instructions for it.

I don't know eglinfo though, so try to double check that you really have the FOSS driver.

matthewsnyder‭ We're way outside the scope of Q/A here, but in case you're interested, I've solved the problem by pretty much just flipping a radio button that's been sitting in front of me for a month.

Quoting myself:

I've located the offending settings. I may have enabled these by myself some while ago; not sure if they default to on or not. Either way I feel very stupid for spending such a long time figuring something as basic as that out, especially as I may have caused all this by enabling the offending setting in the first place.

• Nvidia X Server Settings
• X Screen 0
  • OpenGL Settings:
    • Allow Flipping

If this setting is enabled, I experience the behaviour I've experienced when either "Allow G-SYNC/G-SYNC Compatible" is enabled (blackouts and video output crash), or when "Force Composition Pipeline" is enabled (system freeze when a Wine game's fullscreen window is key.

I guess it's up to Nvidia, PopOS, or X Server developers to decide if this is a bug.

That's weird. And you get decent FPS in games and so on? In any case, that definitely sounds like the Linux driver for your Nvidia card has some bugs. Maybe the driver crashes, and X responds by falling back to something else, idk.

To bring it back to the original topic: There's no point trying to chroot to troubleshoot this. It's a video driver problem, so you would be messing with the graphics driver config on your normal OS. Even if you accidentally misconfigure the driver so bad the graphics don't come up at all, you would just switch to a TTY and work from the terminal there.

The live USB is only needed if:

• It doesn't boot
• It boots but can't login at all (eg. forgot password)
• Internet doesn't work at all (not even ethernet or USB tethered phone) and you can't install pacakges Otherwise it is unnecessary.

That's weird. And you get decent FPS in games and so on?

Indeed. Minecraft, Battlefront II, RDR2, etc, great framerate. Apex, a bit unstable, but that's just AL being AL. Jedi: Fallen Order, sure, except for when UE4's outdated threading solutions say no. Jedi: Survivor, heck no, 2K FSR to 4K at ultra and ray-tracing can't handle it well. :P

To bring it back to the original topic: There's no point trying to chroot to troubleshoot this

Trust me, I gave up long before.... I never even managed to run any of the things I wanted, in the first place. :P I'd probably have to know Linux, Wine, etc inside out to be able to get it done. Anyway, it was a suggestion from one of the Pop!_OS distro developers. He just didn't know how I'd actually get them running...