Description of problem: startx is given an unknown option by the x11vnc package and fails to start an X server Version-Release number of selected component (if applicable): Steps to Reproduce: 1. start x11vnc with the create option on server side - # x11vnc -create 2. attempt to connect to vnc session on client side - $ vncviewer server Actual results: ############################################################### #@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@# #@ @# #@ ** WARNING ** WARNING ** WARNING ** WARNING ** @# #@ @# #@ YOU ARE RUNNING X11VNC WITHOUT A PASSWORD!! @# #@ @# #@ This means anyone with network access to this computer @# #@ may be able to view and control your desktop. @# #@ @# #@ >>> If you did not mean to do this Press CTRL-C now!! <<< @# #@ @# #@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@# #@ @# #@ You can create an x11vnc password file by running: @# #@ @# #@ x11vnc -storepasswd password /path/to/passfile @# #@ or x11vnc -storepasswd /path/to/passfile @# #@ or x11vnc -storepasswd @# #@ @# #@ (the last one will use ~/.vnc/passwd) @# #@ @# #@ and then starting x11vnc via: @# #@ @# #@ x11vnc -rfbauth /path/to/passfile @# #@ @# #@ an existing ~/.vnc/passwd file from another VNC @# #@ application will work fine too. @# #@ @# #@ You can also use the -passwdfile or -passwd options. @# #@ (note -passwd is unsafe if local users are not trusted) @# #@ @# #@ Make sure any -rfbauth and -passwdfile password files @# #@ cannot be read by untrusted users. @# #@ @# #@ Use x11vnc -usepw to automatically use your @# #@ ~/.vnc/passwd or ~/.vnc/passwdfile password files. @# #@ (and prompt you to create ~/.vnc/passwd if neither @# #@ file exists.) Under -usepw, x11vnc will exit if it @# #@ cannot find a password to use. @# #@ @# #@ @# #@ Even with a password, the subsequent VNC traffic is @# #@ sent in the clear. Consider tunnelling via ssh(1): @# #@ @# #@ http://www.karlrunge.com/x11vnc/#tunnelling @# #@ @# #@ Or using the x11vnc SSL options: -ssl and -stunnel @# #@ @# #@ Please Read the documention for more info about @# #@ passwords, security, and encryption. @# #@ @# #@ http://www.karlrunge.com/x11vnc/faq.html#faq-passwd @# #@ @# #@ To disable this warning use the -nopw option, or put @# #@ the setting in your ~/.x11vncrc file. @# #@ @# #@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@# ############################################################### 25/10/2010 15:38:53 x11vnc version: 0.9.8 lastmod: 2009-06-14 25/10/2010 15:38:53 wait_for_client: WAIT:cmd=FINDCREATEDISPLAY-Xvfb 25/10/2010 15:38:53 initialize_screen: fb_depth/fb_bpp/fb_Bpl 24/32/2560 25/10/2010 15:38:53 25/10/2010 15:38:53 Autoprobing TCP port 25/10/2010 15:38:53 Autoprobing selected port 5900 The VNC desktop is: XenMini.xensoft.com:0 PORT=5900 25/10/2010 15:38:55 Got connection from client 127.0.0.1 25/10/2010 15:38:55 other clients: 25/10/2010 15:38:55 incr accepted_client for 127.0.0.1:59499. 25/10/2010 15:38:55 wait_for_client: got client 25/10/2010 15:38:55 client progressed=0 in 15/10 0.012660 s 25/10/2010 15:38:55 client_set_net: 127.0.0.1 0.0004 25/10/2010 15:38:55 wait_for_client: running: env X11VNC_SKIP_DISPLAY='' /bin/sh /tmp/x11vnc-find_display.jRxkFt 25/10/2010 15:38:56 wait_for_client: find display cmd failed 25/10/2010 15:38:56 wait_for_client: FINDCREATEDISPLAY cmd: /bin/sh /tmp/x11vnc-find_display.jRxkFt Xvfb trying N=20 ... redir_daemon= /usr/bin/startx /usr/bin/xterm -- /usr/bin/Xvfb :20 -screen 0 1280x1024x24 +kb -cc 4 -nolisten tcp -auth /tmp/.xas53395627.z2orcA /usr/bin/nohup: appending output to `nohup.out' xauth: creating new authority file /root/.serverauth.5584 xauth: (stdin):2: unknown command "1f458cd3cbc523ceea7a894a1fb07082" Unrecognized option: +kb use: X [:<display>] [option] -a # default pointer acceleration (factor) -ac disable access control restrictions -audit int set audit trail level -auth file select authorization file -br create root window with black background +bs enable any backing store support -bs disable any backing store support -c turns off key-click c # key-click volume (0-100) -cc int default color visual class -nocursor disable the cursor -core generate core dump on fatal error -dpi int screen resolution in dots per inch -dpms disables VESA DPMS monitor control -deferglyphs [none|all|16] defer loading of [no|all|16-bit] glyphs -f # bell base (0-100) -fc string cursor font -fn string default font name -fp string default font path -help prints message with these options -I ignore all remaining arguments -ld int limit data space to N Kb -lf int limit number of open files to N -ls int limit stack space to N Kb -nolock disable the locking mechanism -logo enable logo in screen saver nologo disable logo in screen saver -nolisten string don't listen on protocol -noreset don't reset after last client exists -nr create root window with no background -reset reset after last client exists -p # screen-saver pattern duration (minutes) -pn accept failure to listen on all ports -nopn reject failure to listen on all ports -r turns off auto-repeat r turns on auto-repeat -render [default|mono|gray|color] set render color alloc policy -retro start with classic stipple and cursor -s # screen-saver timeout (minutes) -t # default pointer threshold (pixels/t) -terminate terminate at server reset -to # connection time out -tst disable testing extensions ttyxx server started from init on /dev/ttyxx v video blanking for screen-saver -v screen-saver without video blanking -wm WhenMapped default backing-store -wr create root window with white background -maxbigreqsize set maximal bigrequest size +xinerama Enable XINERAMA extension -xinerama Disable XINERAMA extension -dumbSched Disable smart scheduling, enable old behavior -schedInterval int Set scheduler interval in msec +extension name Enable extension -extension name Disable extension -query host-name contact named host for XDMCP -broadcast broadcast for XDMCP -multicast [addr [hops]] IPv6 multicast for XDMCP -indirect host-name contact named host for indirect XDMCP -port port-num UDP port number to send messages to -from local-address specify the local address to connect from -once Terminate server after one session -class display-class specify display class to send in manage -cookie xdm-auth-bits specify the magic cookie for XDMCP -displayID display-id manufacturer display ID for request [+-]accessx [ timeout [ timeout_mask [ feedback [ options_mask] ] ] ] enable/disable accessx key sequences -ardelay set XKB autorepeat delay -arinterval set XKB autorepeat interval -screen scrn WxHxD set screen's width, height, depth -pixdepths list-of-int support given pixmap depths +/-render turn on/off RENDER extension support(default on) -linebias n adjust thin line pixelization -blackpixel n pixel value for black -whitepixel n pixel value for white -fbdir directory put framebuffers in mmap'ed files in directory -shmem put framebuffers in shared memory Fatal server error: Unrecognized option: +kb 25/10/2010 15:38:57 XOpenDisplay(":20") failed. 25/10/2010 15:38:57 Trying again with XAUTHLOCALHOSTNAME=localhost ... 25/10/2010 15:38:57 *************************************** 25/10/2010 15:38:57 *** XOpenDisplay failed (:20) *** x11vnc was unable to open the X DISPLAY: ":20", it cannot continue. *** There may be "Xlib:" error messages above with details about the failure. Some tips and guidelines: ** An X server (the one you wish to view) must be running before x11vnc is started: x11vnc does not start the X server. (however, see the -create option if that is what you really want). ** You must use -display <disp>, -OR- set and export your $DISPLAY environment variable to refer to the display of the desired X server. - Usually the display is simply ":0" (in fact x11vnc uses this if you forget to specify it), but in some multi-user situations it could be ":1", ":2", or even ":137". Ask your administrator or a guru if you are having difficulty determining what your X DISPLAY is. ** Next, you need to have sufficient permissions (Xauthority) to connect to the X DISPLAY. Here are some Tips: - Often, you just need to run x11vnc as the user logged into the X session. So make sure to be that user when you type x11vnc. - Being root is usually not enough because the incorrect MIT-MAGIC-COOKIE file will be accessed. The cookie file contains the secret key that allows x11vnc to connect to the desired X DISPLAY. - You can explicitly indicate which MIT-MAGIC-COOKIE file should be used by the -auth option, e.g.: x11vnc -auth /home/someuser/.Xauthority -display :0 x11vnc -auth /tmp/.gdmzndVlR -display :0 you must have read permission for the auth file. ** If NO ONE is logged into an X session yet, but there is a greeter login program like "gdm", "kdm", "xdm", or "dtlogin" running, you will need to find and use the raw display manager MIT-MAGIC-COOKIE file. Some examples for various display managers: gdm: -auth /var/gdm/:0.Xauth -auth /var/lib/gdm/:0.Xauth kdm: -auth /var/lib/kdm/A:0-crWk72 -auth /var/run/xauth/A:0-crWk72 xdm: -auth /var/lib/xdm/authdir/authfiles/A:0-XQvaJk dtlogin: -auth /var/dt/A:0-UgaaXa Sometimes the command "ps wwwwaux | grep auth" can reveal the file location. Only root will have read permission for the file, and so x11vnc must be run as root (or copy it). The random characters in the filenames will of course change and the directory the cookie file resides in is system dependent. See also: http://www.karlrunge.com/x11vnc/faq.html Expected results: startx command would not fail and a VNC session would be established Additional info: I believe the latest tarball of x11vnc removed the offending +kb option. I have not built it to test that it works.
Firstly thank you very much for bugreport. I build 0.9.12 version, please test it, ant if it helps - I'll push updates. http://koji.fedoraproject.org/koji/taskinfo?taskID=2564924 http://koji.fedoraproject.org/koji/taskinfo?taskID=2564927
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.