The installation instructions and examples of Chapter 1 only describe installation up to being able to login to the commandline. By this I mean the Linux prompt, which is conceptually the same as the MSDOS prompt. Though, the final installation step, in STEP 8: Running KDE (page xxx), does introduce the installation and running of KDE -- if you got into KDE at that step, fine. Basically, you will be reading this chapter if you have not yet got the system switching into graphics mode and running KDE.
Linux is a two-tier system, just like MSDOS and MSWindows 3.x/95/98. The power-up process first loads MSDOS then Windows. In the days of MSWindows 3.x, the loading process would stop at the MSDOS prompt and the user would then type “win” to load MSWindows. Windows 95/98 still loads MSDOS first, but doesn't stop there, attempting to hide the fact of MSDOSs existence.
The Linux commandline is sometimes referred to as terminal mode, text mode, or character mode, equivalent conceptually to MSDOS (though far more powerful than MSDOS!), while the graphics mode is equivalent to MSWindows. The Linux graphics mode requires that a program called an X server (also called X Windows) be executed, which have client applications. To get an idea of what the X server is, think of it as being the graphics driver, or interface, for applications. The primary client application will be the desktop, such as KDE or Gnome.
There are various X servers available, some commercial and some free. The most famous free one, and used with most Linux distributions, is XFree86. The name seems to imply that it is developed for Intel x86 type of CPUs, which was true originally, but now XFree86 is ported to just about every major CPU.
So, after having got Linux installed to the extent of being able to login to the commandline, there are still two more steps; installing XFree86 then KDE. Getting the X server going properly is often the most difficult part of the install process. Actually, it shouldn't be if your video adaptor card (and chip) is one of those supported by XFree86.
As you have got past the first phase of installation, and able to login, you can have a look at the XFree86 documentation. This is in /usr/X11R6/lib/X11/doc/ and there is a file README that will tell you the version number and what video cards and chipsets are supported. There is also the file README.Config that has useful installation notes, and I recommend that you look through it.
Of course, if you are a complete “newbie” you won't have a clue how to open a text file, not even how to move around in the directory structure. Chapter 3 introduces you to the Linux commandline, and xxx (page xxx) explains how to get going with the vi text editor.
I can show you how to get to the right directory and open a file:
$ cd /usr/X11R6/lib/X11/doc
$ vi README.Config
This presumes you are logged in of course!
In my case study of installing Red Hat 5.2, XFree86 was version 3.3.2, which (curses) did not support my SiS5598 video chip. If you find yourself in that situation, you can do what I did and download the latest version. Go to http://www.xfree86.org/ and find out if the latest version supports your chipset and if so follow the instructions to download and install.
If there is no version of XFree86 that supports your video chipset, then you will have to find an alternative X server or buy another video adaptor card. Or wait for a later version of XFree86. The problem should only arise if you have a very recent video chip or a very exotic and rare one.
You could be very brave (and a masochist) and attempt to configure XFree86 to work with your unsupported card. Some guidelines on this are to be found at the Internet site http://www.uno.edu/~academico/banshee/.
The following sections describe troubleshooting procedures for installing XFree86, following the case study threads introduced in Chapter 1. These are extremely useful to read if you run into a problem with installation, but they are also useful to scan through so that you are forewarned! Knowing about some trouble areas can help you to avoid them.
It is most likely however that XFree86 will install without any trouble whatsoever. With most installations, the base install procedure will already have installed and configured XFree86, so all you have to do is type this:
# startx
Some distributions won't even require that, as you will be taken into graphics mode, i.e., XFree86 and a desktop environment will be executed immediately upon the base installation. In such a situation, you may be presented with a graphical login window immediately upon power-up.
Some distributions will require you to create or edit the text file /etc/X11/XF86Config before you can launch XFree86. This file is introduced in XF86Config (page xxx). You can create this file using the program xf86config*, as described in Section Video configuration with xf86config* (page xxx).
You may find that the video image on your screen is not quite right, maybe truncated on one or more sides, or too small or large. In that case you can fine-tune it using xvidtune*, as described in Section Tune your monitor with xvidtune* (page xxx).
This section continues my story about installing Red Hat 5.2 (with notes on 6.2), as begun in Chapter 1 Installing Red Hat Linux (page xxx) (CASE #1).
See Installation steps (page xxx) for the precise (but generic) steps for installation.
XFree86 was installed along with the rest of Linux, so it should have been a simple exercise to start XFree86 and a graphical desktop:
# startx
The # here is the Linux prompt, though on your system you will have some text preceding it. The # usually indicates that you are logged in as root (or superuser), while a $ indicates that you are logged in as a user.
Please note that this case study does not apply to just Red hat 5.2. It illustrates typical XFree86 install problems and solutions that are applicable to many Linux distributions and versions.
In my Red Hat case study, although I could log into the Linux commandline, typing “startx” to load XFree86 resulted in lines all over the screen. The reason, in a nutshell, is that my Red Hat CDROM has a version of XFree86 which does not support the SiS5598 video chip. This puzzled me, as generic VGA, 640x480 at 16 colours should work on any video card. Even 800x600 at 256 colours is completely standardised and should work on any card.
I fiddled with the XF86Config file, which is located in directory /etc/X11/ -- note that at first I thought it was in /usr/X11R6/lib/X11/ but this is where Unix plays funny games. The XF86Config file in the latter directory is a link to the real one.
For further information on linking, see Chapter 3, Linking files (page xxx).
Hold on a second. What do I mean by “fiddled with”? XF86Config is a text file, and by fiddling I mean that I opened it with a text editor and looked at the file, maybe trying some changes. But you have just got Linux installed, you're a “newbie” and haven't a clue how to run an editor, nor even how to navigate around the directories. You can find information on using the Linux commandline in Chapter 3, but basically you can edit XF86Config by typing this:
# cd /etc/X11
# vi XF86Config
The vi editor is one of the Unix character mode editors, and is somewhat crude compared with the nice graphical interfaces that you are accustomed to.
You can find the basics of how to drive it in Chapter 3, vi text editor (page xxx).
I fiddled for ages, to no avail. Note that the text file XF86Config is created during the install process, after you have made choices about your type of video adaptor card, fonts, dynamically-loadable modules, mouse, keyboard, and monitor. You can look in it and see the result of your choices. It is read by XFree86 when it loads.
You can find information about the format of the data stored in the file XF86Config by looking at the documentation in /usr/X11R6/lib/X11/doc/. The file README.Config is useful.
You can also get on-line documentation by typing:
# man XF86Config
Note that this brings up a screenful at a time, pressing any key brings up the next screenful, <q> quits.
XF86Config has configuration information about your mouse and keyboard, but they are usually no problem. Most systems have a Microsoft-compatible serial mouse and a standard 101-key US-style keyboard. Or maybe you have something different, but it's straightforward and your XF86Config should contain the right information about these.
A bit of a look into the format of information with regard to video, is useful, as this is complex. Here is an extract from XF86Config in my Red Hat case study system:
#BK THIS FILE IS CONFIGURED FOR MY SCAN CT-1469 14-inch
#BK MONITOR 800x600 only.
# File generated by xf86config.
I've left out the comments, font, dynamic-loadable modules, keyboard, and mouse sections. Here is the Monitor section, somewhat condensed:
#**********************************************************
# Monitor section
#**********************************************************
# Any number of monitor sections may be present
Section "Monitor"
Identifier "BKs 14inch monitor"
VendorName "Scan"
ModelName "CT-1469"
# HorizSync is in KHz unless units are specified.
# HorizSync may be a comma separated list of discrete
# values,
or a comma separated list of ranges of values.
HorizSync 31-35.5
# VertRefresh is in Hz unless units are specified.
# VertRefresh may be a comma separated list of discrete
# values, or a comma separated list of ranges of values.
VertRefresh 56-87
# This is a set of standard mode timings. Modes that are
# out
of monitor spec are automatically ignored by the
# server,
so there's no immediate need to delete modelines.
# With these modes, the best standard mode that your
# monitor
and video card can support for a given resolution
# is automatically used.
#BK only modes 640x400, 640x480, 800x600 usable below, but
#BK commented out.
#BK I used "xvidtune", in an xterm inside xwindows, and
#BK came
up with this for my Scan monitor ...
# 800x600 @ 56.33Hz Vsync, 35.43KHz hsync
Modeline "800x600" 36.00 800 824 896 1016 600 601 603 629
# 640x400 @ 70 Hz, 31.5 kHz hsync
#BK Modeline "640x400" 25.175 640 664 760 800 400 409 411 450
# 640x480 @ 60 Hz, 31.5 kHz hsync
#BK Modeline "640x480" 25.175 640 664 760 800 480 491 493 525
# 800x600 @ 56 Hz, 35.15 kHz hsync
#BK ModeLine "800x600" 36 800 824 896 1024 600 601 603 625
We are getting a bit ahead of ourselves here. This listing is from XF86Config after I got it all going. The 800x600 modeline I inserted is detailed later, in Tune your monitor with xvidtune* (page xxx). So, bear that in mind, and look back here as you read subsequent sections.
The rest of the modelines are not reproduced here. XFree86 uses the horizontal and vertical scan rates specified above, to calculate which of the modelines are acceptable. The acceptable ones can all be used when in graphics mode. The key combination <ctrl-alt-+> can be used to rotate through them. However, some of the acceptable modes may not be to your liking, such as 640x400 shown above. In my case (the “Red Hat” case study), the standard modelines were not displaying properly on the screen, so although they were acceptable from XFree86's point of view, I commented them out.
Also, I wanted to stay permanently in 800x600, using the modeline that I had designed via xvidtune*. Frankly, 640x480 is pathetic when running KDE. Some windows expect at least 800x600, and are very difficult to use at lower resolutions. Therefore I recommend that even if you only have a 14-inch monitor, go for 800x600. Yes, I know that some dirt-cheap 14-inch monitors look blurry in 800x600 mode, but ... well ... get a better monitor!
The following Graphics device section is also heavily edited, that is, bits cut out:
#**********************************************************
# Graphics device section
#**********************************************************
# Any number of graphics device sections may be present
# Device configured by xf86config:
Section "Device"
Identifier "BKs on-board video"
VendorName "SiS"
BoardName "5598"
VideoRam 1024
EndSection
Actually, the SiS5598 video chip in this case study is on the motherboard, and uses a configurable amount of memory, borrowed from the main RAM. This is specified in the BIOS setup. The default was 1024K bytes, which I have entered above.
The next extract has specs for the video server. The video modes I have chosen, and the SiS5598 chip, require the SVGA server. There are also mono, standard VGA, and accelerated servers specific to particular video chipsets. Samples of these are in the file, but I have only shown below the SVGA server:
#**********************************************************
# Screen sections
#**********************************************************
# The Colour SVGA server
Section "Screen"
Driver "svga"
Device "BKs on-board video"
Monitor "BKs 14inch monitor"
Subsection "Display"
Depth 8
Modes "640x480" "800x600" "1024x768"
ViewPort 0 0
#Virtual 1024 768
Virtual 800 600
EndSubsection
Subsection "Display"
Depth 16
Modes "640x480" "800x600"
ViewPort 0 0
Virtual 800 600
EndSubsection
Subsection "Display"
Depth 24
Modes "640x480"
ViewPort 0 0
EndSubsection
Subsection "Display"
Depth 32
Modes "640x400"
ViewPort 0 0
EndSubsection
EndSection
I have more to say about the VGA and SVGA servers and the latter part of the above listing, in VGA and SVGA servers (page xxx), further unfolding the saga of the Red Hat case study.
To find out how I created the XF86Config file listed above, see Video configuration with xf86config* (page xxx). Note though that it would be created during the normal install process. I recreated it using xf86config* as part of the debugging process.
You can see above that I have inserted a modeline into XF86Config created by myself. As you read the sections below describing the trouble shooting saga of installing Red hat Linux 5.2, you will come to Tune your monitor with xvidtune* (page xxx), which describes how to develop a custom modeline, and why you would want to do so.
A note about the Red Hat install process: the choices I made resulted in only the standard VGA server being installed, not the SVGA (Super VGA) server.
XFree86 actually consists of a number of servers, one of which is right for your system. There are some servers written especially for certain video chipsets, and some that are more generic. The latter category are the VGA and SVGA servers, the latter of these being the most likely one used by most systems.
When I was fiddling around with Linux video, prior to reloading MSWindows (remember, I installed it the first time but Linux somehow corrupted it), I decided to reinstall Linux and explicitly choose the SVGA server. Thinking about this in retrospect, maybe I could simply have used the Red Hat Package Manager to install it (actually, this is the best way) -- this is getting a bit ahead, so don't worry about it.
Explicitly choosing the SVGA server during the install process results in both VGA and SVGA servers being installed, as the docs state that the VGA server is needed by XFree86 and will always be installed. Note that this is all academic if your video chipset is supported, as normally you would just select it from a list during the install process, and wouldn't have to explicitly choose any particular driver.
It is instructive to look at the server specs in XF86Config, that XFree86 reads when it starts up. The SVGA server specs are shown at the end of XF86Config (page xxx).
The Depth specification is 8, 16, 24, and 32. This means the number of bits to represent the color of a pixel (dot on the screen). Once you have KDE running, you'll be able to select whatever one you want, but due to my limited video RAM, the higher “depths” can use only lower screen resolutions. An 8-bit value to hold a color means 256 colors. A 16-bit value can represent 2^16 colors, which is 65,536 colors.
The Modes entry shows resolution modes allowable for the current color depth and the amount of video RAM.
The Virtual section allows a virtual screen, in which you could be running in, say, 640x480 resolution, but by moving the mouse to the boundaries have the screen automatically scroll, giving a virtual size of, say 800x600. However, I found this more trouble than it's worth.
I looked at the site http://www.xfree86.org/ and found that the latest version 3.3.3.1 of XFree86 supports my video chip, and this is where having MSWindows proved useful. I used Windows to download the upgrade, into a directory in the first partition.
Then, back in Linux, I mounted the C: drive as a MSDOS filetype, by this command:
# mount -t msdos /dev/hda1 /mnt/cdrive
Note that I discovered afterwards that I could have mounted the MSDOS partition so that Linux will recognise long filenames, by typing this:
# mount -t vfat /dev/hda1 /mnt/cdrive
The first is the way I actually did it in this case study, as recorded in my notes, while the second is the option I would now recommend. Note also the # prompt, meaning that I am logged in as root, or superuser.
On my system with just one IDE hard drive, the first partition is hda1. The second (extended) partition is hda2, which the Linux install process divided into logical partitions hda5, hda6 and hda7 (“Workstation” class install).
This presupposes you to be logged in as root or superuser, and /mnt/drive/ must already have been created. I was then able to copy the files across to my Linux partition. Note that the msdos filetype constrains filenames to the famous 8+3 limit, but fortunately all the files were already within this limit (or mount as vfat type).
I ran xf86config* -- note that I place the * on this to emphasise that this is an executable, not a text file.
Refer to Chapter 3, Listing directory contents with ls* (page xxx)), for details on filename postfix character. This is also explained in the Introduction (page xxx).
Just to be confusing, there is also a file called XF86Config* that is also an executable, and there is XF86Config which is a text file -- see why I use the postfixes! There is also Xconfigurator*, and all three of these executables will configure the video card and monitor.
What these executables do is modify or create the configuration file XF86Config. This text file is read by the XFree86 server when it loads. It is supposed to have all the correct specs for your video card, monitor, keyboard, and mouse. For a partial listing of XF86Config, see Section XF86Config (page xxx).
I found Xconfigurator* to have limitations -- in some places it did not give the option to make manual adjustments even though the instructions said it could.
I used xf86config*, which does not read the old XF86Config (text file) -- it creates one from scratch. Rename the old one if you're not confident about this.
Note that the Linux commandline man command can be used to obtain more information on xf86config*.
Guess what, it worked!
I was in, with X Windows (i.e., XFree86) running, and the most pathetic looking graphic windowing system that I've ever seen (the default graphical desktop supplied with Red Hat 5.2 is not KDE or Gnome). Furthermore, my image was too large for the screen, clipped at the top, right, left, and bottom. This clipping occurred in both 640x480 and 800x600 modes (curses again).
Then I discovered xvidtune*. I ran this inside the X Windows desktop, in a terminal window, and it enabled me to finetune the size and positioning of the image.
At this point, you should have got XFree86 running, either straight-off or after following my guidelines in the above sections. You should have some kind of graphical desktop displaying, depending on the default for your distribution. This desktop will have the ability to run terminal windows, also known as consoles. This is analogous to running MSDOS in a window inside MSWindows. With some desktops, there are already one or more terminal windows open, but in the case of KDE you have to go to the big K button, select Utilities then Konsole. At the commandline prompt inside the terminal window, you just type:
# xvidtune
Note that KDE graphical desktop has the executable kvidtune*, which is just a KDE-specific port of the former. You can use either. Figure 2.1 shows the window.
Figure 2.1: xvidtune* window.
Note that I found the Test button in xvidtune* to be buggy. Instead I used Apply only.
Note also that I introduce xvidtune* here with the disclaimer that you use it at your own risk. The same goes for the modeline that I show below. It is possible to select a scan rate that is too fast for the monitor, that may cause damage to the electronics in the monitor.
However, xvidtune* does read the video monitor configuration information from XF86Config, that is, the allowed range of horizontal and vertical scan rates, and will not allow you to enter any setting that goes outside these. This can “save the day”.
Basically, you drag the sliders, then press the Apply button. You will be pleasantly surprised to find that you have total control of the sizing and placing of the video image on the screen. One common problem I have seen in PCs running MSWindows is the image slightly offset on the screen and maybe slightly smaller than it could be, or maybe not symmetrical. Sometimes the controls on the back of the monitor can compensate, but not always.
I learnt how to use xvidtune* simply by carefully changing each slider and observing the effect. Do this, with extreme caution, and you should be able to build a mental picture of how it works. It is probably wise to read some documentation though! Type this in a console window:
$ man xvidtune
I had a cheap 14 inch monitor for this particular case study, and what surprised me is that my new settings were also spot-on for another cheap monitor -- indicating that the standard modeline entry in XF86Config is not so good, at least not for my combination of video chipset and monitors.
You need to read the documentation supplied with XFree86 to understand what I mean by “modeline” entry, and if you still can't find enough documentation, browse around at http://www.xfree86.org/. Also try http://www.linux.org/help/.
However, the first place you should be looking is in /usr/X11R6/lib/X11/doc/, particularly file README.Config. Your distribution may also have PostScript/ and html/ subdirectories. The html/ subdirectory has an enormous number of files, but fortunately there is a starting point: DOCIndex.html. If you have KDE running at this point, you can easily view HTML files as the Kfm file manager has HTML browser capability built-in (see Chapter 4).
xvidtune* outputs the new settings onto the terminal window (standard output), that must be manually entered into XF86Config. I decided to only work in 800x600, and this is what I came up with:
Horizontal sync = 35.43KHz, vertical sync = 56.33Hz
Modeline entry: WARNING: FOR AUTHOR'S PC. USE AT OWN RISK.
"800x600" 36.00 800 824 896 1016 600 601 603 629
I manually entered this into XF86Config and commented out the modelines that were troublesome.
Troubleshooting Xfree86: CASE #1 (page xxx) has a very detailed introductory coverage of troubleshooting procedures. My installation of Debian 2.1, at least as far as XFree86 is concerned, was far less troublesome. There is little to write about, but some useful notes can still be made.
After the base installation of Debian version 2.1, as described in Section Installing Debian linux (page xxx), the text file /etc/X11/XF86Config did not exist. This is very different from some other distributions that create and configure XF86Config during the base install. Therefore, I created it, using xf86config*.
xf86config* is introduced in Troubleshooting Xfree86: CASE #1 (page xxx).
My monitor is a 14 inch ADI ProVista, and has horizontal scan range of 31-69KHz, and vertical scan range of 50-100Hz. The card is an S3 ViRGE, and I didn't know the exact chipset. Of course, I could have pulled the card out and looked at the chips, but xf86config* has a “S3 ViRGE (generic)” card option, which I chose. After choosing the card or chip type, xf86config* then offers a choice of X server, with a recommended one to suit the chosen card/chipset. In my case, the recommended one is XF86_SVGA, even though there is an accelerated server called XF86_S3. I presume that had I known the particular chipset I could have used the accelerated server. My warning here is go with the default -- don't choose the S3 server (as it is not the one recommended by the program).
There are also other options where it is best to select the default if uncertain. For example, RAMDAC (default nothing) and clockchip (default none).
One section of xf86config* where you need to go very slowly is the selection of allowed video modes and color depths. You can configure allowed video modes (640x480, 800x600, 1024x768, etc.) for each color depth, and note this, you can select the default mode for each color depth. The color depths are 8, 16, 24, and 32. This refers to how many bits are used to represent each pixel, or dot, on the screen. 8 bits corresponds to 256 colors, 16 bits to 65,536 colors, etc. While in this section, be sure that you have fully understood it and configured the modes as you want.
If you have a 14 onch monitor, you may only want to operate in 800x600 mode. I do not recommend 640x480 as it doesn't work well with KDE. 1024x768 is too small to see. Therefore, you may decide to only allow 800x600. In that case, get rid of all other modes while at that section of xf86config*. I mention this, as I left in both 800x600 and 1024x768, and when I installed KDE it configured itself for the higher resolution. If 1024x768 is not an allowed option in XF86Config, KDE won't configure to it.
Once XF86Config is created, type this:
# startx
Graphics mode will start, with the default window manager. The latter was chosen during the base install of Debian Linux, and in my case I chose fvwm95.
What now remains is to install KDE, which is described in Installing KDE
(page xxx). The CASE #2 thread for installing KDE is in Troubleshooting
KDE install: CASE #2 (page xxx).
There is one “problem” still, with the Debian installation. It defaulted to launching graphics mode immediately on power-up, bypassing the commandline. This is normally ok, however it is not ok if graphics mode doesn't work!
If you find yourself in this situation, that is, you can't get out of graphics mode (simply called “X” below), there are fixes. They are as follows:
(see Starting KDE
(page xxx)).
This continues the SuSE case study, from Installation: CASE #3 (page xxx).
As part of the installation, I had to provide a password, to be able to login as superuser. After YaST had finished, I was presented with the Login: prompt, and I was soon logged in. YaST does not setup the video, and this is left to another program called SaX.
Note however that it is possible to call SaX from within YaST, but somehow I missed that step.
This is where I ran into another hitch. My minimal installation had only installed the xvga16 server, which is a basic 16 color VGA server. SaX loaded this server, and I was in graphics mode. I looked around in the windows and was able to find a selection for the TVGA8900C chipset, but when I selected it, an error message appeared “Server not installed. Please install the package xsvga”.
So, I exited from SaX, then executed YaST, simply by typing its name at the commandline prompt:
# yast
I went to the window with the item ChangeØcreate configuration, and selected the package group named xsrv. This is a group of X server packages, and I highlighted the item named xsvga and pressed <enter>. I checked the dependencies and then moved down to Start installation.
After exiting from YaST, I again executed SaX, and this time was able to select the SVGA server as required for my video chipset.
SaX also has windows for configuring mouse, keyboard, and monitor. I have a cheap 14 inch monitor on this PC, and chose a horizontal sync range of 31-36KHz and a vertical sync range of 55-87Hz. I had no documentation on the monitor. I chose a default of 800x600, 8-bit color (256 colors). Note that KDE does not run very well in 640x480.
After exiting from SaX, I typed “startx” at the commandline prompt, but only got a blank screen with the mouse cursor on it. No KDE, nor any window manager at all. Then I realised that KDE wasn't even installed -- with my messing around during the installation, I had missed it out.
So, back to YaST. See Section Troubleshooting KDE install: CASE #3 (page xxx) for the next instalment!
The version of Linux that you install will probably install KDE also -- make sure you obtain a distribution that does. Some distributions will be like MSWindows 95/98, in that they will try and pretend the Linux commandline isn't there -- you will be taken straight to the KDE desktop. Others will first log you into the commandline, then you can start KDE - just as you did when you typed "win" at the MSDOS prompt in the MSWindows 3.x days.
In the latter case, you would login as a user, and for the very first time you may have to type this:
$ usekde
usekde* is actually a script; it is possible that your distribution has installed KDE but you don't have this script. Never mind, try the next step. Note that you would only execute usekde* once, as it sets up your home directory with files in which KDE can store your personal data and configuration information.
The next step is to start KDE by typing this:
$ startx
If this doesn't work, then read the case studies below. All of these case studies may have something useful, regardless of which distribution you have. Anyway, to be focused for now:
If you have a Debian installation, go to Troubleshooting KDE install: CASE #2 (page xxx).
If you have a SuSE installation, go to Troubleshooting KDE install: CASE #3 (page xxx).
For a Red Hat installation go to Troublshooting KDE install: CASE #1 (page xxx).
It may be that when you boot-up, your PC goes into a graphical environment that is not KDE, or perhaps that is what it does after typing “startx”. This means that you are defaulting to the wrong window manager. Read through the case studies in the following sections to learn of various ways to tackle this.
Continuing my case study of the Red Hat 5.2 install. As mentioned a few times, this is illustrative of the types of problems encountered and can be applied to other versions and distributions, not just RH 5.2.
My distribution CDROM did not have KDE, so I had to download it. The KDE site is http://www.kde.org/, and I located the RPMs (packages) for Red Hat 5.2.
What are RPMs? This is an absolutely fantastic system developed by Red Hat, hence the name Red Hat Package Manager. Refer to Section Package management (page xxx).
I installed KDE ok, but then I didn't know how to get it running. It seemed that I had to type “usekde” first, then “startx”, as described above, however that didn't work.
It should have worked, but it seemed that when I had upgraded XFree86 something was changed. I was logged in as root when I installed KDE, and the install process created three files in /root/ (superuser's home directory) : .Xclients, .kde/, Desktop/ .
.Xclients (the period in front means that this is a hidden file) contains a line “startkde”, which starts KDE. This is supposed to happen when you type “startx” at the command prompt, except it doesn't work. Somehow, after typing “startx”, .Xclients should be accessed.
Back-tracking for a moment. When you log in as a non-root user, you need to create these files in your home directory, which you do by typing “usekde” at the command prompt -- don't forget, this is something you must do yourself, after installing KDE. Because I installed KDE as root, these files were automatically created in root's home directory, /root/. However, a user, for example /home/bkauler/, doesn't have these files, so must type “usekde” at the prompt, but only once.
Note that every user has his or her own home directory, and this is where you'll be when you login. These directories are by default located in /home/.
It seemed in my system that .Xclients was not being accessed. What I had to do is create a file called .xinitrc in my home directory (remember, the leading “.” means that it will be a hidden file). All that it needed was the text “startkde” in it. Note that the documentation warns you not to type “startkde” at the command prompt, so that's out -- it must be inside the .xinitrc file.
Some people may find that their system already has a .xinitrc file. Fine, except that neither my root nor user home directories had it. So, I created .xinitrc:
$ touch .xinitrc
then put just one line in it: “startkde” using vi.
Then, from the command prompt (presuming that “usekde” was typed in earlier, just once):
$ startx
KDE starts!
Debian Linux 2.1 does not install KDE by default. The DEB packages can be obtained from two sources, http://www.kde.org/ or http://kde.tdyc.com/. I obtained KDE version 1.1.1 from the latter site.
The latter site has a Packages file, that is a database of packages available from that site. You need to download and add this information to the local package database. I added this line to the text file /etc/apt/sources.list:
deb http://kde.tdyc.com/slink kde contrib rkrusty
Note that Debian version 2.1 is codenamed Slink. The next version is codenamed Potato, and if your system is Potato, this is what you would need to put into the file:
deb http://kde.tdyc.com/potato kde contrib rkrusty
I then executed dselect* and chose Update from the menu. I then exited from dselect*.
I obtained a list of all packages starting with “kde” in the local database, by typing this:
# dpkg --list kde*
The rest of the install procedure is described in Chapter xxx, Debian package management (page xxx), which introduces dselect* and shows how to download and install KDE as an example.
After installation, I had to edit /etc/X11/window-managers, as also described in the Section referenced immediately above. Note that Red Hat systems do not have this file. Also, with Debian I did not have to type “usekde” to configure my home directory -- in fact the usekde script doesn't exist. These details may vary with other distributions.
The Debian system also configured to go straight into graphics mode and launch the KDE login window, so there was no need to type “startx”.
This continues the SuSE case study, from Installation: CASE #3 (page xxx) and Troubleshooting Xfree86: CASE #3 (page xxx).
I ran KDE for the first time simply by typing:
# startx
This automatically created the appropriate files in the home directory, and does so also for any user. KDE started up beautifully.
I wanted to configure the system so that at boot up it would go straight into the graphical login screen. Linux distributions vary with how this is done, but I was impressed with SuSE's centralised configuration system.
The file /etc/rc.config is a central place for all configuration settings.
There are two entries in /etc/rc.config that I needed to change. This is how they were before I edited them (the one in the middle is ok already):
DISPLAYMANAGER=””
DEFAULT_WM=kde
KDM_SHUTDOWN=root
The DISPLAYMANAGER entry defines what you get at login. For the two quotes with nothing between, as shown above, you get a text console at login, i.e., the commandline. The default window manager was already set to KDE, so no problem there. The last line means that only the superuser can shutdown from the KDM graphical login window. These are my changes:
DISPLAYMANAGER=kdm
KDM_SHUTDOWN=all
KDM, meaning KDE Display Manager, is the application responsible for putting up the graphical login window.
However, simply changing /etc/rc.config is not enough. The changes must be read and put into effect. SuSE supply an application that scans through /etc/rc.config and applies all changes:
# SuSEconfig
After that, I had to logout and reboot the PC, and up came the graphical login window!
(c) Copyright Barry Kauler 2000. All rights reserved.
Extract from book Linux for me, to be published sometime.
Main page:
http://www.crosswinds.net/~goosee/
or http://www.goosee.com/ or http://goosee.net/
