Closed camperboy1000 closed 1 year ago
Hello @camperboy1000, Assertion 'device' failed at src/libsystemd/sd-device/device-private.c:103, function device_get_tags_generation(). Aborting.
looks like it's coming from systemd, (https://github.com/systemd/systemd/blob/main/src/libsystemd/sd-device/device-private.c#L103), instead of Steam. I think this issue should also be reported to your distro's package maintainer(s) for systemd and/or libgudev.
Same issue here
Same here on Sway 1:1.8.1-1
Assertion 'device' failed at src/libsystemd/sd-device/device-private.c:103, function device_get_tags_generation(). Aborting.
Downgrading libgudev
and lib32-libgudev
to version 237-2
solves the issue.
Running into this issue myself I found this post on the Arch Forums.
I'm unsure if removing lib32-libgudev
has any adverse effects on steam/games, but it seems to be a solution in case nothing else depends on it
For what it's worth, lib32-libgudev
may be brought into some people's systems by Proton on Arch, which depends on it. So it may be a more significant issue for Proton, for whose users removing the package isn't an option. though it may also be that Steam itself is having problems when the library is installed
thanks, downgrading packages fixed my suddenly broken steam as well
sudo pacman -U https://archive.archlinux.org/packages/l/libgudev/libgudev-237-2-x86_64.pkg.tar.zst
sudo pacman -U https://archive.archlinux.org/packages/l/lib32-libgudev/lib32-libgudev-237-2-x86_64.pkg.tar.zst
steam --reset
Got it working for me.
Edit: Actually it looks like the reset was enough, i updated libgudev and steam still works.
In my case lib32-libgudev was a required dep of lib32-gst-plugins-good, which i don't really need anyway. Removing the package solved my issue.
sudo pacman -U https://archive.archlinux.org/packages/l/libgudev/libgudev-237-2-x86_64.pkg.tar.zst sudo pacman -U https://archive.archlinux.org/packages/l/lib32-libgudev/lib32-libgudev-237-2-x86_64.pkg.tar.zst steam --reset
Got it working for me.
Edit: Actually it looks like the reset was enough, i updated libgudev and steam still works.
@GithubUser5462 are you saying you updated both libgudev
and lib32-libgudev
and it works? Or just libgudev
? I don't think the reset has anything to do with it, I tried that and steam still breaks unless I downgrade lib32-libgudev
specifically.
Downgrading libgudev
as well doesn't seem functionally necessary, but I don't know if there are any prickly side effects from having the lib32 package on a different version than the main one.
Removal of the lib32 version isn't an option for me as I have Proton installed on my system.
Upstream issue filed for Arch's lib32-libgudev
packager, as requested by @kisak-valve: https://bugs.archlinux.org/task/79006
Yes i ran sudo pacman -Syu lib32-libgudev libgudev
so version 238-1.
I have two pc fully updated, steam is working fine on both. Weird.
Maybe i had a different problem.
On advice of Arch maintainers, issue opened upstream with libgudev
: https://gitlab.gnome.org/GNOME/libgudev/-/issues/9
I just experienced the same bug on a fully updated arch system with the latest steam beta, downgrading both libgudev
and lib32-libgudev
to version 237-2
works.
Can confirm that downgrading both libgudev and lib32-libgudev to version 237-2 works as well.
The package that had lib32-libgudev
as dependency in my system was pronton-ge-custom-bin
, removing it with pacman -Rs proton-ge-custom-bin
solves this issue, in Arch. Beware of optional dependencies of other packages:
:: lib32-alsa-plugins benötigt optional lib32-libpulse: for conf_pulse, ctl_pulse and pcm_pulse plugins
:: lib32-sdl2 benötigt optional lib32-libpulse: PulseAudio audio driver
:: lutris benötigt optional lib32-vkd3d: DirectX 12 support
:: wine-staging benötigt optional lib32-gnutls
:: wine-staging benötigt optional lib32-libpulse
:: wine-staging benötigt optional lib32-libxcomposite
:: wine-staging benötigt optional lib32-libxinerama
:: wine-staging benötigt optional lib32-libva
:: wine-staging benötigt optional lib32-gtk3
:: wine-staging benötigt optional lib32-gst-plugins-base-libs
To iterate on this further and to also reiterate what has been said on the respective issue trackers, the issue lies with Steam's runtime super old 32 bit version of libnm
. Installing lib32-libnm
so that Steam uses the system's libnm
version instead fixes the issue for now.
After debugging for quite some time, here are my findings:
If you aren't interested in details, skip to the end for solutions.
The assertion fails because a member in the struct udev_device
is NULL
when it shouldn't be. This struct is an opaque pointer: its members can only be accessed by libudev
. The only other libudev
function this struct is passed to (besides the reference counting ones such as udev_device_ref()
) is udev_device_new_from_subsystem_sysname()
, called by g_udev_client_query_by_subsystem_and_name()
.
Placing a breakpoint at this function shows that calls to it use the Steam-provided version of libudev
.
(gdb) bt
#0 0xec837c49 in udev_device_new_from_subsystem_sysname ()
from /home/karthin/.local/share/Steam/ubuntu12_32/steam-runtime/lib/i386-linux-gnu/libudev.so.0
#1 0xeb6214a1 in g_udev_client_query_by_subsystem_and_name (client=0xe3828cd0, subsystem=0xe8dc77c8 "net",
name=0xe2db3190 "wlan0") at ../libgudev/gudev/gudevclient.c:507
#2 0xe8d55927 in ?? ()
from /home/karthin/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libnm.so.0
#3 0xe8d56e40 in nm_device_get_vendor ()
from /home/karthin/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libnm.so.0
However, calls to the function where the assertion fails, device_get_tags_generation()
, use the system-provided version.
(gdb) bt
[...]
#5 0xeaa8476c in log_assert_failed (text=<optimized out>, file=<optimized out>, line=<optimized out>,
func=0xeaaa7608 <__func__.29.lto_priv.2> "device_get_tags_generation") at ../systemd-stable/src/basic/log.c:889
#6 0xeaa8d269 in device_get_tags_generation (device=<optimized out>)
at ../systemd-stable/src/libsystemd/sd-device/device-private.c:103
#7 device_get_tags_generation (device=<optimized out>)
at ../systemd-stable/src/libsystemd/sd-device/device-private.c:102
#8 udev_device_get_current_tags_list_entry (udev_device=0xdb950e10)
at ../systemd-stable/src/libudev/libudev-device.c:863
#9 0xeba42fb5 in fetch_current_tags (device=0xdb950c90) at ../libgudev/gudev/gudevdevice.c:146
#10 _g_udev_device_new (udevice=udevice@entry=0xdb950e10) at ../libgudev/gudev/gudevdevice.c:163
#11 0xeba434af in g_udev_client_query_by_subsystem_and_name (client=0xdb95a100, subsystem=0xe91c77c8 "net",
name=0xe31ca2b0 "wlan0") at ../libgudev/gudev/gudevclient.c:511
#12 0xe9155927 in ?? ()
from /home/karthin/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libnm.so.0
#13 0xe9156e40 in nm_device_get_vendor ()
from /home/karthin/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libnm.so.0
[...]
(gdb) f 7
(gdb) info sym device_get_tags_generation
udev_device_get_current_tags_list_entry + 49 in section .text of /usr/lib32/libudev.so.1
The version provided by Steam is much, much older than the version provided by the system. These two versions are not ABI-compatible, hence the difference in soversion.
$ ls -l /home/karthin/.local/share/Steam/ubuntu12_32/steam-runtime/lib/i386-linux-gnu/libudev.so.0
lrwxrwxrwx 1 karthin karthin 17 Mar 23 12:06 /home/karthin/.local/share/Steam/ubuntu12_32/steam-runtime/lib/i386-linux-gnu/libudev.so.0 -> libudev.so.0.13.0
$ ls -l /usr/lib32/libudev.so.1
lrwxrwxrwx 1 root root 16 Jun 1 14:23 /usr/lib32/libudev.so.1 -> libudev.so.1.7.6
lib32-libudev0-shim
LD_LIBRARY_PATH
, Steam prefers dependencies provided by the system over its own. lib32-libudev0-shim
installs a version of libudev.so.0
that loads libudev.so.1
, so there will be no ABI-related issues.Note that while these solutions do work, using them only avoids the issue. In the future, if another library were to use new libudev
features not available in the version provided by the Steam runtime, you may run into ABI-related issues.
lib32-libnm
libnm
makes calls to libgudev
, which subsequently makes calls to libudev
, causing the crash. Using a version of libnm
provided by Arch, which has no dependency on libgudev
, does not cause the crash.libgudev
lib32-libgudev
libgudev
it provides.I had this issue today after upgrading as well. Arch/EndeavourOS with KDE. Downgrading the two libgudev packages mentioned by GithubUser5462 and doing a steam reset got it working for me.
Ditto for the update and then steam core dump. Downgrading libgudev packages resolved the problem here as well. (Well... band-aided it.)
Here are some solutions that worked for me. I have only tested these on Arch Linux:
1. Installing `lib32-libudev0-shim` Because of the order in `LD_LIBRARY_PATH`, Steam prefers dependencies provided by the system over its own. `lib32-libudev0-shim` installs a version of `libudev.so.0` that loads `libudev.so.1`, so there will be no ABI-related issues. 2. Installing `lib32-libnm` `libnm` makes calls to `libgudev`, which subsequently makes calls to `libudev`, causing the crash. Using a version of `libnm` provided by Arch does not cause the crash.
Did these two and it worked great.
On Vanilla Arch myself.
I tried to uninstall lib32-libgudev at first but I was stopped bercause proton-ge-custom was using it as a dependency. This issue showed for me first when I updated proton-ge-custom within the last 24 hours so maybe there is something to investigate there.
Replying to https://github.com/ValveSoftware/steam-for-linux/issues/9805#issuecomment-1627611123
I found just installing libnm and lib32-libnm from the Arch repo fixed it, no need to downgrade or install anything else.
I'm running EndeavourOS.
There is an Arch bug 75157 to add lib32-libnm/lib32-va as (opt)depends just over an year ago.
I solved it after installing the lib32-libnm. The 'lib32-' prefix is necessary.
Just uninstall lib32-libgudev, I am using Arch.
yay -R lib32-libgudev
Hello everyone,
I've noticed that many people here are trying solutions such as uninstalling/downgrading lib32-libgudev
or installing lib32-libnm
. While these solutions may work for now, I wouldn't recommend them as long-term solutions. I have updated my comment with my reasoning.
@devkarthin note that lib32-libudev0-shim
should not be needed, if new(er) system components are used - components outside of the (old) Ubuntu based root, use dlopen(libudev.so.1)
, falling back to libudev.so.0
.
While the Ubuntu based files are demoted (with some exceptions), when newer system libraries are found - as you have already noticed.
A while ago the Steam Runtime developer maintaining the library detection/promotion "greatly encouraged" that the Steam package would (opt)depends on lib32-libnm and friends. The bugs have been opened since alas :frowning_face:
I'll confirm that adding lib32-libnm resolved the issue for me. The updated libgudev files do not crash Steam with the addition.
Installing lib32-libudev0-shim
did not work for me on Artix Linux. Uninstalling lib32-libgudev did.
Confirming yay -Syu lib32-libnm
fixed this issue for me
same for me pacman -Syu lib32-libnm
(have no revert libgudev
)
Installing lib32-libudev0-shim fixed it for me on Manjaro 23.0.0
sudo pacman -U https://archive.archlinux.org/packages/l/libgudev/libgudev-237-2-x86_64.pkg.tar.zst sudo pacman -U https://archive.archlinux.org/packages/l/lib32-libgudev/lib32-libgudev-237-2-x86_64.pkg.tar.zst steam --reset
Got it working for me.
Edit: Actually it looks like the reset was enough, i updated libgudev and steam still works.
thanks. this fixed it for me.
sudo pacman -U https://archive.archlinux.org/packages/l/libgudev/libgudev-237-2-x86_64.pkg.tar.zst sudo pacman -U https://archive.archlinux.org/packages/l/lib32-libgudev/lib32-libgudev-237-2-x86_64.pkg.tar.zst steam --reset
Got it working for me.
Edit: Actually it looks like the reset was enough, i updated libgudev and steam still works.
Downgrade is what fixed it for me.
i upgraded and reset but it didn't work.
so, downgrade is the only thing that works for me.
Confirming
yay -Syu lib32-libnm
fixed this issue for me
This also works for me.
Debian-based (EDIT: "Ubuntu" just for people searching) users can do sudo apt install libnm0:i386
which fixed it for me.
Confirming that I had this issue, which was resolved by installing lib32-libudev0-shim
. I'm on Arch Linux.
Same happend to me recently on Garuda Linux Soaring Raptor. Doing sudo pacman -S lib32-libudev0-shim
indeed fixed it.
Uninstalling
proton-ge-custom-bin
worked for me
That "works" because it's also removing all dependencies of proton-ge-custom-bin
, which includes lib32-libgudev
.
Also everybody please don't comment on this issue with "confirming this or that worked for me". This has next to no value, simply upvote the respective comment.
Friend of mine had the issue. Nothing in the thread fixed it for him. In the end on his computer there is no lib32-libnm or lib-gudev, because this is the current state of his computer after trying all the various combination of the "solutions" here, so here's mine: Totally random solution, it didn't fix anything as I can see my friend Steam log is nothing compared to my working Steam log, however he now can start and use steam. I did a steam --reset
, then started Steam, which almost ALWAYS worked whatever workaround was applied (only the subsequent launch were guaranteed to not work after the reset), so in the first launch after the --reset
I went into the Steam Settings, and I Enabled the GPU accelerated Rendering in web views
. Subsequent Steam restart now works. All other subsequent restarts now work. But something is still very messed I feel, but it works for him now.
The solution for my friend was to delete the folder ~/.cache/nvidia
but only after deleting the folder ~/.nv
which seemed to take precedence over the other. Seems like some GLCache issue related. This work with or without the setting for GPU accelerated rendering.
Workarounds aside, what is the stance of Valve developers on this issue's actual solution?
This could be considered a packaging issue, where distro maintainers need to be aware of the correct compatibility packages or shims which need to be added to correctly package Steam (such as what has been suggested over at Arch with https://bugs.archlinux.org/task/75157, though based on comments here, there are also other affected distros).
It could also be considered a Valve tech-debt issue where Steam needs to be updated to modern versions of these libraries so that compatibility workarounds or packaging shims aren't necessary. Or, at the very least, documenting more openly what these dependencies are so that distro maintainers don't need to rely on reactively debugging issues to figure out what needs to be patched.
Valve devs have been relatively quiet on this issue since workarounds were reported, but it'd be useful for folks watching this issue to hear a substantive update on where this goes from here.
Workarounds aside, what is the stance of Valve developers on this issue's actual solution?
I'm not a Valve developer, but I help them with the Steam Runtime and packaging. If Valve developers are busy with other things (or on vacation, since it's that time of year), then I'm probably the best you're going to get in the short term.
This could be considered a packaging issue, where distro maintainers need to be aware of the correct compatibility packages or shims which need to be added to correctly package Steam (such as what has been suggested over at Arch with https://bugs.archlinux.org/task/75157, though based on comments here, there are also other affected distros).
tl;dr: Yes, there is a list of key libraries that packagers should add dependencies on. For various annoying technical reasons the Steam Runtime cannot reliably provide everything.
Valve's official packaging for the Steam client is https://repo.steampowered.com/steam/, which is intended to work on Ubuntu, and contains the "bootstrapper" that can be used to install the rest of Steam. As far as I'm aware, everyone who packages the Steam client bases their packaging in some way on that.
If you unpack the "source code" from https://repo.steampowered.com/steam/archive/stable/steam_latest-stable.tar.gz (currently version 1.0.0.78) and look in debian/control
, you will see some lists of mandatory and optional dependencies in the steam-libs-amd64
and steam-libs-i386
stanzas; and in debian/changelog
you can find the reasons why several of them are mandatory or optional dependencies (often written by me).
I would recommend that anyone packaging Steam for another operating system should pull in their operating system's equivalent of the packages listed in Valve's Steam bootstrapper packaging, with a similar strength of dependency. For example, in Ubuntu, steam-libs-i386
pulls in the libnm0:i386
package as a Recommends
(a dependency that is installed by default, but can be removed if you specifically ask to remove it). The Arch equivalent is that in Arch, it should pull in lib32-libnm
, either as a hard dependency or an optdepends
(I'm not sure which, I don't know how "strong" an Arch optdepends
is). This is not just because of dependency stack issues like this one, but also because libnm
is more likely to be able to communicate successfully with a matching version of NetworkManager, and in the past we've seen crashes when sufficiently badly mismatched versions communicate.
I would also recommend that users of Debian/Ubuntu derivatives install the Recommends unless they have a good reason not to - they're all listed there and installed by default by a reason.
A known issue in the packaging of Valve's Steam bootstrapper is that steam-libs-amd64
and steam-libs-i386
are not mandatory dependencies of the steam-launcher
package. They should be, but because of how Valve have historically documented the installation procedure for steam-launcher
, it is not possible to make them mandatory at the packaging level; instead, a script run during Steam startup tries to install them. This is not ideal, but it's the best that can be done, given the historical constraints that exist. Please package as though steam-libs-amd64
and steam-libs-i386
were mandatory dependencies - they would be if we could do that.
Similarly, some of the dependencies in steam-libs-*
are weaker than they should ideally be, because Valve's Steam bootstrapper aims to support old versions of Ubuntu where not all the packages existed. If you're packaging Steam for a specific newer distribution, then you can (and probably should) make some of the dependencies stronger.
With a different hat on, I'm a maintainer of Debian's steam-installer package, which is considered official by Debian but unofficial by Valve. steam-installer
pulls in a list of libraries similar to the ones in Valve's Steam bootstrapper: in fact it's a somewhat longer list, and the dependencies are stronger.
Valve's Steam bootstrapper packaging does not currently have a dependency on libudev0
(which in Debian/Ubuntu contains the same code as Arch's lib32-libudev0-shim
), but honestly it probably should have a Recommends. I'll look into that, but I'm not fully in control of the release schedule for the Steam bootstrapper (as I said, I'm not a Valve developer), so I can't give any specific timeline.
It could also be considered a Valve tech-debt issue where Steam needs to be updated to modern versions of these libraries so that compatibility workarounds or packaging shims aren't necessary.
I wish it was that easy! The 'scout' Steam Runtime included with Steam is constrained to contain only very old libraries, because it usually sets the minimum library versions for any OS that Steam can run on: for many of the included libraries, nothing older can be supportable, however much Valve might want to support it. This is particularly problematic for older "LTS" distributions (I believe Ubuntu 16.04 is currently the minimum), or for derivatives based on an older LTS distribution (for example the latest release of Linux Mint is often based on an older-than-current Ubuntu LTS release).
For a few higher-level libraries with "nice" version numbering (like SDL), it is possible to include backports in the Steam Runtime, and we do; but for lower-level libraries we often can't.
The libnm in scout is already a backport of a somewhat more modern version (from Debian 9, according to my notes), and is probably the most modern version that's feasible to include: when working on a 10+ year old base, the dependency chains for other backports quickly become prohibitive.
libudev is likely to be one of the difficult ones to backport because of its history: the SONAME break from libudev.so.0 to .so.1, the transition from independent project to part of systemd, and the forked version in libeudev. All of those are factors that make it more likely to be non-backportable.
One possible route that might be taken in future versions of Steam is moving some of its functionality into a container, similar to how Proton games are handled, which would allow the container to have a more modern library stack (the ones used for Proton are based on Debian 10 and 11) without breaking compatibility with older host OS distributions. That comes with its own compatibility and complexity headaches, but at some point it's going to become necessary anyway. I don't know whether the parts that communicate with NetworkManager would be candidates for that treatment, but I hope so!
Or, at the very least, documenting more openly what these dependencies are so that distro maintainers don't need to rely on reactively debugging issues to figure out what needs to be patched.
I don't control what documentation Valve offers, so I can't help you with that. The dependency lists in the Steam bootstrapper are the closest thing there is to a canonical dependency list right now.
Thanks for an incredibly detailed response. I'm sure there will be much more discussion soon but just one quick point for now (emphasis mine):
For example, in Ubuntu, steam-libs-i386 pulls in the libnm0:i386 package as a Recommends (a dependency that is installed by default, but can be removed if you specifically ask to remove it). The Arch equivalent is that in Arch, it should pull in lib32-libnm, either as a hard dependency or an optdepends (I'm not sure which, I don't know how "strong" an Arch optdepends is).
From the mighty Wiki (emphasis mine) (https://wiki.archlinux.org/title/PKGBUILD#optdepends):
An array of packages that are not needed for the software to function, but provide additional features. This may imply that not all executables provided by a package will function without the respective optdepends. If the software works on multiple alternative dependencies, all of them can be listed here, instead of the depends array.
optdepends dependencies aren't installed alongside the package by default. If they're brought in by another package (say package-a
), and a user recursively removes package-a
and its dependencies (pacman -Rs package-a
), the dependency will be kept on the machine. If a user explicitly removes the dependency, pacman
will allow the removal (while printing a warning about the optional dependency).
This sounds mostly similar to "Recommends" except that it's not installed by default. However it also seems like an anti-pattern where the optional dependencies are sometimes functionally necessary as opposed to just enabling optional features. At any rate, this is being discussed across several Arch Linux issues including the one I linked previously.
That sounds to me as though Arch optdepends
are more like apt's Suggests (perhaps a little stronger than Suggests, but definitely weaker than Recommends), and that's really too weak for a lot of the libraries Steam benefits from.
where the optional dependencies are sometimes functionally necessary as opposed to just enabling optional features
The problem here is that in principle, the Steam Runtime provides nearly everything Steam needs, making an equivalent library at OS level merely a nice-to-have that might have more features or fewer bugs - but because certain combinations of newer libraries will crash, we can easily get dependency relationships that aren't even representable by common package managers, like "if you have libfoo >= 3 then you also need libbar".
Same problem on gentoo. After rebuild networkmanager with abi_x86_32 flag problem disappeared
After rebuild networkmanager with abi_x86_32 flag problem disappeared
If this installs a 32-bit (i386) version of libnm.so.0
, then that's exactly Gentoo's equivalent of installing libnm0:i386
on Debian/Ubuntu or lib32-libnm
on Arch.
- Installing
lib32-libudev0-shim
- Because of the order in
LD_LIBRARY_PATH
, Steam prefers dependencies provided by the system over its own.lib32-libudev0-shim
installs a version oflibudev.so.0
that loadslibudev.so.1
, so there will be no ABI-related issues.
In principle this should be the good workaround, but unfortunately, this is not completely true: archlinux/libudev0-shim#4 prevents that from working the way it should in distros that package this shim (at least Arch, Debian and Ubuntu, possibly others).
The Steam Runtime cannot unconditionally prefer dependencies provided by the system, because part of the purpose of the Steam Runtime is being able to run Steam and Steam games on older "LTS" distributions such as Debian stable/oldstable, Ubuntu LTS and the RHEL/CentOS family, and it sometimes provides backported libraries that are newer than the versions in the oldest OS that is supported (notably SDL). When that happens, the Steam Runtime must detect it, and use its own backported library if necessary - but we can only do that if the versions compare in the intended order.
I'm going to look into whether we can work around this in the Steam Runtime, but it would be nice to fix this upstream in Arch's libudev0-shim rather than having to work around it.
Gentoo has a slightly different libudev.so.0 shim and that one should work OK, because if the Steam Runtime can't identify whether a library is older or newer (in particular if no symlinks are involved at all), then it prefers the host OS copy.
Until the issues with libudev.so.0
version comparison are resolved, the workaround I would suggest as most likely to be reliable is to install a 32-bit libnm.so.0
(lib32-libnm
on Arch, libnm0:i386
on Debian/Ubuntu, or whatever is the closest equivalent on other OSs). Having this library at the OS level has solved other Steam crashes in the past (when an older libnm has trouble talking to a new NetworkManager) so it's a good idea in general, whether this issue is solved differently or not.
In some environments it might also be necessary to install a 32-bit libusb-1.0.so.0
(lib32-libusb
on Arch, libusb-1.0-0:i386
on Debian/Ubuntu, or your OS's equivalent). That's the other library in the Steam Runtime, apart from libnm.so.0
, that could pull in libudev. (You might have this already as a dependency of something else.)
I'm looking at possible solutions for this on the Steam Runtime side, but if it's solvable from there then it will take some time.
I'm looking at possible solutions for this on the Steam Runtime side, but if it's solvable from there then it will take some time.
We've been able to backport a somewhat more recent libudev for the Steam Runtime while maintaining compatibility with older distributions and eudev, so a future Steam beta will hopefully resolve this. Having both 64- and 32-bit system copies of libudev.so.1
from 2015 or later is recommended: the minimum would be systemd v215 or eudev v1.9, but newer would be better. If present, the runtime will prefer to use those instead of its own fallback version.
Until then, the workaround that I'd recommend is as described in my previous comment: install a 32-bit system copy of libnm.so.0
, and if that doesn't resolve the crash, try doing the same for libusb-1.0.so.0
.
I installed lib32-libnm
and the problem was solved.
By the way, I haven't installed lib32-libudev0-shim
. And I don't install the Proton-GE
from archlinuxcn
or aur
, but from the official repository.
Sorry for my poor English.
on Gentoo I've fixed with
echo sys-libs/libudev-compat abi_x86_32 > /etc/portage/package.use/steam
emerge -vq sys-libs/libudev-compat
Your system information
Please describe your issue in as much detail as possible:
Arch Linux recently updated the
libgudev
andlib32-libgudev
packages to version238
in accordance with the release upstream. After updating, Steam crashes during launch. I have included the last couple lines before the crash below:Downgrading
libgudev
andlib32-libgudev
to version237-2
works.Steps for reproducing this issue:
libgudev
andlib32-libgudev
to version238-1
Temporary WorkaroundDowngrading thelibgudev
andlib32-libgudev
packages to version237-2
is a temporarily workaround to get Steam to launch. The downgrade AUR package can be used to do this. Remember to update these packages when this issue is fixed.Solutions
See this comment by devkarthin for a couple solutions.