See states.dot for a state diagram of the system update script generated from
template file updata_system_update.template.sh. The states are defined by the
presence or absence of various empty stamp files. The table below defines the
exact relation.
| Stamp file | init | U | R1 | US | UR | UR2 | URF | UF | RF | FR | FR2 | FRF | done |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
update_started |
- | X | X | X | X | X | X | X | X | X | X | X | (X) |
update_done |
- | - | - | X | X | X | X | - | - | - | - | - | (X) |
update_failure |
- | - | - | - | - | - | - | X | X | X | X | X | (X) |
update_failure_again |
- | - | - | - | - | - | - | - | X | - | - | - | (X) |
update_reboot_started |
- | - | - | - | X | X | X | - | - | X | X | X | (X) |
update_reboot_stderr |
- | - | - | - | - | X | X | - | - | - | X | X | (X) |
update_reboot_failed |
- | - | - | - | - | - | X | - | - | - | - | X | (X) |
update_finished |
- | - | - | - | - | - | - | - | - | - | - | - | X |
/system-update |
- | - | X | (X) | (X) | (X) | (X) | (X) | - | (X) | (X) | (X) | - |
Files update_exit_code and update_reboot_exit_code are also created and
deleted by the script, but they do not affect the state.
State R2 shown in diagram states.dot is the same as FR2, and state
C in the diagram is the same as UR2. Therefore, these are not listed in
the table above. In case the update script determines state FR2 at startup,
it starts execution at state R2 in the diagram; correspondingly, if the
state is UR2 at startup, the script starts at state C. Otherwise, the
script would end up in an infinite reboot loop.
State R1 shown in diagram states.dot is the same as R2 and is
distinguished by the presence or absence of the /system-update symlink. This
is a marker for offline system updates managed by systemd. If the symlink is
there, then we are in state R2; otherwise, we might be in R2.
The done state is kind of special as it depends only on the presence of the
update_finished file. That is, if this file is present, then no other stamp
files need to be considered.
State U is typically entered from the REST API. The user has requested a system update in some way, and this request should end up in the REST API. It will generate the update script from our template and start updaTA. In case the update is to be done via package manager, the required packages are downloaded while in this state.
State R1 is typically entered from a systemd service when systemd has tricked the system into offline system update mode. The system-update service will restart the script generated by the REST API, which figures out it is in state R1. Then, it performs the update from the previously downloaded packages.
State R2 is typically entered from the REST API after a reboot. In case the system update has not finished, updaTA will try to finish it in this state.