This document tries to define how self-update should behave in different scenarios. It contains also some information about which changes should be made.
-
Minimize the amount of error messages. In a nutshell, we should report problems only if the user explicitly set an URL for the registration server or the update repository.
-
Try to reduce the impact of timeouts. We should avoid using the fallback URL (defined in the control file) if the registration server is unreachable because most likely it will also fail.
-
Add an option to disable/enable self-update to Linuxrc boot menu (future).
-
Allow to set the default option in the distribution control file. The idea is to set the default value without modifying Linuxrc. allow enabling/disabling (future).
Self-Update comprises of three different steps:
- Get the updates repository URL. When it comes to SLE, it may require contacting a registration server to get such an URL (unless another one is specified by the user).
- Download and apply updates (if any) from the updates repository.
- Restart YaST2 if any update was applied.
So when using SLE, it can require contacting two different servers and adding some software to the inst-sys, so a proper error handling is crucial.
NOTE: for openSUSE the first step is slightly simpler as the URL, if not specified by the user, it is read from the control file.
This is the 'happy' scenario. Network is fully working, registration server is available and updates can be cleanly applied.
- YaST2 will contact the registration server (scc.suse.com) to get the URL of the self-update repository.
- The repository will be added.
- If some update is available, the installer will be updated and restarted.
Error handling: the user will be notified if:
- The registration server is unreachable although the network is configured and
the system has an IP address (firewall, no route to host, DNS does not resolve
the registration server name, etc.). In that case the
self_update_url
specified in the control file will be used. - the server where the update repository lives cannot be reached. Note that no error will be shown if the repository is not found as we just consider that, in such a case, no updates are available.
- the repository is not valid
Proposed changes: do not warn the user and skip the self-update silently in case of the aforementioned errors.
If the network is enabled, YaST2 will try to perform the self-update as seen in the With full network access section. So, as the registration server is unreachable:
- YaST2 will show an error pop-up regarding the communication with their registration server.
- The
self_update_url
in the control file, if any, will be used as a updates repository. - If some update is available, the installer will be updated and restarted.
Error handling: same error handling than the With full network access. So the user will get three errors: one for the registration server timeout, a warning about not being able to determine the self-update URL and, finally, another error about not reaching the updates repository.
Proposed changes: do not warn the user and skip the self-update silently if the update repository cannot be found.
As the self-update is the very first step in the installation, the SMT server address should be specified as early as possible:
- via SLP. For security reasons, the user will be asked if at least one SMT server is found.
- using the
regurl
boot parameter.
- YaST2 will contact the SMT server in order to obtain the URL of the self-update repository.
- The repository will be added.
- If some update is available, the installer will be updated and restarted.
Error handling: same error handling than With full network access.
Proposed changes: warn the user in case of connection problem.
The user can provide an URL to a custom self-update repository. In this case, the registration server is not needed at all.
- The repository will be added.
- If some update is available, the installer will be updated and restarted.
Error handling: the user will be notified if:
- the server where the update repository lives cannot be reached.
- the repository is not found. It differs from the default error handling because the URL was specified by the user.
- the repository is not valid.
If network is not configured, the self-update will be silently skipped.
Regarding the self-update feature, AutoYaST will work mostly as a regular installation. Additionally, an AutoYaST profile allows to specify:
- A registration server (
reg_server
element). Analogous toregurl
boot parameter. - A self-update updates repository (
self_update_url
). Analogous to specifying an URL for theself_update
boot parameter.
In AutoYaST is specially important not to block the installation with error messages. If the registration or the updates repositories were not available, the only ways of avoiding error messages were:
- Disabling self-update through the
self-update
boot parameter. - Customizing the
report
section of the AutoYaST profile to disable errors. Obsviously, that's a bad thing because you won't get errors for other real problems.
Fortunately, since version 3.2.8, self-update can be disabled using the
general/self_update
option in the AutoYaST profile.
-
We considered informing the user about a successful self-update. However, as it should be the normal case, we considered is enough with showing the update progress and restarting the installer.
-
For the future, we should consider adding some kind of "versioning" to the installer so the user can check it if needed. As the instsys contains several packages with their own versions, we could consider using a date from packages.
-
Try to reduce timeouts when contacting the registration servers. For example, if the registration server could not be reached, do not use the fallback URL in the control file as it most likely will fail.
-
Consider reporting an error when the self-update is only partially applied.
-
Other kind of errors (SSL, API, incompatible SMT) are handled like a regular network error, so in the default case, the self-update will be skipped.
https://gist.github.com/imobachgs/cb03b6a87dd5e31c89a9463d30db4252#with-full-network-access says in the Error handling part:
Note that no error will be shown if the repository is not found as we just consider that, in such a case, no updates are available.
but in the Proposed changes it saysdo not warn the user and skip the self-update silently if the update repository cannot be found
It looks as no change is required. Maybe it should read
if the server where the update repository lives cannot be reached
instead?