[Spacewalk-list] Duplicate packages in selection and spacewalk

[Kalchik, Jeffery]

Good morning.

The hash clash isn’t unknown, I have it albeit under different channels.

Given your situation, as a fall back, you could run spacewalk-channel during a chrooted post install script, to add your SaltStack channel and install packages there.  Not optimal, but a possibility.  I do this for things that I really can’t determine until run time, like installing the HP Proliant Support Pack.

Jeff Kalchik
Systems Engineering
Land O’Lakes

From: spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces at redhat.com] On Behalf Of Andreas Dijkman
Sent: Wednesday, May 18, 2016 10:23 AM
To: spacewalk-list <spacewalk-list at redhat.com>
Subject: [Spacewalk-list] Duplicate packages in selection and spacewalk

Hi,

We have a SW2.4-installation, successfully setup with PXE-boot, kickstart, the works.

I recently started using SaltStack as configuration management, so I’ve added the SaltStack-repository to my SpaceWalk-system (https://repo.saltstack.com/yum/rhel6/). Everything works fine until I try to kickstart a system using PXE or ISO. Somehow the SpaceWalk-system is confused about duplicate packages that are the same in versions but not in hash. In my case it first breaks on the package pciutils. I think Spacewalk decides to serve the wrong package during installation so anaconda is complaining it can’t find the correct package. SaltStack isn’t playing nice because in their repo they are supplying the same packages as used in CentOS. But the packages from Oracle Linux and CentOS are different from each other.

After I removed the SaltStack-channels and packages from SpaceWalk, the Kickstart worked fine again…

Is there a way to prioritise packages during kickstart with spacewalk or give a spacewalk-channel priority above other channels? I really want to keep the SaltStack-channel in our SpaceWalk-server, but if it breaks updates, I have to figure something else out.

Kind regards,

Andreas Dijkman
This message may contain confidential material from Land O'Lakes, Inc. (or its subsidiary) for the sole use of the intended recipient(s) and may not be reviewed, disclosed, copied, distributed or used by anyone other than the intended recipient(s). If you are not the intended recipient, please contact the sender by reply email and delete all copies of this message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20160519/e71cb481/attachment.htm>