Red Hat Bugzilla – Bug 55661
up2date does not GUI
Last modified: 2015-01-07 18:52:25 EST
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: Always 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
*** 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!