I would like to stress that this article series was in the making long before the release of Slackware 10.0, so most of the examples will appear as being geared to Slackware 9.1 and 9.0. However, please bear in mind that Slackware is very consistent among versions so you have a good chance of applying what is shown here to the newest version. As far as myself is concerned, I've transitioned elrohir and sombragris to 10.0 over the last weekend; and so far, so good. (On the other hand, denethor still runs 9.0, without a flaw.)
In Part II we will focus on the hardest part: making sound and video work. Sound is not especially difficult; but video is. Fortunately, after this step, it is an easy ride. Now, do not despair: I said that this part is hard, not that it is arcane, difficult to understand, or for "Unix wizards" only. It is hard because it differs so much from other distros which have, for the most part, better tools to do the task. But you can certainly do it and you have a very good chance to succeed.
The first boot leaves you with only one user in a text-only setup. When booting, look closely at the boot messages to check for signals of trouble (and, especially if you are using Slackware 10.0, check whether the parallel port is recognized). As the installer and administrator of the box, having the boot messages printed on screen instead of being hidden by a so-called "friendly" bootsplash is not only a bonus; it is also one less possible point of failure --the bootsplash package requires a specially patched kernel and I've grown to distrust such an expensive move to achieve such a frivolous gain.
Once in the login prompt, log in as root. Once you complete the login, you will be notified that you have mail. You can read your mail using the mail command, which will show you two messages. Both of them are important and it can be said that both of them give good suggestions; but one of these, a message from Patrick Volkerding, deserves special attention. Go and read it carefully. And then save it for future reference. It has a lot of useful information, and chances are you'll need some of it one day.
One of the first tasks you should do is checking the init system. The init system --the set of system scripts that handles the task of starting and shutting down the machine-- is located in /etc/rc.d/, and it is one of the striking differences between Slackware and other distros. The Slackware init system is based on the BSD init style, instead of the more complex SysV init that is used in distros such as Fedora or Mandrakelinux. In stark contrast with the SysV style init, the Slackware init scripts are much simpler and leaner, and they're actually understandable even if you don't know a thing about shell scripting. They are written with the clearest syntax possible, and they're well commented, so it is unlikely that you would get lost in these files.
Now we are going to investigate whether we should make changes to one of these init scripts. Therefore, the one obvious suggestion before going further is: have a backup ready. This would save you a lot of grief in case anything goes wrong. In order to edit the script, you might use any editor; my personal preference lies between joe and jed, resorting sometimes to the Midnight Commander's built-in editor for a quick edit.
The init script you should especially check is /etc/rc.d/rc.modules/, which loads extra drivers into the Linux kernel. You can load each module by uncommenting the relevant entries. (In shell scripts, comments are denoted by a hash mark, #. Deleting the hash mark makes the line active.) As for what should be edited, it is left to you, and it will depend on whether you have some hardware that was not detected by the kernel or some module you want to load because some program requires it. A special case is when you happen to run Slackware 10.0 and have some need to use the parallel port (especially for printing). If this is so, I advise you to uncomment the parallel port modules; as far as I can tell, the kernel of Slackware 10.0 comes with parallel support disabled (Why? I don't know.).
The portion below would be the uncommented part of /etc/rc.d/rc.modules for my machines. I use the APM part for sombragris, my laptop, and the rest would be required by a Slackware 10.0 setup:
#### APM support ### # APM is a BIOS specification for saving power using several different # techniques. This is mostly useful for battery powered laptops. /sbin/modprobe apm #### PC parallel port support ### if cat /proc/ksyms | grep "[parport_pc]" 1> /dev/null 2> /dev/null ; then echo "parport0 is built-in, not loading module" > /dev/null else if [ -r /lib/modules/$RELEASE/misc/parport_pc.o -o -r /lib/modules/$RELEASE/misc/parport_pc.o.gz -o -r /lib/modules/$RELEASE/kernel/drivers/parport/parport_pc.o -o -r /lib/modules/$RELEASE/kernel/drivers/parport/parport_pc.o.gz ]; then # Generic setup example: /sbin/modprobe parport_pc # Hardware specific setup example (required for PLIP and better # performance in general): #/sbin/modprobe parport_pc io=0x378 irq=7 fi fi #### Parallel printer support ### if cat /proc/ksyms | grep "[lp]" 1> /dev/null 2> /dev/null ; then echo "lp support built-in, not loading module" > /dev/null else if [ -r /lib/modules/$RELEASE/misc/lp.o -o -r /lib/modules/$RELEASE/misc/lp.o.gz -o -r /lib/modules/$RELEASE/kernel/drivers/char/lp.o -o -r /lib/modules/$RELEASE/kernel/drivers/char/lp.o.gz ]; then /sbin/modprobe lp fi fi
Once you're finished with the editing, reboot in order to have these changes brought into effect. Of course, you could avoid having to reboot by loading each module manually; but rebooting helps you to see the whole process in the context of the init system works. I prefer to do things that way.
Second order of business after logging in as root is to check whether the sound is working. Slackware 9.1 ships with ALSA 0.9x, which is an excellent sound architecture (Slackware 10.0 ships ALSA 1.0). However, ALSA has all the channels muted by default. First unmute the sound and set appropriate values using alsamixer, which is shown in Figure 2. Then check your sound using aplay:
# aplay /usr/share/sounds/phone.wav
If the sound system is working, you will hear a phone ringing with the following console output:
Playing WAVE '/usr/share/sounds/phone.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
In that case, you should save the mixer settings as the default ones using the alsactl store command.
Usually, the sound system works without problem at the first boot. If it doesn't, check the documentation, available locally at /usr/doc/alsa-*, and online at the ALSA website, which may have some pointers useful in solving your sound problems.
Even after unmuting the sound card, it is possible that normal users might be unable to use the sound card. If that's the case, then check the ownership of the sound card device (usally /dev/dsp), and then add any relevant user to the same group of the sound card (in my system, that's the 'audio' group). We'll see how to add and manage users and groups in Part III of the series.
Lastly, I would like to comment about a strange problem that I've experienced in elrohir and its subsequent workaround. While working as a normal user, I had no trouble accesing the sound card in the console. However, sound was muted in KDE. After a lot of checking, I've found that somehow KDE manages to put a control called 'VIA DXS' to zero. The solution is: (1) Use KMix to unmute the relevant control and to set all the controls according to your preferences; and (2) in the KDE Control Center, go to Sound & Multimedia > Mixer, check "Load volumes on login" and click on "Save Current Volumes".
Setting up the X Window System is always a tricky undertaking. This is furthermore complicated by the fact that Slackware does not offer good tools to perform this task. None of the X setup tools available in Slackware is comparable to the config tools offered by other well-known distros such as Mandrake or Fedora. You might, however, have more than a fair chance to get a good, working and functional X setup with a little patience.
There are at least six ways to configure X in Slackware without having to resort to completely edit a config file from scratch. (Note: Settings specific to X11R6.7/Slackware 10.0 are shown in parentheses.)
Now we want to set the specifications of the monitor. The two critical parameters are the vertical refresh rate, which is the rate at which the the whole screen is refreshed, and most importantly the horizontal sync rate, which is the rate at which scanlines are displayed. The valid range for horizontal sync and vertical sync should be documented in the manual of your monitor. If in doubt, check the monitor database /usr/X11R6/lib/X11/doc/Monitors to see if your monitor is there. Press enter to continue, or ctrl-c to abort.The problem here is that the file referenced (/usr/X11R6/lib/X11/doc/Monitors) does not exist --even in Slackware 10.0--, so you must know beforehand the horizontal and vertical sync frequencies of your monitor (hint: Google is your friend). That issue aside, everything should work as expected.
This ends the most difficult part of our setup. Here is an area where Slackware really needs better tools; or perhaps it is the X Window System that needs better configuration tools so that users and administrators would not be so reliant in distro-specific tools. However, I hope you are able to produce a good setup with the pointers presented here; and I trust that a little guidance and experience can go a long way.
Our next article will focus on how to add and manage users and groups, install fonts, and how KDE can simplify those tasks greatly. Keep going!
Eduardo SÃ¡nchez is a Contributing Editor of Open for Business. He is married to Gloria, and lives with his wife in AsunciÃ³n, Paraguay (South America), where he works as pastoral assistant of Villa Morra Baptist Church. You can reach him at firstname.lastname@example.org.