Bug 502958
Summary: | sat 5.3.0 installation on rhel4- s390x fails with EOFError | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Satellite 5 | Reporter: | Sayli Karmarkar <skarmark> | ||||||||
Component: | Installer | Assignee: | Devan Goodwin <dgoodwin> | ||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Sayli Karmarkar <skarmark> | ||||||||
Severity: | medium | Docs Contact: | |||||||||
Priority: | low | ||||||||||
Version: | 530 | CC: | cperry, gkhachik, mzazrivec, tlestach | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | All | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | sat530 | Doc Type: | Bug Fix | ||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2009-09-10 20:37:27 UTC | Type: | --- | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Bug Depends On: | |||||||||||
Bug Blocks: | 456985, 468153 | ||||||||||
Attachments: |
|
Description
Sayli Karmarkar
2009-05-27 22:35:47 UTC
Created attachment 345687 [details]
rhn-installation.log
Same EOFError is seen even after I manually install all required packages and then run ./install.pl --answer-file=/root/answers.txt I'm pretty sure this problem is caused by the fact that you are using a RHEL-4 system from RHTS with installed yum. Satellite installer will never work correctly on RHEL-4 with yum, as this is not a standard setup (RHEL-4 normally does not contain yum; it comes with up2date). install.pl here detects yum and assumes it is on a RHEL-5 system, where yum behaves differently (much more recent version). For RHEL-4 systems reserved from RHTS you need to rpm -e yum first. This bug as written isn't a bug. However, I would like to morph this bug into a new bug saying that we need a secondary check against redhat-release. There is nothing wrong with installing yum on RHEL-4... although it does go against the stated installation guide. I would still like to see a secondary check added. Milan, Isn't yum coming into picture only when there are packages needed to be installed? Correct me if I am wrong. If already all packages needed are installed manually, why should we see error mentioned in comment# 2? ~SayliK (In reply to comment #3) > I'm pretty sure this problem is caused by the fact that you are using > a RHEL-4 system from RHTS with installed yum. Satellite installer will > never work correctly on RHEL-4 with yum, as this is not a standard > setup (RHEL-4 normally does not contain yum; it comes with up2date). > install.pl here detects yum and assumes it is on a RHEL-5 system, where > yum behaves differently (much more recent version). > > For RHEL-4 systems reserved from RHTS you need to rpm -e yum first. Sayli, was this an automated installation? If so, is yum being installed on the RHEL 4 RHTS systems a recent change? And more importantly is the script being used to automate the install prepared to offer input for the yum prompt? (it looks to me like the script is not designed to answer the question when yum asks if it should proceed with the install) Note that yum is used to install the packages from the ISO, though I don't remember getting prompted y/n during a normal RHEL 5 install. Investigating changing the logic to also check for redhat-release, and if on RHEL 4 just use up2date even if yum is present. Actually when yum is called it offers the -y option, which should suppress the prompt. Sayli is there any chance you could post the version of yum installed on these RHEL 4 machines? I think that's probably why we're getting the prompt. (no -y option) Ok logic has changed to check for yum as it did before, but if: rpm -q --qf='%{VERSION}' redhat-release Starts with a 4, we ignore yum and stick to up2date just the same. spacewalk.git: 0530358fae431007a25697ec6210478033414502 satellite.git: 449a348a7b1fc42055d894ff1fa1fe2f74408b56 Here is what I am seeing: [root@z204 satiso]# ./install.pl --answer-file=/root/answers.txt * Starting the Red Hat Network Satellite installer. * Loading answer file: /root/answers.txt. * Performing pre-install checks. * Pre-install checks complete. Beginning installation. * RHN Registration. ** Registration: System is already registered with RHN. Not re-registering. Warning: Found yum on RHEL 4, using up2date instead. * Installing required packages. The following packages from Red Hat Enterprise Linux that are not part of the @base group have to be installed on this system for the installer and the Satellite to operate correctly: ... ... perl-IO-String perl-Parse-Yapp perl-Time-HiRes tftp-server xorg-x11-deprecated-libs ** Checking if up2date is available ... We can try to install the needed packages now, by running up2date -i. Do you want to run this command now [y/N]? y ** Running rpm --import /usr/share/rhn/RPM-GPG-KEY Installing packages. The log can be found in /var/log/rhn/rhn-installation.log You can tail -f in another terminal to see the progress. Running up2date --arch=s390x --arch=noarch -i PyXML alsa-lib apr apr-util compat-db distcache gd gd-devel gd-progs httpd httpd-suexec libaio mkisofs mod_python mod_ssl newt-perl perl-Archive-Tar perl-Compress-Zlib perl-DateManip perl-Digest-HMAC perl-Digest-SHA1 perl-IO-String perl-Parse-Yapp perl-Time-HiRes tftp-server xorg-x11-deprecated-libs * Applying updates. * Installing RHN packages. Could not install RHN packages. Most likely your system is not configured with the @Base package group. See the RHN Satellite Server Installation Guide for more information about Software Requirements. Exit value: 251. Please examine /var/log/rhn/rhn-installation.log for more information. /var/log/rhn/rhn-installation.log is attached. yum and up2date versions installed are: [root@z204 satiso]# cat /etc/redhat-release Red Hat Enterprise Linux AS release 4 (Nahant Update 7) [root@z204 satiso]# rpm -q up2date up2date-4.7.1-17.el4 [root@z204 satiso]# rpm -q yum yum-2.2.2-1.rhts.EL4 So, Brandon and Devan, what do we expect to happen? As far as I understand 2 outcomes seem to be valid: 1. install should proceed without error, just running up2date instead of yum to install packages. 2. error asking user to un-install yum or warning saying it is not a standard setup. Created attachment 347496 [details]
new rhn-installation.log
It seems like some files are conflicting with files from yum package.
Based on the above it looks like the new code properly decided to use up2date. You're correct about yum conflicting with python-urlgrabber, which I believe is a new dependency for us, thus why we're just seeing this now. I think at one time urlgrabber was part of yum in RHEL 5 but was split out into it's own package. At this point IMO there's not much we can do, yum on RHEL 4 is obviously not standard or supported and with this ticket we made some changes to attempt to accommodate it, but the package used in RHTS is already causing problems. Perhaps we could get a newer version of yum deployed automatically in RHTS but there's probably a reason they're using an older one. Otherwise I think we just have to rpm -e yum when testing Satellite installs on RHEL 4 RHTS systems. Anyone know who to talk to in RHTS who might know more about why/how they use yum in the infrastructure on RHEL 4, and if they have any suggestions for this problem? Yup. Removing yum helps and installation is completed without EOF error mentioned in the bug description. Moving to verified. ~SayliK Created attachment 347954 [details]
log with error using yum
Installation of Satellite-5.3.0-RHEL4-re20090819.0 on s390x with yum: 1.) installed # rpm -q yum yum-2.2.2-1.rhts.EL4 sat installation fails because of package conflict python-urlgrabber-2.9.8-0.3.el4 and yum-2.2.2-1.rhts.EL4 2.) uninstalled # rpm -q yum package yum is not installed sat installation successful Confirming that rhts yum disallows the sat installation on s390x/RHEL4. 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 |