-
Notifications
You must be signed in to change notification settings - Fork 70
Components of SteamOS
Table of Contents generated with DocToc
- About
- SteamOS Install process
- Post-installation actions
- The boot process
- The update process
- Unattended upgrades
- GPU drivers / Display
- Session switching
- The autorepair process
- SteamOS differences vs. Debian
- Citations
The purpose of this page is to breakdown the different technical and architectural areas of SteamOS. What is similar to Debian? What is added?
[ ! ] <This section requires more expansion> [ ! ]
See: Installation
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
In a semi-linear fashion, the boot workflow is:
- User turns on machine
- GRUB bootloader loads and executes the default kernel and initrd image
- Services and run-level programs are started
- If LightDM fails to start, the autorepair service, as a "run once" type, initiates /usr/bin/steamos-autorepair
- 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
- steamos-session is initiated, starting the compositor (steamcompmgr) and Steam itself
- User logs in
- /usr/bin/steamos-update fires off
- Any Steam updates or SteamOS upgrades(via the unattended upgrade) are processed.
/etc/apt/apt.conf.d
processes configuration files in numerical order. - Any updates requiring reboot will signal the Gnome "inbox" notification to notify the user a reboot/restart is needed.
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.
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 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
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:
- Debian policy
- Everything you need to know about conffiles: configuration files managed by dpkg backup archive link
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)
- 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.
As mentioned above, the autorepair service, is a "run once" type service. This initiates /usr/bin/steamos-autorepair, which performs the following tasks
- Checks if the greeter, Lightdm, fails to start within an acceptable time frame (10 seconds)
- Starts dependent services for script
- A graphical splash is generated by Plymouth to display "SteamOS is attempting to recover from a fatal error," along with a progress bar
- Repair attempts are made with
dpkg
andapt-get
to fix any misconfigurations and other problems with packages. - DKMS modules are forcefully rebuilt
- User is notified repair is complete and system is restarted
[ ! ] <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