salt: Failed to do pkg.refresh_db on Windows minion on 2015.8.1

@jfindlay @eliasp , I’ve got the same problem as @nimishp on #28162 on Windows XP 32 bit with saltstack 2015.8.1 on the master and the minion.

When running the update :

salt 'hostname' pkg.refresh_db

I’ve got :

hostname:

without any other output

Running :

sudo salt 'SR-SIC-GES1A' cmd.run 'C:\salt\salt-call -c C:\salt\conf -l debug pkg.refresh_db'

Outputs :

hostname:
    [DEBUG   ] Reading configuration from C:\salt\conf\minion
    [DEBUG   ] Configuration file path: C:\salt\conf\minion
    [WARNING ] Insecure logging configuration detected! Sensitive data may be logged.
    [DEBUG   ] Reading configuration from C:\salt\conf\minion
    [DEBUG   ] Initializing new SAuth for ('c:\\salt\\conf\\pki\\minion', 'SR-SIC-GES1A', 'tcp://10.133.32.206:4506')
    [DEBUG   ] Generated random reconnect delay between '1000ms' and '11000ms' (5884)
    [DEBUG   ] Setting zmq_reconnect_ivl to '5884ms'
    [DEBUG   ] Setting zmq_reconnect_ivl_max to '11000ms'
    [DEBUG   ] Initializing new AsyncZeroMQReqChannel for ('c:\\salt\\conf\\pki\\minion', 'SR-SIC-GES1A', 'tcp://10.133.32.206:4506', 'aes')
    [DEBUG   ] Initializing new SAuth for ('c:\\salt\\conf\\pki\\minion', 'SR-SIC-GES1A', 'tcp://10.133.32.206:4506')
    [DEBUG   ] Initializing new AsyncZeroMQReqChannel for ('c:\\salt\\conf\\pki\\minion', 'SR-SIC-GES1A', 'tcp://10.133.32.206:4506', 'clear')
    [DEBUG   ] Decrypting the current master AES key
    [DEBUG   ] Loaded minion key: c:\salt\conf\pki\minion\minion.pem
    [DEBUG   ] Loaded minion key: c:\salt\conf\pki\minion\minion.pem
    [DEBUG   ] LazyLoaded jinja.render
    [DEBUG   ] LazyLoaded yaml.render
    [DEBUG   ] LazyLoaded pkg.refresh_db
    [DEBUG   ] LazyLoaded cp.cache_dir
    [DEBUG   ] Initializing new AsyncZeroMQReqChannel for ('c:\\salt\\conf\\pki\\minion', 'SR-SIC-GES1A', 'tcp://10.133.32.206:4506', 'aes')
    [DEBUG   ] Initializing new SAuth for ('c:\\salt\\conf\\pki\\minion', 'SR-SIC-GES1A', 'tcp://10.133.32.206:4506')
    [INFO    ] Caching directory 'win/repo-ng/' for environment 'base'
    [DEBUG   ] LazyLoaded jinja.render
    [DEBUG   ] LazyLoaded yaml.render
    [DEBUG   ] Initializing new AsyncZeroMQReqChannel for ('c:\\salt\\conf\\pki\\minion', 'SR-SIC-GES1A', 'tcp://10.133.32.206:4506', 'aes')
    [DEBUG   ] Initializing new SAuth for ('c:\\salt\\conf\\pki\\minion', 'SR-SIC-GES1A', 'tcp://10.133.32.206:4506')
    [DEBUG   ] LazyLoaded nested.output
    local:

I’m unable to use the win repo since a switch to 2015.5 or 2015.8 I’ve try to remove completly the minion on the host and reinstall it without success.

Minion version :

    Salt Version:
               Salt: 2015.8.1

    Dependency Versions:
             Jinja2: 2.7.3
           M2Crypto: Not Installed
               Mako: Not Installed
             PyYAML: 3.11
              PyZMQ: 14.7.0
             Python: 2.7.10 (default, May 23 2015, 09:40:32) [MSC v.1500 32 bit (Intel)]
               RAET: Not Installed
            Tornado: 4.2.1
                ZMQ: 4.1.2
               cffi: Not Installed
           cherrypy: Not Installed
           dateutil: 2.4.2
              gitdb: Not Installed
          gitpython: Not Installed
              ioflo: Not Installed
            libnacl: Not Installed
       msgpack-pure: Not Installed
     msgpack-python: 0.4.6
       mysql-python: Not Installed
          pycparser: Not Installed
           pycrypto: 2.6.1
             pygit2: Not Installed
       python-gnupg: 0.3.7
              smmap: Not Installed
            timelib: Not Installed

    System Versions:
               dist:
            machine: x86
            release: 2003Server
             system: 2003Server 5.2.3790 SP2 Multiprocessor Free

Master version :

Salt Version:
           Salt: 2015.8.1

Dependency Versions:
         Jinja2: 2.6
       M2Crypto: 0.21.1
           Mako: Not Installed
         PyYAML: 3.10
          PyZMQ: 14.0.1
         Python: 2.7.3 (default, Aug  1 2012, 05:14:39)
           RAET: Not Installed
        Tornado: 4.2.1
            ZMQ: 4.0.4
           cffi: Not Installed
       cherrypy: Not Installed
       dateutil: 1.5
          gitdb: 0.5.4
      gitpython: 0.3.2 RC1
          ioflo: Not Installed
        libnacl: Not Installed
   msgpack-pure: Not Installed
 msgpack-python: 0.3.0
   mysql-python: 1.2.3
      pycparser: Not Installed
       pycrypto: 2.6.1
         pygit2: Not Installed
   python-gnupg: Not Installed
          smmap: 0.8.2
        timelib: Not Installed

System Versions:
           dist: Ubuntu 12.04 precise
        machine: x86_64
        release: 3.2.0-29-virtual
         system: Ubuntu 12.04 precise

After some reading, i’ve change parameters on the master for the winrepo. I’ve got exactly the same issue.

#####     Windows Software Repo settings #####
##############################################
# Location of the repo on the master:
win_repo_dir: '/srv/salt/win/repo'

#
# Location of the master's repo cache file:
winrepo_cachefile: '/srv/salt/win/repo/winrepo.p'

About this issue

  • Original URL
  • State: closed
  • Created 9 years ago
  • Comments: 25 (18 by maintainers)

Most upvoted comments

@droptables Also, I’m not sure how having multiple install_flags entries is handled by winrepo. I would guess that the last one wins. So, I would suggest something like this for install_flags:

install_flags: '/l*v C:\Install.log PIDKEY=KEY /quiet'

@droptables as a starter any version numbers NEED to be in single quotes, as per doc. (any that end in zero) are (almost?) guaranteed to fail it they aren’t in single quotes. you have no space between full_name: ^ packagename (but that might not matter for yaml or might just be a result of your obfuscation, just wanted to point it out - just in case)

and as @twangboy said names matter very much to winrepo, make absolutely sure that the windows uninstall registry entries name of the package matches your full_name 100% case and space and all, as per docs.

and I suspect when testing your uninstaller you might also run into surprises. I suggest and re-read the docs on uninstallers in the case of msiexec = true. you usually have either the msi itself listed in the uninstaller field (see 7zip as a example), or alternatively the GUID of the installed pkg in the uninstaller filed (again see te 7zip sample in the docs showing both scenarios)

Using msiexec; true and the using msiexec.exe in the uninstaller is not an intended combination. although I suspect you might get away with it, if you then also added the /x {GUID} to the uninstall_flags: field.