YaST provides three systemd services: YaST2-Firstboot.service YaST2-Second-Stage.service and autoyast-initscripts.service. The first two services belong to yast2-installation and the last one to autoyast2-installation.
The service YaST2-Firstboot.service takes care of running YaST Firstboot. Nowadays this service only does that, so it seems misplaced in yast2-installation. Maybe it should be moved to yast2-firstboot. Anyway, the service would fail if yast2-firstboot is not installed.
The service YaST2-Second-Stage.service runs the AutoYaST second stage on the first boot after an AutoYaST installation/upgrade. And autoyast-initscripts.service runs after the second stage in order to execute customs scripts.
Once AutoYaST installation/upgrade is done (a.k.a. first stage), the system boots and starts the second stage. The YaST UI is shown meanwhile the second stage is running. Just after finishing the second stage, its UI is closed, landing in the tty1 virtual console while the autoyast-initscripts.service is being executed:
- AutoYaST First Stage
- Boot
- YaST2-Second-Stage.service
- autoyast-initscripts.service
- User login
By default, the user login is shown after finishing the execution of the init scripts, although the AutoYaST profile can be configured to force booting after the second stage. The type of login depends on the systemd target. In case of graphical.target, the Display Manager is executed. Otherwise, a getty service is generated in tty1.
AutoYaST installation/upgrade can be performed either locally or remotely via SSH or VNC connection. Some adjustments are required in the configuration of the services to properly work when connecting to a remote machine.
When SSH is used to install/upgrade a remote machine, AutoYaST Second Stage waits for the user to re-connect and continue with the installation. This is done so to allow the user to see the YaST UI meanwhile the second stage is running. To accomplish this, SSH connection for the root user should be allowed, but prevented for other users.
The first attempt to restrict SSH connection to only root user was to force YaST2-Second-Stage.service to run before systemd-user-sessions.service, see yast/yast-autoinstallation#82. Note that non-privileged users cannot login meanwhile /run/nologin file exists. And systemd-user-sessions.service takes care of removing such a file when the service starts. So, delaying systemd-user-sessions.service execution seemed to be a good idea, but it generates a systemd-pam timeout when root tries to connect. The service needs to be running before any attempt of login, even for root. Otherwise user sessions cannot be created.
Now, YaST2-Second-Stage.service runs after systemd-user-sessions.service, so users would be able to connect, even non-privileged ones. To limit connetions to root, YaST2-Second-Stage.service creates /run/nologin before its execution and remove the file once it has finished, see yast/yast-installation#1024 and yast/yast-installation#1030.
When using VNC, YaST starts a VNC server in the remote machine in order to allow the user to connect and follow the AutoYaST Second Stage. QA team found a race condition when systemd-user-sessions.service runs before YaST2-Second-Stage.service. Switching to another virtual console (ctrl+alt+f2-6), makes systemd-getty-generator to instantiate a getty service on demand. Note that getty auto-generation is prevented if systemd-user-sessions.service runs after YaST2-Second-Stage.service. And, for some reason, if a getty is instantiate on demand before YaST2-Second-Stage.service, then XVNC fails to start. Note that switching to a virtual console before YaST Second Stage usually does not happen, but openQA tests could do it to execute something.
To avoid this problem, YaST2-Second-Stage.service is preventing getty@tty1-6.service to run before finishing the YaST Second Stage, see yast/yast-installation#1033.