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 problem

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](/issue/ValveSoftware/steam-for-linux/10) _g_udev_device_new (udevice=udevice@entry=0xdb950e10) at ../libgudev/gudev/gudevdevice.c:163
[#11](/issue/ValveSoftware/steam-for-linux/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](/issue/ValveSoftware/steam-for-linux/12) 0xe9155927 in ?? ()
   from /home/karthin/.local/share/Steam/ubuntu12_32/steam-runtime/usr/lib/i386-linux-gnu/libnm.so.0
[#13](/issue/ValveSoftware/steam-for-linux/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

Solutions

• 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.

Other solutions

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.

• 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, which has no dependency on libgudev, does not cause the crash.
• Preloading/installing an older version of the libgudev
  • Older versions do not call the failing function.
• Uninstalling lib32-libgudev
  • This makes Steam use the version of 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.

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 of libudev.so.0 that loads libudev.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

I commented above that my Steam was working with lib32-libudev0-shim, but it stopped working today. (I didn't update my system before it broke, but I think Steam updated itself.)

I installed lib32-libnm (lib32-libusb was already installed) and that fixed the issue.

@MathSquared the Arch shim has a bug that would prevent if from working reliably see https://github.com/archlinux/libudev0-shim/issues/4. It also has a secondary issue, which you might exhibit if you rebuild it https://github.com/archlinux/libudev0-shim/pull/3

Not much we can do about either - it's up-to the Arch devs to press the Merge button.

Is this actually still an issue? I added 32-bit "libudev0" as a dependency on Gentoo to address this yesterday, but now a user tells me the problem had already gone away in the mean time. I build most things with 32-bit, so I haven't been able to tell myself.

Is this actually still an issue?

"It's complicated". Whether it is an issue depends on the exact combination of libraries that you have installed on the host system, and on how lucky you have been. I would recommend that packagers should include a solution or workaround on the packaging side: typically the workaround will be low-effort and make the package work considerably more reliably, reducing the number of bug reports that the packager receives, which seems like a good deal to me.

As I said in https://github.com/ValveSoftware/steam-for-linux/issues/9805#issuecomment-1660892183, a solution to this on the Steam Runtime side is in the pipeline and will hopefully be in a future Steam beta. I don't have control over Steam's release cycle, so I can't predict when this will happen. If all goes well, when this change has got all the way through the release pipeline to stable status, it will make the workarounds unnecessary (but also harmless, so there will be no need to rush to remove them).

I added 32-bit "libudev0" as a dependency on Gentoo to address this yesterday

Thank you, I think that is an appropriate change for Gentoo packaging. Gentoo's libudev0 shim is not installed in exactly the same way as Arch's (it doesn't suffer from https://github.com/archlinux/libudev0-shim/issues/4), so I think this will act as a reliable workaround on Gentoo specifically (but not for anyone else).

Non-Gentoo-based distributions that have a shim version of libudev0 implemented in terms of libudev1 tend to use the one that originated in Arch - for instance that's what we have in Debian. This is not (yet!) a reliable workaround as long as https://github.com/archlinux/libudev0-shim/pull/3 and https://github.com/archlinux/libudev0-shim/issues/4 are unfixed: https://github.com/archlinux/libudev0-shim/pull/3 is fixed in Debian but not in Arch, and https://github.com/archlinux/libudev0-shim/issues/4 is not fixed anywhere. The changes that are queued for a future Steam beta include a workaround for https://github.com/archlinux/libudev0-shim/issues/4 which should make this more reliable.

For users of non-Gentoo-based distributions like Arch, Debian and Ubuntu, my recommendation is still https://github.com/ValveSoftware/steam-for-linux/issues/9805#issuecomment-1651882221. For example, in Debian's steam-installer package, I upgraded libnm0:i386 from Recommends to Depends and added libusb-1.0-0:{amd64,i386} to Recommends.

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.

This change arrived in yesterday's Steam client beta release (1692041866, 14 August 2023), which should work correctly even without the workarounds that I previously recommended. In the fixed version, ~/.steam/root/ubuntu12_32/steam-runtime/version.txt should say 0.20230801.56012 or later.

I would still recommend that packagers of the Steam client should give it at least a weak/optional dependency on 32-bit libnm.so.0 (Debian/Ubuntu: libnm0:i386, Arch: lib32-libnm, or your distribution's equivalent). As I said before, even if it isn't necessary for this crash, we've seen crashes with previous Steam releases that could be resolved by upgrading the 32-bit libnm.so.0 to a version that matches the installed version of NetworkManager. In Debian, I used Recommends, which is an optional dependency that is installed by default but can be removed by the user: I think that's an appropriate strength of dependency to use here.

The changes that are queued for a future Steam beta include a workaround for https://github.com/archlinux/libudev0-shim/issues/4 which should make [using Arch's libudev0-shim] more reliable

This change was ValveSoftware/steam-runtime@2677a6e and is also included in yesterday's Steam client beta (1692041866, 14 August 2023).

Is this actually still an issue? I added 32-bit "libudev0" as a dependency on Gentoo to address this yesterday, but now a user tells me the problem had already gone away in the mean time. I build most things with 32-bit, so I haven't been able to tell myself.

Yes. I had this issue after upgrading to libgudev-238. Installing sys-libs/libudev-compat fixed it for me.
Building net-misc/networkmanager with USE=abi_x86_32 probably would also work.

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

This solved the problem for me, I'm using the latest packages too.

Removing lib32-gudev is a workaround, not a good solution for this.

As said above, the good solution is now included in the Steam client beta branch, and will ship in the stable (general-availability) branch at some point in the future (I cannot predict a timeline for this, it depends what is happening in unrelated Steam development topics).

If you cannot use the beta for whatever reason, better workarounds can be found in https://github.com/ValveSoftware/steam-for-linux/issues/9805#issuecomment-1651882221.

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.

This change arrived in yesterday's Steam client beta release (1692041866, 14 August 2023) ... In the fixed version, ~/.steam/root/ubuntu12_32/steam-runtime/version.txt should say 0.20230801.56012 or later.

This updated runtime is now included in the general-availability (default, stable, non-beta) version of the Steam client. @kisak-valve, if there is no negative feedback in the next few days, I think we can close this issue.

I don't see any release notes for this update in the usual place yet; the change seems to have gone out unannounced.

The workaround mentioned in https://github.com/ValveSoftware/steam-for-linux/issues/9805#issuecomment-1678860610 should no longer be needed, but it's harmless and might prevent unrelated crashes, so I would still recommend it to distros/packagers.