From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040404 Firefox/0.8 Description of problem: Here are the output of the error screen: it asked for this info to be reported. Error activating XKB configuration. Probably internal X server problem. X server version data: The X.Org Foundation 60700000 If you report this situation as a bug, please include: - The result of xprop -root | grep XKB - The result of gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb [root@localhost root]# xprop -root | grep XKB _XKB_RULES_NAMES_BACKUP(STRING) = "xfree86", "pc105", "us", "", "" _XKB_RULES_NAMES(STRING) = "xfree86", "pc105", "us", "", "" [root@localhost root]# [root@localhost root]# gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb layouts = [us] model = pc105 overrideSettings = false options = [] [root@localhost root]# Version-Release number of selected component (if applicable): xorg-x11-6.7.0-0.4 How reproducible: Always Steps to Reproduce: 1.login 2. 3. Actual Results: a error popup window comes up Expected Results: no errors Additional info:
Since you got this in first, I will just expand on it for the other things I found. Yes, I got the popup: Error activating XKB configuration. Probably internal X server problem. X server version data: The X.Org Foundation 60700000 If you report this situation as a bug, please include: - The result of xprop -root | grep XKB - The result of gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb But, I also found some other stuff: 1. The selinux policy has XFree86 definitions but not Xorg 2. The /etc/X11/X symbolic link points to /usr/X11R6/bin/XFree86 3. There are lots of references in /etc/* to XF86Config and /etc/X11/X [do a "grep -r" on /etc/*]
Changed platform to all ... this is not just i386
Better still, do: grep -r -i "xfree86" /etc/* I have no idea how many hits are relevant but there are lots of them.
Dan Walsh has an updated selinux policy at ftp://people.redhat.com
I am not sure if this is related to the popup or not. The xorg-x11 package includes the file: /usr/X11R6/lib/X11/xkb/keycodes/xfree86
I'm getting the exact same error. Everything as the original writer, version and errors, only difference is I get se (Sweden) where he got us (U.S.).
The problem is because our config tool hard codes: Option "XkbRules" "xfree86" in the config file. Xorg X11 uses "xorg", not "xfree86" so it breaks. Remove that line from the config entirely and it should work on both XFree86 and Xorg.
Mike- Will this be fixed in the next rawhide xorg release?
It's not an xorg-x11 bug, so technically no. ;o) Remove the above line from your config file and the problem will go away. Alternatively, change the line to read: Option "XkbRules" "xorg" The "xfree86" xkbrules is not part of X.org anymore having been renamed to "xorg". pyxf86config has been modified to not put this line in the config file anymore. Once it is in rawhide and I get reports it fixes the problem for people, I'll close all of the 200 bugs open about this prob. ;o) Thanks guys.
OK, I commented out the line: Option "Xkbrules" "xfree86" Logout, telinit 3, telinit 5 (just to make sure), login ... still get the popup do xprop -root | grep XKB now get "xorg" instead of "xfree86" but still get the popup.
Oh yes, updated current with development as of 15 April.
I change to "xorg" also and still get the popup. Obviously, someone is not sure how this stuff works.
*** Bug 120917 has been marked as a duplicate of this bug. ***
Tried changing to xorg, as well as removing XkbRules line entirely, and neither fixed the popup box. Created a brand new user account just to see if it was existing gconf config problem, but new user also exhibited popup problem. For further troubleshooting, I've found that playing around with the gnome-keyboard-properties applet will tickle the bug as well.
Having spent several hours investigating this problem, yes, I am very sure how it works. ;o) I have personally tested this problem and reproduced it on 2 systems now, and I have applied the latest packages from our internal dist-fc2 collection instance which contain fixes, including pyxf86config, and libxklavier, and system-config-display. Once all X server configuration files are physically removed, and a single brand new xorg.conf file generated, and hand inspected to ensure that the XkbRules line is *not* present, the problem no longer occurs for the setxkbmap issue, and other issues that have been reported. It is possible that there may still be other bugs present, however so far, none of the bugs discovered with respect to the xkb rules file have been xorg-x11 bugs. I have discovered the config file bug responsible for setxkbmap breaking, and confirmed the fix, and we have discovered libxklavier hard codes the name of the rules file as "xfree86" which is broken as designed. Jeremy Katz has changed libxklavier to use "xorg" as the rules file, which is a kludge for now to get it to work, however the upstream developers of libxklavier should change it to query the X server to get the name of the rules file. This issue (and others) are not closed yet in bugzilla you'll note, which is to give enough time for all of our fixes to both get merged into publically visible rawhide, and allow end users time to upgrade to the new packages. Some things were fixed only this morning, and most likely are not publically visible yet. Please have patience with this issue, until our fixes are available. Once we have confirmed each issue is properly fixed, we will update the various Xkb rules related bug reports and close them as duplicates as can be confirmed, and close them as RAWHIDE once that can be confirmed as well. If gnome-keyboard-properties still is broken after these updates, then most likely gnome-keyboard-properties or something it links to is broken also, possibly needing a recompile, or additional fixes. Either way, these issues will definitely be resolved in future builds. Thank you once again for your patience, and your testing efforts.
I solved this by simply adding a symlink in /usr/X11R6/lib/X11/xkb/rules: ln -s xorg.lst xfree86.lst Temporary, sure, but setxkbmap is happy again.
Yes, that did it. I suspect the fix will be to add a symlink to the xorg-x11 package (until the code can be cleaned up of xfree86 references). I noticed that there was another symlink for xfree86->xorg already being part of the xorg-x11 package.
After installing control-center-2.6.1 and libxklavier-1.0.2, this problem disappeared.
*** Bug 120932 has been marked as a duplicate of this bug. ***
*** Bug 120994 has been marked as a duplicate of this bug. ***
*** Bug 121000 has been marked as a duplicate of this bug. ***
*** Bug 121101 has been marked as a duplicate of this bug. ***
This bug has been flagged as the master duplicate for this issue, in which xprop returns "xfree86" for Xkbrules despite the server hard coding "xorg" internally. The alias "xkbrules-xprop" has been assigned to this bug for easier closing of duplicate issues. Also note that while this report is filed against xorg-x11 currently, this is not believed to be an xorg-x11 issue, but an issue in the other respective components discussed above, however I'm keeping it assigned to the xorg-x11 component, as it is easier for me to track/dupe other issues against it, and likely easier for people to find who are querying bugzilla, as people will assume it is an X bug, due to the bogus error messages that state it is "probably an X server bug" (despite the fact it is not). As mentioned above in my comment #15, we believe this issue to be fixed in the latest updated versions of packages in our internal tree, which seems now to have been pushed externally (not confirmed). Sangu's comment #18 seems to confirm this is fixed as per my previous comments. Since many people are duped on this issue, I would like as many people as possible to update to the latest packages of *everything* (not just xorg-x11) from rawhide today, and confirm wether or not this issue is still present. In particular, make sure that the following packages are updated to the latest: libxklavier control-center pyxf86config system-config-display It is also important to make sure your X server config file does not contain the line: Options "XkbRules" "xfree86" If that line appears in the config file, remove it, and restart the server, or rerun the latest "system-config-display --reconfig". One further note, is for people who prefer to download rawhide rpms and recompile them themselves either for previous OS releases, or for whatever other reason, is that some of these problems are due to bad assumptions in static libraries, and if you're recompiling anything which we claim is fixed, you must be certain to compile the static libraries with fixes first, then recompile everything that uses them. Obviously, the easy way to do that, is to just use Red Hat supplied binaries. ;o) So, I'm leaving this issue in ASSIGNED state temporarily, until various others CC'd with these issues can do the necessary updates, and then indicate wether or not the issue is resolved. Thanks in advance for your testing efforts, and for reporting these issues to Red Hat.
*** Bug 121254 has been marked as a duplicate of this bug. ***
I still get the error with Options "XkbRules" "xfree86" removed from /etc/X11/XF86Config and the packages [scott@curran103 scott]$ rpm -q libxklavier control-center pyxf86config system-config-display libxklavier-1.00-2 control-center-2.6.0.3-3 pyxf86config-0.3.18-1 system-config-display-1.0.13-2 I tried changing Options "XkbRules" "xfree86" to Options "XkbRules" "xorg" but still recieved the error.
control-center 2.6.1 is required aparently according to comments in one of the bug duplicates. I've cc'd the maintainer of the control-center package for comment, as I was unable to locate the package that people claim fixes the problem.
Actually, it is comment #18 in this bug report which indicates version 2.6.1 is required. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120858#c18 This bug report is not an xorg-x11 bug, but is really a control-center bug, or a bug in one of control-center's dependant libraries perhaps. Unfortunately, I don't maintain any of those apps/libs mentioned above, so I don't know who fixed what when in where. ;o) I do know that libxklavier, control-center, system-config-display, pyxf86config all received fixes related to similar (but not identical) problems. jrb, sangu: Where does one obtain control-center 2.6.1, claimed to fix this issue?
sangu: You claim libxklavier 1.0.2 fixes the problem for you in comment #18, however there is no such thing as libxklavier 1.0.2 at least as far as I can see. If someone could confirm what the proper version is of each of the affected packages, by confirming the problem is both gone, and performing an "rpm -q <packagename>" on each package, then cut and pasting the exact specific version number of each package required into the report, that would be greatly appreciated. ;o) So far, I'm unable to find either of the packages listed in comment #18. What I can directly confirm personally however, is that the following package versions or newer are required: pyxf86config-0.3.18-1 system-config-display-1.0.13-2 Additionally, by reviewing the rpm changelog of the other packages: $ changelog /mnt/redhat/beehive/comps/dist/fc2/libxklavier/1.00-2/SRPMS/libxklavier-1.00-2.src.rpm * Thu Apr 15 2004 Jeremy Katz <katzj> - 1.00-2 - patch for xorg.xml instead of xfree86.xml So I'm assuming that Sangu's comment is a typo which should have been "libxklavier 1.00-2" instead of the stated "1.0.2". The control-center rpm may be a typo perhaps also, but I'll leave that for others to comment on. Thanks for info, and for testing.
I make two packages(control-center-2.6.1 and libxklavier-1.0.2). control-center-2.6.1]# cat ChangeLog | more 2004-04-15 Jody Goldberg <jody> * Release 2.6.1 2004-04-15 Jody Goldberg <jody> * configure.in : Force libxklavier 1.0.2 so that we can work with x.org and xfree86
*** Bug 121279 has been marked as a duplicate of this bug. ***
I do not have the control-center or libxklavier packages installed and I still get the error. I also installed the latest rawhide updates.
Created attachment 99545 [details] XKB Error Window
xprop -root | grep XKB _XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc105", "us", "", "" _XKB_RULES_NAMES(STRING) = "xorg", "pc105", "us", "", "" gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb layouts = [us] model = pc105 overrideSettings = true options = [] I have tried editing /etc/X11/XF86Config so that it either has xorg or has the line commented out, as such: Identifier "Keyboard0" Driver "keyboard" # Option "XkbRules" "xorg" Option "XkbModel" "pc105" Option "XkbLayout" "us" I have made a sym link from XF86Config to xorg.conf in /etc/X11 as man xorg.conf suggests as the location of future xorg config file. Here are the version I have of the above mentioned packages: rpm -q libxklavier control-center pyxf86config system-config-display libxklavier-1.00-2 control-center-2.6.0.3-3 pyxf86config-0.3.18-1 system-config-display-1.0.13-2 Like everyone else it happens at every launch of GNOME and I attached a screenshot of the error in Comment #32. Comment #16's suggestion corrected the problem so I will use this until an official fix is found.
This began working for me after I let system-config-display redo my config file from scratch and upgrading to these two packages soon to be in rawhide (copied to download.fedora.us RPMS.updates): libxklavier-1.02-1 control-center-2.6.1-1 I suspect the config file part was unrelated to the problem, because both libxklavier and control-center say "real xkb fix" in their changelogs.
Note that none of the automatic tools removed the XkbRules line nor did they rename XF86Config to the new /etc/X11/xorg.conf name.
Warren: The upstream libxklavier fix is the better one, however our fix worked as well but it was just a hack (hard coding xorg rules file instead of xfree86 rules file). So it's better that we'll be updating to the new libxklavier, but it shouldn't make any noteable difference IMHO from what we currently had. The control-center update is the real likely fix. It occurs to me that comment #18 above was indicating a non-Red Hat package fixed the problem rather than the ones in rawhide, hence some of the confusion trying to find what package versions fixed what. The only way the XkbRules line will get removed at all if it is present (wether it is pointing to xfree86 rules or xorg rules) is one of the following: 1) The user edits the config file and removes the XkbRules line or 2) The user updates system-config-display to current rawhide, and then runs it and causes a new config to be written out. This will work, but ONLY if using Red Hat compiled binaries (I say this because some people recompile and end up with a non-working setup due to static linking against older libraries that are broken on their system). Also, the python portion of pyxf86config has been changed, so this is important too. If you do not do #2, nor #1 above, the XkbRules line will not change, and the config file will tell the X server to use the 'xfree86' rules file which doesn't exist (intentional upstream removal). In this case, it isn't a bug in any current app, it is a bug caused by the old config tool writing out an unnecessary line to the config file which now must be removed in order for things to work. I can fix that in a kind of kludgy way, which might help cut down on problems: - I can have xorg upgrades automatically fudge the xorg.conf config file to remove any XkbRules line if present. Kindof ugly, but we've done that for removing PEX/XIE module load lines before, and fudging the font server in the font path and a few other things, so it's doable if the demand is there and the problem big enough. Just need to beat the rpm spec file with my ugly stick a few times. ;o)
An error, just like the picture. I just updated to the latest xorg versions yesterday. I have not tried to run system-config-display yet. I am running without SELinux and the suggested additional outputs are listed below. (same old stuff) rror activating XKB configuration. Probably internal X server problem. X server version data: The X.Org Foundation 60700000 If you report this situation as a bug, please include: - The result of xprop -root | grep XKB xprop -root | grep XKB _XKB_RULES_NAMES_BACKUP(STRING) = "xfree86", "pc105", "us", "", "" _XKB_RULES_NAMES(STRING) = "xfree86", "pc105", "us", "", "" - The result of gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb layouts = [us] model = pc105 overrideSettings = false options = []
Maybe we need updated packages but... I reinstalled (no recompilation) from rawhide today: control-center-2.6.0.3-3.i386.rpm libxklavier-1.00-2.i386.rpm libxklavier-devel-1.00-2.i386.rpm pyxf86config-0.3.18-1.i386.rpm system-config-display-1.0.13-2.noarch.rpm Commented out ( also tried a change to xorg ) the Xkbrules line in xorg.conf: grep Xkb /etc/X11/xorg.conf ...................... # Option "XkbVariant" "nodeadkeys" # Option "XkbOptions" "ctrl:swapcaps" #Option "XkbOptions" "" # Option "XkbRules" "xorg" Option "XkbModel" "pc105" Option "XkbLayout" "us" #Option "XkbVariant" "" Restarted X, still got popup. xprop -root | grep XKB _XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc105", "us", "", "" _XKB_RULES_NAMES(STRING) = "xorg", "pc105", "us", "", "" gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb layouts = [us] model = pc105 overrideSettings = false options = [] Then tried system-config-display --reconfig: system-config-display --reconfig Traceback (most recent call last): File "/usr/share/system-config-display/xconf.py", line 412, in ? hardware_state.merge_into(xconfig) NameError: name 'hardware_state' is not defined Xorg.0.log: (==) Using config file: "/etc/X11/xorg.conf" (==) ServerLayout "single head configuration" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "ATI Radeon 8500 DV" (**) |-->Input Device "Mouse0" (**) |-->Input Device "Mouse1" (**) |-->Input Device "Keyboard0" (**) Option "XkbModel" "pc105" (**) XKB: model: "pc105" (**) Option "XkbLayout" "us" (**) XKB: layout: "us" (==) Keyboard: CustomKeycode disabled ................... Good luck. sean
mharris: I have made changes to system-config-display (1.0.13-3) and rhpl (0.143-1) that should prevent the XkbRules line from ever getting written out. I believe that this should fix this bug, but please test and verify.
FYI: Using the same set of rpms listed in comment #38, system-config-display messed up my monitor resolution: all of a sudden I could only use 640x480 and 800x600, even after restart (all I did was open it, then click "OK" without manually changing anything). What it did was comment the vertical and hotizontal sync lines in my /etc/X11/XF86Config file. Uncommenting them and restarting X fixed the problem. The problem reappeared when I opened system-config-display again (so I fixed it the same way).
WorksForMe now. Got control-center-2.6.1-1.i386.rpm libxklavier-1.02-1.i386.rpm libxklavier-devel-1.02-1.i386.rpm pyxf86config-0.3.18-1.i386.rpm system-config-display-1.0.13-3.noarch.rpm restarted X - no popup. Good work. FWIW system-config-display --reconfig gives same error. I realize it's another bug. sean
Ok, I'm closing this bug as fixed in rawhide now, with the instructions for getting a fixed system being to upgrade to the latest rawhide rpms of all packages, but in particular the packages listed in comment #41 above, as several people have confirmed via bugzilla, email, or IRC, that the problem goes away with those packages installed. Once the packages are updated on the system, please rerun the "system-config-display --reconfig" tool, and with the new config it generates, start the X server and try to reproduce this problem. If the problem persists, then follow the following steps: 1) Shut down X server 2) Edit X server config file to ensure the XkbRules line is not present, and also ensure the X server config file is named "xorg.conf", renaming it if necessary. 3) REBOOT THE COMPUTER completely 4) start the X server once the system is booted back up If the problem still persists, reopen this bug report and include the output of "rpm -q" for each of the packages listed in the above comment #41. Then attach your X server config file, log file, and any other relevant details. Thanks for testing Fedora Core 2 test releases everyone.
*** Bug 121558 has been marked as a duplicate of this bug. ***
*** Bug 121574 has been marked as a duplicate of this bug. ***
*** Bug 117134 has been marked as a duplicate of this bug. ***
*** Bug 121637 has been marked as a duplicate of this bug. ***
*** Bug 121774 has been marked as a duplicate of this bug. ***
*** Bug 121836 has been marked as a duplicate of this bug. ***
*** Bug 121639 has been marked as a duplicate of this bug. ***
*** Bug 121910 has been marked as a duplicate of this bug. ***
*** Bug 121965 has been marked as a duplicate of this bug. ***
*** Bug 121714 has been marked as a duplicate of this bug. ***
Informational update: xorg-x11-6.7.0-2 and later builds now contain rpm %pre script modifications which will automatically remove any Option "XkbRules" line that may be pre-existing in the config file. This should help to reduce the effects of this problem for users upgrading. Thanks again to everyone for your testing and patience.
*** Bug 116925 has been marked as a duplicate of this bug. ***
*** Bug 122828 has been marked as a duplicate of this bug. ***
*** Bug 122673 has been marked as a duplicate of this bug. ***
*** Bug 122893 has been marked as a duplicate of this bug. ***
*** Bug 121984 has been marked as a duplicate of this bug. ***
*** Bug 123128 has been marked as a duplicate of this bug. ***
Well, bug #123128 isn't a 100% duplicate, because I used test3 to upgrade an existing RH9 installation. So, the bug is still present in 1.92 at least when upgrading, IMHO.
Test3 did not have an automated way of making that warning message go away, while FC2 final does. So don't worry about it.
I still have this problem when upgrading (using anaconda) from FC1. The current package-set is installed: control-center-2.6.1-3 libxklavier-1.02-1 package libxclavier-devel is not installed pyxf86config-0.3.18-2 system-config-display-1.0.14-1 The following output was requested by the error-message: _XKB_RULES_NAMES_BACKUP(STRING) = "xfree86", "pc105", "be", "", "" _XKB_RULES_NAMES(STRING) = "xfree86", "pc105", "be", "", "" and layouts = [us] model = pc105 overrideSettings = true options = [] I've changed my /etc/X11/XF86Config, but still have to reboot. Just a message that it isn't fixed with FC2 final after upgrading from FC1. Looking at the %pre-script of xorg-x11, I see for my system: [root@emyn root]# ls -la /usr/X11R6/lib/X11/xkb/compiled /var/lib/xkb lrwxrwxrwx 1 root root 26 May 15 08:08 /usr/X11R6/lib/X11/xkb/compiled -> ../../../../../var/lib/xkb /var/lib/xkb: total 12 drwxr-xr-x 2 root root 4096 May 17 01:16 . drwxr-xr-x 36 root root 4096 May 15 07:56 .. -r--r--r-- 1 root root 644 May 7 17:29 README Now going for a reboot.
Comment 7 fixed it for me. Still I guess this should be handled by the installer/package, most people upgrading will have XkbRules set to xfree86.
*** Bug 123322 has been marked as a duplicate of this bug. ***
FWIW this still happens with FC1 -> FC2 final upgrade (and changing the XkbRules line to "xorg" or removing it does fix it)
The 6.7.0-2 package was supposed to automatically strip the XkbRules line from the X server config file during installation/upgrade, however the actual code for it got inadvertently left out. I've built a new package that contains the code to fix up the config file upon X server installation. The new package is xorg-x11-6.7.0-3, which is currently available temporarily at the following URL: xorg-x11-6.7.0-3 is now available for download via 'yum' and ftp at the following URL: ftp://people.redhat.com/mharris/testing/fc2
i updated xorg to 6.7.0-3 on a FC2 final clean install and still get the same error note: i get the message for Romanian layout, for other (e.g. Polish) no xprop -root | grep XKB _XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc105", "us", "", "" _XKB_RULES_NAMES(STRING) = "xorg", "pc105", "us", "", "" gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb layouts = [us,ro ro_us] model = pc105 overrideSettings = false options = []
About the advice in #66: I tried to upgrade from 1.92 to FC2 final. That didn't work. I then downloaded xorg-x11-6.7.0-3 and a bunch of other files to satisfy rpm dependencies. That didn't work either. I constantly got soms SELinux hints, which didn't make any sense to me. I then backed up my files and did a complete re-install of FC2, that worked.
*** Bug 123702 has been marked as a duplicate of this bug. ***
*** Bug 123626 has been marked as a duplicate of this bug. ***
*** Bug 123724 has been marked as a duplicate of this bug. ***
*** Bug 123806 has been marked as a duplicate of this bug. ***
*** Bug 123732 has been marked as a duplicate of this bug. ***
*** Bug 123893 has been marked as a duplicate of this bug. ***
*** Bug 124455 has been marked as a duplicate of this bug. ***
*** Bug 124252 has been marked as a duplicate of this bug. ***
*** Bug 123984 has been marked as a duplicate of this bug. ***
*** Bug 124526 has been marked as a duplicate of this bug. ***
*** Bug 124537 has been marked as a duplicate of this bug. ***
*** Bug 124846 has been marked as a duplicate of this bug. ***
*** Bug 124895 has been marked as a duplicate of this bug. ***
I'm sorry to say that I followed every suggestion in this list on my newly-installed FC2, including comment #42, and I still get that darn popup :-(. I didn't see this anywhere, but this only happens when I log in as a user other than root. It works perfectly on root, but gives that popup for other users. In other users, the Bluecurve theme seems to not take effect, the desktop is black, and the mouse is very fast. I ran up2date after logging in for the first time as root, so I'm wondering if the updated packages create problems for new users. I haven't touched anything else in the system other than running up2date, so I'm wondering what's wrong. KDE seems to work properly, but I would like to use GNOME if possible. Here are the package versions that I am using: control-center-2.6.1-3 libxklavier-1.02-1 package libxklavier-devel is not installed pyxf86config-0.3.18-2 system-config-display-1.0.14-1 The `system-config-display --reconfig` produced the error message mentioned in this thread, so I deleted xorg.conf and re-ran system-config-display. I verified that XkbRules was not in xorg.conf. I set it up, rebooted, and tried logging in as a non-root user. The XkbRules pop-up is still there :-(. Should I attach my xorg.conf server config?
*** Bug 123283 has been marked as a duplicate of this bug. ***
*** Bug 125578 has been marked as a duplicate of this bug. ***
I still get the error message when login with an user other that root. Today I used up2date to make a complete update of my system. Every available package has been downloaded. The versions of the packages are the same or newer than listed in #82. Now the command "gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb" return simply nothing.
William: really really strange. Empty gconftool result means there is something horribly wrong with either g-s-d or gconf. Just one question - are you using normal x.org X server from FC2 or VNC or some other (commercial?) X server? What is the result of xprop -root | grep XKB?
*** Bug 125640 has been marked as a duplicate of this bug. ***
Fully updated FC2 machine. Seing the same behavior as comment #82 and Comment #85. Output of the error message below: [mwesley@localhost X11]$ xprop -root | grep XKB _XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc105", "us", "", "" _XKB_RULES_NAMES(STRING) = "xorg", "pc105", "us", "", "" [mwesley@localhost X11]$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb [mwesley@localhost X11]$ For every non-root user: - background is black - bluecurve icons are missing (old openoffice, mozilla, gnome icons are instead shown) - no icons in the panel menu
Is gconfd-2 running at all? Is gnome-settings-daemon running? It seems the latter is broken.
*** Bug 125722 has been marked as a duplicate of this bug. ***
*** Bug 125902 has been marked as a duplicate of this bug. ***
*** Bug 126276 has been marked as a duplicate of this bug. ***
I am experiencing the same problem as Marty in #88. A freshly installed FC2 and I am receiving the XKB error, output of xprop is the same, no output from the gconftool-2 command, and every non-root user receives the black background and no bluecurve icons, and no menu icons. To answer Sergey in #86, I am using the stock xorg X server that comes with FC2. And to answer Sergey in #89, gconfd-2 and gnome-settings-daemon are both running and an rpm -V control-center comes back clean. From the number of comments in this bug, I would hope that the status of this bug doesn't remain CLOSED
The remaining bug is a control-center bug, is probably why this one is closed - not sure the dups are being marked vs. the right bug. Then again, I'm not sure we have a control-center bug open.
Andrew: do non-root users have gnome-settings-daemon runnning? It looks like it can not start properly for some reason. Havoc: ok, you can create new bug against g-c-c - up to you, you hold the wheel, you drive. Just could you please post the reference here - so I could find and help people, ok?
Andrew, deeply sorry, I did not notice you mentioned gnome-settings-daemon is running. At this point I really don't know what to think (it is not exactly keyboard-related:). I'll ask Jody - probably he heard something about this problem.
Havoc, I can open a control-center bug if one is not opened (after some further testing of course ;). BTW, I should have noted in my previous comments that this FC2 installation has been fully updated with errata. I have since installed a fresh FC2 and have not applied any updates and the gconfd/gnome-settings-daemon issue has not yet appeared and the XKB error doesn't appear with the XkbRules option removed. I'm wondering if the other issue has to do with the libgnome errata release, or possibly gnome-session (I'm not a GNOME guru so I have no idea which package could be causing the problems, but those are the only 2 errata packages I see in the RHN applet GUI). Before I added my previous comment I reinstalled the control-center RPM with --force however that didn't alleviate the gconfd/gnome-settings-daemon issue. I am going to build a FC2 virtual machine with VMWare and then apply the updates to see if I experience the "possible" control-center bug. Thanks for the help.
Andrew: Seth Reinoso already opened a control-center bug, bug 123649, which looks to be the same problem. FWIW, I've had the same problem myself. Fresh install of FC2, updated everything I could with apt-get (from freshrpms.net), problem started for accounts other than root. Same deal - error on login, no bluecurve theme, no icons in menu, etc. I didn't have any Options "XkbRules" line at all in xorg.conf, and adding Options "XkbRules" "xorg" didn't help. I performed a fresh reinstall and haven't updated anything yet, now everything's peachy.
*** Bug 126899 has been marked as a duplicate of this bug. ***
FYI, I have installed FC2 in a VMWare VM and updated the box piecemeal and everything seems fine now. First I updated libgnome to see if that was the issue and the machine did not exhibit the black background/no bluecurve issue. I then updated gnome-session - no issues. I then updated the packages that I knew had nothing to do with gnome or X (bison, cdda2wav, cvs, etc). No anomalies. I then updated openmotif, xinitrc, and the rest of the packages and still no issues showed up. In between these updates, I rebooted, created a brand new user and logged in as the new user, as to create new gconf and GNOME settings files. I also logged in as previously created users and they had no problems either. I'm not sure if there were any updates issued within the last 5 days, but it seems to be working at least in my virtual machine. Now to take the plunge on my real workstation. I'm wondering if an up2date/yum mirror has/had a corrupt package. I will post my results here when I have more.
*** Bug 127096 has been marked as a duplicate of this bug. ***
Just want to turn your attention to this bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124537 This provides quite another case. In this case, there are several thin clients, all running FC1, which connects to a thin client server. When this server was running FC1, it was no problem, and we saw no reason why upgrading to fc2 should propose any trouble. And after reinstalling the machine with fc2, everything ran troublefree on the local server console, but when the clients connected, the error message popped up. Exept for the error message there was no further trouble - but i hope an upgrade of the clients to fc2 will fix this, as it is not acceptable in a production enviroment...
Kyrre: Fedora Core is intended for enthusiasts, hobbiests and developers, and should not ever be used in a production environment. If you require a solution which is intended for production environment I recommend contacting Red Hat sales to inquire about Red Hat Enterprise Linux, and a Red Hat Network subscription. Fedora Core is a development platform which is bleeding edge, and tracks technology advances. It is not ever intended to be used in business production environments.
<rh_sales> EAT YOUR BRAAAAAANE. (runs)
That said, we still need to fix these bugs ;-)
Slight status update, just for clarificative purposes. I've updated the summary line to properly reflect the original reported problem was a bug in GNOME control-center instead of "xorg" as was indicated initially, as that seemed to confuse many people into thinking that the problem was an X.Org bug. Also updated the component to "control-center". Not all bugs that have xkbrules related problems are duplicates of this one, just the gnome control-center ones, although in many cases the problems are very similar. As Havoc mentiones above, as we discover xkbrules related problems in applications that are a part of Fedora Core 2, we will need to fix them. We've fixed control-center, KDE, libxklavier, and other packages, however occasionally a new problem is discovered in a new application. Openoffice for example seems to have this problem as well. People are encouraged to report new bug reports for other applications which fail also, so that we can track down any real problems left and try to fix them in future updates. There is a fairly high number of false bug reports however, so users are requested to please follow the following steps: - Please make sure you are running Fedora Core 2 installation from the final release of FC2, or update completely to the final FC2 release first. - Install all FC2 updates that have been released to date. - Make sure your X server config file is named "xorg.conf". If it is named XF86Config or XF86Config-4 or anything else, please rename the file to xorg.conf and delete any other config files that might be present, or move them out of the way so the X server can't find them. - Edit your xorg.conf and make sure it does not contain any line specifying the XkbRules filename. If you find the following line in the file, remove it and save the file: Option "XkbRules" "xfree86" It is important that this line does not exist in the file. An xorg-x11 package update that is currently in "testing" will be released this week to FC2 updates which upon upgrade will both rename the X server config file to xorg.conf, and also make sure that the above Option line is removed from the file if present. - Restart the X server for all changes to take effect. By following the above instructions, your X server will be properly configured, and will use the correct xkbrules file, which is "xorg". Applications which use the xkbrules file and query the X server to get the name of the file by using the Xkb extension, will be given the name "xorg". You can test this by running the "xprop" utility as follows: xprop -root | grep XKB _XKB_RULES_NAMES_BACKUP(STRING) = "xorg", "pc105", "us", "", "" _XKB_RULES_NAMES(STRING) = "xorg", "pc105", "us", "", "" If the above command shows "xfree86" instead of "xorg", then please go through the steps above once again and ensure that you haven't missed a step. Also make sure that the display you are looking at is using a Fedora Core 2 X server. Some people have made the mistake of using an XFree86 X server on a previous OS release, and remotely connecting to a Fedora Core 2 box, editing their FC2 X server config, and running xprop. ;o) Once you correctly have the xprop utility reporting "xorg" as above, the applications which use xkb should now work correctly. If you discover an application in Fedora Core 2 which does not work correctly, or which displays an xkb related error, it is highly likely that that application contains a bug which will need to be fixed. After ensuring the above steps have been followed for X server configuration, please see if an update is available for Fedora Core 2 for the problematic application. If there is no update, or if the update still doesn't fix the xkb related problem, please file a new bug report in bugzilla against that particular application. You can carbon copy me on the bug report as well, and I may be able to help the package maintainer of the buggy app to fix up the xkb problem with that app. If you discover applications failing which do not come with Fedora Core 2, such as 3rd party apps, apps running remotely over the network, proprietary apps, or others, it is highly probably that those applications have long standing bugs in them which hardcode XFree86. In order to fix such problems, the application needs to be updated to query the X server for the xkbrules filename, and not hard code a specific X11 implementation. Fixing that is generally simple for open source applications, however it can be difficult to impossible for applications to which the source is not available. If this situation arises, there is a hackish workaround that you can try which may or may not work, which is to add a "xfree86" symlink in the xkbrules directory on your FC2 machine which points to the "xorg" xkbrules file. That alone may work around the buggy application, but if it does not, you may need to then reconfigure the X server to override the XkbRules file, by putting the Option "XkbRules" "xfree86" line back in the config file and restarting the X server. That may or may not help work around the buggy application. If the problem still persists, the buggy application will need to be recoded to query the X server properly by using the Xkb extension. If the application is part of a Red Hat OS distribution, please feel free to file a bug against that component in our bugzilla, and CC me on it, and I'll do what I can to assist the package owner in fixing the problem. As an additional note, the xkbrules file is now named "base" in the modularized upstream "xkbdesc" project. Any applications out there which still hard code "xfree86" and/or "xorg" will break again when the new xkbdesc is integrated into the distribution. If you know of applications which have worked around the first renaming by hard coding both filenames, please file bug reports in Red Hat bugzilla against these applications also and/or contact the upstream developers. That way we can all ensure all applications are doing this the right way far into the future, and will work with a variety of X11 implementations. Thanks.
previously reported http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125722 IMOH, my test report a failure from xorg-x11 let looks at output from cli, $ setxkbmap -v -layout ca_enhanced result are OK, means keyboard has the correct Kb layout. check is the slash key, left of the right shift key is now é, e with acute acccent. others key êûôîçèù work has expected. $ setxkbmap -v -layout us result are OK ============= this is the first misbehavior $ setxkbmap -v -layout "us,ca_enhanced" Error loading new keyboard description from previous $ setxkbmap -v -layout ca_enhanced we have line, symbols: en_US(pc105)+ca_enhanced now we have symbols: pc/pc(pc105)+pc/us+pc/ca_enhanced:2 ^ --------------------------------/ the added "pc/" from rules is wrong ==================== following cli has let me beleiving that $ setxkbmap -print -layout "us,ca_enhanced" \ | xkbcomp -xkb -o tata.xkb - Error: Can't find file "pc/ca_enhanced" for symbols include Exiting Abandoning symbols file "(null)" Error: symbols not defined in XkbWriteXKBSymbols Output file "tata.xkb" removed ======================= command that was previously failing, now succeed $ setxkbmap -print -layout "us,de" \ | xkbcomp - $DISPLAY
segg: The problem you're reporting is unrelated to the one this bug is filed about, however it is known that the ca_enhanced keyboard layout is incompatible with being used in multi-keyboard setups. Ivan Pascal the XKB maintainer has explained this in greater detail in another bug report somewhere although I don't have the number handy. You may wish to query both Red Hat and freedesktop.org bugzilla for "ca_enhanced", as that'll probably find the bug report which describes why ca_enhanced may not be used with other keyboard layouts. Hope this helps.
segg: Ah, just after I posted comment #108, I just noticed an update to the original bug you filed. I incorrectly marked your bug as a duplicate of this one it seems. Sorry about the confusion. Sergei's comment in bug #125722 that you filed was what I was referring to above. I'll follow up in bug #125722 for that issue.
In answer to comment #103 from Mike A. Harris: Its a kind of testing-production-enviroment. I am running a Linux network built around FC clients and an (old) Debian file/login-server for my school - the most obivious choise of distro in Norway would be "skolelinux", not redhat, but it would be to much of a job of putting it up as a test system on the same LAN as the windows-computers. If management decides to drop Windows and go with Linux instead, Debian-based Skolelinux will probably be the distro of choice, as most other linux-driven norwegian schools use this system. Sorry. Contact me directly for more info/discussion. Good that the bug got fixed - as far as i can see, it would also cause problems with HW X-clients (for the lucky ones that got one (or more) of those), LSTP, etc etc etc.
I am experiencing the same problem as Marty in #88. A freshly installed FC2 with all the updates and I am receiving the XKB error, output of xprop is the same, no output from the gconftool-2 command, and every non-root user receives the black background and no bluecurve icons, and no menu icons. i have read carefully the Comment #106 and all is ok. Nevertheless i still got the message. how can i know which application is generating this message?
well i have installed control-center-2.6.1-3 and it doesn't fixed the problem
Happened to me in FC3 when choosing romanian keyboard in xorg.conf and romanian keyboard in Gnome Preferences. Solved by deleting .gonf/desktop/gnome/peripherals/keyboard