Same issue here.

Steam client version (build number or date): /client/steam_client_ubuntu12 version 1686779606
Distribution (e.g. Ubuntu): Fedora 38 6.3.7-200.fc38.x86_64
Opted into Steam client beta?: No
Have you checked for system updates?: Yes
Hardware: AMD Ryzen 5 PRO 4650U with Radeon Graphics

The steam client and associated games were working yesterday before the update. Launching Steam from menu and running from the command line both fail to launch. I have tried steam -reset but with same result.

The output from the steam command including error can be viewed in this gist

Same problem here on Linux Mint 21.1

Steam client version (build number or date): /client/steam_client_ubuntu12 version 1686779606
Distribution (e.g. Ubuntu): Linux Mint 21.1 Cinnamon with 6.1.0-1013-oem kernel
Opted into Steam client beta?: No
Have you checked for system updates?: Yes
Hardware: AMD Ryzen 7 PRO 5850U with Radeon Graphics

Error from steam command: gist

Also tried to "lower" the /etc/machine-id by removing most of the characters, did not help.

Having the same issue, which occurred right after I updated. It does not appear to be limited to just Arch, as I use Ubuntu.

sysout contains dbus[572781]: D-Bus library appears to be incorrectly set up: see the manual page for dbus-uuidgen to correct this issue. (Failed to stat "/var/lib/dbus/machine-id": Value too large for defined data type; Failed to stat "/etc/machine-id": Value too large for defined data type)

Steam client version (build number or date): built Jun 14 2023 20:16:17
Distribution (e.g. Ubuntu): Ubuntu 22.04.2 LTS with 5.19.0-43-generic kernal
Opted into Steam client beta?: No
Have you checked for system updates?: No
Hardware: AMD Ryzen 9 3900X (24) @ 3.800GHz, NVIDIA GeForce RTX 3080

Full output located here

Tried this now and steam client updated to version 1686880776
Getting same error

Full output here

Unfortunately no, I don't have xdg-desktop-portal-gnome installed at all, I use xdg-desktop-portal-gtk, but even with both packages removed it does not work and end with same error as stated above.

I would also just like to point out, running steam with -vgui results in the same error

Updated workaround for this issue:

1. Ensure system time is correct
2. Run sudo touch -c /etc/machine-id
3. If on a debian system, run sudo touch -c /var/lib/dbus/machine-id

If these steps do not work, please comment below with the output of the following commands:

stat /etc/machine-id
stat /var/lib/dbus/machine-id

Many thanks for thisinstruction - this works for me!

Workaround this issue - Steps to regenerate your machine id:

..

You can find more information about this procedure here: https://unix.stackexchange.com/a/403054/538239

thank you, that worked for my affected Fedora 38 system

If you're going to invalidate and replace /etc/machine-id, please copy the value ahead of time and share what Steam had a hard time with (after you're no longer using that value, the working replacement is not interesting in terms of troubleshooting).

The regenerating machine-id method worked. The old one is 01bec1201eae48818a8ca29b25db895a. Hope that helps in further troubleshooting of the issue!

Thank you @Gamebuster19901 this helped me also on Fedora 38.

My original machine-id was d55b812d2bea42dc80ca3df15d361362

Both of the old IDs given above match what I have here in that they're 32-digit hexadecimal numbers (so the old file's length should be 33 bytes, the extra byte being an LF).

Hello! Same issue on Fedora 37:

dbus[9363]: D-Bus library appears to be incorrectly set up: see the manual page for dbus-uuidgen to correct this issue. (Failed to stat "/var/lib/dbus/machine-id": Value too large for defined data type; Failed to stat "/etc/machine-id": Value too large for defined data type)

Full log:
https://gist.githubusercontent.com/oneoa/7334a3fcd408a1d350dd458ffce3fdfc/raw/5ae968311faded048c53981b999b6ac6453295ff/steam_client_version_1686880776_crash_log.txt

Hex dump of /etc/machine-id:

00000000: 3839 6666 3632 3765 6636 6365 3436 3033  89ff627ef6ce4603
00000010: 6132 3763 3662 3930 3238 3630 6239 6630  a27c6b902860b9f0
00000020: 0a                                       .

I haven't made any changes to the OS since the crash. Let me know if more info is needed.

Same issue, resetting the UUID by generating a new one from dbus-uuidgen fixed it, the old and the new were the same length. My old one was 081e3238a9ed4634a3ec2d5a75a98b9c (33 byte file in total, made up of that ascii as well as a newline). I notice one of the above ones started with a 0 as well, wonder if a bad parser is hitting it or something. Though one of the others prior did not start with a 0. But still, two of 3 starting with a 0 is a fairly low chance for this, need some more non-working values though...

EDIT: And for note, my new one does not start with a 0, still a 33 byte sized file.

The file that is causing trouble is most likely /var/lib/dbus/machine-id, but it seems like some of the dumps here are for /etc/machine-id

If anyone is still running into issues it would be good to check the value for /var/lib/dbus/machine-id on your system and paste it here. Hexdumps like @oneoa 's are probably the best format. E.g. via hexdump /var/lib/dbus/machine-id

On Ubuntu /var/lib/dbus/machine-id is symlink to /etc/machine-id:

$ ls -l /var/lib/dbus/machine-id
lrwxrwxrwx 1 root root 15 lut  4  2018 /var/lib/dbus/machine-id -> /etc/machine-id

My old value was:

$ cat ~/machine-id
882fa37e9a9c4a34a5e7cc9324b68939

$ hexdump ~/machine-id 
0000000 3838 6632 3361 6537 6139 6339 6134 3433
0000010 3561 3765 6363 3339 3432 3662 3938 3933
0000020 000a                                   
0000021

And after regenerating it (which helped) I got:

$ cat /etc/machine-id
226346f2a42a7a877212db076490a2db

$ hexdump /etc/machine-id
0000000 3232 3336 3634 3266 3461 6132 6137 3738
0000010 3237 3231 6264 3730 3436 3039 3261 6264
0000020 000a                                   
0000021

Side note, initially I thought crash is caused by GLib, I still have those "critical" errors but seems those are not affecting Steam:

(process:4915): GLib-GObject-CRITICAL **: 20:54:08.175: g_object_ref: assertion 'G_IS_OBJECT (object)' failed

Actually, the contents of the file is most likely not the issue.

I suspect it is a metadata field in the file that is the problem since the stat() call is what is failing in libdbus here:
https://gitlab.freedesktop.org/dbus/dbus/-/blob/master/dbus/dbus-file-unix.c#L95

And for errno 75/EOVERFLOW we seem to have the following documented error conditions:

• The file size in bytes or the number of blocks allocated to the file or the file serial number cannot be represented correctly in the structure pointed to by buf.
• Or, a value to be stored would overflow one of the members of the stat structure.

If you run into this error, please collect this info instead:

stat /var/lib/dbus/machine-id
stat /etc/machine-id

Yes, what @lostgoat said. The error "Value too large for defined data type" is most likely to be referring to the "inode number" of the file containing the machine ID, and not the content of the machine ID itself.

Regarding https://github.com/ValveSoftware/steam-for-linux/issues/9605#issuecomment-1595601706:

2. run `sudo rm -f /etc/machine-id`
3. run `sudo dbus-uuidgen --ensure=/etc/machine-id`

I don't think this is the right workaround, and changing the machine ID is quite a destructive thing to do. If this works, it'll only be working by coincidence.

To people who are experiencing this crash: do you have your operating system's 32-bit version of libdbus installed?

If not, try installing it. If that works, it'll be a much safer workaround than changing the machine ID. On Arch the package to install is lib32-dbus, on Debian/Ubuntu it's libdbus-1-3:i386; other distributions will vary. I don't know how Fedora spells that, possibly dbus-libs.i686?

Or if you already have the OS's 32-bit libdbus installed, please report what version it is (any version 1.12.x or later should be good). If you can check its contents with objdump -T -x /usr/lib32/libdbus-1.so.3 | grep stat (or /usr/lib/i386-linux-gnu/libdbus-1.so.3 on Debian/Ubuntu, or /usr/lib/libdbus-1.so.3 on Fedora) then that's also useful information. The good result (which I see on Debian, with version 1.14.6) is that it refers to lstat64, stat64 and/or fstat64; the bad result is that it refers to lstat, stat and/or fstat without the 64 suffix.

If installing the 32-bit version of the OS's libdbus is successful, then that will point to a way that the Steam Runtime can avoid this happening.

@smcv

Yes, what @lostgoat said. The error "Value too large for defined data type" is most likely to be referring to the "inode number" of the file containing the machine ID, and not the content of the machine ID itself.

If so, easiest way to fix it is moving machine_id file around. In my case (Slackware), I have only "/var/lib/dbus/machine-id". So doing as root:

cp /var/lib/dbus/machine-id /var/lib/dbus/machine-id_
rm /var/lib/dbus/machine-id
mv /var/lib/dbus/machine-id_ /var/lib/dbus/machine-id

Should fix this problem, and, in my case, it was .

Edit:
It could be also wrong atime in this file (after 19th January 2038). I recall weird date when I stat my machine-id file. And when I found it in my terminal history it was that indeed. My atime was "2038-05-28 20:07:13.793999783 +0200", and it isn't fit into 32-bit date.

In this case my workaround still works, by easier way is just "touch" machine-id file.

I can confirm the issue in my case was also that /etc/machine-id was accessed when I set my computer time past the year 2038.

touch /var/lib/dbus/machine-id
touch /etc/machine-id

Should work too like @Hannibal-pl said, and fixed my problem.
I also had a similar issue with Steam's font due to the same reason.

Can confirm that setting the system time to some distant time in the future makes this issue reproducible. (About a year ago I set my system time to the year ~2400 to test software, then changed it back, which is probably how I encountered this issue the first time).

These were the steps I took to recreate this issue again:

1. Set the year of the system clock to 2105
2. Reboot the system
3. Reboot the system again
4. Set the system time back to the correct time
5. Open a terminal
6. execute steam
7. Steam will not launch (has same error message as this issue)

I am then able to quickly fix the issue by doing the following:

1. run sudo touch /var/lib/dbus/machine-id

Here is the terminal output of steps 5-8 above: https://pastebin.com/raw/3hHcmDHF

(Note: I've also updated the previous post that had the bad workaround. You also probably don't have to reboot twice to reproduce, but those are the exact steps I took.)

@Gamebuster19901

(Note: I've also updated the previous post that had the bad workaround. You also probably don't have to reboot twice to reproduce, but those are the exact steps I took.)

Updated workaround for this issue:

1. Ensure system time is correct
2. Run sudo touch /etc/machine-id
3. If on a debian system, run sudo touch /var/lib/dbus/machine-id

This is too much simplified. You should only touch existing machine-id file. If you touch nonexisting one it will be created empty. This also can be bad for the system.

It should be something like that:

1. Ensure system time is correct
2. If file /etc/machine-id exists, run sudo touch /etc/machine-id
3. If file /var/lib/dbus/machine-id exists, run sudo touch /var/lib/dbus/machine-id

Yes, I can confirm, it's related to access time my old file had 2121-04-20 17:45:26 (I don't know why).

Steam runs on 32-bit so Epochalypse/Y2K38 happened.

The solution based on the previous ones is to tun touch with -c or --no-create flag

• Ensure system time is correct
• run sudo touch -c /etc/machine-id
• run sudo touch -c /var/lib/dbus/machine-id

I'm able to recreate the problem here.

Running touch as root, if I run

touch -d '@2147483647' /var/lib/dbus/machine-id /etc/machine-id

(both files already exist and are valid) then Steam starts up without that data type error.

If I instead run

touch -d '@2147483648' /var/lib/dbus/machine-id /etc/machine-id

then that error occurs. (Steam does start up, though.)

@netpok is right: it's 32-bit time_t which is the problem.

There's discussion of transitioning i386 from 32-bit time_t (from a Linux distribution POV) and links to related resources at https://wiki.debian.org/ReleaseGoals/64bit-time.

It may be time to drop most use of i386 within Steam. What remains is probably going to have to handle code which uses 32-bit time_t and code which uses 64-bit time_t.

Yes, post-2038 timestamps are another possible cause of EOVERFLOW "Value too large for defined data type".

That would explain why regenerating the machine UUID accidentally worked around this: changing the content wasn't necessary, but it would have had the side-effect of resetting the timestamp, and that prevented the crash.

It is not quite as simple as "old timestamp good, new timestamp bad": I tried to reproduce this bug by intentionally setting the wrong timestamp on a test system, and while using the bundled 32-bit libdbus-1.so.3 from the Steam Runtime I was unable to reproduce it. I only saw the bug when using an OS-provided copy of the 32-bit libdbus-1.so.3. This is the opposite of what I previously expected.

The backtrace from the crash involves Steam's copy of SDL 3, so there is a SDL 3 change that should be able to reduce the impact of this.

This is too much simplified. You should only touch existing machine-id file. If you touch nonexisting one it will be created empty. This also can be bad for the system.

Yes, you should not create an empty machine ID. @netpok's suggestion of using sudo touch -c seems like the best workaround: that will avoid needing to make the workaround conditional on whether particular files already exist.

@Gamebuster19901 or someone from Valve, please could you edit https://github.com/ValveSoftware/steam-for-linux/issues/9605#issuecomment-1595601706 to recommend sudo touch -c as suggested in https://github.com/ValveSoftware/steam-for-linux/issues/9605#issuecomment-1598310661? [edit: kisak-valve did this, thanks!]

There's discussion of transitioning i386 from 32-bit time_t (from a Linux distribution POV) and links to related resources at https://wiki.debian.org/ReleaseGoals/64bit-time.

Unfortunately, the Steam Runtime is in a particularly difficult situation here, because it has to maintain backwards-compatibility with old 32-bit game binaries, and those will all be assuming 32-bit time_t. Breaking the ABI of runtime libraries would cause those games to crash or otherwise misbehave, even if the Steam client itself can avoid the issue by using less 32-bit code and more 64-bit code.

The backtrace from the crash involves Steam's copy of SDL 3, so there is a SDL 3 change that should be able to reduce the impact of this.

I've proposed libsdl-org/SDL#7850.

During Steam startup, Steam's 32-bit gldriverquery utility also crashes with a similar symptom, so presumably SDL 2 would benefit from a backport of the same change - but that crash doesn't seem to be breaking Steam in the same way, so it's less important to fix.

@lostgoat

[user@fedora ~]$ stat /etc/machine-id 
  File: /etc/machine-id
  Size: 33        	Blocks: 8          IO Block: 4096   regular file
Device: 0,34	Inode: 145444      Links: 1
Access: (0444/-r--r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Context: unconfined_u:object_r:machineid_t:s0
Access: 2129-07-12 09:38:17.840706229 +0600
Modify: 2022-04-27 12:38:02.669239506 +0600
Change: 2022-04-27 12:38:02.669239506 +0600
 Birth: 2022-04-27 12:38:02.669239506 +0600

@smcv

[user@fedora ~]$ rpm -qa | grep dbus-libs
dbus-libs-1.14.8-1.fc37.x86_64
dbus-libs-1.14.8-1.fc37.i686

UPD:
Checked Steam today: it updated and started as usual. The error is still there, but Steam didn't crash this time. Thanks for the patch! Should I fix the time nonetheless or is it OK to leave it as it is?

@smcv

[user@fedora ~]$ rpm -qa | grep dbus-libs
dbus-libs-1.14.8-1.fc37.x86_64
dbus-libs-1.14.8-1.fc37.i686

UPD: Checked Steam today: it updated and started as usual. The error is still there, but Steam didn't crash this time. Thanks for the patch! Should I fix the time nonetheless or is it OK to leave it as it is?

You should still touch the file.

Steam now also starts for me when earlier it didn't, thanks for the quick fix, but the error also persists for me, so in case it's useful, I'm on Lubuntu 22.04, I have the following libdbus installed:

libdbus-1-3/jammy-updates,jammy-security,now 1.12.20-2ubuntu4.1 amd64 [installed,automatic]
libdbus-1-3/jammy-updates,jammy-security,now 1.12.20-2ubuntu4.1 i386 [installed,automatic]

objdump on the 32-bit libdbus shows:

00000000      DF *UND*  00000000 (GLIBC_2.33) lstat64
00000000      DF *UND*  00000000 (GLIBC_2.33) stat64
00000000      DF *UND*  00000000 (GLIBC_2.33) fstat64

And stating the machine IDs does show atimes beyond 2038 for whatever reason:

  File: /etc/machine-id
  Size: 33              Blocks: 8          IO Block: 4096   regular file
Device: 806h/2054d      Inode: 2093576     Links: 1
Access: (0444/-r--r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2040-06-04 08:05:42.570900342 +0200
Modify: 2020-03-01 00:03:26.189327886 +0100
Change: 2020-03-01 00:03:26.189327886 +0100
 Birth: 2020-03-01 00:03:26.165326301 +0100

  File: /var/lib/dbus/machine-id -> /etc/machine-id
  Size: 15              Blocks: 0          IO Block: 4096   symbolic link
Device: 806h/2054d      Inode: 2015100     Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2040-06-04 08:05:45.486900295 +0200
Modify: 2020-03-01 00:03:26.253332114 +0100
Change: 2020-03-01 00:03:26.253332114 +0100
 Birth: 2020-03-01 00:03:26.253332114 +0100

@MerkaST

Try running

touch -c -a FILENAME

on both files where FILENAME is the path to the file.

That should reset the access time to the system's current time.

@smvc

on Debian/Ubuntu it's libdbus-1-3:i386

That was already installed on mine when I had the issue above. The version is 1.14.4-1ubuntu1.

❯ objdump -T -x /usr/lib/i386-linux-gnu/libdbus-1.so.3 | grep stat
00000000      DF *UND*  00000000 (GLIBC_2.33) lstat64
00000000      DF *UND*  00000000 (GLIBC_2.33) stat64
00000000      DF *UND*  00000000 (GLIBC_2.33) fstat64
00030290 g    DF .text  00000073  LIBDBUS_PRIVATE_1.14.4 _dbus_list_get_stats
00010850 g    DF .text  000000b2  LIBDBUS_1_3 dbus_connection_set_dispatch_status_function
00015590 g    DF .text  000000e5  LIBDBUS_PRIVATE_1.14.4 _dbus_connection_get_stats
000105f0 g    DF .text  0000007d  LIBDBUS_1_3 dbus_connection_get_dispatch_status

Also, here's the stat of a copy of the original non-working file that was renamed to what it is now, which sadly won't give the original filedates (makes me wonder if just copying, deleting original, and renaming the copy would have fixed it...):

❯ stat /etc/machine-id.bak 
  File: /etc/machine-id.bak
  Size: 33              Blocks: 8          IO Block: 4096   regular file
Device: 259,2   Inode: 9971297     Links: 1
Access: (0444/-r--r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-06-17 20:42:13.917745887 -0600
Modify: 2023-06-17 20:35:20.518377423 -0600
Change: 2023-06-17 20:35:20.518377423 -0600
 Birth: 2023-06-17 20:35:20.518377423 -0600

makes me wonder if just copying, deleting original, and renaming the copy would have fixed it...

Most likely yes.

Thank you to those who have showed us what symbols are in their libdbus-1-3:i386. I don't think we need this information from anyone else.

My original guess was that this was about files having large inode numbers (Inode: in stat(1) output) that won't fit in a 32-bit integer. These are accessible for all 64-bit binaries, and also OK for 32-bit binaries that exclusively refer to symbols like {,l,f}stat64 or __{,l,f}stat64_time64, but would break 32-bit binaries that refer to the older {,l,f}stat symbols. I think we have enough information now to be confident that this guess was incorrect.

It seems that the real reason for this to happen is incorrect timestamps (either Access, Modify or Change) that won't fit in a 32-bit integer, meaning timestamps that are several years into the future (January 2038 or later). These are accessible for all 64-bit binaries, and also OK for 32-bit binaries that exclusively refer to the very new __{,l,f}stat64_time64 symbols, but would break 32-bit binaries that refer to the older {,l,f}stat64 or {,l,f}stat symbols.

Confusingly, all of these are possible results from C/C++ source code that calls stat, fstat or lstat, depending on precisely how it was compiled.

Unfortunately, because the Steam Runtime needs to be able to run on older systems, it is not practical for it to use __{,l,f}stat64_time64. So there is no easy general solution to this.

I'm hoping to make future versions of libdbus compile with 64-bit timestamps on 32-bit platforms, which is part of a long-term solution. This doesn't work for all libraries, because some libraries change their ABI when compiled like this; but libdbus specifically avoids exposing system types in its API/ABI, so for libdbus specifically, it should be OK to change the types that are used internally. Obviously this will need some careful testing to make sure it doesn't cause regressions.

For the more general problem, all file timestamps should be equal to or older than the current date and time on a correctly configured system, so we still have almost 15 years to find a better answer. It seems as though all instances of this have involved a system clock that was incorrectly set several years into the future.

Because the machine ID is accessed during boot, if you have ever booted the computer with a system clock set to a date/time in the future (for whatever reason), the machine ID file's most-recent-access time will stay stuck in the future until fixed manually. A mitigation for this is that many people configure their filesystem to be mounted with relatime or noatime, which makes the access time less likely to be updated.

Any file can be affected by this: the machine ID is just an extra-visible one, because it causes a chain of events that ended up with Steam not starting.

The general workaround is (still) to run this as root, for example using sudo or pkexec:

touch -c /etc/machine-id /var/lib/dbus/machine-id

Try running
touch -c -a FILENAME

My understanding is that this shouldn't be necessary, because touch defaults to setting both the access time and the modification time to the current time. I tested this on btrfs with relatime to make sure that relatime doesn't interfere, and it seems that isn't a problem. But if touch -c FILENAME doesn't work on a particular system, you could try using touch -a -c FILENAME and touch -m -c FILENAME separately.

I don't remember ever setting my system time into the future, but I do dual-boot with Windows and my BIOS occasionally forgets its settings especially when completely off power for a while (I'm pretty sure I've changed the battery), so maybe a weird timestamp slipped in there at some point. Or maybe I just played around with it at some point and forgot.

It appears that this issue affects Source games as well. Portal didn't start until I touched my machine-ids and displayed the same error, Black Mesa however did start (I didn't check for the error message).

It appears that this issue affects Source games as well

A similar symptom will be seen with anything 32-bit that uses SDL, Source engine or otherwise (but 64-bit SDL games like Dota 2 should be unaffected). The general answer, at least for the next decade or so, is to ensure your system clock is not set years into the future; and if your system clock has been incorrect in the past, use touch to reset the mtime/atime of the machine ID and any other affected files.

For games that use a system copy of SDL, if your operating system provides a recent 32-bit SDL package (libsdl2-2.0-0:i386 in Debian, lib32-sdl2 in Arch and so on), upgrading that to 32-bit SDL 2.28.0 or later would avoid the crash, because 2.28.0 includes https://github.com/libsdl-org/SDL/pull/7852 (a SDL2 equivalent of the SDL3 change that avoided the Steam crash).

In the case of the Steam Runtime, a future Steam beta will upgrade the Steam Runtime's included SDL to 2.28.1 or later, which will be used for most games if it's newer than your system copy or if you do not have a system copy at all.

Games that bundle their own copy of SDL (for example Team Fortress 2) will not benefit from this change, and it's up to the game developer to either update their SDL or switch to the one provided by the Steam Runtime or operating system.