Bug 448697 - Yum update fails kickstarting RHEL 5.x from Satellite 5.1
Yum update fails kickstarting RHEL 5.x from Satellite 5.1
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Provisioning (Show other bugs)
510
All Linux
medium Severity high
: ---
: ---
Assigned To: Devan Goodwin
Preethi Thomas
:
Depends On:
Blocks: 457075 465512 468994
  Show dependency treegraph
 
Reported: 2008-05-28 05:56 EDT by Rafael Godínez Pérez
Modified: 2010-10-22 21:29 EDT (History)
8 users (show)

See Also:
Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-09-10 15:22:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
ks-post.log showing unsatisfied dependencies for yum in ks (6.56 KB, text/plain)
2008-05-28 05:56 EDT, Rafael Godínez Pérez
no flags Details

  None (edit)
Description Rafael Godínez Pérez 2008-05-28 05:56:19 EDT
Description of problem:

Failure of upgrading yum before register with satellite and install new
additional software specified in activation key.
After reboot of provisioned client, is not possible to install software using yum.

Version-Release number of selected component (if applicable):

RHN Satellite 5.1.0
RHEL 5.x
yum 3.2.8-9
yum 3.0.1-5
python-iniparse

How reproducible:

Always.


Steps to Reproduce:
1. Create a kickstart for RHEL 5.1. You may include some additional software
(i.e. osad) in activation key.
2. Provision a new machine using this kickstart
3. After provision, try to install software using yum. If you selected something
(i.e. osad) to be installed in activation key, it won't be there.
4. check ks-post.log, yum didn't upgrade.
  
Actual results:

Yum still in kickstart tree version.
Selected additional software not installed.
Error messages in ks-post.log .

Expected results:

Yum upgraded to recent version (3.2.8-9)
Selected additional software available.


Additional info:
this works well in Satellite 5.0, but not in 5.1.
Problem is in the way yum is updated before register in Satellite: it does not
look into yum dependencies before selecting which packages should be downloaded
with wget and installed with rpm -Uvh to have yum, pirut, rhnlib, etc. up to
date before register in satellite.
Dependencies are somehow hardwired, but they have changed between yum-3.0.1-5
and yum-3.2.8-9. The latter needs python-iniparse, which is not in the kickstart
tree, neither is selected to download and install altogether with yum, pirut,
etc. Also newer version (>= 1.1.0) of metadata-parser is needed.
Comment 1 Rafael Godínez Pérez 2008-05-28 05:56:19 EDT
Created attachment 306912 [details]
ks-post.log showing unsatisfied dependencies for yum in ks
Comment 2 Neal Pitts 2008-07-23 11:56:17 EDT
My client is also seeing this issue on Satellite 5.0.1 and 5.0.2.  It was first
noticed when building RHEL5 servers.
Comment 4 Clifford Perry 2008-09-09 11:14:48 EDT
Adding to Sep Customer backlog tracking bug.
Comment 5 Devan Goodwin 2008-10-22 12:26:16 EDT
The issue with osad not getting installed appears to be fixed in Satellite 5.2. 

Tested a kickstart profile for both RHEL 5 and RHEL 5u2, each associated with the same activation key that indicated to install osad. In both cases osad was installed after the kickstart.

Interesting to note that with the RHEL 5.2 kickstart, no dependency errors were present in ks-post.log. (osad was still installed)

RHEL 5.0 kickstart, the dependency error *was* in ks-post.log:

error: Failed dependencies:

        python-iniparse is needed by yum-3.2.8-9.el5_2.1.noarch

        yum-metadata-parser >= 1.1.0 is needed by yum-3.2.8-9.el5_2.1.noarch

        yum = 3.0.1-5.el5 is needed by (installed) yum-updatesd-3.0.1-5.el5.noarch


And yet osad was installed, so this does not seem to have been the reason why osad wasn't getting installed.

IIRC we fixed issues with this not long ago, but it looks like it should have been in 5.1: https://bugzilla.redhat.com/show_bug.cgi?id=434943 

In any case this ticket seems to be more so related to the yum upgrade failing, looking into this now.
Comment 6 Devan Goodwin 2008-10-22 15:13:54 EDT
This is a complicated problem that's only getting worse. The freshen list is there as a rather unpleasant workaround for a situation where we might ship a really busted application in RHEL 5.0 (for example) that prevents proper upgrades or other RHN behavior, so after we kickstart RHEL 5.0 we then try to go install the latest versions of several packages from the latest RHEL, in this case 5.2. This is done with wget and rpm, trying to bypass yum completely which appears to have been involved in whatever nasty scenario cause this.

Already we're seeing new dependencies creeping up and that problem will only get worse and worse as RHEL progresses.

For instance the list just went from:

{"yum",  "pirut", "yum-rhn-plugin"};

to:

{"yum",  "pirut", "yum-rhn-plugin", "python-iniparse", "yum-metadata-parser", "yum-updatesd", "rhn-setup",
 "rhn-check", "rhn-client-tools", "rhnsd", "gamin-python"};


In addition, python-iniparse is a completely new package that isn't installed by default in RHEL 5.0, so the rpm -Fvh (freshen) won't pick it up if it isn't installed. 

We could change this to a -Uvh but this will start installing packages that may not previously have been installed. (pirut for instance!)

In short, this attempt at replicating the behavior of yum from a shell script at the end of a kickstart is bound to fail eventually and is really not something we should be doing. It sounds like this has the unfortunate implication that a RHEL 5 kickstart would have some serious problems post kickstart, possibly not being able to upgrade, or perhaps communicate with Satellite at all.

There are many many ways this could break, for instance if the user added any obscure package to their kickstart profile, but this package then depended on one of our refresh packages, the upgrade will fail.

Discussions underway for what to do.
Comment 7 Devan Goodwin 2008-10-23 11:02:18 EDT
I have tested removing the RHEL 5 package freshen list entirely and doing a RHEL 5.0 and 5.1 kickstart to see if (a) the system can still communicate with satellite and (b) the system can still yum upgrade.

RHEL 5.0:

- rhn_check functions fine.
- Scheduled a package refresh, picked up fine.
- yum upgrade found a dependency error with xen-libs (ks was for a Xen host) but removing xen allowed the upgrade to proceed fine. This isn't something addressed by the wget hack in any case.
- yum upgrade then proceeds fine, system now up to date.

RHEL 5.1:
- rhn_check works ok.
- yum upgrade works ok.

It looks as if yum-rhn-plugin was the original problem causing package. I think the root ticket is: https://bugzilla.redhat.com/show_bug.cgi?id=378911 (see comment #72 in particular) Essentially if there is some underlying problem talking to the satellite (SSL errors, missing packages, etc) the correct exception is getting masked by one that doesn't identify the problem. (python variable reference exception)

If this is correct and we are upgrading yum-rhn-plugin to properly report errors, then I would argue we can go ahead with removing this manual attempted upgrade functionality. If a user ends up in a situation where they cannot upgrade due to some improper configuration elsewhere (and are not seeing correct error messages), we should rely on the errata infrastructure in place as described in ticket 378911. 

Normal operation seems to be ok, thus I think it best we remove this code.

Thoughts?
Comment 11 Devan Goodwin 2008-10-29 08:09:18 EDT
Fix applied in spacewalk git repo: 77a369d3709360f27c0c1213c36f1ca9699ad2cc

This will appear in Satellite 5.3.
Comment 15 Devan Goodwin 2009-06-04 09:58:42 EDT
Looks like jsherrill re-added this code in March in commit f5376cb9 for CentOS kickstarts.

Justin could you review the above discussion on why this code was bad and/or unmaintainable and let us know your preference for best course of action.

IMO we probably need to revert f5376cb9 and instead implement some kind of scheduled package install to get the client packages installed for CentOS.
Comment 16 Justin Sherrill 2009-06-04 10:48:12 EDT
heh,  sorry about that devan.  Didn't realize I had re-added anything that you removed.   

So I'm not opposed to reverting f5376cb9, but we still need a way to get client packages installed on the machines before registration.  You can't schedule a package install, because the system hasn't registered yet!  (Cent doesn't ship with any of our registration utilities).  

We probably could simply add a "CentOs" distro type that the user could select and only generate those lines in the Kickstart if the distro is of that type.
Comment 17 Devan Goodwin 2009-06-04 11:46:47 EDT
Lets revert for now and take another stab at getting the client packages installed on Cent OS in a future release of Spacewalk. That is indeed a tricky chicken and egg problem to solve, a check for CentOS or Fedora might do it but we're running the risks of dependency problems as per the above, particularly if you consider what this list of packages might turn into for different versions of Fedora.
Comment 18 Devan Goodwin 2009-06-04 12:05:53 EDT
Reverted in spacewalk.git: 06b89603b02bc4f2ce0b28f484eb02835dd84c43
reverted in satellite.git: 7558a5f
Comment 20 Preethi Thomas 2009-08-04 09:54:53 EDT
Release Pending
Satellite: test1182.test.redhat.com
client: fjs-0-13 kickstarted to rhel5u1 yum update works fine after ks.
Comment 21 Brandon Perkins 2009-09-10 15:22:39 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-1434.html

Note You need to log in before you can comment on or make changes to this bug.