SteamOS NVIDIA Installer 0.2.5

SteamOS NVIDIA Installer 0.2.5

Notifications work again with the October 13 Steam Stable client update.
Steam client build 1791918634 moved the Gamepad UI notification selector into a
different JavaScript file. The previous helper did not recognize that asset and
left it unchanged, so notifications could show a black border again. This update
adds a verified profile for the new file and selects Steam's existing embedded
notification renderer.

Older supported Steam clients remain supported. The profiles for Stable
1788652215 and Beta 1789781627 are retained. The helper selects the appropriate
file, checks its complete hash and keeps a separate verified backup. An unknown
client is left unchanged; a stale file from an older Steam installation is not
used as a fallback for an unknown new client. There is no need to change your
Steam client channel to install this update.

The fix was checked on SteamOS 3.8.28 with Stable client 1791918634: the controller
notification appeared without the black border. Automated checks cover both
older profiles, the new profile, already patched clients, switching layouts,
exact restoration and safe refusal of unknown files.

Install through SteamOS Installer Update in Desktop Mode, then restart as
requested by the updater. The package carries the same Gamescope, 4K/GBM, HDR,
VRR and overlay fixes as 0.2.4. Only the notification helper changes in the update
payload. This is an installer integration update, not a SteamOS system update.

SteamOS NVIDIA Installer 0.2.4

0.2.4 fixes a picture that breaks when Game Mode changes to 4K on NVIDIA, keeps the notification fix applied after Steam updates itself, and makes the diagnostic report identify the installer update source.

The picture no longer breaks when Game Mode changes to 4K. On an NVIDIA card, raising the resolution to 3840x2160 while Game Mode was running, or switching HDR on at that resolution, could fill the screen with displaced and repeated fragments. We also reproduced the resolution-change corruption with Valve's packaged Gamescope on the same hardware. The Gamescope in this release allocates the images it sends to the display through GBM. With that change, resolution, HDR and VRR changes at 3840x2160 stayed correct through repeated changes, a game and both overlays, and the picture was correct after a cold start with HDR already on. That was measured on one machine with a 4K DisplayPort monitor. The same monitor was also tested over HDMI after a clean installation: 4K at 60 Hz, HDR and resolution changes worked correctly. VRR worked over DisplayPort but was not available on this HDMI connection. A television was not tested. The new path is used only where this project's Gamescope is selected. A system that runs Valve's compositor is not affected.

The notification fix now survives Steam updating itself. The workaround for the black box drawn around notifications is reapplied when Steam starts. After a Steam client update, returning to Game Mode could fail to reapply the workaround even though its service still reported success. It now runs at every start of Steam. A client update that replaces the file while Steam keeps running is still only picked up at the next start.

The diagnostic report identifies the installer update source. It names the configured source, including the legacy official repository, distinguishes missing, unreadable and invalid configuration, and reports source files the updater rejects because of their ownership, permissions or symlink status. Custom source paths, credentials and signing keys are omitted from the summary. The check runs locally without contacting the update server.

Gamescope is the only compiled component that changes. MangoApp is unchanged from 0.2.3, and Remote Play receiver and NVENC binaries already installed are kept; this package cannot add them to a system that lacks them.

Install through SteamOS NVIDIA Installer Update and restart. The new Gamescope setting and the notification fix take effect from that restart.

SteamOS NVIDIA Installer 0.2.3

0.2.3 keeps the corrected Gamescope selected across more SteamOS versions.

Until now the correction was selected only on SteamOS 3.8, and only when the installed
gamescope package matched the exact version the artifact was built against. An ordinary
system update could therefore switch the correction off and bring back the menu
corruption and the black picture in Remote Play from this machine.

The installer now asks the artifact itself whether it accepts the options the session
will pass to it. If it does, the correction stays selected. If it does not, the system
keeps Valve's compositor and says so in the artifact's status file, beside the package
it found. No graphical session is started and no display is touched while this is
checked, and an artifact whose libraries do not resolve on the target still stops the
installation rather than passing quietly.

Gamescope and MangoApp are unchanged from 0.2.2, including their compatibility limits.
Existing Remote Play receiver and NVENC binaries are preserved; this package cannot add
them to a system that lacks them.

Install through SteamOS NVIDIA Installer Update and restart. The prepared system slot
keeps its update source, its signing key and the selected NVIDIA driver.

SteamOS NVIDIA Installer 0.2.2

0.2.2 moves official installer updates to 60plus/SteamOS_Nvidia_Installer.

Install through SteamOS NVIDIA Installer Update and restart. The prepared system slot switches to the new repository. The signing key, custom update sources and selected NVIDIA driver stay unchanged.

Gamescope and MangoApp are unchanged from 0.2.1, including compatibility limits. Existing Remote Play receiver and NVENC binaries are preserved; this package cannot add them to a system that lacks them.

Tools older than 0.1.9 need the intermediate updates described in the manual first.

The old repository keeps 0.2.2 and earlier releases available. Rolling back to the previous system also restores that slot's previous update source.

SteamOS NVIDIA Installer 0.2.1

This release delivers a filter that stops Steam being offered display modes the compositor will
reject, a clearer Gamescope section in the diagnostic report, and a repair path in Installer Update
for a system that already reports this version but is missing files from it.

Five files differ from 0.2.0: the Gamescope build, its provenance record, the updater, the updater's
window, and the diagnostic report. Every other file in the signed bundle is byte identical to 0.2.0.

What the display mode filter changes

A 4K television that offers 4096x2160 could have that mode written into Steam's saved preference. The
compositor rejects it, and because no match is found the screen comes up at a lower resolution with no
message explaining why. This build stops that mode being advertised, so it cannot be chosen by
accident. On the television this was tested with, the advertised list went from seven modes including
four at 4096x2160 to three, all at 3840x2160.

A system that already has 4096x2160 saved will still start at the lower resolution until the
resolution is chosen once by hand.

Gamescope compatibility, and where the corrections are active

The bundled Gamescope build carries four corrections: two capture fixes adapted from upstream work, a
correction for the corrupted Game Mode menus on NVIDIA, and the display mode filter above.

The two capture fixes are present in upstream Gamescope 3.16.30. The menu correction and the mode
filter are not, so a system running the distribution's own compositor does not have them.

This project's build is selected only where the system is on the SteamOS 3.8 line, ships
gamescope 3.16.23.6-1, and has the session layout the build expects. On a system outside those
conditions, including the SteamOS 3.9 line, this release leaves the distribution's compositor in
use, and these two corrections are then inactive. The integration was tested surviving an OS update
to 3.9.2 and back; applying Installer Update while already on 3.9.2 was not tested. Read the
recorded decision at any time:

cat /usr/lib/steamos-nvidia/gamescope/status.txt

A line beginning stock means this project's build is not in use. On the 3.9.2 system this was tested
on, the menu corruption returned in that state.

The SteamOS versions named in the signed manifest record where the integration was tested, which is not
the same thing as a guarantee that every optional correction is active. Applying a release on the 3.9
line in particular has not been exercised.

Known limitations

Gamescope can crash while leaving Game Mode. Two separate failures were seen on the test machine:
a fault in the Vulkan cleanup at exit, which was also seen on 0.2.0 and on the distribution's own
packaged build, and a separate abort when the X11 connection goes away during shutdown. Both happen as
the session ends. Desktop startup and re-entry to Game Mode were observed after both kinds of exit,
and a game was also run after the Vulkan cleanup failure. Neither is fixed by this release, and neither is
claimed to be harmless: each one writes a core dump, which takes disk space. The Vulkan one is reported
upstream as ValveSoftware/gamescope#1526.

Raising the output resolution while Game Mode is already running can corrupt the picture until the
session is restarted. This release does not fix that and does not establish where the fault belongs.
Restarting Game Mode is what clears it. Choosing the resolution before you start playing is a
sensible precaution rather than a tested remedy.

Verifying what you downloaded

installer-bundle.tar      b71564006d21ffbc2a31b71efefb15623b134b3b756d47ac7ad3857734ed7d25
installer-manifest.json   9030162ccf3a4ea0fc0eda82d00bff0da9130ea3b3f328a2bff0682db42a13ba

installer-manifest.sig is an Ed25519 signature over the manifest, made with the key an installed
system already carries, so Installer Update verifies both the manifest and every file in the bundle
before anything is written. The manifest's own bundle_sha256 must match the bundle, and it does.

These three files are for Installer Update. They are not source archives and not bootable images. To
build an installer image, follow
Build the USB image.

The wiki is the current manual. The source archives on this page are a snapshot of the code at this
tag, so a documentation page inside them can be older than the same page on the wiki.

How it was tested

On one PC, an RTX 5060 with the pinned NVIDIA 610.57.04 driver, on SteamOS 3.8.28 build 20260922.1.
Three routes, each including the machine taking its first SteamOS update afterwards: a clean
installation from the image, an update from the desktop over an existing 0.2.0 system, and an upgrade
from the USB image over an existing installation. In every case the integration survived the OS update
with all of its recorded files intact, and the compositor this project builds was confirmed to be the
one running, by resolving the live process rather than by appearance.

One machine is one machine. Another display, another connection or another pair of display modes should
be treated as untested rather than as known good.

SteamOS NVIDIA Installer 0.2.0

This release delivers the Gamescope build that fixes corrupted Game Mode menus on
NVIDIA. Nothing else changes: every other file in it is byte identical to 0.1.9.

Install 0.1.9 first if you are still on 0.1.8 or older. An installed version writes
only the files it was built knowing about, and Gamescope was added to that list in
0.1.9. Going straight from 0.1.8 to this release would install the tools and skip the
Gamescope binary, and the machine would then report itself up to date without the fix.
0.1.9 says plainly which files it is leaving for a later release, so it is easy to
tell. A system installed from a 0.1.9 image or newer is unaffected.

What the fix does

With a menu open over a game, Gamescope could hand the game and Steam's interface
straight to two hardware planes and let the display engine blend them. On NVIDIA that
blend draws displaced and repeated fragments of the interface, black rectangles,
coloured bands and speckle over much of the screen, while the upper part of the menu
stays readable.

This build refuses that route when a layer that needs alpha blending would be placed on
a plane, on a display device the kernel reports as nvidia-drm. The frame is composited
instead, which is what already happens whenever the overlay is on, HDR is on, or the
image scale is not one to one. Those three settings were the only known workarounds and
they are no longer needed.

GAMESCOPE_NVIDIA_COMPOSITE_ALPHA=0 in the Gamescope session opts out of this one
reason. Every other reason to composite still applies, so opting out does not mean
direct presentation is guaranteed.

What was measured

On one PC with an RTX 5060, over DisplayPort and HDMI, at 2560x1440 in 165, 144, 120 and
60 Hz and at 1920x1080 in 120 and 60 Hz, with HDR off and on, with VRR off and on where
the connection offered it, and with the performance overlay off and on. The menus were
checked in the main Steam interface, over a running game, during a controller
notification and through repeated rapid opening and closing.

Every result was attributed from Gamescope's own record of which route it chose, not
from appearance alone, and the corruption was deliberately reproduced with the change
disabled on both connections, so a clean picture is not simply a machine that stopped
failing on its own.

Two things that were expected and turned out false, recorded because they were in this
project's own documentation: a lower output resolution is not a workaround and was worse
here, and HDMI is not a separate fault but the same one reached more often, because that
display offers more small modes over HDMI.

What is not established

The precise defect inside the closed driver is not identified. This avoids a
presentation route rather than repairing it, and it does not separate the blend itself
from plane programming, buffer layout or synchronisation. It is not evidence that every
similar report elsewhere has the same cause.

No performance claim is made. Power was sampled with the presentation route changed, but
the scene was a game with moving opponents rather than a repeatable benchmark, so the
difference cannot be attributed to the route.

Validation: the source tree passed its test suite, 272 tests. The bundle is byte
identical to the one published as 0.1.9, so the only thing that changed is which version
the manifest declares and therefore which files an installed tool will now place.

SteamOS NVIDIA Installer 0.1.9

This release exists so that a later one can replace Gamescope on a machine that is
already installed. Until now it could not: the signed bundle carried eighteen files
and Gamescope was not among them, so changing it meant building a new USB image and
installing from scratch. That is also the only reason the display fix described below
cannot arrive today.

• Add Gamescope to the set of files a release may deliver, as its own all or nothing
  group beside the performance overlay. Its binary, the provenance file that records
  which source commit it was built from, and its license now sit where the existing
  installer function already looks for them, so that function verifies the binary
  against its own checksum, refuses an artifact built from a commit it does not
  recognise, writes the session override and regenerates the addon manifest. No new
  installation code was needed.
• Carry a Gamescope build that fixes corrupted Game Mode menus on NVIDIA. With a
  menu open, Gamescope could hand the game and Steam's interface straight to two
  hardware planes and let the driver blend them, and that blend draws displaced
  fragments, black rectangles and coloured bands over much of the screen. The build
  refuses that route when a layer needing alpha blending would be placed on a plane,
  on a display device the kernel reports as nvidia-drm. Set
  GAMESCOPE_NVIDIA_COMPOSITE_ALPHA=0 in the Gamescope session to opt out of that
  one reason; every other reason to composite still applies.

An installation running 0.1.8 will not receive that Gamescope build from this
release, and will say so. An installed version only writes the files it was built
knowing about, and it names the ones it skipped. This release gives it the file list
that includes Gamescope, so the release after this one can deliver the binary. A
system installed from a new image gets it immediately.

Nothing else changes. The recovery base remains SteamOS 3.8.14.

Validation: the source tree passed its test suite, which gained four tests for the
changes above, 272 in total. The Gamescope change was verified on one PC with an
RTX 5060 before it was packaged, over DisplayPort and HDMI, at 2560x1440 in 165, 144,
120 and 60 Hz and at 1920x1080 in 120 and 60 Hz, with HDR off and on, with VRR off and
on where the connection offered it, and with the performance overlay off and on. The
menus were checked in the main Steam interface, over a running game, during a
controller notification and through repeated rapid opening and closing. Each result
was attributed from Gamescope's own record of which route it chose rather than from
appearance alone, and the corruption was deliberately reproduced with the change
disabled on both connections, so a clean picture is not simply a machine that stopped
failing. What is not established: the precise defect inside the closed driver is not
identified, this avoids a presentation route rather than repairing it, and it is not
evidence that every similar report elsewhere has the same cause. No performance claim
is made; power was sampled with the route changed but the scene was a game with moving
opponents rather than a repeatable benchmark.

SteamOS NVIDIA Installer 0.1.8

Four fixes, and one change that decides what future releases are allowed to carry.
Installer Update delivers all of it, including the rebuilt overlay, so no new image
is needed.

• A release may now carry files this version does not know, instead of being
  refused whole. An installed tool judged a new release against the file list it
  was built with, so a manifest naming one unfamiliar file was rejected with
  Release has missing or unexpected files. Because the update window only ever
  offers the latest release, the first release to add a file would have left every
  older installation with no way forward, and the list could therefore never change.
  Unknown names and unknown fields are now ignored and named in a note, every signed
  file in the archive is still read and checksummed before anything is written, and
  only the files this version knows are installed. The format number stays strict, so
  a future change that must not be half applied can still refuse cleanly.

• The overlay model names no longer depend on an option that arrives by chance.
  Overlay levels 3 and 4 print the detected GPU and CPU above their readings only
  when MangoHud's mangoapp_steam option is present in the configuration Steam
  writes for the overlay. Steam writes that option itself, but not always: on the
  same machine, at level 4 with a game running, it was absent on one occasion with
  the names missing, and present later with the names shown. Level 4 also applies
  full, which clears the option unless a configuration line puts it back. So the
  feature worked for one person and not for the next, with no user action to explain
  it. Both labels are computed only in this project's overlay build, so requiring
  them to be non-empty is sufficient and is a condition this project controls. The
  rebuilt overlay differs from the previous one only by the 64 bytes of the removed
  condition.

• The Steam notification workaround now also applies when Steam starts from the
  desktop. It was attached to the Game Mode launcher alone, so after Steam verified
  its own files the opaque notification border came back and nothing reapplied the
  workaround until Game Mode was started again. Both launchers now pull it in, and it
  is reapplied whenever Steam restarts in either mode.

• The driver list stops presenting two different claims as one. Choosing a driver
  version offered ten releases, each marked with the same green indicator, which reads
  as an endorsement of ten drivers nobody here has run. NVIDIA documenting a GPU in a
  driver's range and this project having built and accepted that driver are separate
  claims and now look separate. The text above the list names the tested version, and
  when the tested one has aged out of the ten newest package sets the list says so
  rather than leaving the reader to work it out.

• Documentation. The documented way to switch the Remote Play receiver off named
  one launcher and therefore stopped working on the desktop in 0.1.7. It now names
  both and carries a command that writes both overrides. The encoder and notification
  sections say which launchers they attach to, and why the desktop has to have
  LIBVA_DRIVER_NAME removed while Game Mode never sets it.

Known and not fixed here. The notification workaround still selects the Steam client
asset by file name and hash, and this release cannot correct that: the signed bundle
does not carry that file, and a release that added it would have been refused by every
older installation. A later release can add it now that the change above is installed.
Receiving a stream in Desktop Mode still needs hardware decoding switched off in
Steam's own settings, unchanged from 0.1.7 and explained on the Troubleshooting page.

Under investigation and not affected by this release: on the tested PC, driven at
2560x1440 and 165 Hz over DisplayPort with HDR off, the Game Mode menus can draw with
visible glitches while a game runs and the performance overlay is off. It reproduces
with the overlay SteamOS packages and on an older integration, so it is neither new
here nor something this release changes. Two settings cleared it on that machine:
switching Automatic Scale Image off and stepping back one, or turning HDR on. The same
connection and mode is recorded as working with HDR on.

Validation. The published tree passes its suite on Linux, and ShellCheck is clean at
the severity the project's workflow uses. The corrected overlay patch was checked
against the exact MangoHud commit the builder uses, which is also the commit SteamOS
packages, and the overlay was rebuilt in a disposable SteamOS build root from the
published source, with its hashes compared in the build guest, in the build container
and on the host before the files were accepted. The documented receiver override
command was extracted from the manual and executed. The systemd directive that
reapplies the notification workaround was verified against systemd 257 on the tested
PC, with a deliberately invalid directive as a control. Hardware acceptance of the
overlay names follows this update on the tested PC.

SteamOS NVIDIA Installer 0.1.7

Two fixes for the desktop, and the update window fits the screen again. Nothing
compiled changed, so Installer Update delivers all of it and no new image is
needed.

• The update confirmation window can be answered again. Zenity grows a dialog
  to fit its text and ignores a requested height, so the previous release's notes
  pushed Continue and Cancel off the bottom of a 1440p screen and the window could
  not be dismissed at all. It now shows the first lines, says how many are left
  and points at the release page.

• Steam in Desktop Mode gets the same environment as Game Mode. Game Mode
  starts Steam as steam-launcher.service, the KDE desktop starts it as an
  instance of app-steam@.service, and everything this project adds hung off the
  first one only. Outgoing Remote Play from the desktop therefore encoded on the
  CPU with libx264 while the hardware encoder sat idle, because Valve's
  /etc/profile.d/libva.sh forces a driver name written for AMD hardware. Both
  drop-ins are now written for both launchers from one loop, and the wrong driver
  name is removed for Steam. Measured on hardware: the desktop now reports
  Desktop PipeWire NV12 + VAAPI HEVC where it reported libx264 before.

Known and not fixed here: receiving a stream in Desktop Mode still needs hardware
decoding switched off in Steam's own settings. With it on, Steam's client picks a
decode path that costs 153 ms per frame instead of the one it uses under
Gamescope, and rebuilds its decoder three to four times a second rather than
decoding. Software decoding measures 1.66 ms per frame and 43 frames per second on
the same machine, and Game Mode is unaffected. The receiver driver behaves
identically in both modes and a different client decodes in hardware on the same
desktop, so this is not something this project can fix. See the Troubleshooting
page.

Validation. Both changes were exercised on an RTX 5060 with NVIDIA 610.57.04 on
SteamOS 3.8.28. The source tree passes its suite on Linux.

SteamOS NVIDIA Installer 0.1.6

This release stops two fixes from switching themselves off, ends a hang that made
the machine look dead after leaving a streamed game, and lets the installer use a
disk that already holds a system.

• The Gamescope capture correction now follows the package it was built from,
  not a SteamOS release number. Valve moved stable from 3.8.16 to 3.8.28 on
  22 September with Gamescope 3.16.23.6-1. The previous rule required SteamOS
  3.8.16 and Gamescope 3.16.23.4-1 exactly, so an ordinary system update switched
  the correction off. Nothing failed and nothing was logged as an error: the
  status file simply read stock, and outgoing Remote Play showed a black
  picture at the other end. The artifact is now selected when the installed
  Gamescope package matches the one it was compiled against, on the SteamOS 3.8
  line, and stands aside otherwise. Measured on hardware across a move to 3.9.2
  Preview and back: the correction is chosen on 3.8.28, stands aside for Valve's
  newer Gamescope on 3.9.2, and returns on its own afterwards.

• The Remote Play receiver no longer wedges when a stream ends. Leaving a game
  that was being streamed to this machine could leave Steam's streaming_client
  alive but unable to exit, with the compositor still showing its last, black
  frame. The machine looked hung while it was in fact working, ignored SIGTERM and
  needed SIGKILL. The receiver driver waited for a decoded surface with no
  timeout, while every path that ends the thread able to release it left surfaces
  marked as in progress. It now releases what it abandons, and bounds the wait,
  naming the surface in the log if it gives up. The pinned upstream revision
  carries no fix for this and no upstream issue covers it, so the patch is this
  project's own. Installer Update cannot deliver this one, because the
  receiver driver is compiled rather than scripted: an affected system needs a
  new image.

• The installer offers a disk that already holds an installed system, and
  unmounts it first. Any machine with a system on it reported no available
  target, because the installer environment mounts an installed system's
  partitions automatically and the picker treated a mounted disk as unavailable.
  The workaround was to delete the partitions by hand, after which the installer
  erased the disk anyway. The list now names what each disk holds, an existing
  SteamOS installation, a count of other partitions, or none, and releases the
  chosen disk before writing. It refuses with the partition and mount point named
  if that fails, and refuses to touch a disk in use as swap.

• The updater records which SteamOS releases were tested instead of refusing
  every other one. Releases declared a single version and the updater refused
  anything else, so this release would have been refused on current stable, and
  the next point release would do it again. Below the oldest tested release the
  update still refuses and names it, because there is nothing to stand on. At or
  above it the update proceeds and says on standard error what was tested and what
  this system reports. A release that genuinely does not fit still fails loudly:
  the integration ends by verifying every addon and aborts the transaction rather
  than degrading quietly. This release declares 3.8.14, 3.8.16, 3.8.28 and 3.9.2.

Build tooling, which does not change an installed system:

• The complete builder no longer demands one recovery release. Valve publishes a
  single current image and replaces it over time, so the builder records the
  release it finds and warns when it is not one this project has validated. What
  it still refuses is a build root whose package repositories come from another
  SteamOS line. Validated releases and the tested driver now live in one file,
  config/build-baselines.json, read by the builder, the artifact guard and the
  installer.
• The plain installer defaults to the tested driver instead of whatever Arch
  ships that day. --driver latest remains available and is now a deliberate
  choice.
• Artifact metadata is recorded in a fixed order, so the same commit built on
  different hosts produces the same files. Four hosts now agree on the same 89
  addon files.
• The two artifact builders that compile against libdrm declare the kernel
  headers they need. They previously worked only because the complete build runs
  them after two builders that installed the package, so building one artifact on
  its own, which --remote-play-dir and --nvenc-dir are documented to accept,
  failed at the first object.
• An image records the commit it was built from again. The build runs as root
  against a checkout owned by the build user, git refused the repository, the
  message went nowhere and the recorded value became unknown.

Validation. Every change that reaches an installed system was accepted on
hardware: an RTX 5060 with NVIDIA 610.57.04. The candidate image was installed
over an existing system without deleting partitions by hand, the first SteamOS
update was applied and moved the machine to 3.8.28, and every addon, the driver
rebuilt for the new kernel, the userspace check and the read-only root were
verified afterwards. The receiver fix was exercised three times, leaving a game
inside a live session and disconnecting the session completely, and then again
from the image. The machine was moved to 3.9.2 Preview and back: the driver
rebuilt for a kernel from a different series, the addon digest was identical at
all three stops, and the Gamescope selection behaved as described above. The
candidate's payload was compared against the image already accepted on hardware:
89 files, nothing added or removed, 87 byte-identical, and the two that differ
are this release's own changes. The source tree passes its suite on Linux, 242
tests with one skip, including the five files that cannot run on Windows.

Known and not fixed here: a picture streamed from a PC to this machine arrives at
about 64 percent of the brightness it left with. That was measured on two
different SteamOS releases, with two kernels and two compositors, with hardware
decoding on and off and hardware encoding on and off, and in the opposite
direction the same pair of machines is correct. Nothing this project installs is
in that path. See the Troubleshooting page.