I am writing a background update script that is started by systemd-timers. It would be an internal replacement for the yast2 method to be more homogeneous between many Leap and Tumbleweed (client) installations.
According to the documentation, when a reboot is required, zypper should exit with the code “102”. This is necessary because I would generate a GUI notification in this case. But it doesn’t seem to work.
After manually updating systemd or kernel (for testing purposes), I always get “0” back at “$?”. “105” if I cancel the update, which is correct and expected.
Any advice?
...
102 - ZYPPER_EXIT_INF_REBOOT_NEEDED
Returned after a successful installation of a patch which requires reboot of computer.
...
Is it really the difference between “patch” and “update/upgrade”?
Hi
That sort of process on multiple machines sounds fraught with danger… If lots of machines, why not consider salt or other management ways, eg staging updates etc?
I don not know the answers, but can tell what I think about the semantics of Patch and Update. It is a bot confusing, but as I understand it (from the zypper man page), those things that come from the Update repositories (Oss-Update and non-OSS-Update) are Patches . You will install patches when you do:
zypper patch;
zypper up (which may include more e.g. from Packman).
According to this theory, when you do a zypper up, you will also install patches and thus in theory you should get a return code of 102 when e.g. a new kernel is involved (as you assume).
I normally use YaST > Software > Online Update (equivalent to zypper patch), which shows pop-up windows before starting a the process to inform that a reboot asap is required) giving the oportunity to bail out) and after finishing (as a reminder). This means that the correct information is available in the RPMs. BTW, I can not remember to have seen this for systemd, only for the kernel.
So, when you can prove that the return code is not set correctly in these cases, a bug report may be needed.
thx for your feedback.
I think everyone could reproduce that as following:
mlsuse:~ # zypper in -f systemd
Loading repository data...
Reading installed packages...
Forcing installation of 'systemd-234-lp152.31.25.1.x86_64' from repository 'Main Update Repository'.
Resolving package dependencies...
The following package is going to be reinstalled:
systemd
The following package requires a system reboot:
systemd
1 package to reinstall.
Overall download size: 2.5 MiB. Already cached: 0 B. No additional space will be used or freed after the operation.
Note: System reboot required.
Continue? [y/n/v/...? shows all options] (y):
mlsuse:~ # echo $?
0
Shouldn’t we get 102 back instead of 0?
@malcolmlewis
I’ve never heard about this (https://github.com/saltstack/salt ?). But anyway, I know cdist or ansible for example. But in my opinion, “update logic” should working independent and without a single point of failure. Also, clients can be turned off or traveling around the globe. Ansible, cdist and may be others are more straight forward for server farm purposes.
Why do you think that’s very dangerous? Are updates from openSUSE not stable or zypper/yast powerful enough?
Sure, in respect of tumbleweed’s dist-upgrade, that’s another story (and wouldn’t be the default system).
But, I will check out their documentation. Thanks a lot.
@hvc
I know about the difference between patch, update and upgrade. But you’re right! “zypper up” do patches as well.
Therefore 102 should be triggered anyway.
Hi
Just rolling out automatic updates without some sort of review, with Tumbleweed at least there is the snapshot notification and if something is broken folks post on the Mailing list pretty quick
With some sort of staging process it gives you a chance to review, check then deploy… AFAIK RMT could also do this for you to deploy out to systems wherever they may be…
If lots of machines, why not consider salt or other management ways, eg staging updates etc?