Description of problem: When installing x86_64 satellite 5.2 in disconnected mode complains of @base packages missing. This is despite having them properly installed. The installer in disconnected mode will complain about a host of packages missing in the logs. See notes below for work around that worked for me. -- Version-Release number of selected component (if applicable): 5.2 64bit Satellitie How reproducible: 100% Steps to Reproduce: 1. Mount back loop satellite iso 2. start install.pl in disconnected mode 3. see complaints in error logs Actual results: Appears @base is missing. Expected results: Complete install. Additional info: This appears fixable when user creates there OWN repo file that points to Satellite and Oracle directory on mount back looped ISO. Once done, user needs to install package group Satellite and begin install. 95% completes with possible exception of 1 or 2 rpms that need to be installed from Oracle directory. Also..this DOES not appear to be the issue in non-disconnected mode.
Please provide the exact error complaints that you get in the logs. Please provide the output that the installer gives you on the terminal.
Error message received: 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: 21.
That's on the terminal. What's in the install log (exactly)?
So, is this bugzilla about missing packages or missing GPG key?
they're directly related, however, more than happy to raise a separate bug for the GPG issue if required?
In further testing, the issue deals NOT just with the GPG key. In terms of mount-back looping the iso and creating the repo files that point to Satellite directory AND Oracle directory is the way I was able to complete the install.
I would like to separate some behavioral anomolies I see as well: 1) perl-Error package gpg key issue. In my case manually installing the rpm in CONNECTED mode allows for rest of installation to complete. 2) In disconnected mode, even after installing the package, the installer still complains about the REST of the missing packages that are part of the Satellite directory on ISO. However a "work around" per se is to create a repo and point back to Satellite. -- this behavior in terms of the installer different than in connected mode.
(In reply to comment #12) > In further testing, the issue deals NOT just with the GPG key. In terms of > mount-back looping the iso and creating the repo files that point to Satellite > directory AND Oracle directory is the way I was able to complete the install. If you're doing it this way, you are making it complicated for yourself. There is no need to create the repository, as yum localinstall (which the Satellite installer uses) will handle the directories just fine.
Jan, > There is no need to create the repository, as yum localinstall (which the > Satellite installer uses) will handle the directories just fine. Running into this issue two times now on customer site, I would like to stress that the yum localinstall that you refer to does _not_ work for a disconnected satellite. If you expect it to work, then I inform you, it is *broken*.
(In reply to comment #13) > I would like to separate some behavioral anomolies I see as well: > > 1) perl-Error package gpg key issue. In my case manually installing the rpm in > CONNECTED mode allows for rest of installation to complete. There is nothing magical about connected mode. While connected (to hosted or to Satellite), the channel has gpg key specified, and I assume it will ask you whether you want to import it. If you create the RHEL repository properly (with gpg key specified), the Satellite installer will use the key (it is the same for RHEL packages and for Satellite packages) and there won't be any problem. As I've already said a couple of times -- if you install the packages using repository, defined gpg key for that repository. You can also rpm --import the key manually. Or you use kickstart which imports it for you, which incidently is what I see on my RHEL 5.2 -- the key is already imported. > 2) In disconnected mode, even after installing the package, the installer still > complains about the REST of the missing packages that are part of the Satellite > directory on ISO. However a "work around" per se is to create a repo and point > back to Satellite. -- this behavior in terms of the installer different than in > connected mode. The installer only complains if *you* *tell* *it* to install the packages for you, and you do not have the system registered to RHN hosted or some other source of packages (local repository). Just don't do that. If you tell the installer you do not want the dependencies installed for you, it will give you list of packages that are missing. You can then install them any way you like -- anaconda, rpm, anything. Yes, this behaviour and the fact that Satellite does not ship RHEL packages on its installation ISO is a feature.
(In reply to comment #15) > Jan, > > > There is no need to create the repository, as yum localinstall (which the > > Satellite installer uses) will handle the directories just fine. > > Running into this issue two times now on customer site, I would like to stress > that the yum localinstall that you refer to does _not_ work for a disconnected > satellite. > > If you expect it to work, then I inform you, it is *broken*. Please provide exact command, terminal output, and rhn-installation.log for case when you had machine which was not registered to RHN, it did not have repo created on Satellite ISO directories, and it had all necessary dependencies installed or repo with those dependencies available, and it failed.
Jan, > Please provide exact command, terminal output, and rhn-installation.log for > case when you had machine which was not registered to RHN, This is all detailed in IT #258208 > it did not have repo created on Satellite ISO directories, Initially it did not. > and it had all necessary dependencies installed server did not have the necessary dependencies installed; I was relying on the installer automatically installing them. However, as you say, packages that are required from rhel-5-server base channel will _not_ be imported because there is no RHN connection or rhel-5-server repo available. Hence, the install fails with the output contained in the log file attached to the IT. > or repo with those dependencies available, and it failed. We've covered this one off i believe; the problem lies with the repo not having the GPG key available. I think we're in agreement, but I very strongly feel that the issues highlighted need to be made much clearer in our Satellite documentation so customers' and consultants do not run into this 'issue'.
(In reply to comment #18) > > server did not have the necessary dependencies installed; I was relying on the > installer automatically installing them. However, as you say, packages that > are required from rhel-5-server base channel will _not_ be imported because > there is no RHN connection or rhel-5-server repo available. > > Hence, the install fails with the output contained in the log file attached to > the IT. Which is expected. Closing as NOTABUG.