Upgrading Xorg 6.9 to 7.1
With the release of Debian 4.0 (Etch), Xorg version 7.1 has been included. This is a major change in the packaging from the previous versions (XFree86 of any version and Xorg versions 6.x), and is therefore a complex upgrade which pushes the limits of apt and causes various problems for users. The XStrikeForce is working through the bugs, but in the meantime this page is here to help users out with the transition. Here are some of the more common problems and how to solve them.
Please be sure that bugs are submitted to the BTS before reporting them here. The XStrikeForce needs to know about them in order to solve them. The goal is not to send users to this page, but to make sure that the upgrades are as clean as possible.
Upgrading Xorg 6.9 to 7.1
- x11-common installation
- User is not authorized to start x server
- Missing xserver-xorg
- Missing Drivers
- Can't Load Modules
- DRI with i810
- NVIDIA binary drivers from nvidia.com web site (the .run file)
- ati binary drivers (on x86/amd64)
- The /usr/X11R6 directory
- Ctrl-Alt-Function keys not working
- Key press does a resolution switch
- Missing fonts
- Missing CID font support and '/usr/bin/mkcfm'
- Failed swiss german keyboard configuration migration
- See Also
The meta-package xorg is the new metapackage for X. The previous metapackages x-window-system and x-window-system-core are now transitional packages, both of which only depend on this package, and they will go away following the etch release. It is highly recommended that most users install this package in order to ensure that they have a full functional X system. For example, to install using aptitude:
aptitude install xorg
The x11-common package is required to be successfully installed before any of the other X11R7 packages are installed. The reason for this is that it is responsible for moving directories around so that they're in the new -- FHS-compliant -- format.
The biggest problem with this is that the /usr/X11R6/bin directory must become a symlink to /usr/bin, where all the Xorg binaries are now stored. Because no one likes to have their programs deleted out from under them, the installation of x11-common will fail if it tries to remove this directory and fails. x11-common currently conflicts with packages in Debian that are known to install anything to /usr/X11R6/bin, so that the directory can be automatically cleared as well as possible before attempting installation. (If you find a package in Debian that installs to /usr/X11R6/bin, but x11-common doesn't conflict with it, please file a bug report against x11-common!) Despite this safety measure, several unofficial packages or programs, (including some versions of opera and fglrx), can install software to this directory. Because x11-common does not conflict with these packages (it would not be feasible to add a conflict against every single unofficial package ever created), its installation will fail.
The workaround for this is that if you have left-over items hanging around /usr/X11R6/bin, simply move them to a temporary location (or even to /usr/bin, where /usr/X11R6/bin will eventually point) until x11-common has successfully installed and made /usr/X11R6/bin in to a symlink. Then simply move them back once x11-common has installed successfully. This will prevent many common errors with the installation, and it provides you with the full knowledge of what's going on with your system. Forcing the installation of x11-common has been shown to cause the expected breakages, so it's highly recommended that you use this workaround instead.
The above workaround does not work if the files in /usr/X11R6/bin are from installed packages. dpkg does not know that you have moved the files (or care); it sees a file conflict and gives up, de-configuring x11-common and things rapidly go pear-shaped from there as described in #371161. Instead of (re)moving files, if the files are provided by a package you have no option but removing the package. -- JoeyHess
User is not authorized to start x server
Users that upgrade from sarge have reported the x11-common fails to create a /etc/X11/Xwrapper.config, this results in non-root users try to start x getting the error "User is not authorized..." the temporary solution is to run "dpkg-reconfigure x11-common".
Some people have reported that xserver-xorg is removed upon upgrade. While this issue is being worked out, if your X server mysteriously refuses to start, be sure to check to see that this package is actually installed.
Check your /etc/apt/sources.list and make sure you have
deb http://ftp.debian.org/debian unstable main contrib
listed. The old http://amd64.debian.net/debian-pure64/ repositories are obsolete and is one possible reason that some people are reporting that xserver-xorg is removed on the dist-upgrade. Do *NOT* do the upgrade if xserver-xorg is going to be removed as part of the upgrade or you will not be able to start KDM/X afterwards.
(EE) No Input driver matching `$foo'
Now that all the drivers are packaged separately, you may need to install some extra packages. The simplest way to do this is to install the xserver-xorg-video-all and xserver-xorg-input-all packages or the xorg metapackage. Alternately, when you get the above message, look for a package named like xserver-xorg*foo. You will almost definitely need to install:
And you are likely to need to install a xserver-xorg-video-foo driver for your video card.
Can't Load Modules
Errors about not being able to load modules (most notably glcore) can be fixed by removing the line to load them from your xorg.conf. This can be done automatically for non-customized config files by running dpkg-reconfigure xserver-xorg as root.
If the gdm display manager does not start the X server, make sure that /etc/gdm/gdm.conf contains the line command=/usr/bin/Xorg -audit 0 instead of command=/usr/X11R6/bin/X -audit 0 in the [server-Standard] section.
It is possible to manually fix /usr/share/gdm/defaults.conf and /usr/share/gdm/factory-defaults.conf, if they still contain the wrong path and your X-server does not start - this is not intended, but possible as easy quick'n'dirty fix. This issue is also known as bug 362925 and bug 363160.
You may want to edit /etc/X11/wdm/Xservers to update the server path from /usr/bin/X11/X to /usr/bin/Xorg
DRI with i810
libmesa stops working after upgrade to X11R7 with i810 driver (and maybe some others). The i810 driver is too new for mesa. It is necessary to download new drivers from http://dri.freedesktop.org/snapshots/ and copy *_dri.so files to /usr/lib/dri/. This is bug 359328.
Upgrading the mesa stuff to the version in experimental will also work. -- JoeyHess
NVIDIA binary drivers from nvidia.com web site (the .run file)
If installing the original nvidia drivers from the nvidia.com drivers download page with the official driver script, execute the installer with the --x-module-path=/usr/lib/xorg/modules/ option. Otherwise not only will the driver itself be installed in /usr/X11R6/lib64/modules/drivers or /usr/X11R6/lib/modules/drivers, but the OpenGL libraries might also not work.
Update: for the newer drivers (at least for the Linux IA32 driver version 1.0-8774), this option does not seem to be necessary anymore. Instead, the packages xserver-xorg-dev and pkg-config need to be installed, otherwise the installer will give warnings that it is unable to determine the correct installation paths and it will ask you to install the XOrg SDK/development package. This can be done using
aptitude install pkg-config xserver-xorg-dev
ati binary drivers (on x86/amd64)
The ati drivers were broken, but are fixed now. The Debian packages in non-free should work ok, see AtiHowTo.
If 'startkde' refuses to load, copy /usr/lib/X11/xinit/xinitrc to ~/.xinitrc and open it in your favourite text editor; remove anything under the line # start some nice programs and add exec startkde &. Running 'startx' will give you your KDE back.
The /usr/X11R6 directory
Since everything under /usr/X11R6 has been moved out, the directory itself is no longer used nor pertinant to the system, save for the problems where a workable solution has been found above. Since X.org is X11R7, X11R6 is phased out and thus the naming convention of the directory goes, too. However, there will be no /usr/X11R7 directory. Instead, X.org has pushed for FHS compliance with this release. As such, binaries install to /usr/bin, libraries to /usr/lib, etc. X no longer plays by its own rules, but will instead integrate well with the rest of your file system.
Ctrl-Alt-Function keys not working
If Ctrl-Alt-Function keys stop working, try removing the keyboard variant option from xorg.conf if it's there. (option "XkbVariant") dpkg-reconfigure xserver-xorg and leave the keyboard variant field empty.
If this doesn't work, chvt 1 from a root shell will switch to console 1. However, once the X display is back in view, the key combinations will not work again.
Key press does a resolution switch
Several users reported that their keyboard is unusable because each key press produces a resolution switch. It appears that they have /lib/libX11.so.6 and /lib/libXext.so.6 files (as well as usual symlinks). Removing /lib/libX11.so* and /lib/libXext.so* fixes this problem, but it is not clear yet why these files have been created.
Okay I had two problems: ksplash and kopete segfaulted at startup and the keys produced a switch of resolution. I solved them both by apt-get remove nxserver nxnode nxclient, after I found out, that ksplash crashes, because it tried to use /usr/NX/lib/libpng12.so or similar. I also don't have the files in /lib/
<Bert Vorenholt> In my case, I was missing the XKeysymDB file in /usr/share/X11/ (X11R6 location was /usr/X11R6/lib/X11/) which is part of the libx11-6 package. I just reïnstalled it with "apt-get install --reinstall libx11-6". All is working fine now. </Bert Vorenholt>
Same problem, but other reason: Missing XKeysymDB file, because the path in /etc/profile was not updated. So change manually old entry "XKEYSYMDB=/usr/X11R6/lib/X11/XKeysymDB" to "XKEYSYMDB=/usr/share/X11/XKeysymDB". Once you do this you can also change the entry of "XNLSPATH=/usr/X11R6/lib/X11/nls", if it is in the profile.
If X reports missing fonts ("fixed" for example) when trying to start the x server, try purging the xfonts-base package. Note that this will remove all old font configuration from the machine. Use the --force-depends option to remove xfonts-base and all of its dependents (this includes xorg): dpkg --purge --force-depends xfonts-base
In addition, the fonts have moved in order to comply with the FHS. The xserver-xorg package will try to automatically modify your xorg.conf to deal with this, but it will not always work. You'll want to be sure that you have FontPath directives pointing to /usr/share/fonts/X11/misc, /usr/share/fonts/X11/Type1, and updated paths for the other fonts already installed on your system.
Missing CID font support and '/usr/bin/mkcfm'
The program called mkcfm has been removed from source and CID font support (used mostly by Asian languages) of PostScript fonts are removed. If you still have /usr/share/fonts/X11/CID, you may want to remove all the contents with rm -rf /usr/share/fonts/X11/CID.
If running dpkg-reconfigure x-ttcidfont-conf produce error message, this may be the cause.
Failed swiss german keyboard configuration migration
The migration from Sarge's xfree 4.3.0 to Etch's 7.1.0 failed to correctly transport the keyboard layout to the new xorg.conf file (ALT-CTRL-Fx and ALT-Gr among others wouldn't work) (bug 410721). The correct settings are:
Option "XkbLayout" "ch" Option "XkbVariant" "de"