I updated F14 system yesterday, installed SCD just now: [init 3]# system-config-display File "/usr/share/system-config-display/xconf.py", line 27, in <module> import xf86config File "/usr/lib/python2.7/site-packages/xf86config.py", line 1, in <module> import ixf86config ImportError: /usr/lib/python2.7/site-packages/ixf86configmodule.so: undefined symbol: xstrtokenize From devel mailing list: "looks like /usr/lib{64}/python2.7/site-packages/ixf86configmodule.so was linked incorrectly"
see bug #624297
*** Bug 627720 has been marked as a duplicate of this bug. ***
*** Bug 624297 has been marked as a duplicate of this bug. ***
*** Bug 634890 has been marked as a duplicate of this bug. ***
624297 has the best details on this. I think upstream http://www.mail-archive.com/xorg-devel@lists.x.org/msg05237.html was the initial cause of all this; as Sandro says in 624297: "It seems an error in xorg-server packaging: xstrtokenize is declared as extern in <xorg/misc.h> and the binary containing its implementation is libos.la that is not installed by the Makefile. Whoever use xstrtokenize from misc.h will have thise undefined symbol." Proposing as nth for F14 as this affects rather a lot of things, including system-config-keyboard according to https://bugzilla.redhat.com/show_bug.cgi?id=634890 . It breaks system-config-display and the related tools in Fusion which implement various out-of-tree drivers, which is something a lot of users rely on. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Maybe here is the solution: http://lists.x.org/archives/xorg-devel/2010-April/006905.html
Ajax proposed: http://fpaste.org/wwa3/raw/ I'm doing a build to test this atm. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
ajax's fix works. I then hit a subsequent problem in pyxf86config but that's separate, will file it separately. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
so, just to be clear - ajax, if you could apply the fix for this to the next X server update that'd be great, and we can tackle the next one separately. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Any news from ajax?
This was discussed at the 2010-10-01 blocker / NTH review meeting, and accepted as a nice-to-have.
Does someone have a patched src.rpm or something similar to share. It would be quite nice to have this problem solved. It would be great if the patch would make it into the repos until f14 is released. I mean since it is already there...
the patch doesn't really entirely fix the issue. if you use it, you hit https://bugzilla.redhat.com/show_bug.cgi?id=638656 . -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Suse seems to have a patch for xstrtokenize here: https://build.opensuse.org/package/view_file?file=xorg-server-option_libxf86config.diff&package=xorg-x11-server&project=X11%3AXOrg&srcmd5=f02a02762aac73adcabc199850587890 that avoid to include utils.c.
I've tested the Suse patch and it works for me, solving this and bug #638656.
Mmm, while just importing xf86config in python seems to work fine without any missing symbol, it seems that something goes wrong while reading the xorg.conf file. nvidia-config-display segfault calling xf86getToken () from /usr/lib/python2.7/site-packages/ixf86configmodule.so.
I'm trying also to patch xorg-x11-server-1.9.1-2.fc14.src.rpm with xorg-server-option_libxf86config.diff from suse, but i get the same old error xstrtokenize message if i try to start livna-config display. Is this the patch file what you mean? Or did you use a other one?
Ditto here, both system-config-display and nvidia-config-display segfault with the above patch. Sandro...do you have xorg.conf file?
Created attachment 455689 [details] xorg.conf for testing xf86config (In reply to comment #19) > Sandro...do you have xorg.conf file? Yes, I've just attached it.
Removing F14 NTH status as F14 is now out. Remaining open nice-to-have issues do NOT automatically become nice-to-have issues for Fedora 15. If you believe a Fedora 14 issue which was accepted as nice-to-have but not resolved in time for release should also qualify for nice-to-have status for Fedora 15, please re-propose it as nice-to-have for Fedora 15. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I'm seeing this error after an upgrade to F14. nvidia-xconfig did work and helped to create a functional xorg.conf.
I see the same problem running F14 with intel graphics driver.
Package: xorg-x11-drv-nvidia-1:260.19.12-3.fc14 Latest Crash: Wed 03 Nov 2010 06:11:44 PM Command: /usr/bin/python -tt /usr/sbin/nvidia-config-display Reason: xf86config.py:1:<module>:ImportError: /usr/lib64/python2.7/site-packages/ixf86configmodule.so: undefined symbol: xstrtokenize Comment: got the <<< Checking for module nvidia.ko: [ OK ] Enabling the nvidia driver: Traceback (most recent call last): File "/usr/sbin/nvidia-config-display", line 28, in <module> import livnaConfigDisplay.ConfigDisplay File "/usr/lib/python2.7/site-packages/livnaConfigDisplay/ConfigDisplay.py", line 29, in <module> import xf86config File "/usr/lib64/python2.7/site-packages/xf86config.py", line 1, in <module> import ixf86config ImportError: /usr/lib64/python2.7/site-packages/ixf86configmodule.so: undefined symbol: xstrtokenize [FAILED] >>> message on first boot after upgrade from fedora 13 read bugzilla messages - ran nvidia-xconfig without problem (made small changes in h and v refresh) ran nvidia-config-display to see what would happen and it crashed. previous Fedora 13 xorg.conf was made correctly by nvidia-config-display system seemed ok on boot except for the boot message above just wanted to add this to Bug 623742 if it is useful info... sorry if it is useless crap... the system info didn't transmit to bugzilla because it is an nvidia driver
Some solution to fix it is here https://bugzilla.rpmfusion.org/show_bug.cgi?id=1469 or your can use fixed xorg-*-nvidia rpms from here: http://mirror.yandex.ru/fedora/russianfedora/russianfedora/nonfree/fedora/releases/14/Everything/i386/os/
Is any Red Hat / Fedora X developers actively working on this? It's been listed as NEW for quite some time.
(In reply to comment #25) > Some solution to fix it is here > https://bugzilla.rpmfusion.org/show_bug.cgi?id=1469 > > or your can use fixed xorg-*-nvidia rpms from here: > > http://mirror.yandex.ru/fedora/russianfedora/russianfedora/nonfree/fedora/releases/14/Everything/i386/os/ Add, please, at your site http://russianfedora.ru links to your repos and gpg-key. It will be more convenient. I find some info in http://otvety.google.ru/otvety/thread?tid=689a0bd812ec1413
(In reply to comment #25) > Some solution to fix it is here > https://bugzilla.rpmfusion.org/show_bug.cgi?id=1469 > > or your can use fixed xorg-*-nvidia rpms from here: > > http://mirror.yandex.ru/fedora/russianfedora/russianfedora/nonfree/fedora/releases/14/Everything/i386/os/ I add russianfedora repos: su -c 'rpm -Uvh http://mirror.yandex.ru/fedora/russianfedora/russianfedora/free/fedora/releases/14/Everything/x86_64/os/russianfedora-free-release-14-1.noarch.rpm' su -c 'rpm -Uvh http://mirror.yandex.ru/fedora/russianfedora/russianfedora/nonfree/fedora/releases/14/Everything/x86_64/os/russianfedora-nonfree-release-14-1.noarch.rpm' russianfedora-nonfree depend from russianfedora-free. yum update xorg-*-nvidia - by yumex. These fixed for me. uname -r -> 2.6.35.6-48.fc14.x86_64
Unfortunately - I have intel based graphic card so you fix cannot by applied. But thx fo suggestion (for others). (In reply to comment #28) > (In reply to comment #25) > > Some solution to fix it is here > > https://bugzilla.rpmfusion.org/show_bug.cgi?id=1469 > > > > or your can use fixed xorg-*-nvidia rpms from here: > > > > http://mirror.yandex.ru/fedora/russianfedora/russianfedora/nonfree/fedora/releases/14/Everything/i386/os/ > > I add russianfedora repos: > > su -c 'rpm -Uvh > http://mirror.yandex.ru/fedora/russianfedora/russianfedora/free/fedora/releases/14/Everything/x86_64/os/russianfedora-free-release-14-1.noarch.rpm' > > su -c 'rpm -Uvh > http://mirror.yandex.ru/fedora/russianfedora/russianfedora/nonfree/fedora/releases/14/Everything/x86_64/os/russianfedora-nonfree-release-14-1.noarch.rpm' > > russianfedora-nonfree depend from russianfedora-free. > > yum update xorg-*-nvidia - by yumex. > > These fixed for me. uname -r -> 2.6.35.6-48.fc14.x86_64
Minnikhanov Thanks! it worked!!!! By the way if you just installed a fresh OS, you can just add the repos first and then type yum install kmod-nvidia Thats it. Thanks!!
Ok there is a problem. everytime i reboot the display changes to 1024x768 and i have to use the nvidia tool to set it to automatic (1920x1080) I modified the xorg.conf file but it gets modified upon reboot. BAD!!!! Common cant someone solve this bug!!!! Its really irritating!
(In reply to comment #31) > Ok there is a problem. everytime i reboot the display changes to 1024x768 and i > have to use the nvidia tool to set it to automatic (1920x1080) > I modified the xorg.conf file but it gets modified upon reboot. BAD!!!! Common > cant someone solve this bug!!!! Its really irritating! Are you changing xorg.conf manually or from nvidia-settings?, Do not forget the button "Save to X configuration file" in nvidia-settings...
Both ways. In fact when i type service nvidia restart, it reverts back to the original.
(In reply to comment #31) > Ok there is a problem. everytime i reboot the display changes to 1024x768 and i > have to use the nvidia tool to set it to automatic (1920x1080) > I modified the xorg.conf file but it gets modified upon reboot. BAD!!!! Common > cant someone solve this bug!!!! Its really irritating! Yes, nvidia rc.d script will rewrite xorg.conf to default every start. Your should disable start nvidia service if your are modified xorg.conf. /sbin/chkconfig nvidia --del I will try to do something to fix this bug.
arkady: see my suggestion on RPM Fusion bugzilla. You don't need to overwrite xorg.conf . You just need to put a snippet in /etc/X11/xorg.conf.d , which only needs to specify the driver and modules stuff. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
MAS: "Is any Red Hat / Fedora X developers actively working on this? It's been listed as NEW for quite some time." not particularly, no. It doesn't really affect anything in Fedora any more, now s-c-d has been orphaned. It's ajax's area, but he really isn't very excited about working on this code. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
arkady: now I come to think of it, though, the 'disable' operation probably does need to touch xorg.conf as nvidia-xsettings may have written to it :/ -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #37) > arkady: now I come to think of it, though, the 'disable' operation probably > does need to touch xorg.conf as nvidia-xsettings may have written to it :/ > > > > -- > Fedora Bugzappers volunteer triage team > https://fedoraproject.org/wiki/BugZappers Yes, Your are right. And I already fix this in last build in russianfedora repo. Now if xorg.conf is present nvidia-config-setting does not recreate it. So your can modify xorg.conf.
hannes give me the link in the german fedora forum. Try this xorg-x11-drv-nvidia.src.rpm from rpmfusion fc15 and rebuild it for fc14. http://buildsys.rpmfusion.org/plague-results/fedora-development-rpmfusion_nonfree/xorg-x11-drv-nvidia/260.19.12-4.fc15/SRPM/ This one works pefect without /etc/rc.d/init/nvidia and livna-config-display. I've tested it. He ajax, how much presure do you need? Min 40% of fedora users are using the prob. nvidia driver. Pls change the xorg-server.
Hi! I get the same problem, is there a solution, I just can't find out! Can anybody explain to newbies how is it possible to get fixed this problem? No 3d programs or games work with this problem, please help me! Boot message: ........ Checking for module nvidia.ko: [ OK ] Enabling the nvidia driver: Traceback (most recent call last): File "/usr/sbin/nvidia-config-display", line 28, in <module> import livnaConfigDisplay.ConfigDisplay File "/usr/lib/python2.7/site-packages/livnaConfigDisplay/ConfigDisplay.py", line 29, in <module> import xf86config File "/usr/lib/python2.7/site-packages/xf86config.py", line 1, in <module> import ixf86config ImportError: /usr/lib/python2.7/site-packages/ixf86configmodule.so: undefined symbol: xstrtokenize [FALLITO] ..................
(In reply to comment #28) > (In reply to comment #25) > > Some solution to fix it is here > > https://bugzilla.rpmfusion.org/show_bug.cgi?id=1469 > > > > or your can use fixed xorg-*-nvidia rpms from here: > > > > http://mirror.yandex.ru/fedora/russianfedora/russianfedora/nonfree/fedora/releases/14/Everything/i386/os/ > > I add russianfedora repos: > > su -c 'rpm -Uvh > http://mirror.yandex.ru/fedora/russianfedora/russianfedora/free/fedora/releases/14/Everything/x86_64/os/russianfedora-free-release-14-1.noarch.rpm' > > su -c 'rpm -Uvh > http://mirror.yandex.ru/fedora/russianfedora/russianfedora/nonfree/fedora/releases/14/Everything/x86_64/os/russianfedora-nonfree-release-14-1.noarch.rpm' > > russianfedora-nonfree depend from russianfedora-free. > > yum update xorg-*-nvidia - by yumex. > > These fixed for me. uname -r -> 2.6.35.6-48.fc14.x86_64 Thank You, this worked for me. I am in the USA and I was wondering if adding these repositories will effect other packages during updates. Should they (the Russian repositories) be disabled after the patch is complete? Does it matter?
*** This bug has been marked as a duplicate of bug 624297 ***
Felix as reporter or a developer, could please reopen this? and mark bug #624297 as duplicate of this one? Maybe here we are loosing focus on the bug: it's not nvidia-* that is broken. It's xorg-x11-server-devel. Any fix in any other package is only a workaround for this bug. Xorg people doesn't seems too happy about any other program except xorg server linking against libxf86config.a. However, every program that include /usr/include/xorg/misc.h will be affected. In bug #624297 Lubomir say that pyxf86config is fixed. Wonderfull, everything that include pyxf86config will work. The rest still remains broken. This bug is not closed for me and the solution of #624297 is not a valid solution for this bug.
seems not to be fixed in the x86_64 repo. I just updated to F14 and it does not work.
the fix has not been submitted as an update. you need to get it from koji. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Russian Fedora repo solution doesn't work for me. The nvidia driver loads but the screen stays black.
teoman: don't use that, it's a hack with problems. Use the fixed pyxf86config from the other bug. That fixes the problem properly. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I agree with Sandro in comment #43 that we should leave this bug open to track the underlying problem of X not providing the function correctly. Providing the function directly in pyxf86config is a good workaround for pyxf86config, but does not fix any cases of any *other* library using xstrtokenize. So, re-opening. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
For those following this bug because of the consequences for pyxf86config and hence livna-config-display, nvidia-config-display, psb-config-display in Fusion - even though this bug remains open, the fix for #624297 will fix all those cases; please subscribe to that bug, install the test update for pyxf86config when it becomes available, and follow up on that fix in that bug. This bug is for the underlying issue of X server not providing the function. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Yesterday I made update via yum update command using updates repo. Installing updated pyxf86config resolved my issue.
the last update has resolved the problem for me, thank you for this great job ;-)
(In reply to comment #51) > Yesterday I made update via yum update command using updates repo. Installing > updated pyxf86config resolved my issue. (In reply to comment #52) > the last update has resolved the problem for me, thank you for this great job > ;-) Please see Adam's comment 49. The pyxf86config bug is <a href="https://bugzilla.redhat.com/show_bug.cgi?id=624297">bug 624297</a>.
Yup, the last update fixed the issue for me too. Thanks, finally i can play with blender in F14! :)
Reporter can you confirm that this has been fixed, please? Thank you
Matej: see comment 48 and comment 49.
I just updated a different F14 system (using mga) from that used for comment 0 and neither yum nor a root shell nor me at http://mirrors.kernel.org/fedora/releases/14/Everything/i386/os/Packages/ can find anything resembling system-config-display. :-(
felix: system-config-display is orphaned for f14. most people hitting this are using one of its derivatives which still exists in rpm fusion - there's the generic livna-config-display , and nvidia-config-display , fglrx-config-display and psb-config-display for the various proprietary drivers in fusion, which are used in those driver packages to ensure the drivers are configured. THIS bug, as stated above, is for the underlying problem of X.org not providing xstrtokenize, which is still valid. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I recommend mass-unsubscribing everyone with a note telling them to resubscribe if they actually care about the X server bug. People are *not* reading comments!
We no longer ship pyxf86config in F17+, so I don't plan to ever fix this.