On Wed, Jan 28, at 08:40 Dan Nicholson wrote: > On Wed, Jan 28, 2009 at 6:15 AM, Agathoklis D. Hatzimanikas > <[email protected]> wrote: > > > > The third one was the famous error "couldn't find default font fixed", > > and although I've done all the usual steps, I wasn't able to fix this, > > so I just cheated and by blatantly copied the fonts from an old working > > system I was able to continue. I don't know exactly the reason for this > > failure, both the "font-alias" and "bdftopcf" packages was installed > > properly with no error. > > This one is tough because there are a lot of ways it can fail. If > copying old fonts into the same path that was giving you problems > works, then that probably means that something in the font toolchain > was broken during the installation. That usually means bdftopcf, > mkfontdir or mkfontscale. I think you want to have font-alias and > encodings installed before you start installing any fonts since > mkfontdir/mkfontscale operate on them. One thing to keep in mind is > that you have to run mkfontdir/mkfontscale post-install if you're > using a DESTDIR. >
Oh yes, I think that is, it's probably a DESTDIR thing, as it was my first installation using DESTDIR. > > The fourth is basically the reason for this email, so the solution can be > > archived for reference to people with the same problem. > > > > > > Now, when I've tried to log in X, my computer just locked. I couldn't > > use the mouse, I couldn't use the keyboard to switch to virtual consoles, > > so basically it left nothing else other than a hard reset (after years > > without one, that was an unpleasant experience). > > The graphics locked, too, or just the input devices stopped > responding? Usually if the computer locked, it's the graphics device > getting wedged. Can you ssh in from another machine while this is > happening? What chipset are you using? Can you post an Xorg.log from > when this happened? > It was just the input devices. I am able to ssh from another machine and that's how I killed X and went back to a virtual console. For your information here is a relevant part from a working X: X.Org X Server 1.5.3 Release Date: 5 November 2008 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.27.6 i686 Current Operating System: Linux AH 2.6.27.6 #3 SMP Wed Nov 19 08:30:17 EET 2008 i686 Build Date: 27 January 2009 11:48:14PM ... (==) Log file: "/var/log/Xorg.0.log", Time: Wed Jan 28 19:38:36 2009 (==) Using config file: "/usr/lib/X11/xorg.conf" (==) ServerLayout "Layout0" (**) |-->Screen "Screen0" (0) (**) | |-->Monitor "Monitor0" (**) | |-->Device "NVIDIA Corporation NV40 [GeForce 6200 TurboCache]" (**) |-->Input Device "Keyboard0" (**) |-->Input Device "Mouse0" (**) Option "AllowEmptyInput" "false" (==) Automatically adding devices (==) Automatically enabling devices And here what is logged after commented out the option and starting xorg with "-logverbose 10" (WW) AllowEmptyInput is on, devices using drivers 'kbd' or 'mouse' will be disabled. (WW) Disabling Keyboard0 (WW) Disabling Mouse0 > > > > As I understand it, this is actually a feature. > > I think (not sure) Xorg uses Hal for (keyboard and mouse) auto detection. > > But as I didn't have Hal installed that (feature) transformed into a bug. > > > > This also happened even if I explicitly passed to the "xorg server" > > configure > > options the "--disable-config-hal" switch, plus also configure doesn't > > find hal in $PATH, see: > > > > Checking for HAL... no > > I haven't looked at the logic in a while, but I think that if the HAL > config is not built, then the AllowEmptyInput setting shouldn't > matter. I could be wrong on that, though, and there have certainly > been recent commits to get this to work correctly more often. > I will be happy to check, maybe at the weekend a recent server snapshot. > Another thing to consider is to just use evdev even for xorg.conf > devices. There are very few devices left on Linux that don't work > correctly with evdev. > > > If I am right and I haven't done any mistake other than I don't want to > > use Hal, is it possible over in Xorg, to do something to prevent this from > > happening? Maybe a conditional check that could raise even a fatal error? > > For me that would be acceptable; I'd rather have one than to have locked > > from using the computer at all. > > Although a non-HAL xorg is becoming more rare, that configuration > should be supported. There may be bugs in the logic on how to decide > whether devices from xorg.conf are honored. This is xorg-server-1.5.3, > right? Yes 1.5.3. And another thing that I've remembered. As I am a multi language environment I just don't know how I suppose to change keyboard layout (see Xkboptions and XkbLayout), when in fact Xorg (if I got it right) ignores the InputDevices sections. > > > Additionally a little more generosity in verbosity would me more than > > welcomed, so users can spot more easily these kind of problems, a "big > > fat warning" or something like that. > > You can run Xorg with -logverbose N where N sets the verbosity level > from 1-10. The default is 3. I don't know if this will be really > informative for input devices, though. > Thanks, I knew about this switch, but if a mis-configured xorg.conf or a missing dependency can result in such a lock out, I would like - as a plain user - to be informed with some more verbosity than usual, especially if it was (like this case) during a transition from another subsystem to another. And there it is. It seems that many more people were locked out the same way, since I just tested the "x-setup" page and I see a small paragraph about the same issue - must be DJ that updated the page but it seems I lost it - Regards, Ag. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
