Skip to content

Components of SteamOS

Michael DeGuzis edited this page May 23, 2017 · 27 revisions

Table of Contents generated with DocToc

About

The purpose of this page is to breakdown the different technical and architectural areas of SteamOS. What is similar to Debian? What is added?

SteamOS Install process

[ ! ] <This section requires more expansion> [ ! ]

See: Installation

Post-installation actions

A number of items are processed after a clean installation of SteamOS.

As a general overview, this includes:

  • User and user group creation
  • Seat defaults for lightdm (the graphical greeter)
  • Setup configuration and processing of the recovery image
  • Creation and teardown of /usr/bin/post_logon.sh
  • Network connection setup
  • Default session configuration via dbus-send
  • Grub setup
  • Temporary sudo configuration for /usr/bin/post_logon.sh
  • Early graphics handling and installation of GPU drivers

See: post_install.sh

The boot process

In a semi-linear fashion, the boot workflow is:

  1. User turns on machine
  2. GRUB bootloader loads and executes the default kernel and initrd image
  3. Services and run-level programs are started
  4. If LightDM fails to start, the autorepair service, as a "run once" type, initiates /usr/bin/steamos-autorepair
  5. The greeter service, lightdm is started, which processes the supplementary file /etc/lightdm.conf. This automatically performs a log in for user "steam".
  • The default sessions for users "desktop" and "steam" are set during the one-time only post_install.sh here.
  • The default session for either user (typically always "steam" unless changed) is processed out of /usr/share/xessions/<session_name>.desktop
  1. steamos-session is initiated, starting the compositor (steamcompmgr) and Steam itself
  2. User logs in
  3. /usr/bin/steamos-update fires off
  4. Any Steam updates or SteamOS upgrades(via the unattended upgrade) are processed. /etc/apt/apt.conf.d processes configuration files in numerical order.
  5. Any updates requiring reboot will signal the Gnome "inbox" notification to notify the user a reboot/restart is needed.

The update process

This script fires off after login. It handles a few scenarios where packages may have been misconfigured, the unattended upgrades for the OS, and notifications for the Steam client.

See: /usr/bin/steamos-update

What creates reboot/update notifications?

update-notifier-common was removed in Debian Jessie. unattended-upgrades now includes a simple script /etc/kernel/postinst.d/unattended-upgrades which touches the file. reboot-notifier is another small package which is compatible with the format of update-notifier-common. SteamOS makes use of unattended-upgrades to update the system in a seamless fashion.

Once you login, /usr/bin/steamos-update fires off. This will process a few items, including the unattended-upgrade process. After this script is complete, the "inbox" is refreshed. Any updates requiring restart of the Steam client or SteamOS will be indicated by an envelope in the top right corner of the screen.

Unattended upgrades

Unattended upgrades are processed after a user logs into the Steam client. The client is designed to automatically run /usr/bin/steamos-update after this has occurred. Based on numerical pinning in /etc/apt/apt.conf.d/<conf_file>, software packages are upgraded automatically. The configuration determines what sources, from where, and how to handle conflicts (if applicable).

See: unattended upgrade

History behind how unattended upgrades work

Note: This is purely anecdotal, and merely provides some insight into the process, especially if mixing sources

There are various problems associated with unattended upgrades. The Debian packages are not designed for unattended upgrades. Various things may require user intervention.

The Debian policy dictates that package upgrades must take care of preserving user changes to configuration files. This article will explain you how most packages ensure this. This is important knowledge for anyone who has to manage upgrades: knowing how it works lets you easily automate most of it and deal correctly with the fallout. How dpkg manages configuration files

Most packages rely on dpkg to properly install configuration files. Dpkg keeps a checksum of the last installed version of configuration file. When it must install a new version, it calculates the checksum of the currently installed file and if it doesn’t match anymore, it knows that the user has edited the file. In that case, instead of overwriting the configuration file, it asks the user what to do. You probably already have seen those questions, they look like this

Configuration file `/etc/bash.bashrc'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** bash.bashrc (Y/I/N/O/D/Z) [default=N] ? 

In this specific example, if you answer “Y” or “I” (for “yes” or “install”), dpkg will install the new version of /etc/bash.bashrc but it will also backup the current version in /etc/bash.bashrc.dpkg-old. If you answer “N” or “O” (for “no” or “old”), dpkg will install the new version in /etc/bash.bashrc.dpkg-dist and /etc/bash.bashrc is left untouched. The two other answers allow you to examine the differences before taking a decision. Note that if you choose to start a shell, the new version is currently available as /etc/bash.bashrc.dpkg-new (and since Squeeze there are convenient environment variables $DPKG_CONFFILE_OLD and $DPKG_CONFFILE_NEW in case you want to create a custom review script).

All configurations files managed by dpkg are called “conffiles” because that’s the name of the field where they are recorded in the dpkg database. You can display the list of conffiles for any package:

$ dpkg --status bash
[...]
Conffiles:
 /etc/skel/.profile ecb6d3479ac3823f1da7f314d871989b
 /etc/skel/.bashrc 2afdd6c53990f2387a7ef9989af0bc07
 /etc/skel/.bash_logout 22bfb8c1dd94b5f3813a2b25da67463f
 /etc/bash.bashrc 5b3c3bc73d236e4e1b6f9b6c1ed5964e
[...]

The command “dpkg-query --showformat='${Conffiles}\n' --show bash” can give you the same information if you need to retrieve only that field. The 32 characters after the filename are the MD5 checksum of the original configuration file provided by the package1.

ready.json

ready.json shows contents of what unattended-upgrades processes. This may help troubleshoot upgrade problems.

For instance:

{
  "autoremovals": [],
  "blacklisted": [],
  "kept_back": [],
  "to_install": {},
  "to_upgrade": {
    "libxapian22": "1.2.19-1+deb8u1"
  },
  "whitelisted": []
}
/run/unattended-upgrades/ready.json (END)

Problems:

  • package may prompt in the postinst script (using the read command)
  • package may ask questions with debconf
  • conffile questions may be asked by dpkg

Fortunately, there are only few packages that ask prompt using "read". But especially for universe, it can not be guaranteed that they do not do this. Important packages like the kernel, libc, etc do it still. Debconf questions can be tackled by running with it with the noninteractive frontend.

Conffile questions may come up if a package ships with an insecure configuration by default and the conffile is updated in the package, but the user modified that conffile (security upgrades like this happend in the past). You can read further about this at the Debian wiki. If a package upgrade makes changes in the directory /etc or if there are new configfiles (e.g. "interactive mode," such as apt-get upgrade asking you what to do with the old configuration file), you may run into issues.

Further reading:

GPU drivers / Display

Graphics switching and glx-alternatives are processed via /etc/init.d/update-graphics. This runs as a service and is designed to update the graphics stack based on your current hardware.

See: Working-with-display-drivers
See also: Custom Resolutions and Refresh Rates

See also: Debian considering automated upgrades (good info)

Session switching

  • With a normal, unaltered system start, lightdm will log in user "steam" automatically, in which the default session (set during post-install) "steamos-sessoin" is launched.
  • Once the "Desktop Session" is enabled in the Steam Client > Settings Gear > Interface, an option to exit to the desktop is inserted into the power menu.
    • The work to make this happen was already done in post-install, so what is happening here, is you are switching to a new session (on a different TTY) and logging in as user "desktop", which calls about the default session "gnome" for that user.
    • This script is presumably a reverse of the /usr/bin/returntosteam, but baked into the Linux client
  • A desktop icon, named "Return to Steam" initiates the script /usr/bin/returntosteam, which switches the you back to the original session user "steam" started earlier, as before, with dbus-send. This icon is not to be confused with the normal steam.desktop desktop file.

The autorepair process

As mentioned above, the autorepair service, is a "run once" type service. This initiates /usr/bin/steamos-autorepair, which performs the following tasks

  1. Checks if the greeter, Lightdm, fails to start within an acceptable time frame (10 seconds)
  2. Starts dependent services for script
  3. A graphical splash is generated by Plymouth to display "SteamOS is attempting to recover from a fatal error," along with a progress bar
  4. Repair attempts are made with dpkg and apt-get to fix any misconfigurations and other problems with packages.
  5. DKMS modules are forcefully rebuilt
  6. User is notified repair is complete and system is restarted

SteamOS differences vs. Debian

[ ! ] <This section requires more expansion> [ ! ]

  • A stack of python helpers that work between the Steam Client and SteamOS to extend the functions of Steam BPM.
    • Needs expansion/proof

Citations

  1. Everything you need to know about conffiles: configuration files managed by dpkg
Clone this wiki locally