Same here with steam client beta but on a ext4 partition with archlinux; let me know if more info is needed.
Same here with steam client beta but on a ext4 partition with archlinux
This pretty much rules out my btrfs sub volume setup.
This is not actually because your directories are on different filesystems, it's because the experimental steamrt3c client is/was wrongly trying to run some commands that start a new container inside the steamrt3c container. The steamrt3c container has several different mount points for the same filesystem, and hard links won't work between these different mount points.
Starting a container inside a container isn't expected to work anyway, and the command will eventually fail with message bwrap: execvp /usr/lib/pressure-vessel/from-host/libexec/steam-runtime-tools-0/pv-adverb: Too many levels of symbolic links.
This is a known issue and is closely related to #13006 (possibly a duplicate of #13006, depending how you count issues). The solution should be for the Steam client to stop trying to launch diagnostic commands like d3ddriverquery64.exe inside the steamrt3c container, and instead launch each one in its own container in parallel, the same way that actual games get launched.
This should be fixed in the latest beta client
Closing per the last comment.
the Steam client to stop trying to launch diagnostic commands like
d3ddriverquery64.exeinside the steamrt3c container
@smcv Will such a fix also prevent the wine prefix "0" created over and over again? Sometimes, when Steam starts, this gets created and swarmed with d3ddriverquery64.exe processes. But I observed it long before steamrt3c has even been talked about. It's a long standing issue for me.
Since this is closed, and if that is a different issue: Is it worth opening a new bug report for it?
Will such a fix also prevent the wine prefix "0" created over and over again?
I don't know, I can't see into the code that runs d3ddriverquery64.exe. If those processes are run under Proton/Wine, then they're going to need some sort of wineprefix, otherwise they won't/can't work. If they were using a wineprefix named 0, then they are (or were) probably being run as though they were Steam app-ID 0.
I observed it long before steamrt3c has even been talked about
That seems like a strong indication that it's nothing to do with steamrt3c or this issue report, and so shouldn't be discussed further on this issue. If this is something that you can reproduce in current Steam Client versions, and it has an impact on your use of Steam, then I'd recommend opening a separate issue describing the problem and its impact.
Nothing extracted yet.
Your system information
Please describe your issue in as much detail as possible:
Somehow, pv thinks that directories are on different file systems and fails to create hard-links, it later also runs into an infinite loop. I'm not sure why that is: Yes, I'm using btrfs subvolumes, for
.local/share/Steamand also forcompatdatato create snapshots - but none of those applies to the paths mentioned: They are within the same subvolume. But it's probably still true somehow because it also fails to create hardlinks (which won't work across volume boundaries), and finally it ends in an infinite loop broken by "too many levels".