Components of SteamOS
The purpose of this page is to breakdown the different technical and architectural areas of SteamOS. What is similar to Debian? What is added?
See: Installation
A number of items are processed after a clean installation of SteamOS.
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 Plymouth fails to start, the autorepair service as a "run once" type, kicking off /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.shhere.
- The default session for either user (typically always "steam" unless changed) is processed out of
/usr/share/xessions/<session_name>.desktopis processed - steamos-session is initiated, starting the compositor (steamcompmgr) and Steam itself
- User logs in
-
/usr/bin/steamos-updatefires off - Any Steam updates or SteamOS upgrades(via the unattended upgrade are processed.
/etc/apt/apt.conf.dprocesses configuration files in numerical order. - Any updates requiring reboot will signal the Gnome "inbox" notification to notify the user a reboot/restart is needed.
Note: This is purely anecdotal, and merely provides some insight into the process
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
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.
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.
