Text:
Your system information
- Steam client version (build number or date): 1785799196
- Distribution: Linux Mint Cinnamon, Ubuntu
- Opted into Steam client beta?: No
- Have you checked for system updates?: Yes
- Runtime: Steam Linux Runtime 4.0 (steamrt4)
- What versions are listed in
steamapps/common/SteamLinuxRuntime_4/VERSIONS.txt?:
#Name Version Runtime Runtime_Version Comment
depot 4.0.20260805.254769 # Overall version number
pressure-vessel 0.20260805.0
pressure-vessel-arm64 0.20260805.0
scripts 0.20260805.0 # from steam-runtime-tools
steamrt4 4.0.20260805.254769 steamrt4 4.0.20260805.254769 # steamrt4_platform_4.0.20260805.254769/
My steam runtime diagnostics, which I ran AFTER the solution: https://gist.github.com/DigitalDed/86a52b06f17fab7f09cb8f0b2ee46845
Please describe your issue in as much detail as possible
Every game using Steam Linux Runtime 4.0 regenerates the de_DE.UTF-8
locale from scratch on every single launch, via pv-locale-gen, adding
significant startup delay (in my case, roughly 20 seconds extra on the
first launch of Kingdom Hearts HD 1.5+2.5 ReMIX after boot: ~50s instead
of ~30s). This happens because LANG=de_DE.UTF-8 is passed into the
container, but the container's built-in locales only include C.utf8
and en_US.utf8. For some reason, it then ALSO has to generate the english UTF 8. Let me show you the lines:
de_DE.UTF-8": No such file or directory
pv-locale-gen: Missing locale de_DE.UTF-8 (found in $LANG)
pv-locale-gen: Generating locale de_DE.UTF-8...
pv-locale-gen: Generated locale de_DE.UTF-8 successfully
pv-locale-gen: Generating locale en_US.UTF-8...
pv-locale-gen: Generated locale en_US.UTF-8 successfully
Not sure why it feels the need to also generate the en_US.UTF-8. Now that it can actually find the de_DE.UTF-8, it doesn’t generate either. But that is not all. After generating it, after loading a bit, it decides that it can’t find de_DE.UTF-8 again and decides to generate both UTF-8‘s again. Meaning without the de_DE.UTF-8, it generates a total of 4 UTF-8‘s.
I traced this down to the root cause, which I don't think has been
documented in the other issues reporting similar symptoms (e.g. #757,
#807, ValveSoftware/steam-for-linux#10649):
- Each container root (
SteamLinuxRuntime_4/var/tmp-XXXXXX/usr) is
freshly built on every Steam launch from the platform depot at
SteamLinuxRuntime_4/steamrt4_platform_<version>/files/.
- This build process appears to be driven by the manifest at
steamrt4_platform_<version>/usr-mtree.txt.gz, which lists every
file that gets copied into the fresh container (confirmed indirectly
via a related crash log format in a different issue: "Could not
create copy './lib/python3.9/LICENSE.txt' from ... into
'.../var/tmp-U6V7L2/usr'").
de_DE.UTF-8 (and presumably most non-English locales) is not part
of this manifest, so it's never present in the freshly built
container - forcing pv-locale-gen to compile it from scratch every
time, in a throwaway location, with no persistence between launches.
- The
keep file mechanism (documented for var/tmp-XXXXXX) does
not help here: it only prevents deletion of that specific
container root, but a brand new one is still built on every Steam
restart regardless.
Steps for reproducing this issue
- Set your system/Steam language to German (or any language other
than English, though I can only speak for German here).
- Launch any Proton game or native title using Steam Linux Runtime
4.0.
- Observe
pv-locale-gen: Missing locale de_DE.UTF-8 /
Generating locale de_DE.UTF-8... in the log on every launch of a game.
Workaround that worked for me
I compiled the missing locale as a standalone (non-archive) directory
and added it directly to the platform depot, then patched the
corresponding manifest so pressure-vessel's own file-copy step picks
it up:
# 1. Compile the locale in the directory format pressure-vessel expects
sudo localedef -f UTF-8 -i de_DE --no-archive /tmp/de_DE.UTF-8
# 2. Copy it into the platform depot's file tree
sudo cp -a /tmp/de_DE.UTF-8 \
"SteamLinuxRuntime_4/steamrt4_platform_<version>/files/lib/locale/de_DE.UTF-8"
# 3. Add matching entries (type/mode/time/size/sha256) for every file
# to usr-mtree.txt.gz, mirroring the existing C.utf8 entries
After this, de_DE.UTF-8 is included automatically in every
built container, and the "Missing locale" / "Generating locale"
messages no longer appear.
The obvious downside to this solution is that this modifies the depot files directly, and probably gets reverted by the next Steam Linux Runtime 4.0 update.
My solution, a script: https://gist.github.com/DigitalDed/f71bf649473a5cecf124d4bd6a921c4e
I plan to fix this everytime that Runtime removes it after an update, hence the script. Perhaps it's useful for others as well.
Text:
Your system information
steamapps/common/SteamLinuxRuntime_4/VERSIONS.txt?:#Name Version Runtime Runtime_Version Comment
depot 4.0.20260805.254769 # Overall version number
pressure-vessel 0.20260805.0
pressure-vessel-arm64 0.20260805.0
scripts 0.20260805.0 # from steam-runtime-tools
steamrt4 4.0.20260805.254769 steamrt4 4.0.20260805.254769 # steamrt4_platform_4.0.20260805.254769/
My steam runtime diagnostics, which I ran AFTER the solution: https://gist.github.com/DigitalDed/86a52b06f17fab7f09cb8f0b2ee46845
Please describe your issue in as much detail as possible
Every game using Steam Linux Runtime 4.0 regenerates the
de_DE.UTF-8locale from scratch on every single launch, via
pv-locale-gen, addingsignificant startup delay (in my case, roughly 20 seconds extra on the
first launch of Kingdom Hearts HD 1.5+2.5 ReMIX after boot: ~50s instead
of ~30s). This happens because
LANG=de_DE.UTF-8is passed into thecontainer, but the container's built-in locales only include
C.utf8and
en_US.utf8. For some reason, it then ALSO has to generate the english UTF 8. Let me show you the lines:de_DE.UTF-8": No such file or directory
pv-locale-gen: Missing locale de_DE.UTF-8 (found in $LANG)
pv-locale-gen: Generating locale de_DE.UTF-8...
pv-locale-gen: Generated locale de_DE.UTF-8 successfully
pv-locale-gen: Generating locale en_US.UTF-8...
pv-locale-gen: Generated locale en_US.UTF-8 successfully
Not sure why it feels the need to also generate the en_US.UTF-8. Now that it can actually find the de_DE.UTF-8, it doesn’t generate either. But that is not all. After generating it, after loading a bit, it decides that it can’t find de_DE.UTF-8 again and decides to generate both UTF-8‘s again. Meaning without the de_DE.UTF-8, it generates a total of 4 UTF-8‘s.
I traced this down to the root cause, which I don't think has been
documented in the other issues reporting similar symptoms (e.g. #757,
#807, ValveSoftware/steam-for-linux#10649):
SteamLinuxRuntime_4/var/tmp-XXXXXX/usr) isfreshly built on every Steam launch from the platform depot at
SteamLinuxRuntime_4/steamrt4_platform_<version>/files/.steamrt4_platform_<version>/usr-mtree.txt.gz, which lists everyfile that gets copied into the fresh container (confirmed indirectly
via a related crash log format in a different issue: "Could not
create copy './lib/python3.9/LICENSE.txt' from ... into
'.../var/tmp-U6V7L2/usr'").
de_DE.UTF-8(and presumably most non-English locales) is not partof this manifest, so it's never present in the freshly built
container - forcing
pv-locale-gento compile it from scratch everytime, in a throwaway location, with no persistence between launches.
keepfile mechanism (documented forvar/tmp-XXXXXX) doesnot help here: it only prevents deletion of that specific
container root, but a brand new one is still built on every Steam
restart regardless.
Steps for reproducing this issue
than English, though I can only speak for German here).
4.0.
pv-locale-gen: Missing locale de_DE.UTF-8/Generating locale de_DE.UTF-8...in the log on every launch of a game.Workaround that worked for me
I compiled the missing locale as a standalone (non-archive) directory
and added it directly to the platform depot, then patched the
corresponding manifest so pressure-vessel's own file-copy step picks
it up:
After this,
de_DE.UTF-8is included automatically in everybuilt container, and the "Missing locale" / "Generating locale"
messages no longer appear.
The obvious downside to this solution is that this modifies the depot files directly, and probably gets reverted by the next Steam Linux Runtime 4.0 update.
My solution, a script: https://gist.github.com/DigitalDed/f71bf649473a5cecf124d4bd6a921c4e
I plan to fix this everytime that Runtime removes it after an update, hence the script. Perhaps it's useful for others as well.