# How SM displays package installation failures **URL:** \ **Category:** SUSE Multi Linux Manager\ **Created:** [March 30, 2017, 9:51pm UTC](https://forums.suse.com/t/how-sm-displays-package-installation-failures/29620 "2017-03-30T21:51:32Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![lychina](https://avatars.discourse-cdn.com/v4/letter/l/97f17d/32.png) [@lychina](https://forums.suse.com/u/lychina)\ **Post date:** [March 30, 2017, 9:51pm UTC](https://forums.suse.com/t/how-sm-displays-package-installation-failures/29620/1 "2017-03-30T21:51:32Z")
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. ---
**Author:** ![lychina](https://avatars.discourse-cdn.com/v4/letter/l/97f17d/32.png) [@lychina](https://forums.suse.com/u/lychina)\ **Post date:** [March 30, 2017, 10:08pm UTC](https://forums.suse.com/t/how-sm-displays-package-installation-failures/29620/2 "2017-03-30T22:08:42Z")
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? ---
**Author:** ![kwk](https://sea2.discourse-cdn.com/flex022/user_avatar/forums.suse.com/kwk/32/11997_2.png) [@kwk](https://forums.suse.com/u/kwk)\ **Post date:** [March 31, 2017, 9:35am UTC](https://forums.suse.com/t/how-sm-displays-package-installation-failures/29620/3 "2017-03-31T09:35:23Z")
> [@lychina;37348](#): > > 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. ---
**Author:** ![Albert](https://avatars.discourse-cdn.com/v4/letter/a/48db29/32.png) [@Albert](https://forums.suse.com/u/Albert)\ **Post date:** [April 18, 2017, 9:39pm UTC](https://forums.suse.com/t/how-sm-displays-package-installation-failures/29620/4 "2017-04-18T21:39:52Z")
> [@kwk;37358](#): > > Please open a support request and attach supportconfig for server and client for further investigation. Just opened a support ticket for this issue.