Salt: pkg.installed succeeded but says it failed
python-pip has been installed after the execution of this state:
salt-ssh minion state.sls my_sls
minion:
----------
ID: necessary_packages
Function: pkg.installed
Result: False
Comment: The following packages failed to install/update: python-pip=7.1.2 42 targeted packages were already installed
Started: 12:36:58.350875
Duration: 12753.843 ms
Changes:
----------
python-pip:
----------
new:
7.1.2-1.0
old:
...
Finally running salt-ssh-2015.8.0 and salt-2015.8.0 installed via pip.
srkunze
All 36 comments
Re-running results in:
salt-ssh minion state.sls my_sls
minion:
----------
ID: necessary_packages
Function: pkg.installed
Result: False
Comment: The following packages failed to install/update: python-pip=7.1.2 42 targeted packages were already installed
Started: 12:55:00.202166
Duration: 4425.51 ms
Changes:
@srkunze, thanks for the report. I am unable to reproduce the problem. Is there anything else you can share about the situation? Here is what I used:
pip:
pkg.installed:
- name: python-pip
OS: ubuntu 14.04
jfindlay
on 26 Sep 2015
That is the zypper output:
minion:~ # zypper in python-pip
Loading repository data...
Warning: Repository '<reponame>' appears to be outdated. Consider using a different mirror or server.
Reading installed packages...
Resolving package dependencies...
The following NEW package is going to be installed:
python-pip
1 new package to install.
Overall download size: 1,3 MiB. After the operation, additional 5,8 MiB will be used.
Continue? [y/n/? shows all options] (y): y
Retrieving package python-pip-7.1.2-1.0.noarch (1/1), 1,3 MiB ( 5,8 MiB unpacked)
Retrieving: python-pip-7.1.2-1.0.noarch.openSUSE12.3.rpm .......................................................................................................................................[done (315,6 KiB/s)]
(1/1) Installing: python-pip-7.1.2-1.0 .......................................................................................................................................................................[done]
Additional rpm output:
update-alternatives: using /usr/bin/pip2.7 to provide /usr/bin/pip (pip) in auto mode
minion:~ # echo $?
0
As one can see, the exit value is zero.
srkunze
on 28 Sep 2015
@srkunze, thanks for the extra info.
jfindlay
on 28 Sep 2015
Is there something, I can do here?
srkunze
on 8 Oct 2015
@srkunze, this might be fixed by #27797.
jfindlay
on 9 Oct 2015
This bug is back in 2015.8.7, 2015.8.5 is fine.
ID: java-1.8.0-openjdk.x86_64
Function: pkg.installed
Result: False
Comment: The following packages failed to install/update: java-1.8.0-openjdk=1.8.0.65-3.b17.el7
Started: 12:36:34.861717
Duration: 203959.475 ms
Changes:
----------
java-1.8.0-openjdk:
----------
new:
1:1.8.0.65-3.b17.el7
old:
java-1.8.0-openjdk-headless:
----------
new:
1:1.8.0.65-3.b17.el7
old:
deamen
on 16 Mar 2016
Still there with 2016.3.1.
srkunze
on 12 Jul 2016
I have the same issues,my salt version is 2016.3.0(centos 6.5/python 2.6.6),but if i don't specify version when use pkg.install,the problem is gone.
zhouyuyong
on 19 Jul 2016
The problem seems to be coming from the yum respond having "Package 1:" instead of "Package"
[root@minion3 salt]# yum install java-1.8.0-openjdk
Loaded plugins: fastestmirror
Setting up Install Process
Loading mirror speeds from cached hostfile
* base: mirror.vcu.edu
* epel: mirrors.cat.pdx.edu
* extras: mirror.hostduplex.com
* updates: mirrors.cat.pdx.edu
Package 1:java-1.8.0-openjdk-1.8.0.101-3.b13.el6_8.x86_64 already installed and latest version
Nothing to do
[root@minion3 salt]#
Take a look at yum install git
[root@minion3 salt]# yum install git
Loaded plugins: fastestmirror
Setting up Install Process
Loading mirror speeds from cached hostfile
* base: mirror.vcu.edu
* epel: mirrors.xmission.com
* extras: mirror.scalabledns.com
* updates: mirrors.cat.pdx.edu
Package git-1.7.1-4.el6_7.1.x86_64 already installed and latest version
Nothing to do
hoitsang
on 3 Aug 2016
+1, hit this following the tutorial on digitalocean with the most basic salt state:
vim:
pkg:
- installed
$ salt-call --local state.apply packages
[ERROR ] boto_route53 requires at least boto 2.35.0.
local:
----------
ID: vim-enhanced
Function: pkg.installed
Result: True
Comment: The following packages were installed/updated: vim-enhanced
Started: 22:00:06.838433
Duration: 6025.485 ms
Changes:
----------
vim-enhanced:
----------
new:
2:7.4.160-1.el7
old:
Summary for local
------------
Succeeded: 1 (changed=1)
Failed: 0
------------
Total states run: 1
$ salt --version
salt 2016.3.1 (Boron)
$ python --version
Python 2.7.5
$ cat /etc/redhat-release
CentOS Linux release 7.2.1511 (Core)
bwhaley
on 11 Aug 2016
Same here, error using the most basic example, installing vim to a Centos 7 minion:
thor:
ID: vim
Function: pkg.installed
Result: False
Comment: The following packages failed to install/update: vim
Started: 23:40:47.181361
Duration: 2657.922 ms
Changes:
Summary for thor
Succeeded: 0
Failed: 1
Total states run: 1
On minion side:
Package 2:vim-enhanced-7.4.160-1.el7.x86_64 already installed and latest version
liquidox
on 19 Aug 2016
I am having this issue in 2016.11.0 general release, but only with python-pip for some reason, other packages work fine.
fraajad
on 14 Dec 2016
@dougofthemoment Same here.
srkunze
on 17 Dec 2016
@srkunze
I figured it out, in the epel repo you have to specify python2-pip, there is no longer python-pip as of a week ago...
fraajad
on 17 Dec 2016
Any word on a fix for this issue? I'm experiencing failures when trying to install specific version of packages in CentOS 7 hosts even though the package actually installs successfully. If I remove the version specifier, the Salt run succeeds.
forty8bits
on 11 May 2017
I am seeing false failures with a windows minion:
ID: install packages Function: pkg.installed Result: False Comment: The following packages failed to install/update: chocolatey, rubyinstaller_x64 The following packages were already installed: svn, git, firefox, chrome, node.js, tortoise-svn, tortoise-git Started: 12:41:48.810000 Duration: 24016.0 ms Changes: ---------- chocolatey: ---------- install status: success rubyinstaller_x64: ---------- install status: success_Output Truncated by me here_
Succeeded: 4 (changed=5)
Failed: 1
badriance
on 24 Jul 2017
root@saltmaster:/home/vagrant# salt '*' state.apply installpkgs.www
www:
----------
ID: install WWW packages
Function: pkg.installed
Result: False
Comment: The following packages failed to install/update: ms-vcpp-2010-sp1-mfc-redist_x64
The following packages were already installed: availabilityservice, affinitizer, jittracker, ddpreloader, wwwdotnet, webstateservice, jrcapture
Started: 09:56:53.562000
Duration: 15187.0 ms
Changes:
----------
ms-vcpp-2010-sp1-mfc-redist_x64:
----------
install status:
success
Summary for www
------------
Succeeded: 0 (changed=1)
Failed: 1
------------
Total states run: 1
Total run time: 15.187 s
ERROR: Minions returned with non-zero exit code
root@saltmaster:/home/vagrant# salt '*' pkg.install ms-vcpp-2010-sp1-mfc-redist_x64
www:
----------
ms-vcpp-2010-sp1-mfc-redist_x64:
----------
install status:
success
Found another instance of this problem. This time it only reports failure in a group of pkg.installs, and it still reports success in the "Changes" field and does actually succeed at installing the package.
calebwoofenden
on 11 Sep 2017
@calebwoofenden Please do not mix windows issues with CentOS issues. The pkg.installed state expects certain output from modules. Currently win_pkg does implement the correct way to return errors. Please raise a new issue prefixed with win_pkg:
damon-atkins
on 12 Sep 2017
I'm running into the same thing with a specific piece of software I'm trying to install.
Assume the package is called michaelsoft-1.2.3-45.el7.x86_64.
michaelsoft:
pkg_version: 1.2.3
If I try the following snippet, salt returns a message that the packages failed to install or update. Contrary to the salt output, the packages DO get installed.
Install packages:
pkg.installed:
- enablerepo: internal_repository
- fromrepo: internal_repository
- pkgs:
- {{ michaelsoft.pkg }}: {{ michaelsoft.pkg_version }}
- {{ michaelsoft.pkg }}-libs: {{ michaelsoft.pkg_version }}
Salt shows the correct output strictly because I put the -45.el7 portion of the package name on. The packages are installed just as above.
{% set osmajorrelease = salt['grains.get']('osmajorrelease') %}
Install packages:
pkg.installed:
- enablerepo: internal_repository
- fromrepo: internal_repository
- pkgs:
- {{ michaelsoft.pkg }}: {{ michaelsoft.pkg_version }}-45.el{{ osmajorrelease }}
- {{ michaelsoft.pkg }}-libs: {{ michaelsoft.pkg_version }}-45.el{{ osmajorrelease }}
It would be useful to have a flag such as ignore_release: True much like ignore_epoch: True that would allow someone to ignore -45.el7 or other release information.
pgporada
on 29 Sep 2017
It seems I keep running into this problem every few Salt releases. I recently upgraded to 2017.7.1 (Nitrogen) and now my nginx_pkg state is failing.
nginx_pkg:
pkg.installed:
- name : nginx
- version : 1.12.1-1.33.amzn1
- fromrepo : amzn-main
You can omit the fromrepo attribute, but it doesn't make a difference.
# salt foo state.sls nginx.pkg
foo:
----------
ID: nginx_pkg
Function: pkg.installed
Name: nginx
Result: False
Comment: The following packages failed to install/update: nginx=1.12.1-1.33.amzn1
Started: 19:12:38.419164
Duration: 4645.366 ms
Changes:
Summary for foo
------------
Succeeded: 0
Failed: 1
------------
Total states run: 1
Total run time: 4.645 s
# salt foo cmd.run 'yum info nginx'
foo:
Loaded plugins: priorities, update-motd, upgrade-helper
1093 packages excluded due to repository priority protections
Installed Packages
Name : nginx
Arch : x86_64
Epoch : 1
Version : 1.12.1
Release : 1.33.amzn1
Size : 1.4 M
Repo : installed
From repo : amzn-main
Summary : A high performance web server and reverse proxy server
URL : http://nginx.org/
License : BSD
Description : Nginx is a web server and a reverse proxy server for HTTP, SMTP,
: POP3 and IMAP protocols, with a strong focus on high concurrency,
: performance and low memory usage.
# yum -y --disablerepo=* --enablerepo=amzn-main install nginx-1.12.1-1.33.amzn1
Loaded plugins: priorities, update-motd, upgrade-helper
amzn-main | 2.1 kB 00:00:00
Package 1:nginx-1.12.1-1.33.amzn1.x86_64 already installed and latest version
Nothing to do
# rpm -qa --queryformat '%{NAME}_|-%{EPOCH}_|-%{VERSION}_|-%{RELEASE}_|-%{ARCH}_|-(none)\n' | grep nginx
nginx_|-1_|-1.12.1_|-1.33.amzn1_|-x86_64_|-(none)
nginx-mod-mail_|-1_|-1.12.1_|-1.33.amzn1_|-x86_64_|-(none)
nginx-mod-http-geoip_|-1_|-1.12.1_|-1.33.amzn1_|-x86_64_|-(none)
nginx-mod-http-image-filter_|-1_|-1.12.1_|-1.33.amzn1_|-x86_64_|-(none)
nginx-mod-stream_|-1_|-1.12.1_|-1.33.amzn1_|-x86_64_|-(none)
nginx-all-modules_|-1_|-1.12.1_|-1.33.amzn1_|-x86_64_|-(none)
nginx-mod-http-perl_|-1_|-1.12.1_|-1.33.amzn1_|-x86_64_|-(none)
nginx-mod-http-xslt-filter_|-1_|-1.12.1_|-1.33.amzn1_|-x86_64_|-(none)
nginx-release-rhel_|-(none)_|-6_|-0.el6.ngx_|-noarch_|-(none)
2017-10-05 19:00:40,763 [salt.loaded.int.module.cmdmod ][INFO ][13301] Executing command ['yum', '-y', '--disablerepo=*', '--enablerepo=amzn-main', 'install', 'nginx-1.12.1-1.33.amzn1'] in directory '/root'
2017-10-05 19:00:40,928 [salt.loaded.int.module.cmdmod ][TRACE ][13301] stdout: Loaded plugins: priorities, update-motd, upgrade-helper
Package 1:nginx-1.12.1-1.33.amzn1.x86_64 already installed and latest version
Nothing to do
2017-10-05 19:00:40,928 [salt.loaded.int.module.cmdmod ][INFO ][13301] Executing command ['rpm', '-qa', '--queryformat', '%{NAME}_|-%{EPOCH}_|-%{VERSION}_|-%{RELEASE}_|-%{ARCH}_|-(none)'] in directory '/root'
2017-10-05 19:00:41,311 [salt.state ][ERROR ][13301] The following packages failed to install/update: nginx=1.12.1-1.33.amzn1
2017-10-05 19:00:41,311 [salt.state ][INFO ][13301] Completed state [nginx] at time 19:00:41.311129 duration_in_ms=4655.328
As you can see from the minion log, the package is found to be already installed and yet the state fails.
-- UPDATE --
I tried adding "ignore_epoch: True" to the nginx_pkg state, but that didn't have any effect.
What did work was prepending 1: to the version number.
nginx_pkg:
pkg.installed:
- name : nginx
- version : 1:1.12.1-1.33.amzn1
- fromrepo : amzn-main
# salt foo state.sls nginx.pkg
foo:
----------
ID: nginx_pkg
Function: pkg.installed
Name: nginx
Result: True
Comment: Version 1:1.12.1-1.33.amzn1 of package 'nginx' is already installed
Started: 19:45:32.762797
Duration: 398.382 ms
Changes:
Summary for foo
------------
Succeeded: 1
Failed: 0
------------
Total states run: 1
Total run time: 398.382 ms
dwiest
on 5 Oct 2017
Is there an update for a possible fix of this issue? We keep running into it over and over again.
BenjaminSchiborr
on 26 Oct 2017
All,
I just ran into this issue and found something interesting.
ID: curator_package_dependencies
Function: pkg.installed
Name: python-pip
Result: False
Comment: The following packages failed to install/update: python-pip
Started: 17:43:10.542141
Duration: 40934.825 ms
Changes:
----------
python-setuptools:
----------
new:
0.9.8-7.el7
old:
python2-pip:
----------
new:
8.1.2-5.el7
old:
Notice, that the package that I was trying to install was python-pip. In CentOS, that is referred to as python2-pip. Because it went ahead and found that out for me, it still installed....but Salt was looking for python-pip, and therefore marked it as a failure.
Once I changed my state to python2-pip, the EXACT name that is coming from the package management software, things went green:
ID: curator_package_dependencies
Function: pkg.installed
Result: True
Comment: All specified packages are already installed
Started: 17:53:57.920742
Duration: 536.19 ms
Changes:
jbkc85
on 4 Dec 2017
fwiw, I'm seeing this same behavior using salt version 2017.7.2-1 on Amazon Linux.
salt-master-2017.7.2-1.amzn1.noarch
salt-minion-2017.7.2-1.amzn1.noarch
in my sls, I call for a particular version of a package to be installed:
fish:
pkg.installed:
- name: fish
- version: 2.7.1-1.1
- fromrepo: shells_fish_release_2
... on on the minion, looking at debug output, I observe the package installation succeeding:
```[ERROR ] Made the following changes:
'fish.i686' changed from 'absent' to '2.7.1-1.1'
[INFO ] Completed state [fish] at time 04:34:45.209435 duration_in_ms=6723.025
[INFO ] Returning information for job: 20180102043437692860
[DEBUG ] minion return: {'fun_args': ['pkgs.fish-shell'], 'jid': '20180102043437692860', 'return': {'pkgrepo_|-shells_fish_release_2_|-shells_fish_release_2_|-managed': {'comment': "Package repo 'shells_fish_release_2' already configured", 'name': 'shells_fish_release_2', 'start_time': '04:34:37.900206', 'result': True, 'duration': 578.289, '__run_num__': 0, '__sls__': u'pkgs.fish-shell', 'changes': {}, '__id__': 'shells_fish_release_2'}, 'pkg_|-fish_|-fish_|-installed': {'comment': 'The following packages failed to install/update: fish=2.7.1-1.1', 'name': 'fish', 'start_time': '04:34:38.486410', 'result': False, 'duration': 6723.025, '__run_num__': 1, '__sls__': u'pkgs.fish-shell', 'changes': {'fish.i686': {'new': '2.7.1-1.1', 'old': ''}}, '__id__': 'fish'}}, 'retcode': 2, 'success': True, 'fun': 'state.apply'}
... but on the master, I get a Schr枚dinger's cat response that indicates both failure and success:
ID: fish
Function: pkg.installed
Result: False
Comment: The following packages failed to install/update: fish=2.7.1-1.1
Started: 04:34:38.486410
Duration: 6723.025 ms
Changes:
----------
fish.i686:
----------
new:
2.7.1-1.1
old:
```
adamehirsch
on 2 Jan 2018
Same issue as @adamehirsch above ...
CentOS Linux release 7.4.1708 (Core)
salt-master-2017.7.1-1.el7.noarch
salt-minion-2017.7.1-1.el7.noarch
The sls
install-elasticsearch:
pkg.installed:
- name: elasticsearch
- version: 6.2.1
install-kibana:
pkg.installed:
- name: kibana
- version: 6.2.1
install-logstash:
pkg.installed:
- name: logstash
- version: 6.2.1
Output when above salt state is run from master on a minion without any of the above packages installed:
ID: install-elasticsearch
Function: pkg.installed
Name: elasticsearch
Result: False
Comment: The following packages failed to install/update: elasticsearch=6.2.1
Started: 10:56:31.405100
Duration: 3819.178 ms
Changes:
----------
elasticsearch:
----------
new:
6.2.1-1
old:
----------
ID: install-kibana
Function: pkg.installed
Name: kibana
Result: False
Comment: The following packages failed to install/update: kibana=6.2.1
Started: 10:56:35.269305
Duration: 10698.329 ms
Changes:
----------
kibana:
----------
new:
6.2.1-1
old:
----------
ID: install-logstash
Function: pkg.installed
Name: logstash
Result: False
Comment: The following packages failed to install/update: logstash=6.2.1
Started: 10:56:46.001168
Duration: 11291.323 ms
Changes:
----------
logstash:
----------
new:
1:6.2.1-1
old:
Error logs from /var/log/salt/minion on minion:
2018-02-13 10:56:35,175 [salt.state ][ERROR ][29970] Made the following changes:
'elasticsearch' changed from 'absent' to '6.2.1-1'
2018-02-13 10:56:45,923 [salt.state ][ERROR ][29970] Made the following changes:
'kibana' changed from 'absent' to '6.2.1-1'
2018-02-13 10:56:57,248 [salt.state ][ERROR ][29970] Made the following changes:
'logstash' changed from 'absent' to '1:6.2.1-1'
And on minion these packages are now installed:
# rpm -qa | grep -E 'elas|logstash|kib'
kibana-6.2.1-1.x86_64
elasticsearch-6.2.1-1.noarch
logstash-6.2.1-1.noarch
theunsa
on 13 Feb 2018
@theunsa , I'm experiencing the same issue on the 2017.2 branch. One workaround that did the trick for me was to do e.g.
firefox:
module.run:
- name: pkg.install
- m_name: firefox
- version: latest
instead of
firefox:
pkg.installed:
- version: latest
In my case, I found that running pkg.installed against a given package without pinning it to a specific repo seemed to eliminate the error; I believe (though this was a little while ago now) that the issue for me came out because the package had dependencies that couldn't be fulfilled from the pinned repo.
adamehirsch
on 13 Feb 2018
Thanks @BenjaminSchiborr ... clever workaround!
theunsa
on 19 Feb 2018
Also seeing this in 2017.7.4, on Windows.
dhs-rec
on 23 Mar 2018
@jbkc85 's solution worked in my case. Installing "vim" with Salt 2017.7.7 was succeeding on the minion (CentOS 7.5 VM) although it was reported as failing on the master. If I instead used the package name "vim-enhanced", which is the name the package manager prefers, then it all works.
romanows
on 17 Sep 2018
I see the same issue with the latest develop branch on openSUSE Leap 15.0 system.
matwey
on 23 Sep 2018
had the same issue, put a workaround in place by making the package name and version an exact match to the changes output.
In my case, changes output was:
'docker-ce': {'new': '18.03.1.ce-1.el7.centos', 'old': ''},
I updated the state to:
install_docker:
pkg.installed:
- name: docker-ce
- version: 18.03.1.ce-1.el7.centos
gnalsa
on 14 Oct 2018
Suggest it comes down to you asked for version 1.1 and got 1.1.1 which is not the same. In newer version of salt you can use >= not sure if that will solve 1.1 not equal to 1:1.1.
damon-atkins
on 14 Oct 2018
(edited, this will not be fixed, known issue, fixes have negative impact on pkg.installed state)
https://github.com/saltstack/salt/issues/41819
Here is a Quote
"we did at one time have a mechanism to check for what packages provide a given package, if the package name specified was not itself available, using a yum/dnf plugin. The problem was that it was painfully slow, adding in some cases 10 seconds or more to a single pkg.installed state."
Here is my original comment
I am running into the same issues with packages such as vim on Centos/RHEL.
The actual package name vs the ability of yum to search for packages that provide this feature. Do you recognize this as a problem or are we going to have to figure out the exact package names and then keep separate salt states for Centos vs Ubuntu because centos installs vim-enhanced vs vim?
This is from the YUM man page
_If the name doesn鈥檛 match a package, then package "provides" are searched (e.g. "_sqlite-cache.so()(64bit)") as are filelists (Eg. "/usr/bin/yum")._
run command 'yum provides vim'
I get
2:vim-enhanced-7.4.160-4.el7.x86_64 : A version of the VIM editor which includes recent enhancements
Repo : base
Matched from:
Provides : vim = 7.4.160-4.el7
2:vim-enhanced-7.4.160-4.el7.x86_64 : A version of the VIM editor which includes recent enhancements
Repo : @base
Matched from:
Provides : vim = 7.4.160-4.el7
So, if salt did this query, they would know to watch for vim-enhanced
repoquery --provides vim-enhanced
config(vim-enhanced) = 2:7.4.629-5.el6_8.1
vim = 7.4.629-5.el6_8.1
vim-enhanced = 2:7.4.629-5.el6_8.1
vim-enhanced(x86-64) = 2:7.4.629-5.el6_8.1
I think this is the root of this problem
geeslb
on 18 Oct 2018
Any news on this???????????
I have face with the same issue on salt 2017.7.5
hartemiev-vs
on 19 Oct 2018
This is not a bug, this is expected behavior. Salt does not support using aliased package names, for the reasons described in this comment.
You will need to use the actual package name. For CentOS, that is vim-enhanced.
@adamehirsch The reason you are seeing that is because the package is a 32-bit package on a 64-bit OS, and Salt adds .arch (e.g. .i686) to the package name so that there are no collisions with potential 64-bit versions of the same package. This is what allows one to have the 64 and 32-bit versions of the same package installed, provided they do not conflict with one another. You would need to use fish.i686 in your example.
terminalmage
on 6 Nov 2018
Related issues
qiushics
路
3Comments
commutecat
路
3Comments
udf2457
路
3Comments
nixjdm
路
3Comments
twangboy
路
3Comments
Most helpful comment
This is not a bug, this is expected behavior. Salt does not support using aliased package names, for the reasons described in this comment.
You will need to use the actual package name. For CentOS, that is
vim-enhanced.@adamehirsch The reason you are seeing that is because the package is a 32-bit package on a 64-bit OS, and Salt adds
.arch(e.g..i686) to the package name so that there are no collisions with potential 64-bit versions of the same package. This is what allows one to have the 64 and 32-bit versions of the same package installed, provided they do not conflict with one another. You would need to usefish.i686in your example.