Description of Problem: It appears that up2date-gnome-2.7.2 doesn't respect the request to avoid X. How Reproducible: (On remote shell with no X server.) # up2date-nox -l Gdk-ERROR **: X connection to foo:11.0 broken (explicit kill or server shutdown). Ugly workaround: # rpm -e up2date-gnome ../C
Are you running up2date-nox as root or as a user? If you are running it as a user, you are actually invoking /usr/bin/up2date-nox, which is a link to consolehelper. consolehelper is an app that prompts you for root's passwd if it needs to be. the consolehelper app will attempt to run a gui X based version of the tool if a DISPLAY env variable is set. If the display that DISPLAY is set to isnt valid, you can get an error like you mention. If you run it as root (or as a user with /usr/sbin) in the path first, you run up2date directly, and it should respect the -nox. I suspect thats whats going on. Hopefully for the next version `consolehelper` will be smarter about that.
I guess I shoulda made the Summary: up2date --nox still reqires remote X server Yes, running as root always. Symtom is reproducible with up2date --nox...as long as X11 forwarding is enabled, but without an X server running. Here, let me give you some more info... System A - Red Hat 7.1 (no bug) # rpm -q up2date-gnome up2date-gnome-2.5.4-1 # up2date --nox -l Retrieving list of all available packages... yada yada System B - Red Hat 7.2 (yes bug) # rpm -q up2date-gnome up2date-gnome-2.7.2-7.x.6 # up2date --nox -l Gdk-ERROR **: X connection to foo:12.0 broken (explicit kill or server shutdown). Observations: - I am on remote console shelled in using ssh - this bug does not happen if I remove up2date-gnome - it only occurs with X11 forwarding enabled, but no X server loaded - I've run in this scenario for many moons. only Enigma seems to manifest bug Good luck, and thanks. ../C
*** Bug 55661 has been marked as a duplicate of this bug. ***
ah, does it only do it one "--list/-l"? There is definately a bug in that case for "--list" handling. That branch ignores the "nox" and attempts to talk to the display set in DISPLAY to see if it should run gui. If DISPLAY is set, it will. I'll fix it so that "--list" mode handles this more approriately.
I tested some more. This bug occurs with all the following options: --nox -l --nox -u foo --nox -i bar --nox -p
I just tested again with 2.7.11-7.x.2 and alas, the problem is not yet resolved.
I'm not sure how relevant this is, but I was having the same problem. Apparently, there is a difference in logging in to the console as root, via ssh/telnet, whatever and logging in as a normal user and then su'ing to root. The path's get set differently, thus one version of up2date-nox get's picked over the other. I find that logging in as a regular user, then calling "su - root" does not set the path the same way as "ssh HOSTNAME -l root". Ie, /usr/bin is placed before /usr/sbin. I haven't exactly figured out what the difference in login procedure is, ie what files are read or not read, but this is most certainly a situation when this kind of error crops up.
I don't know if this is related or not, but even when X forwarding works properly (i.e. - ssh from A to B as user X, su to root, xauth merge ~X/.Xauthority, after which xterm etc work fine), up2date *still* gives: Gdk-ERROR **: X connection to b.foo.com:11.0 broken (explicit kill or server shutdown). What is it about ssh X forwarding that's confusing Gdk?
I belive most of these issues are related to usermode/consolehelper, and/or path weirdness with ssh. Some of the usermode issues will be fixed with the release of usermode-1.5, and up2date 2.7.62 or higher.