Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] On Archlinux state pkg.installed invokes with -S -y -u causing Salt to fully upgrade a system to install one package introducing quirks in the live system. #65200

Open
3 of 9 tasks
ipaqmaster opened this issue Sep 15, 2023 · 1 comment
Assignees
Labels
arch-linux affects this operating system Bug broken, incorrect, or confusing behavior

Comments

@ipaqmaster
Copy link
Contributor

Description

As per title a simple pkg.installed state call causes salt to do a full pacman -S -y -u which upgrades all packages on a system when that isn't remotely what were requested.

If a kernel upgrade occurs as a result of the above, and the past few years it often does - a live system becomes half broken as it's unable to load any new kernel modules until either:

  1. The kernel is downgraded back to what it was prior restoring the correct kernel version's modules directory
  2. The old kernel package is manually extracted into the filesystem to restore the live system's modules directory temporarily.
  3. The machine is restarted into the new kernel.

This doesn't sound like a huge deal at first but the lack of a /lib/modules/a.b.c-arch1-1 kernel module directory for the currently running kernel breaks many things on the live system where previously-unloaded modules must be probed such as mounting new filesystems, tweaking firewall rules and many more driver situations become inattainable until one of the above steps are taken.

This can be avoided with - refresh: False to all relevant salt pkg.installed states or with a jinja grains.filter_by block to catch a "default": True, "Arch": False filter block against the os grain - though both these workarounds are extremely inconvenient and untidy looking for 329+ pkg.installed matches across our salt states - and would not automatically cover new pkg.installed instances without some kind of messy jinja macro - the kind of thing anybody would accidentally forget to use.

(The pkg.install module does not experience this issue :salt host pkg.install somePkg only invoking -S as expected.)

Setup

Saltmaster and minion both on Archlinux - packaged install. Though issue lies in state behaviour not setup.

Please be as specific as possible and give set-up details.

  • on-prem machine
  • VM (Virtualbox, KVM, etc. please specify)
  • KVM salt-master, physical minion in this case.
  • VM running on a cloud service, please be explicit and add details
  • container (Kubernetes, Docker, containerd, etc. please specify)
  • or a combination, please be explicit
  • jails if it is FreeBSD
  • classic packaging
  • onedir packaging
  • used bootstrap to install

Steps to Reproduce the behavior

This should trigger the behaviour:

pkgtest.sls

pacman_pkg.installed_test:
  pkg.installed:
    - name: somePkg

salt archHost state.sls pkgtest
cat /var/log/pacman.log # To see the usage of pacman -S -y -u by this state.

Expected behavior

The salt state to do a pacman -S --noprogressbar --noconfrim --needed somePkg alike the behaviour seen in module pkg.install somePkg which does so without -y (Sync) or -u (Upgrade)

Screenshots
If applicable, add screenshots to help explain your problem.

NA but have /var/log/pacman.log output for each call:

  • salt state pkg.installed with missing package to resolve:

    • [DateHere] [PACMAN] Running '/usr/bin/pacman -S -y -u --noprogressbar --noconfirm --needed somePkg'
  • salt above state file with pkg.installed but with Refresh: False in the state:

    • [DateHere] [PACMAN] Running '/usr/bin/pacman -S --noprogressbar --noconfirm --needed somePkg'
    • (I feel this would be a good default pkg.installed state behaviour for rolling distributions. If the state fails due to an out of sync local package database only then trying -Sy or just erroring and perhaps asking the user to consider adding Refresh:True themselves. If not making 'Refresh' a salt-minion configurable default setting.)
  • Running module pkg.intsall somePkg

    • [DateHere] [PACMAN] Running '/usr/bin/pacman -S --noprogressbar --noconfirm --needed somePkg'

Versions Report

salt --versions-report (Provided by running salt --versions-report. Please also mention any differences in master/minion versions.)
Salt Version:
          Salt: 3006.1

Python Version:
        Python: 3.11.5 (main, Aug 28 2023, 20:02:58) [GCC 13.2.1 20230801]

Dependency Versions:
          cffi: 1.15.1
      cherrypy: Not Installed
      dateutil: 2.8.2
     docker-py: Not Installed
         gitdb: Not Installed
     gitpython: Not Installed
        Jinja2: 3.1.2
       libgit2: Not Installed
  looseversion: 1.2.0
      M2Crypto: 0.38.0
          Mako: 1.2.4
       msgpack: 1.0.5
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     packaging: 23.1
     pycparser: 2.21
      pycrypto: Not Installed
  pycryptodome: 3.12.0
        pygit2: Not Installed
  python-gnupg: Not Installed
        PyYAML: 6.0.1
         PyZMQ: 25.1.1
        relenv: Not Installed
         smmap: Not Installed
       timelib: Not Installed
       Tornado: 4.5.3
           ZMQ: 4.3.4

System Versions:
          dist: arch rolling n/a
        locale: utf-8
       machine: x86_64
       release: 6.4.12-arch1-1
        system: Linux
       version: Arch Linux rolling n/a

Additional context
Add any other context about the problem here.

@ipaqmaster ipaqmaster added Bug broken, incorrect, or confusing behavior needs-triage labels Sep 15, 2023
@OrangeDog OrangeDog added the arch-linux affects this operating system label Sep 15, 2023
@teclab-ifcfraiburgo
Copy link

Expected behavior

The salt state to do a pacman -S --noprogressbar --noconfrim --needed somePkg alike the behaviour seen in module pkg.install somePkg which does so without -y (Sync) or -u (Upgrade)

+1
This would be a far better default behavior.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arch-linux affects this operating system Bug broken, incorrect, or confusing behavior
Projects
None yet
Development

No branches or pull requests

5 participants