How SM displays package installation failures

We have installed SM3 and have (2) SLES11 and (1) SLES12 clients configured for testing. We tested some patch/package updates and everything works ok. However, we were curious to see what would happen in the event of a failure. So, we updated the kernel package and made sure /boot was out of disk space.

If I tried a manual install of the updated kernel packages via the command-line on the SLES12 client:

[CODE]# zypper in kernel-default kernel-default-devel kernel-devel kernel-macros kernel-source
Refreshing service ‘SUSE_Linux_Enterprise_Server_12_SP1_x86_64’.
Loading repository data…
Reading installed packages…
Resolving package dependencies…

The following 4 NEW packages are going to be installed:
kernel-default-3.12.69-60.64.35.1 kernel-default-devel-3.12.69-60.64.35.1
kernel-devel-3.12.69-60.64.35.1 kernel-source-3.12.69-60.64.35.1

The following package is going to be upgraded:
kernel-macros

1 package to upgrade, 4 new.
Overall download size: 0 B. Already cached: 126.3 MiB. After the operation,
additional 640.4 MiB will be used.
Continue? [y/n/? shows all options] (y): y
In cache kernel-default-3.12.69-60.64.35.1.x86_64.rpm
(1/5), 33.6 MiB (139.8 MiB unpacked)
In cache kernel-macros-3.12.69-60.64.35.1.noarch.rpm
(2/5), 1.9 MiB ( 6.1 KiB unpacked)
In cache kernel-devel-3.12.69-60.64.35.1.noarch.rpm
(3/5), 11.2 MiB ( 47.8 MiB unpacked)
In cache kernel-source-3.12.69-60.64.35.1.noarch.rpm
(4/5), 75.9 MiB (450.0 MiB unpacked)
In cache kernel-default-devel-3.12.69-60.64.35.1.x86_64.rpm
(5/5), 3.6 MiB ( 2.8 MiB unpacked)
Checking for file conflicts: …[done]
(1/5) Installing: kernel-default-3.12.69-60.64.35.1.x86_64 …[error]
Installation of kernel-default-3.12.69-60.64.35.1.x86_64 failed:
Error: Subprocess failed. Error: RPM failed: installing package kernel-default-3.12.69-60.64.35.1.x86_64 needs 42MB on the /boot filesystem

Abort, retry, ignore? [a/r/i] (a):[/CODE]

It is obvious from the above message what the problem is. However, when I tried installing the SUSE-12-SP1-2017-485 patch under Software->Patches, the task failed and the error message given in “Failed Systems” under Schedule->“Failed Actions” was:

[QUOTE]{ “module_|-applychannels_|-state.apply_|-run”: { “comment”: “Module function state.apply executed”, “name”: “state.apply”, “start_time”: “13:33:01.666798”, “result”: true, “duration”: 121.093, “run_num”: 0.0, “changes”: { “ret”: { “file_|-/etc/zypp/repos.d/susemanager:channels.repo_|-/etc/zypp/repos.d/susemanager:channels.repo_|-managed”: { “comment”: “File /etc/zypp/repos.d/susemanager:channels.repo is in the correct state”, “name”: “/etc/zypp/repos.d/susemanager:channels.repo”, “start_time”: “13:33:01.751750”, “result”: true, “duration”: 34.299, “run_num”: 0.0, “changes”: {} } } } }, “module_|-patchinstall_|-pkg.install_|-run”: { “comment”: "Module function pkg.install threw an exception. Exception: Zypper command failure: Installation of kernel-default-3.12.69-60.64.35.1.x86_64 failed:
Error: Subprocess failed. Error: RPM failed: \tinstalling package kernel-d[/QUOTE]

Needless to say this is not very descriptive and doesn’t lead one to the real cause of the problem. I know I could look through /var/log/zypper.log on the client but doing this for tens of machines with tens of failures leaves one wary. Is there a way to get a more descriptive failure message when package installation fails? What would be really nice is a full log of the install on the client (as if you typed the zypper command in a tty). In this specific instance, the command-line being invoked on the client by SM is “zypper --non-interactive --no-refresh install --name --auto-agree-with-licenses patch:SUSE-SLE-SERVER-12-SP1-2017-485”. The output of this command, when run on a tty, resembles the original command above input on the command-line. But, the output seems lost to SM.

I tested a similar failure on SLES11-SP3 and SLES11-SP4. While the kernel packages did not install because I filled up /boot on both systems, SM3 did not register the installation as failures. I see both actions under Schedule->Completed Actions->Completed Systems. Why did SM3 not see these as failed installations?

Please open a support request and attach supportconfig for server and client for further investigation.

Just opened a support ticket for this issue.