ESO Hangs on Start after Weekly Package Updates (Steam, Flatpak, F40)

Ask Fedora
, , , , , , , , ,
1

I did a regular system update, today, and got a new kernel and some other package updates. After rebooting, however, Elder Scrolls Online (ESO) hangs right at the start, right before it plays the production credit videos. I login every day, so I know it worked yesterday.

I rebooted with the old kernel, didn’t work. I uninstalled and reinstalled the game in Steam, didn’t help. I also notice that another Steam game is now showing some audio artifacts, but I haven’t tried that one in a while, so not sure when that started. Other games seem fine.

It feels more like some kind of thing with playing the videos at the start and for cut scenes, not the whole game, but I’m not confident about that. However, I would think that those problems wouldn’t be related to system pkgs, since I run Steam in flatpak, and I expect that would isolate most problems to that environment. Graphics driver problems could cross over though, of course.

Here are some of the packages that were updated:

Aug 19 12:10:24 dnf[1391937]: ============================================================================================
Aug 19 12:10:24 dnf[1391937]:  Package                    Arch    Version                    Repository               Size
Aug 19 12:10:24 dnf[1391937]: ============================================================================================
Aug 19 12:10:24 dnf[1391937]: Installing:
Aug 19 12:10:24 dnf[1391937]:  kernel-core                x86_64  6.10.4-200.fc40            updates                  17 M
Aug 19 12:10:24 dnf[1391937]:  kernel-devel               x86_64  6.10.4-200.fc40            updates                  20 M
Aug 19 12:10:24 dnf[1391937]:  kernel-modules             x86_64  6.10.4-200.fc40            updates                  63 M
Aug 19 12:10:24 dnf[1391937]:  kernel-modules-core        x86_64  6.10.4-200.fc40            updates                  38 M
Aug 19 12:10:24 dnf[1391937]:  kernel-modules-extra       x86_64  6.10.4-200.fc40            updates                 2.9 M
Aug 19 12:10:24 dnf[1391937]: Upgrading:
Aug 19 12:10:24 dnf[1391937]:  amd-gpu-firmware           noarch  20240811-2.fc40            updates                  21 M
Aug 19 12:10:24 dnf[1391937]:  amd-ucode-firmware         noarch  20240811-2.fc40            updates                 246 k
Aug 19 12:10:24 dnf[1391937]:  breeze-cursor-theme        noarch  6.1.4-1.fc40               updates                 1.3 M
Aug 19 12:10:24 dnf[1391937]:  breeze-icon-theme          noarch  6.5.0-2.fc40               updates                 9.4 M
Aug 19 12:10:24 dnf[1391937]:  compat-ffmpeg4             x86_64  4.4.5-1.fc40               rpmfusion-free-updates  7.5 M
Aug 19 12:10:24 dnf[1391937]:  egl-wayland                x86_64  1.1.15-1.fc40              updates                  44 k
Aug 19 12:10:24 dnf[1391937]:  ibus                       x86_64  1.5.30-6.fc40              updates                  14 M
Aug 19 12:10:24 dnf[1391937]:  ibus-gtk2                  x86_64  1.5.30-6.fc40              updates                  30 k
Aug 19 12:10:24 dnf[1391937]:  ibus-gtk3                  x86_64  1.5.30-6.fc40              updates                  30 k
Aug 19 12:10:24 dnf[1391937]:  ibus-libs                  x86_64  1.5.30-6.fc40              updates                 259 k
Aug 19 12:10:24 dnf[1391937]:  ibus-panel                 x86_64  1.5.30-6.fc40              updates                 114 k
Aug 19 12:10:24 dnf[1391937]:  ibus-setup                 noarch  1.5.30-6.fc40              updates                  84 k
Aug 19 12:10:24 dnf[1391937]:  ibus-wayland               x86_64  1.5.30-6.fc40              updates                  30 k
Aug 19 12:10:24 dnf[1391937]:  libei                      x86_64  1.3.0-1.fc40               updates                  49 k
Aug 19 12:10:24 dnf[1391937]:  libeis                     x86_64  1.3.0-1.fc40               updates                  50 k
Aug 19 12:10:24 dnf[1391937]:  libwayland-client          i686    1.23.0-2.fc40              updates                  34 k
Aug 19 12:10:24 dnf[1391937]:  libwayland-client          x86_64  1.23.0-2.fc40              updates                  33 k
Aug 19 12:10:24 dnf[1391937]:  libwayland-cursor          i686    1.23.0-2.fc40              updates                  20 k
Aug 19 12:10:24 dnf[1391937]:  libwayland-cursor          x86_64  1.23.0-2.fc40              updates                  19 k
Aug 19 12:10:24 dnf[1391937]:  libwayland-egl             i686    1.23.0-2.fc40              updates                  13 k
Aug 19 12:10:24 dnf[1391937]:  libwayland-egl             x86_64  1.23.0-2.fc40              updates                  13 k
Aug 19 12:10:24 dnf[1391937]:  libwayland-server          i686    1.23.0-2.fc40              updates                  44 k
Aug 19 12:10:24 dnf[1391937]:  libwayland-server          x86_64  1.23.0-2.fc40              updates                  41 k
Aug 19 12:10:24 dnf[1391937]:  libwbclient                x86_64  2:4.20.4-1.fc40            updates                  47 k
Aug 19 12:10:24 dnf[1391937]:  libwinpr                   x86_64  2:3.7.0-1.fc40             updates                 387 k
Aug 19 12:10:24 dnf[1391937]:  linux-firmware             noarch  20240811-2.fc40            updates                  37 M
Aug 19 12:10:24 dnf[1391937]:  linux-firmware-whence      noarch  20240811-2.fc40            updates                  63 k
Aug 19 12:10:24 dnf[1391937]:  plasma-breeze-common       noarch  6.1.4-1.fc40               updates                  49 M
Aug 19 12:10:24 dnf[1391937]:  qt-settings                noarch  40.1-1.fc40                updates                  10 k
Aug 19 12:10:24 dnf[1391937]:  qt6-qtwayland              x86_64  6.7.2-4.fc40               updates                 1.1 M
Aug 19 12:10:24 dnf[1391937]:  realtek-firmware           noarch  20240811-2.fc40            updates                 3.3 M
Aug 19 12:10:24 dnf[1391937]:  selinux-policy             noarch  40.27-1.fc40               updates                  61 k
Aug 19 12:10:24 dnf[1391937]:  selinux-policy-doc         noarch  40.27-1.fc40               updates                 2.6 M
Aug 19 12:10:24 dnf[1391937]:  selinux-policy-minimum     noarch  40.27-1.fc40               updates                 6.9 M
Aug 19 12:10:24 dnf[1391937]:  selinux-policy-targeted    noarch  40.27-1.fc40               updates                 6.9 M
Aug 19 12:10:24 dnf[1391937]:  wavpack                    i686    5.7.0-3.fc40               updates                 238 k
Aug 19 12:10:24 dnf[1391937]:  wavpack                    x86_64  5.7.0-3.fc40               updates                 231 k
Aug 19 12:10:24 dnf[1391937]:  wlroots                    x86_64  0.18.0-1.fc40              updates                 406 k
Aug 19 12:10:24 dnf[1391937]: Installing dependencies:
Aug 19 12:10:24 dnf[1391937]:  wlroots0.17                x86_64  0.17.4-1.fc40              updates                 396 k
2

It seems likely that using the steam rpm version from rpmfusion may work better. At least worth a try.
I have no problems with it.

Did you trim the listing? I see that linux-firmware was updated but I see only a very few of the specific firmware packages that are pulled in by that meta-package.

It helps to provide as much (unedited) information as possible.

Did you also do a flatpak update?

3

Hi @computersavvy , I am using flatpak version of steam. Not sure what you mean by “steam rpm”. I see a steam version from rpmfusion, but I don’t see any steam pkg in the fedora or updates repo. Does

Yes, I trimmed the listing to things that I thought could possibly be related.

4

I installed steam from rpmfusion with dnf install steam
Nothing more nor less and everything installed was an rpm package, not flatpak.

5

Right. I switched from that to flatpak a while go. I still have ~/.steam and there are symlinks in there that Steam (flatpak) is managing.

6

Someone on Matrix Gaming on Linux pointed me here: New steam UI does not open if run with DRI_PRIME=1 · Issue #9383 · ValveSoftware/steam-for-linux · GitHub

Gives me some ideas.

7

and here: Steam takes very long to start, failed to connect to websocket · Issue #10879 · ValveSoftware/steam-for-linux · GitHub

This bug report mentions /etc/hosts and one of the more recent posts specifically mentions the view-localhost entry. Removing that helped; Steam starts quicker now and the the little splash window that had stopped showing up a short while ago is back.

But, ESO still hangs right at the start.

8

I’ve traced the view-localhost down to VMWare Horizon Client RPM, which just threw that line into /etc/hosts. Outrageous behavior. You’re telling me there’s no one at VMWare who understands how /etc/hosts works? WTF VMware?

9

Remember that VMware is proprietary and microsoft centered.
It seems likely that any curveballs they can throw to discourage use of linux and encourage use of windows are fair game.

Why not switch to the native libvirt or VirtualBox for your VMs since neither are dedicated to supporting microsoft.

10

Off-topic a bit, but I’m not using VMWare virtualization. I use libVirt stuff my VMs for sure! But I need the remote client for work; that’s what did the damage. Also, ESXi, their flag-ship product, is a Linux kernel-based hypervisor, so there are plenty of people at VMWare who know what they did was wrong.

11

Getting back to ESO, I guess I can try native Steam. That’ll take a while to configure and reinstall ESO, but that’s an option.

I strace-ed the process last time and I see it in a loop reading from a pipe and writing to a different pipe. But, I couldn’t trace these pipes down to other processes. I didn’t want to lsof the whole system, but I couldn’t figure out now to limit lsof to just the pipes I had already identified. I don’t know if they are named pipes, but I found them in /proc/<pid>/fd/, as if they were named pipes, but lsof didn’t like taking those paths as a target. I’m not sure this would help, but is all I have to go on, so far.

I tried to find a debug option for ESO, but I couldn’t find one. There was some debug plugin, but I think that is for debugging other plugins, not the core game.

12

Okay, not I’m really worried. I installed native Steam from rpmfusion-nonfree-steam repo and that will not even start.

$ steam
fgrep: warning: fgrep is obsolescent; using grep -F
/home/<username>/.local/share/Steam/steam.sh: line 242: [[: 1.0.0.79: syntax error: invalid arithmetic operator (error token is ".0.0.79")
Running Steam on fedora 40 64-bit
STEAM_RUNTIME is enabled automatically
/home/<username>/.local/share/Steam/ubuntu12_32/steam: /home/<username>/.local/share/Steam/ubuntu12_32/steam-runtime/i386/lib/i386-linux-gnu/libgcc_s.so.1: version `GCC_7.0.0' not found (required by /lib/libstdc++.so.6)

I feel like this might be a thing where stuff in .local/share/Steam is really old stuff? That steam.sh script is from 2015! That’s probably when I switched to flatpak, I’m guessing. Does that seem reasonable to you? I suppose I could …

Yeah, seems like archiving the .local/share/Steam directory was safe. I don’t think I need saved game stuff in there, but I’ll keep it around for a bit, anyway. ESO is installing, now.

Actually, I forgot to mention that there was a bootstrap tarball in that directory that was the only updated file. I extracted it and that actually allowed Steam to start. I’m not sure I needed to archive the whole directory, but I thought that might clear out some really old suff in there. There were files from 2004! Didn’t save any space, though, so probably not worth the effort in the end.

13

Oh man. I got ESO installed in the native Steam…but it hangs in exactly the same place!