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

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...

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...)?

   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
/usr/bin/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.

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.

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.

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.

Yes I updated the pam as well.

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?

Yes, they are different bugs.

A release to fix that should be available soon.

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.

I am now using pam-0.75-19.  I no longer see the bug.

I'll mark this as closed in an errata, then.  Thanks!