-
Problem
and I’ve installed steam-1.0.0.79-3.fc40.src.rpm | RPM Info | koji.
I was able to update it:
login, and initially, view its GUI. However, immediately afterward, I saw
and its system tray context menu began to take almost 20 to appear.
Unfortunately, because
$Env:PATH/steamisn’t a binary (instead a symbolic link to a.shscript)gdbcan’t debug the crashes, so I can’t easily report them via Abrtnor gain useful information via KDE’s
coredumpctlGUI:PID: 37342 (steamwebhelper) UID: 1000 (RokeJulianLockhart) GID: 1000 (RokeJulianLockhart) Signal: 11 (SEGV) Timestamp: Tue 2024-03-26 20:03:55 GMT (1h 22min ago) Command Line: ./steamwebhelper --no-sandbox -lang=en_US -cachedir=/home/RokeJulianLockhart/.local/share/Steam/config/htmlcache -steampid=33732 -buildid=1709846872 -steamid=76561198832168690 -logdir=/home/RokeJulianLockhart/.local/share/Steam/logs -uimode=7 -startcount=8 -steamuniverse=Public -realm=Global -clientui=/home/RokeJulianLockhart/.local/share/Steam/clientui -steampath=/home/RokeJulianLockhart/.local/share/Steam/ubuntu12_32/steam -launcher=0 -no-restart-on-ui-mode-change --enable-smooth-scrolling --password-store=basic --log-file=/home/RokeJulianLockhart/.local/share/Steam/logs/cef_log.txt --disable-quick-menu --disable-features=DcheckIsFatal Executable: /home/RokeJulianLockhart/.local/share/Steam/ubuntu12_64/steamwebhelper Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-steam-63e75632331a40e59781fcd5536d5a8d.scope Unit: user@1000.service User Unit: app-steam-63e75632331a40e59781fcd5536d5a8d.scope Slice: user-1000.slice Owner UID: 1000 (RokeJulianLockhart) Boot ID: f5ffd89df9f94695b6a8d6ee96a70bb9 Machine ID: bf7481ba37594c3ab0f27c3b2af4c34c Hostname: sayw4i Storage: /var/lib/systemd/coredump/core.steamwebhelper.1000.f5ffd89df9f94695b6a8d6ee96a70bb9.37342.1711483435000000.zst (present) Size on Disk: 5.5M Message: Process 37342 (steamwebhelper) of user 1000 dumped core. Module /run/host/usr/lib64/dri/armada-drm_dri.so from rpm mesa-24.0.0-2.fc40.x86_64 Module /run/host/usr/lib64/libpciaccess.so.0.11.1 from rpm libpciaccess-0.16-12.fc40.x86_64 Module /run/host/usr/lib64/libedit.so.0.0.72 from rpm libedit-3.1-50.20230828cvs.fc40.x86_64 Module /run/host/usr/lib64/libdrm_intel.so.1.0.0 from rpm libdrm-2.4.120-3.fc40.x86_64 Module /run/host/usr/lib64/libGLX_mesa.so.0.0.0 from rpm mesa-24.0.0-2.fc40.x86_64 Module /run/host/usr/lib64/libdrm_nouveau.so.2.0.0 from rpm libdrm-2.4.120-3.fc40.x86_64 Module /run/host/usr/lib64/libdrm_amdgpu.so.1.0.0 from rpm libdrm-2.4.120-3.fc40.x86_64 Module /run/host/usr/lib64/libelf-0.191.so from rpm elfutils-0.191-4.fc40.x86_64 Module /run/host/usr/lib64/libdrm_radeon.so.1.0.1 from rpm libdrm-2.4.120-3.fc40.x86_64 Module /run/host/usr/lib64/libsensors.so.4.5.0 from rpm lm_sensors-3.6.0-18.fc40.x86_64 Module /run/host/usr/lib64/libxcb-xfixes.so.0.0.0 from rpm libxcb-1.16-4.fc40.x86_64 Module /run/host/usr/lib64/libxcb-sync.so.1.0.0 from rpm libxcb-1.16-4.fc40.x86_64 Module /run/host/usr/lib64/libxcb-present.so.0.0.0 from rpm libxcb-1.16-4.fc40.x86_64 Module /run/host/usr/lib64/libxcb-dri3.so.0.1.0 from rpm libxcb-1.16-4.fc40.x86_64 Module /run/host/usr/lib64/libxshmfence.so.1.0.0 from rpm libxshmfence-1.3.2-3.fc40.x86_64 Module /run/host/usr/lib64/libXxf86vm.so.1.0.0 from rpm libXxf86vm-1.1.5-6.fc40.x86_64 Module /run/host/usr/lib64/libxcb-dri2.so.0.0.0 from rpm libxcb-1.16-4.fc40.x86_64 Module /run/host/usr/lib64/libxcb-glx.so.0.0.0 from rpm libxcb-1.16-4.fc40.x86_64 Module /run/host/usr/lib64/libglapi.so.0.0.0 from rpm mesa-24.0.0-2.fc40.x86_64 Module /run/host/usr/lib64/libudev.so.1.7.8 from rpm systemd-255.4-1.fc40.x86_64 Module /run/host/usr/lib64/libcap.so.2.69 from rpm libcap-2.69-3.fc40.x86_64 Module /run/host/usr/lib64/libX11-xcb.so.1.0.0 from rpm libX11-1.8.7-3.fc40.x86_64 Module /run/host/usr/lib64/libwayland-client.so.0.22.0 from rpm wayland-1.22.0-3.fc40.x86_64 Module /run/host/usr/lib64/libunistring.so.5.0.0 from rpm libunistring-1.1-7.fc40.x86_64 Module /run/host/usr/lib64/libzstd.so.1.5.5 from rpm zstd-1.5.5-5.fc40.x86_64 Module /run/host/usr/lib64/libffi.so.8.1.2 from rpm libffi-3.4.4-7.fc40.x86_64 Module /run/host/usr/lib64/libidn2.so.0.4.0 from rpm libidn2-2.3.7-1.fc40.x86_64 Module /run/host/usr/lib64/libxcb-shm.so.0.0.0 from rpm libxcb-1.16-4.fc40.x86_64 Module /run/host/usr/lib64/libxcb-randr.so.0.1.0 from rpm libxcb-1.16-4.fc40.x86_64 Module /run/host/usr/lib64/libwayland-server.so.0.22.0 from rpm wayland-1.22.0-3.fc40.x86_64 Module /run/host/usr/lib64/libXau.so.6.0.0 from rpm libXau-1.0.11-6.fc40.x86_64 Module /run/host/usr/lib64/libGLdispatch.so.0.0.0 from rpm libglvnd-1.7.0-4.fc40.x86_64 Module /run/host/usr/lib64/libGLX.so.0.0.0 from rpm libglvnd-1.7.0-4.fc40.x86_64 Module /run/host/usr/lib64/libz.so.1.3.0.zlib-ng from rpm zlib-ng-2.1.6-2.fc40.x86_64 Module /run/host/usr/lib64/libgbm.so.1.0.0 from rpm mesa-24.0.0-2.fc40.x86_64 Module /run/host/usr/lib64/libxcb.so.1.1.0 from rpm libxcb-1.16-4.fc40.x86_64 Module /run/host/usr/lib64/libdrm.so.2.4.0 from rpm libdrm-2.4.120-3.fc40.x86_64 Module /run/host/usr/lib64/libexpat.so.1.9.2 from rpm expat-2.6.2-1.fc40.x86_64 Module /run/host/usr/lib64/libGL.so.1.7.0 from rpm libglvnd-1.7.0-4.fc40.x86_64 Module /run/host/usr/lib64/libX11.so.6.4.0 from rpm libX11-1.8.7-3.fc40.x86_64 Module /run/host/usr/lib64/libXfixes.so.3.1.0 from rpm libXfixes-6.0.1-3.fc40.x86_64 Module /run/host/usr/lib64/libXext.so.6.4.0 from rpm libXext-1.3.6-1.fc40.x86_64 Stack trace of thread 37446: #0 0x0000000000000000 n/a (n/a + 0x0) ELF object binary architecture: AMD x86-64 -
-
Cause
Not yet known.
-
Related Issues
-
Components for Fedora doesn’t list Steam, so I’ll report it at https://bugzilla.rpmfusion.org/enter_bug.cgi?product=Fedora&component=steam.
-
-
Workarounds
How ironic that despite Steam from Flathub might not start on Fedora 38,
flatpak install https://dl.flathub.org/repo/appstream/com.valvesoftware.Steam.flatpakref && `
flatpak update app/com.valvesoftware.Steam/x86_64/stable --commit=98f034b154eed70b957bedcba0a5ce3785e70999b4aef85e1f6dd66f2eb15ff7
worked for me.
From Ask Fedora to Proposed Common Issues
I was able to install and run steam (from rpmfusion) on my fedora 40 test bed with no problems
1 Like
@computersavvy, how weird, considering that I only installed this OS yesterday, and I’ve installed solely VSCode, GIMP, and Steam. Anything worth checking to diagnose the cause?
From Proposed Common Issues to Ask Fedora
This could be a good candidate for a Common Issue, if it really affected a large number of people. Let’s see if it does, first. Then we can nominate it.
I can personally run Steam on F40 (installed from Flathub) just fine.
@rokejulianlockhart Your reports are extremely hard to read. They feels like random characters scattered around the page. If you want people to care and get involved in your topics, I suggest that you make them easier to read. That would involve changing your name to a regular name instead of pseudo code (it drags my eyes and distracts me for every single comment you make), avoiding pasting a link without any explanation and avoiding too much mixing text with URLs (especially long URLs), like here. Name your hyperlinks, or visually indent them into a special paragraph and use traditional [1][2][3] notation, if plain text is needed. Make it look and read good. Those are just recommendations, but might get you better feedback from people.
1 Like
In my case I also see steamwebhelper crashes, but they don’t prevent Steam from working.
In your traceback, I see:
Module /run/host/usr/lib64/dri/armada-drm_dri.so from rpm mesa-24.0.0-2.fc40.x86_64
I have no idea what it is. What are your system specs? Architecture, GPU vendor? From a quick search, this looks like something ARM-related, which is outside regular mainstream hardware and is more likely to suffer from issues like this. In that case, a report in Mesa upstream or Valve repository is probably the best way forward.
Had you done a full system upgrade after the install using sudo dnf upgrade --refresh -y followed by a reboot before running steam?
I had done that.
1 Like
-
Diagnosis
-
Very normal -
kcmshell6 kcm_inforeportsOperating System cpe:/o:fedoraproject:fedora:40KDE Plasma Version 6.0.2 KDE Frameworks Version 6.0.0 Qt Version 6.6.2 Kernel Version 6.8.2-300.fc40.x86_64 (64-bit) Graphics Platform Wayland Processors 12 × AMD Ryzen 5 7600X 6-Core Processor Memory 30.5 GiB of RAM Graphics Processor AMD Radeon RX 5700 Manufacturer ASRock Product Name X670E Taichi -
As aforedemonstrated, that is untrue - all of my Linux devices are x86 (or x86-64, as this one is).
-
Although ultimately unrelated, I do intend to report something to Mesa:
-
-
-
-
Report
-
I fail to understand what might need to be explained by that URI. Surely its domain demonstrates that it is a link to a Bugzilla report…?
Regardless, the posts are locked now, but if I’m provided modification rights to them again, I’ll try to explain better.
-
I agree. However, as
demonstrates, the sole solution which would be of use to me is Discourse implementing at least separate forename and surname fields.
-
Many of us use a display name different than the username which is used to log in.
That display name can be whatever and however you choose it, but it is certainly unusual to see a pseudo code name such as you use, and I totally ignore the strange config of that display name. The username seems easy to understand to me. Though pronunciation may not follow the structure that is often the case when trying to phonetically pronounce names from different languages. After all, we do not pronounce names when typing on a forum, so why would that even be an issue in the display name? The display name does not have to even be your real name, and it DOES allow separated sections as shown by many users here and by the way yours is displayed
@computersavvy, I truly apologize, but I’m uncertain of what you’re saying in most of your response, although I’m thankful. For instance, I didn’t realize that my username was potentially problematic. Might you elaborate?
Not that it is wrong, merely that it is jarring to see code like that in the image displayed as a user name on the forum.
You have the choice to have the display name exactly as you choose, and discourse displays the ‘display name’ literally and does not interpret code in that area.
@computersavvy, you appear unaware that name syntax differs from person to person based upon how their parents decided to name them: If you ever have the opportunity to visit Mongolia or China - basically anywhere in Asia which utilizes non-Latin or Cyrillic characters for their primary language - the name order is reversed, even when utilizing something like Japanese Romaji (Latin transliteration). That’s why explicit definition (as a concept, irrespective of its implementation) is useful.
I’ve tried a myriad of solutions, and this is the sole one which appears to at least work everywhere.
Anyway, this is off-topic - we should discuss this somewhere else.
the way the name is displayed does not matter to me, and apparently does not matter to most users. I only added my comments to what was voiced by @kparal in post 7
I agree this is off topic but do have to wonder why your concerns are so vehement when no one else seems to need to voice similar concerns.
@computersavvy, I have found that few else appear to care about supposedly “minor” problems like name misinterpretation. A minor problem is as much of a problem to me as a problem of any superior significance.
Were I to improve the name field, the forename, middlename, and surname would be separate, and a field for pronounciation would be present (like the vCard custom property explained in the Microsoft Exchange Supported vCard Property Documentation on GitHub).
@computersavvy, yes, albeit via plasma-discover-6.0.2-2.fc40.x86_64:
RokeJulianLockhart@sayw4i:~$ sudo dnf upgrade --refresh
[sudo] password for RokeJulianLockhart:
Fedora 40 - x86_64 108 kB/s | 16 kB 00:00
Fedora 40 - x86_64 681 kB/s | 443 kB 00:00
Fedora 40 - x86_64 - Debug 30 kB/s | 11 kB 00:00
Fedora 40 - x86_64 - Debug 16 kB/s | 4.9 kB 00:00
Fedora 40 openh264 (From Cisco) - x86_64 3.5 kB/s | 989 B 00:00
Fedora 40 openh264 (From Cisco) - x86_64 - Debug 2.8 kB/s | 997 B 00:00
Fedora 40 - x86_64 - Updates 45 kB/s | 22 kB 00:00
Fedora 40 - x86_64 - Updates - Debug 130 kB/s | 17 kB 00:00
Fedora 40 - x86_64 - Test Updates 168 kB/s | 12 kB 00:00
Fedora 40 - x86_64 - Test Updates Debug 23 kB/s | 11 kB 00:00
google-chrome 12 kB/s | 1.3 kB 00:00
RPM Fusion for Fedora 40 - Free 22 kB/s | 6.7 kB 00:00
RPM Fusion for Fedora 40 - Free - Test Updates 22 kB/s | 6.4 kB 00:00
RPM Fusion for Fedora 40 - Nonfree 24 kB/s | 6.8 kB 00:00
RPM Fusion for Fedora 40 - Nonfree - Steam 21 kB/s | 6.3 kB 00:00
RPM Fusion for Fedora 40 - Nonfree - Steam Debug 57 kB/s | 6.5 kB 00:00
RPM Fusion for Fedora 40 - Nonfree - Test Updates 22 kB/s | 6.5 kB 00:00
Visual Studio Code 13 kB/s | 1.5 kB 00:00
Dependencies resolved.
Nothing to do.
Complete!
RokeJulianLockhart@sayw4i:~$
in order to ensure I keep this system exactly as it should be.
What i figured out is, when that happens, you can click on the tray icon and select big picture mode (which mostly would work, but there are times even that would not do anything) and then exit out of big picture mode and it should take you to the normal window.