Bug 55661 - up2date does not GUI
Summary: up2date does not GUI
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: pam   
(Show other bugs)
Version: 7.2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Adrian Likins
QA Contact: Jay Turner
Depends On:
TreeView+ depends on / blocked
Reported: 2001-11-04 06:06 UTC by Nevin Kapur
Modified: 2015-01-07 23:52 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-12-23 23:27:32 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Nevin Kapur 2001-11-04 06:06:31 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5) Gecko/20011011

Description of problem:
Running up2date as root does not open the GUI.  It instead gives options  
as thought it was run as update --nox

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

How reproducible:

Steps to Reproduce:
1. Start an X session as an unpriveleged user.
2. Open a terminal and su -.
3. Run up2date from the terminal.

Actual Results:  I see a list of options as I would if I had typed in
up2date --nox.

Expected Results:  A GUI window.

Additional info:

Setting DISPLAY to localhost:0 fixes the problem.  In the buggy scenario
DISPLAY is set to :0.

Version: up2date-2.7.2-7.x.6

Comment 1 Adrian Likins 2001-11-05 19:49:44 UTC

*** This bug has been marked as a duplicate of 55492 ***

Comment 2 Nevin Kapur 2001-11-05 20:14:01 UTC
I'm wondering how this bug is a duplicate of 55492.  That bug is about up2date
trying to open a GUI even when --nox is supplied.  This bug is about up2date
*not* opening a GUI when running under X on a *local* machine.  The bugs seem
related but not duplicates.

Just wondering...

Comment 3 Adrian Likins 2001-11-05 20:23:53 UTC
hmm, your right. I misread the bug report. Related, but indeed not the
same bug.

Not sure what would cause this offhand. DISPLAY seems to be set properly.
what does `which up2date` return in that case?

Without resetting the DISPLAY to localhost:0 can you start up other
X utils (xterm or xclock for example...)?

Comment 4 Nevin Kapur 2001-11-06 00:53:11 UTC
   Not sure what would cause this offhand. DISPLAY seems to be set properly.
   what does `which up2date` return in that case?

[root@bombay root]# which up2date

If I run /usr/sbin/up2date, I see the GUI window.

   Without resetting the DISPLAY to localhost:0 can you start up other
   X utils (xterm or xclock for example...)?

Yes, I can start these X utils just fine.

Comment 5 Need Real Name 2001-11-06 06:59:41 UTC
I have also a similar experience.  I installed the 7.2 cds with the kde
interface. I get the same results when running the KDE 2.2-11 from REDHAT or the
KDE 2.2.1-1 from KDE.ORG  The up2date and up2date-gnome packages were installed
and ran ok.  When not running as root the gui interface would ask for the root
password then run fine.  However after updating to the 2.4.9-7 686 kernal (using
up2date) and again the 2.4.9-13 kernals I get a similar response as noted above.
 Whereis up2date gives /usr/bin/up2date and /usr/sbin/up2date.  When I try to
run up2date from an xterminal I get the following error message:

Xlib: connection to ":0.0" refused by server
Xlib: Client is not authorized to connect to Server
No interactive mode available

and then it give the up2date --help output.  Of course my path as non root does
not include /usr/sbin.  Running /usr/sbin/up2date gives an error message: you
must be root to run this program.  If I su - I get the same error message as
above when running /bin/up2date :Xlib: connection etc.

Also when checking the version of up2date (2.72-7.v.6) with gnurpm or kpackage
verify it indicates that several of the python scripts have different md5sums or
lengths.  Also I note that up2date-gnome and up2date packages both install
/usr/sbin/up2date.  I don't know whether this is relevent or not.

Finally I don't know whether this is part of same bug or not, but when upgrading
the kernal the up2date installs the kernal but then hangs up and does not exit
normally.  I have to hit cancel to exit and of course it doesn't update the
database and the next time I run it, it tells me there is a kernal update available.

Comment 6 Adrian Likins 2001-11-06 19:41:25 UTC
Ah, okay.

Did you also update the pam package to pam-0.75-16?

It looks like this is probabaly a bug in that version
of pam update. Chaning this to a pam bug.

Comment 7 Nevin Kapur 2001-11-06 23:28:13 UTC
I did update to pam-0.75-16 and am also seeing the same behavior as
khill160@home.com.  I too am being prompted to a "newer" version of the kernel
(2.4.9-13) each time even though I already have it installed.

Comment 8 Need Real Name 2001-11-07 02:08:03 UTC
Yes I updated the pam as well.

Comment 9 Need Real Name 2001-11-09 07:30:04 UTC
I removed the pam-0.75-16 package and replace it with the pam-0.75-14 package
from the distribution disk.  The up2date gui will now run from non-root
directory with the root password.  However the problem with the up2date stalling
with a kernal upgrade and then telling me there is a newer kernal available ie.
the one I just installed is still there.  Maybe these are different bugs?

Comment 10 Adrian Likins 2001-11-09 18:28:03 UTC
Yes, they are different bugs.

A release to fix that should be available soon.

Comment 11 Need Real Name 2001-11-28 03:32:06 UTC
When I look at the rpm packages installed, it shows multiple copies of the
kernel installed including all the previous versions of the kernel as well as
multiple copies of the latest one.  However the only files remaining are the
latest kernal trees. Telling kpackage to remove the earlier versions actually
removed the current kernel tree.  When I re-installed the kernel using rpm it
removed the entrys for the earlier kernels, but all the duplicated entrys of the
current version remained.  These also survived rebuilding the database ie. (rpm
-rebuilddb).  Kpackage and rpm (command line) would not remove the duplicate
headers, but gnuprm did.

Comment 12 Nevin Kapur 2001-12-23 23:27:27 UTC
I am now using pam-0.75-19.  I no longer see the bug.

Comment 13 Nalin Dahyabhai 2002-03-08 00:12:45 UTC
I'll mark this as closed in an errata, then.  Thanks!

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