Bug 485681 - installation on RHEL-4 ends with 'Could not run gpg.' but exit code 0
installation on RHEL-4 ends with 'Could not run gpg.' but exit code 0
Status: CLOSED NOTABUG
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Installer (Show other bugs)
530
All Linux
high Severity high
: ---
: ---
Assigned To: Devan Goodwin
Jan Hutař
:
Depends On:
Blocks: 456985 486216
  Show dependency treegraph
 
Reported: 2009-02-16 03:53 EST by Jan Hutař
Modified: 2009-04-06 08:30 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-06 08:30:04 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)
logs from the x86_64 system (85 bytes, text/plain)
2009-02-16 03:53 EST, Jan Hutař
no flags Details

  None (edit)
Description Jan Hutař 2009-02-16 03:53:00 EST
Created attachment 332011 [details]
logs from the x86_64 system

Description of problem:
When I run current nightly installation on RHEL-4, installation ends with 'Could not run gpg.' but exit code is 0.


Version-Release number of selected component (if applicable):
Satellite-5.3.0-RHEL4-re20090213.1


How reproducible:
2 of 3 attempts (on i386 and x86_64 arch, s390x failed on something else)


Steps to Reproduce:
1. # /mnt/redhat/devel/candidate-trees/Satellite-5.3.0-RH
EL4-re20090213.1/s390x/s390x//install.pl --answer-file=/mnt/tests/CoreOS/RHN-Sat
ellite/Inter-Satellite-Sync/Sanity/general/answers.txt --non-interactive --disco
nnected --run-updater


Actual results:
* Setting up users and groups.
** GPG: Initializing GPG and importing key.
** GPG: Creating /root/.gnupg directory
Could not run gpg.  Exit value: 2.
Please examine /var/log/rhn/rhn-installation.log for more information.


Expected results:
should work


Additional info:
# tail /var/log/rhn/rhn-installation.log
[...]
5/5 Installing ../EmbeddedDB/oracle-server-admin-0.1-11.el4.noarch.rpm
All required packages have been installed
gpg: failed to create temporary file `//.gnupg/.#lk0x8545868.dell-pe1850-02.rhts
.bos.redhat.com.13697': No such file or directory
gpg: //.gnupg: directory created
gpg: new configuration file `//.gnupg/gpg.conf' created
gpg: WARNING: options in `//.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `//.gnupg/pubring.gpg' created
# ls /.gnupg
gpg.conf  pubring.gpg
Comment 1 Jan Hutař 2009-02-16 03:55:59 EST
Err, one more thing:

# rpm -q gnupg
gnupg-1.2.6-9
Comment 3 Jesus M. Rodriguez 2009-02-20 09:25:24 EST
I was unsuccessful in recreating this problem. I used my RHEL4u7 x86_64 with
a minimal install, then used the same version of the iso as Jan. I also used
his answers file (with my email address in it), and it created the gpg information
just fine.

The one thing I did which I always do, was I registered my machine to webqa
and up2date'd it fully BEFORE proceeding with the installation.

I'd like to look at what state the machine was in before installation. How
do I get access to the rhts machines?
Comment 4 Jan Hutař 2009-02-23 03:24:39 EST
Hello,
RHTS machines are installed (and destroyed) on demand, so you can not get access to them (but you can reserve one of them).

The only thing we did differently is I did not updated the system before I ran the installer (I have the system registered into the webqa as well). Also I'm running the installer in the environment without TTY? It is possible to simulate it using "cron" or "atd". Could that be the case?

I'll test it again,
Jan
Comment 5 Jan Hutař 2009-02-23 06:53:04 EST
Hello,
I have:

# at now
at> /mnt/redhat/devel/candidate-trees/Satellite-5.3.0-RHEL4-re20090220.1/i386/i386/install.pl --answer-file=/mnt/tests/CoreOS/RHN-Satellite/Installer/Sanity/install/answers.txt --non-interactive --disconnected --run-updater
at> <EOT>
job 2 at 2009-02-23 04:55

And that PASSed. I have done exactly what test would do. But when I have scheduled the test again, I got the error again:

http://rhts.redhat.com/cgi-bin/rhts/jobs.cgi?id=47640

What could be causing this?
Comment 6 Jesus M. Rodriguez 2009-03-04 11:07:04 EST
I have no idea yet what causes this, still needs investigation.
Comment 7 Devan Goodwin 2009-04-02 13:06:29 EDT
Not sure what to do with this, I definitely cannot reproduce under normal install conditions, it must be something to do with the automated nature of the RHTS environment. I notice in the original post:

gpg: failed to create temporary file
`//.gnupg/.#lk0x8545868.dell-pe1850-02.rhts
.bos.redhat.com.13697': No such file or directory
gpg: //.gnupg: directory created
gpg: new configuration file `//.gnupg/gpg.conf' created
gpg: WARNING: options in `//.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `//.gnupg/pubring.gpg' created

Whereas in a normal install everything is happening in /root/.gnupg

What user does the rhts tests get run as? Do they have a home directory on the system?

Not real clear how the technology involved here works but hopefully this is of some help.
Comment 8 Devan Goodwin 2009-04-02 13:09:07 EDT
Ok to bump down the priority/severity of high? I don't think this is an issue customers can hit.
Comment 9 Jan Hutař 2009-04-03 07:21:18 EDT
You are right, but this is blocking my RHEL4 testing - I'm planning to test this:

http://wiki.test.redhat.com/Faq/TipsAndTricks/FakeTerminal

together with:

http://cvs.devel.redhat.com/cgi-bin/cvsweb.cgi/tests/RHN-Satellite/Installer/Sanity/install/

As this is the only thing I can think of. Also last few nightlies was not installable on the RHEL4 because of dependency issues. Do you think that can help?

So please leave this high/high as it is high/high for a QA.
Comment 11 Jan Hutař 2009-04-06 03:37:14 EDT
You were right! Exporting $USER and $HOME is sufficient to solve this. Interesting is, RHEL5 do not need it. If you want to fix this in the installer somehow or CLOSE this, I'm OK with it. Thanks, Jan
Comment 12 Devan Goodwin 2009-04-06 08:30:04 EDT
Excellent that is a relief. :) Probably the version of GPG in RHEL 5 using a different mechanism to determine who the current user is. 

Will close now, cheers.

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