Best of Technical Support

I would like to know how best to synchronize the clocks of the various Linux boxes (various kernels and distributions) on my LAN. —John Morley, jmorley@grafton.demon.co.uk

You should try NTP: www.eecis.udel.edu/~ntp. NTP software is included in common Linux distributions such as Red Hat. —Pierre Ficheux, pficheux@com1.fr

I personally run rdate from my computer's crontab. This gives me an accuracy within one second, which is satisfactory for normal interactive use of the net.—Alessandro Rubini, rubini@prosa.it

This is definitely a useful thing to do wherever you have more than one server, but there are many ways to accomplish it. The most common is to use the timed daemon. Read the man page of the daemon for a detailed description of how to use it. FYI, there are other programs you can download that will do the same job with slightly different features, but since timed is present on almost all modern UNIX systems, it's the best place to start. —Chad Robinson, chadr@brt.com

I am using SuSE Linux 6.1. I defined a new kernel configuration (using make xconfig). If I enable “modules” support, my mouse does not operate. Using exactly the same configuration but creating “monolithic” kernel (meaning that I changed all m's into y's) works fine. I spent a lot of time on this problem and got no results. Do you have any ideas? —Mark Shahaf, mshahaf@ibm.net

You likely have a problem with module autoloading. Try loading the module for your mouse by hand: modprobe psaux for example. Also, if the problem affects only your mouse, you can use modules but compile it in the kernel. Since you probably use the mouse all the time and the code isn't too big, you might as well compile it in the kernel. —Marc Merlin, merlin@varesearch.com

If the mouse driver is compiled as a module, you should load the module in order to be able to use the mouse. Try insmod psaux (or insmod serial if it is a serial mouse), or configure kmod to load it automatically. —Alessandro Rubini, rubini@prosa.it

I am running Red Hat Linux 6.0. If I run in full multiuser mode (by setting the run level in the inittab file to 3), I can execute startx - -bpp 32 and have all the necessary colors displayed. However, if I change the run level from 3 to 5 in the inittab file to run X11 automatically, I receive the following results when I try to load some GUI applications:

Warning: Cannot allocate colormap entry for "gray71"
Warning: Cannot allocate colormap entry for "AntiqueWhite3"
Warning: Cannot allocate colormap entry for "AntiqueWhite2"
...

This happens even though I have already modified the last line in the /etc/X11/xdm/Xservers as follows:

:0 local /usr/X11R6/bin/X -bpp 32

This is exactly what you are supposed to do if you use xdm. However, if you use gdm (the default in Red Hat 6.0), you now need to edit /etc/X11/gdm/gdm.conf. You will find this section:

[servers]
0=/usr/bin/X11/X

Just add your -bpp 32 there. —Marc Merlin, merlin@varesearch.com

When I type startx as a regular user, after the initialization of card, I receive this response:

X11TransSocketUNIXConnect : Can't connect: errno = 111
giving up
xinit: Connection refused(errno 111) unable to connect to X server
xinit: no such process(errno 3) server error
X11TransSocketUNIXConnect : Can't connect: errno = 111

I am running XF86 3.3.3.1-49. I found this very same post in the magazine I get; however, mine is a bit odd. I can run X as root with no problem. I have permissions set for all users to execute X, but things aren't going that way.

On another note, I downloaded the bz2 package of 2.2.10 and installed it. I added support for the /proc file system, for my Linux box to act mainly as a router, for forwarding, firewalling, masquerading and the extra networking goodies. However, when I rebooted, I had no /sys subdirectory under /proc. I do have the /proc directory tree, though. I can start the firewall with no problem and pass arguments to ipchains. When I run uname -a, I get this output:

Linux digitalklown.net 2.2.10 #1 Mon Jul 26 21:17:02 CDT 1999 i586 unknown
running rh6.0

—Jason Helfman, deklown@digitalklown.net

The reason you don't have /proc/sys is that you forgot to add sysctl support in the General setup section of the kernel configuration. When you face unknown problems like this, your best bet is to make sure your 2.2.10 tree is clean by typing make distclean (this will erase your .config file which contains all the compilation options you chose, so if your current copy is there, save it first). If you do have a .config file, now you can copy it into your 2.2.10 tree and build your kernel with the usual make clean (although useless here, since we just did make distclean); make dep; make install; make modules; make modules_install. If you do not have a .config you can get the .config Red Hat used for their kernel by installing the kernel sources by going to /usr/src/linux-version and typing make oldconfig. This will generate a .config in the same directory, and you'll be able to move it to your new 2.2.10 tree.

Following the above procedure should insure that you have a sane set of options selected in your kernel and that the kernel you end up with is built correctly. —Marc Merlin, merlin@varesearch.com

With startx, you fire both the X server and a set of default clients. The errors you report are the clients' errors, which show that the server is not running. You should look earlier on your screen to find why the server failed.

If the server is actually running, then you may have authorization problems. Please check whether your xauth setup is wrong or other authorization means are running and misconfigured. The /proc/sys tree is part of the sysctl implementation. If you didn't enable sysctl when configuring the kernel, no such tree is there. —Alessandro Rubini, rubini@prosa.it