Closed ggiesen closed 1 year ago
This issue actually looks like it may be due to the fact that there's what appears to be a classic version of Salt 3005.1 in EPEL:
[vagrant@rocky9 ~]$ dnf info salt-minion
Extra Packages for Enterprise Linux 9 - x86_64 44 kB/s | 15 kB 00:00
Extra Packages for Enterprise Linux 9 - Next - x86_64 70 kB/s | 23 kB 00:00
Extra Packages for Enterprise Linux 9 - Next - x86_64 2.5 MB/s | 1.4 MB 00:00
SaltStack latest Release Channel for RHEL/CentOS 9 20 kB/s | 2.9 kB 00:00
Available Packages
Name : salt-minion
Version : 3005.1
Release : 2.el9
Architecture : noarch
Size : 32 k
Source : salt-3005.1-2.el9.src.rpm
Repository : epel
Summary : Client component for Salt, a parallel remote execution system
URL : https://saltproject.io/
License : ASL 2.0
Description : The Salt minion is the agent component of Salt. It listens for instructions
: from the master, runs jobs, and returns results back to the master.
: Supports Python 3.
Name : salt-minion
Version : 3005.1
Release : 2.el9
Architecture : x86_64
Size : 30 k
Source : salt-3005.1-2.el9.src.rpm
Repository : saltstack
Summary : Client component for Salt, a parallel remote execution system
URL : http://saltstack.org/
License : ASL 2.0
Description : The Salt minion is the agent component of Salt. It listens for instructions
: from the master, runs jobs, and returns results back to the master.
The same will apply to any system that already ships Salt by default at the same version you're trying to install, such as Debian and its downstreams.
Comment from @dmurphy18 on a related issue:
I don't believe this is a Salt problem, if the user installs a forked built version of Salt from a different repository, then that is up to them. For example: Debian and Ubuntu have long forked the Salt project and built their own packages. It is up to the user to know what they are doing, and to decide which packages to install and from where.
There is no warning about whose repository to install packages from for Debian / Ubuntu for years and I don't see why we should start doing it for RHEL 9 EPEL now.
This is for Classic or Tiamat based packages
In light of that comment, I'm closing this issue.
I haven't confirmed it yet, but I think either the bootstrap script or the Salt packages themselves are actually requiring EPEL, in which case it's very much a Salt problem.
Confirmed:
The bootstrap script is actually installing EPEL. So either the bootstrap script needs to be adjusted to not add EPEL, or some other method needs to be used to prioritize the Salt repo or deprioritize the EPEL repo.
@barbaricyawps Can you reopen this as it's definitely a Salt (salt-bootstrap) issue.
@garethgreenaway and @whytewolf , can you weigh in?
about the only thing i can say is that we shouldn't be installing EPEL anymore we haven't needed it since 2016.x at least. so removal of epel from the bootstrap should be something.
Description of Issue/Question
salt-bootstrap fails to start services after installation when using OneDir on Rocky Linux 9:
Looks to be a similar issue to #1876 but for EL9 instead of EL8
Setup
Steps to Reproduce Issue
(Include debug logs if possible,
bootstrap-salt.sh -D
.)Versions and Systems
(
salt --versions-report
,bootstrap-salt.sh -v
, system type and version, cloud/VM provider as appropriate.)