Linux

[PluMGMK]

ORIGINAL POST 21 APRIL:

I'm having all sorts of issues trying to play Black Mesa with Proton today. I think it's because I screwed up an upgrade of zlib at some point, but now it's just steadfast refusing to run, logging all sorts of unhelpful error messages. So… right now I'm burning a Linux Mint DVD. I figured life's too short for this, especially when I'm going back to work on Monday! I'll still keep LFS for everyday use, and I'll probably get games working on it again in the future (or it might resolve itself) but having an up-to-date Mint around for gaming will probably help a lot. Hopefully…

EDIT: Well, the first attempt at installation over an old Debian install was a bust, but the second time I made sure to format the partition and then it worked like a charm. Dear God, it's glorious to have a distro that just works out of the box…


UPDATE 23 APRIL:

Well, after a couple of days cooling off (and playing Black Mesa on Mint), I came back and sorted it out. Indeed, the crux of the issue is in zlib, even if I don't fully understand it. Let me start at the beginning, just in case someone else has made the same mistakes I did…

After solving some unrelated issues (apparently to do with keeping Proton games on an encrypted partition), I got to the point where starting Steam from the terminal and trying to run Black Mesa gave some output like this:

Code: Select all

wine: RLIMIT_NICE is <= 20, unable to use setpriority safely
Setting breakpad minidump AppID = 362890
Steam_SetMinidumpSteamID:  Caching Steam ID:  76561198025750625 [API loaded no]
terminate called after throwing an instance of 'dxvk::DxvkError'

abnormal program termination

Which is highly uninformative, it has to be said! Still, it suggested there was some issue with DXVK, so I tried again with PROTON_USE_WINED3D11=1. This time:

Code: Select all

wine: RLIMIT_NICE is <= 20, unable to use setpriority safely
libGL error: MESA-LOADER: failed to open radeonsi: /usr/lib/libz.so: cannot open shared object file: No such file or directory (search paths /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/dri:/usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/dri, suffix _dri)
libGL error: failed to load driver: radeonsi
libGL error: MESA-LOADER: failed to open swrast: /usr/lib/libz.so: cannot open shared object file: No such file or directory (search paths /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/dri:/usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/dri, suffix _dri)
libGL error: failed to load driver: swrast
wine: Unhandled page fault on execute access to 00000000 at address 00000000 (thread 0024), starting debugger...
Unhandled exception: page fault on execute access to 0x00000000 in 32-bit code (0x00000000).
*snip*

This was a lot more informative – apparently the Mesa video driver was trying to link to /usr/lib/libz.so as an absolute path, which didn't exist inside the Steam Runtime environment. I did some digging and it turned out that I had screwed up my last update of zlib, so I had /lib/libz.so.1 and /usr/lib/libz.so pointing at two different versions. I rectified the symlinks, which caused a load of programs to start complaining about "no version information" but otherwise didn't really break anything.

I then tried recompiling Mesa, but the libraries it produced still pointed at the absolute path /usr/lib/libz.so – this is the part I still don't fully understand. But I was able to fix the build script manually to sort that out:

Code: Select all

sed '/^ *LINK_ARGS/s|/usr/lib/libz.so|-lz|g' -i build.ninja

Recompiling and reinstalling, it looked like the problem was solved:

Code: Select all

$ ldd /usr/lib/dri/radeonsi_dri.so
         linux-gate.so.1 (0xf7ed7000)
         libglapi.so.0 => /usr/lib/libglapi.so.0 (0xf65fd000)
         libdrm.so.2 => /usr/lib/libdrm.so.2 (0xf65e5000)
         libLLVM-14.so => /usr/lib/libLLVM-14.so (0xeecc6000)
         libexpat.so.1 => /usr/lib/libexpat.so.1 (0xeec96000)
         libz.so => /usr/lib/libz.so (0xeec7e000)
         libdl.so.2 => /lib/libdl.so.2 (0xeec79000)
         libsensors.so.5 => /usr/lib/libsensors.so.5 (0xeec67000)
         libdrm_radeon.so.1 => /usr/lib/libdrm_radeon.so.1 (0xeec57000)
         libdrm_amdgpu.so.1 => /usr/lib/libdrm_amdgpu.so.1 (0xeec4a000)
         libelf.so.1 => /usr/lib/libelf.so.1 (0xeec2c000)
         libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xeea13000)
         libm.so.6 => /lib/libm.so.6 (0xee946000)
         libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xee927000)
         libpthread.so.0 => /lib/libpthread.so.0 (0xee907000)
         libc.so.6 => /lib/libc.so.6 (0xee72b000)
         libffi.so.6 => /usr/lib/../lib/libffi.so.6 (0xee723000)
         librt.so.1 => /lib/librt.so.1 (0xee719000)
         libncursesw.so.6 => /lib/libncursesw.so.6 (0xee6af000)
         libxml2.so.2 => /usr/lib/../lib/libxml2.so.2 (0xee525000)
         /lib/ld-linux.so.2 (0xf7ed9000)
         libz.so.1 => /lib/libz.so.1 (0xee50d000)
         libicui18n.so.71 => /usr/lib/../lib/libicui18n.so.71 (0xee1b6000)
         libicuuc.so.71 => /usr/lib/../lib/libicuuc.so.71 (0xedfb3000)
         libicudata.so.71 => /usr/lib/../lib/libicudata.so.71 (0xec2ae000)
         liblzma.so.5 => /lib/liblzma.so.5 (0xec284000)

But there was zero improvement in the behaviour of Black Mesa! This is when I gave up and went to Mint.

Today I decided to come back to it, and, being calmer, I realized that I could set this env variable:

Code: Select all

PRESSURE_VESSEL_SHELL=instead

Running Steam like this allowed me to press "Play" on Black Mesa, but instead it would pop up an interactive shell and allow me to explore the runtime environment – a lifesaver as far as I'm concerned!

So, from the interactive shell, I examined the libraries linked by the Mesa driver again:

Code: Select all

$ ldd /run/host/usr/lib/dri/radeonsi_dri.so
         linux-gate.so.1 (0xf7f4f000)
         /tmp/pressure-vessel-libs-C1M3K1/${PLATFORM}/gameoverlayrenderer.so => /tmp/pressure-vessel-libs-C1M3K1/i686/gameoverlayrenderer.so (0xf66aa000)
         libglapi.so.0 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libglapi.so.0 (0xf6672000)
         libdrm.so.2 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libdrm.so.2 (0xf665a000)
         libLLVM-14.so => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libLLVM-14.so (0xeed3b000)
         libexpat.so.1 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libexpat.so.1 (0xeed0b000)
         libz.so => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libz.so (0xeecf3000)
         libdl.so.2 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libdl.so.2 (0xeecee000)
         libsensors.so.5 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libsensors.so.5 (0xeecdc000)
         libdrm_radeon.so.1 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libdrm_radeon.so.1 (0xeeccc000)
         libdrm_amdgpu.so.1 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libdrm_amdgpu.so.1 (0xeecbd000)
         libelf.so.1 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libelf.so.1 (0xeec9f000)
         libstdc++.so.6 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libstdc++.so.6 (0xeea86000)
         libm.so.6 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libm.so.6 (0xee9bb000)
         libgcc_s.so.1 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libgcc_s.so.1 (0xee99c000)
         libpthread.so.0 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libpthread.so.0 (0xee97c000)
         libc.so.6 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libc.so.6 (0xee7a0000)
         librt.so.1 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/librt.so.1 (0xee796000)
         /lib/ld-linux.so.2 (0xf7f51000)
         libGL.so.1 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libGL.so.1 (0xee724000)
         libffi.so.6 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libffi.so.6 (0xee71a000)
         /usr/lib/libz.so => not found
         libncursesw.so.6 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libncursesw.so.6 (0xee6b0000)
         libxml2.so.2 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libxml2.so.2 (0xee526000)
         libGLdispatch.so.0 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libGLdispatch.so.0 (0xee4a9000)
         libGLX.so.0 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libGLX.so.0 (0xee467000)
         libicui18n.so.71 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libicui18n.so.71 (0xee110000)
         libicuuc.so.71 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libicuuc.so.71 (0xedf0f000)
         libicudata.so.71 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libicudata.so.71 (0xec20a000)
         liblzma.so.5 => /lib/i386-linux-gnu/liblzma.so.5 (0xec1dc000)
         libX11.so.6 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libX11.so.6 (0xec08b000)
         libxcb.so.1 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libxcb.so.1 (0xec05f000)
         libXau.so.6 => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libXau.so.6 (0xec05c000)

And there it is! "/usr/lib/libz.so => not found". I was scratching my head as to where that had come from, so I found libtree, which does the same thing as ldd but shows it as a tree view to see what libraries are pulling in what others.

The result:

Code: Select all

$ ~/libtree_x86_64 /run/host/usr/lib/dri/radeonsi_dri.so
libgallium_dri.so 
├── libglapi.so.0 [ld.so.conf]
│   └── libpthread.so.0 [ld.so.conf]
├── libelf.so.1 [ld.so.conf]
│   └── /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libz.so.1 [ld.so.conf]
├── libdrm_amdgpu.so.1 [ld.so.conf]
│   └── libdrm.so.2 [ld.so.conf]
├── libdrm_radeon.so.1 [ld.so.conf]
│   └── libdrm.so.2 [ld.so.conf]
├── libsensors.so.5 [ld.so.conf]
├── libpthread.so.0 [ld.so.conf]
├── /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libz.so [ld.so.conf]
├── libexpat.so.1 [ld.so.conf]
├── libLLVM-14.so [ld.so.conf]
│   ├── /usr/lib/libz.so is not absolute
│   ├── libffi.so.6 [ld.so.conf]
│   ├── libncursesw.so.6 [ld.so.conf]
│   ├── libpthread.so.0 [ld.so.conf]
│   ├── libxml2.so.2 [ld.so.conf]
│   │   ├── libicui18n.so.71 [ld.so.conf]
│   │   │   ├── libicuuc.so.71 [ld.so.conf]
│   │   │   │   ├── libicudata.so.71 [ld.so.conf]
│   │   │   │   └── libpthread.so.0 [ld.so.conf]
│   │   │   ├── libpthread.so.0 [ld.so.conf]
│   │   │   └── libicudata.so.71 [ld.so.conf]
│   │   ├── /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libz.so [ld.so.conf]
│   │   ├── libicudata.so.71 [ld.so.conf]
│   │   ├── libicuuc.so.71 [ld.so.conf]
│   │   └── liblzma.so.5 [ld.so.conf]
│   │       └── libpthread.so.0 [ld.so.conf]
│   └── librt.so.1 [ld.so.conf]
│       └── libpthread.so.0 [ld.so.conf]
└── libdrm.so.2 [ld.so.conf]

So, it was coming from libLLVM-14.so

That being the case, I went and recompiled LLVM as I had done for Mesa a couple of days ago, and found the same problem: even though I had fixed the symlinks, it was still hard-coding an absolute path. But I was able to fix it with the same trick:

Code: Select all

sed '/^ *LINK_LIBRARIES/s|/usr/lib/libz.so|-lz|g' -i build.ninja

Once I recompiled and reinstalled with this change, Black Mesa worked a treat! I should note, it even works with DXVK now, confirming that the same issue was behind all the weird errors.

My system still isn't 100% right, I'll have to go and resolve the whole zlib thing properly, but for now it plays games again!

EDIT: Fixed code tags. Some of the story was hidden inside one of them

[PluMGMK]

I think hell might be freezing over: https://www.phoronix.com/scan.php?page= ... rnel&num=1

Nvidia are actually open-sourcing their kernel driver, albeit only for the newest GPUs, and the userspace stuff is staying closed for the moment…

[LoveMetal]

This was a lot more informative – apparently the Mesa video driver was trying to link to /usr/lib/libz.so as an absolute path, which didn't exist inside the Steam Runtime environment. I did some digging and it turned out that I had screwed up my last update of zlib, so I had /lib/libz.so.1 and /usr/lib/libz.so pointing at two different versions. I rectified the symlinks, which caused a load of programs to start complaining about "no version information" but otherwise didn't really break anything.

I had the same problem on osx with a different library, and I learnt the hard way that those suffix numbers are for different major versions of the same library, and that the symlink for the unversionned library was basically a wild and uneducated guess from an installer that though that his library version should be the right one.

[Steo]

I think hell might be freezing over: https://www.phoronix.com/scan.php?page= ... rnel&num=1

Nvidia are actually open-sourcing their kernel driver, albeit only for the newest GPUs, and the userspace stuff is staying closed for the moment…

I seen this and was actually thinking what!

[PopuriAO29]

I've been using old version Ubuntu in VirtualBox for some reason. Trying use alternate install build, and even i got some beta version for Ubuntu that i uploaded on Internet Archive. Actually, Lucid Lynx LTS build.

While I found some FTP from gegereka, I finally got DEFT Linux 4.2.1, it's pretty old version and uses Ubuntu linux.

[PluMGMK]

Oh dear God, Microsoft have hired Lennart Poettering https://www.phoronix.com/scan.php?page= ... -Microsoft

[Steo]

I ended up building LFS again. I really should just start dual booting and having something Debian or Arch based handy for when I'm not in the mood of fixing LFS, instead of impulsively getting rid of it only to want to go back to it again after some time.

Most things are working fine aside from one weird issue I'm having with Steam wanting to be unusual. It won't run any game, but if I decide to change "LD_PRELOAD" in the game launch options, it decides to work again. Even if I just set it to be blank like "LD_PRELOAD="" %command%", the game will work, but I shouldn't have to do this so I'm trying to figure out what's going on. From my talk with Plum as of now, we seem to think it's somehow related to gameoverlayrenderer.so.

[LoveMetal]

I ended up building LFS again. I really should just start dual booting and having something Debian or Arch based handy for when I'm not in the mood of fixing LFS, instead of impulsively getting rid of it only to want to go back to it again after some time.

I’m not sure that LFS is meant to be used as a primary operating system.

[Steo]

I’m not sure that LFS is meant to be used as a primary operating system.

No, it definitely isn't:

LFS = System for Mad Kunts, no one can change my mind on this one. No one.

Still though, I always like learning, and what better way to learn than to literally try to use the system as a daily driver like a crazy person.

It's a good way for me to practice stuff too, because I'm currently undertaking a Python course and I've always tried to use Python to keep the system up to date, essentially writing a package manager, and improving this or adding functions to it is a nice way to test stuff. I can always dual boot with something Debian based in case things go wrong and I don't have time to fix them though, but right now I just need to figure out why Steam is being so smelly!

[PluMGMK]

Back to the whole "smelly" thing, are we?

[Steo]

Well maybe it's not that smelly really, but something is broken somewhere. I like when it works properly.

EDIT: Well I still never figured this out, but the issue is definitely related to the 32-bit version of gameovelayrenderer.so, or something it's linking to. If I use LD_PRELOAD in the launch options for a game on Steam, setting it to a blank string results in the game working properly. However, setting it to the path of that aforementioned file will replicate the same issue I had before. If set the path to the 64-bit version of the gameoverlayrenderer.so file, the game will also launch and work properly. I later found out that if I just delete the gameoverlayrenderer.so file outright from the ubuntu12_32 folder, the game will also work properly, so therefore the issue is definitely something to do with this file, or something else it links to.

It's interesting because Steam is supposed to try to load both the 32-bit and 64-bit versions and only succeed with one, but in this case it just fails and crashes while trying to even load the 32-bit one at all it seems.

[PluMGMK]

As I already explained to ^ by PM, I ended up finding the solution when I upgraded my own system to glibc 2.36. The 32-bit version of gameoverlayrenderer.so calls a libc function without aligning the stack pointer to a 128-bit boundary, which results in a segfault within libc. The solution is to compile the 32-bit version of glibc with:

Code: Select all

CFLAGS="-mstackrealign -g -O2" ../configure …

The "-mstackrealign" makes libc realign the stack itself when the function is called, preventing the crash.

[Steo]

I'm glad that ^ managed to figure it out. I had to just keep deleting the gameoverlayrenderer.so file every time but now when I get back to my own computer after the holidays I can try to recompile glibc.

[PluMGMK]

Good stuff! Btw, another tip: even if you only need to recompile 32-bit glibc to solve this problem, be sure to reinstall the 64-bit version too. Otherwise you'll end up with a 32-bit ldconfig, which sooner or later will remove all the 64-bit libs from your ld.so.cache! That caused Steam games to stop working again for me after a while, until I reinstalled the 64-bit one!

[Steo]

Good stuff! Btw, another tip: even if you only need to recompile 32-bit glibc to solve this problem, be sure to reinstall the 64-bit version too. Otherwise you'll end up with a 32-bit ldconfig, which sooner or later will remove all the 64-bit libs from your ld.so.cache! That caused Steam games to stop working again for me after a while, until I reinstalled the 64-bit one!

Thanks for the heads up, I didn't even consider this. So yeah I'll make sure to recompile both then when I get around to it.

[Steo]

So lately, I've just been thinking about environments when it comes to Linux. I have been using LFS for some time, and always used KDE because it's what I was used to using in other distros. Lately I've been thinking of trying something new just to switch it up a little. I feel like Xfce would be the easiest to try, as it's the lightest and requires the least amount of dependencies to run, while GNOME on the other hand looks really nice, but requires many dependencies to work. I'm fine with resources as I'm sure that 32GB RAM is plenty, but it just depends on whether it's worth compiling all the extra dependencies to try something such as GNOME.

Out of curiosity, what is your favourite environment, and would you recommend it (or others)?

[PluMGMK]

I basically use Sway all the time, but I have GNOME installed so I can use gnome-terminal, nautilus, eog, file-roller, etc. The terminal's good, but I find the other tools a bit clunky since they require a mouse / pointing device to be used efficiently…

[Steo]

Sway looks interesting how it seems to minimise everything including the window borders and put everything on a grid to maximise your screen usage. I had never looked into it before but it looks like it would be good for work usage. It's also interesting that it can be navigated with just a keyboard pretty easily.

GNOME is one I considered installing too since a lot of applications already use many dependencies from it anyway. I would like the idea of it being a little different since I always used KDE and always had the taskbar at the bottom just like in Windows.

[PluMGMK]

I was a very early adopter of Sway. Back in 2016 it didn't put any window borders on at all, since the author at the time believed that Wayland applications should do CSD (client-side decoration)! But then he changed his mind so now it does borders just like i3 (the X11 window manager that inspired it)

[Steo]

Back in 2016 I was still using Windows.