Wed Feb 4 10:01:33 EST 2015
PART 0: Introduction
Welcome to the alt.os.linux.slackware FAQ! This FAQ was created to
help new and not-so-new Slackware Linux users with various aspects of
installing, running, and maintaining a Slackware Linux system. It is
based primarily on traffic in the alt.os.linux.slackware newsgroup.
Wherever possible, answers provided in this document have been worded
so they are not specific to any version of the Slackware distribution.
Where that wasn’t possible, the answers have been written so they
apply to the version that was the current stable release at the
time of writing, (12.1 at the time of the last update of this FAQ).
Any answers that are applicable only to older versions are clearly
identified as applying to the latest version of Slackware for which
they are known to be applicable.
This document would never have been possible without the many
contributions from numerous participants in the alt.os.linux.slackware
newsgroup, listed at the very end of this document. Any errors in
content or omissions are strictly the fault of the FAQ maintainer,
and not of the people whose contributions are included in this FAQ.
These should be brought to the attention of the FAQ maintainer at
Questions answered in this FAQ:
PART I: General questions about Slackware Linux
PART II: Installing Slackware
PART III: Slackware Linux system administration:
PART IV: not Slackware, but Slackware-related
PART V: about the FAQ
PART I: General questions about Slackware Linux
Should I use Slackware?
Of course you should! :-)
Slackware is a Linux distribution suitable for almost any user.
It’s very stable and reliable, actively maintained, and has a
very good track record for prompt security updates. Whether your
intention is to setup a dedicated web server in a remote co-location
facility, or a desktop workstation based on the popular KDE desktop
environment, or any number of options in between, Slackware Linux
is an excellent choice.
Slackware is generally considered the best choice for older hardware,
such as i486-compatibles and early Pentium-based PCs. In fact a
good option for many users wanting to learn GNU/Linux, who are not
ready to do without their existing OS, is to install Slackware on an
older machine. That way they can still have the operating system
they’re already used to on a newer computer, while they learn their
way around Slackware Linux on the console or lightweight windowing
environment (or via network connection, telnet or ssh.)
However, if you’re not into reading documentation at all, you may
wish to try another distribution. All Linux distributions have a
learning curve, and if you won’t read the documentation, you probably
won’t get Slackware Linux working to your satisfaction.
In choosing a Slackware version, it’s best to select the most current
stable version that will run on the hardware you wish to install
it on. Even the most current versions of Slackware Linux will run
on very modest, or aging, systems, if you can do without a windowing
environment (or can work with a lightweight window manager).
The exception is when installing on a very small hard drive: in
such cases Slackware 4.0 or earlier is likely preferable, as you
will be able to get more software installed per megabyte used.
A very useful console-only Slackware 4.0 system can comfortably
fit on a 100MB hard drive.
Where can I download the book that’s on the Slackware website?
(quoted from http://www.slackware.com/book/)
The official guide to Slackware Linux, the Slackware Linux
Essentials, has been recently revised. If you want to be
able to read it online, you may want to visit the slackbook
website. http://www.slackbook.org/ You may also want to buy
a printed copy, in that case please visit the Slackware Store!
What documentation comes with my Slackware installation?
Pay special attention to the files in the root directory of the
first installation disk. Some of the files of particular interest
are listed here, but there are others that contain useful information.
A full installation of Slackware includes quite a bit
man pages: (e.g. "man lilo.conf")
The FSF help system: (e.g. "info -f find")
Linux FAQs: /usr/doc/Linux-FAQs
Linux HOWTOs: /usr/doc/Linux-HOWTOs
Other program documentation: /usr/doc
The kernel documentation: /usr/src/linux/Documentation
There’s also the kernel configuration help. When configuring your
kernel, you can get help on each configuration item. Not all items
have help, but most do. The 2.6 series kernels add make help and
offer a search function within make menuconfig: /<search_term>.
The scripts in /etc/rc.d are generally well commented and can
explain a lot about what goes on when the system starts up, and the
/etc/rc.d/rc.modules script briefly describes almost every kernel
module that is listed in it.
I still need help! What other documentation exists elsewhere on the internet?
There is, of course, the alt.os.linux.slackware newsgroup, populated
by a variety of Slackware Linux users, with varying backgrounds and
levels of expertise with most aspects of running a Slackware Linux
system. No matter what problem you might encounter with Slackware
Linux, there’s very likely someone who frequents this newsgroup with
sufficient knowledge to try and help, or at least to help point you
in the right direction to better help.
It’s probably worth your while to search the newsgroup using google,
for older messages that may have expired from the news server you use.
If someone else has had the same problem and resolved it already,
you might be able to learn from the experience gained in that thread
Slackware’s own Documentation
ftp://ftp.slackware.com/pub/slackware/ (.txt files in per-version
The Official Slackware Book
The Revised Slackware Book Project
A Slackware Wiki
Wikipedia has an entry
Other FAQs about Slackware
How to Install and Run Slackware (written for Slackware-13, but not
particularly version-specific; note reader comments and responses
suggest that some of the author’s information and Slackware experience
are dated, but the comments themselves help the article be more up
to date; by itself, this article should at least help someone get
running on a Slackware system pretty easily)
An online book intended for new Slackware users, but complete enough
to be useful to experienced users as well:
The Slack World has a list of Slackware-related links
which may be useful:
Some general linux help sites
The Linux Documentation Project
X Window System
most software packages have master web sites with documentation
for current versions of their packages. These can usually be
found by searching for the package name on
If all else fails …
Are there other places to discuss Slackware?
Aside from the alt.os.linux.slackware newsgroup, there are many other
places to discuss Slackware. A web search engine will provide links
to many, but here are a few for your convenience:
LinuxQuestions.org - Slackware: "where Linux newbies come for help"
SlackwareHelp.org - "Slackers helping Slackers"
The old Slackware forums have now been incorporated as part of the
userlocal.com forums. These can be found at
The linuxiso.org Slackware forum
The dropline.net Slackware forum
A public Slackware mailing list
#slackware on irc.freenode.net.
When is the next version of Slackware going to be released?
Slackware’s own FAQ has the following to say on the matter:
It's usually our policy not to speculate on release dates, since
that's what it is -- pure speculation. It's not always possible
to know how long it will take to make the upgrades needed and
tie up all the related loose ends. As things are built for the
upcoming release, they'll be uploaded into the -current tree.
If the -current does not exist, it probably means we have just
released a new version of Slackware. A new -current tree will be
formed shortly after the new release is made.
If you watch store.slackware.com, you may find an expected date
of release for the next version of Slackware, especially if the
release is getting close.
One hint that an official release is impending is that the HOWTOs,
FAQs, and boot images are being prepared. Track the CHANGELOG of
-current to get another rough idea for when a release might be
Is there a Slackware version for the AMD64?
There is an official Slackware64 port, now available with the
Slackware DVD at http://store.slackware.com/ (also available for
download, as with the regular 32-bit Slackware).
In addition, to satisfy those that wanted 64-bit Slackware when it
wasn’t officially available from Slackware, Fred Emmott produced an
unofficial port, available from http://www.slamd64.com/.
What about Slackware on other architectures?
There is an official Slackware port to the S/390 architecture,
that appears to be actively developed and maintained.
See http://www.slack390.org/ for details.
Over the years, there have been ports to the SPARC and Alpha
platforms, but neither were kept up to date and were eventually
dropped. Unofficial ports to the Alpha platform (and others?)
have since appeared and disappeared, but none yet have been released
as a complete Linux distribution ported from Slackware.
If you want to, you’re more than welcome to port Slackware to other
architectures, but you can’t call it Slackware without explicit
permission from Patrick Volkerding.
How do I report a bug in Slackware? / How do I contact Patrick Volkerding?
Contact information for Slackware is listed at:
Where is the installation’s "setup" program?
The /sbin/setup script in older Slackware versions allowed quick
access to various system configuration scripts. The configuration
scripts are still there, but "setup" is gone. You can run each of
pkgtool install/remove/view packages, re-run setup scripts
explodepkg explode a Slackware compatible software package
installpkg install a Slackware compatible .tgz package
makepkg make a Slackware compatible .tgz package
removepkg remove an installed package
upgradepkg upgrades a Slackware .tgz package
adduser easy way to add user accounts
makebootdisk create a SYSLINUX bootdisk
mkrescue create a rescue CDROM or floppy
fontconfig select fonts for X
make-bootdisk create a bootdisk
modem-device select your modem device
hotplug enable hotplug on boot
liloconfig create the lilo.conf file
mouse select mouse and enable gpm
netconfig setup networking
services select which services to run on boot
setconsolefont select special console fonts
timeconfig select your timezone
xorgsetup setup X to suit your system
xwmconfig set your default desktop / window manager
Pkgtool can also run many of the setup scripts for you. Pick the
last option before "quit" which says "choose installation scripts
to run again." You pick the scripts to run with the space bar and
Also, note that xorgsetup and xwmconfig are both in /usr/X11R6/bin,
which may not be in your path.
See the manual pages for each of these tools for additional details
about running them, available options, etc.
Doesn’t Slackware support PAM? Everyone else does!
Slackware doesn’t use or include PAM, though of course you’re free
to install and use it on your own systems. You can get Patrick
Volkerding’s own explanation for omitting PAM from the distribution
in the slackware 9.1 Changelog, quoted here:
If you see a security problem reported which depends on PAM,
you can be glad you run Slackware. I think a better name for PAM
might be SCAM, for Swiss Cheese Authentication Modules, and have
never felt that the small amount of convenience it provides is
worth the great loss of system security. We miss out on half a
dozen security problems a year by not using PAM, but you can always
install it yourself if you feel that you're missing out on the fun.
(No, don't do that)
How can I authenticate a Slackware client against an LDAP server without PAM?
If you’ve read above, you know that Slackware doesn’t support PAM,
but the most common way of configuring a linux client to authenticate
against an LDAP server is to use PAM. What to do?
Well, one method is to use the nss_ldap software provided by PADL
(http://www.padl.com). You’ll need to obtain and install the
software yourself, but it’s a lot easier than installing PAM.
The basic procedure follows:
Modify /etc/nsswitch.conf to authenticate against LDAP. You’ll
probably want to modify at least passwd, group, and shadow. It’s
best to add ldap after the files entry for each database (or in an
appropriate order, if you use things like nis). (Personally, I don’t
recommend using compat mode if also using nis or ldap.)
That’s all you should need to do - no restarting of daemons should be
Where’s my .bashrc? / My .bashrc is missing!
Unlike almost all other distributions, Slackware doesn’t ship with
a default .bashrc, so no such file appears by default in your home
directory. There is nothing special or magical about this or any
dotfile (hidden configuration file). Simply create a .bashrc file
with the editor of your choice. The contents generally boil down to
setting variables and shell options, and defining aliases and/or
functions, as well as executing whatever commands you’d like. See
the bash manual page for details.
Why isn’t $PACKAGE included in Slackware?
Because it isn’t. One person controls that which is called
"Slackware", and that one person 1.) didn’t want to include it,
or 2.) didn’t think about it. In either case you can possibly
get an authoritative answer by contacting Slackware directly (see
http://www.slackware.com/contact/ for details). The people on the
alt.os.linux.slackware newsgroup do not have a say in which software
gets included with Slackware.
I downloaded an ISO image. Can I preview it before burning to a CD?
Yes. You need to load the loop.o module in your kernel or compile
it into the kernel itself. insmod loop.o should do it. This will
allow you to mount the ISO image as a pseudo disk and perform file
management on it. I recommend mounting as read only just to protect
To mount an ISO file, as root type:
mount -t iso9660 -o ro,loop filename mountpoint
where filename is the link to or full filename and extension of the
ISO image, and mountpoint must be an existing directory onto which to
mount the image.
Then, you can cd to mountpoint and read the contents of the file
Why did Slackware change from XFree86 to X11 (X.org)?
The reasons for changing to X11R6 (X.org) from XFree86 are given
in the Slackware 10 ChangeLog:
Sun May 30 01:06:39 PDT 2004
x/: Switched to X11R6.7.0 from X.Org. Thanks to those who sent
comments to x[at]slackware.com. Seems the community has spoken,
because the opinions were more than 4 to 1 in favor of using the
X.Org release as the default version of X. I think I've heard
just about every side to this issue now, and it was only after
careful consideration and testing that this decision was made.
It's primarily (as is usual around here) a technical decision.
Nearly everyone else is going with X.Org and it seems to me
that sticking with XFree86 it spite of this would be asking for
compatibility trouble (indeed, we saw some issues between X.Org
and XFree86 4.4.0 until a few things in XFree86 were patched).
I also noticed that the ATI Radeon binary drivers designed for
XFree86 4.3.0 do not work with XFree86 4.4.0, but do work with the
X.Org release. Something I'm *not* in favor of is dragging around
two nearly identical projects, so XFree86 4.4.0 has been moved
to the /pub/slackware/unsupported/ directory on the FTP site.
Why can I only write to my FAT32 drive as root?
For these partitions to be writable by an unprivileged user,
you need to pass options to mount (via the command-line or fstab).
There are several combinations of options you can give. Some examples
follow, but the mount manual page gives more complete details,
lists additional available options, and provides examples of its own.
you can add a line similar to the following to /etc/fstab, so that
whichever user (privileged or not) mounts the filesystem can
write to it:
/dev/XXX /xxx vfat user 0 0
using mount on the command-line, to let a specific UID and/or GID
write to the filesystem, you can use:
mount -o uid=1000,gid=102,rw /dev/XXX /xxx
using mount on the command-line, you can set the umask to let all
users write to the drive (this method is not recommended since
it lets any user, trusted human and otherwise, to write to the
mount -o umask=000,rw /dev/XXX /xxx
Any of these methods can be combined (e.g using uid, gid & umask
together to let the whole group write to the drive). As mentioned
above, see the mount manual page for additional details.
See also http://slackwiki.org/Windows_Partitions for more information.
How do I enable write access on my NTFS partition?
NTFS is a moving target and while read support for it is mature,
write support isn’t. If you enable write support on your NTFS
partition there is a high probability that you will corrupt the
partition and make all or part of your data there inaccessible
in either Linux or Windows. However, if you’re feeling brave,
you can do this by enabling write support in the kernel module.
In the 2.6 kernel you’ll find this option here:
Symbol: NTFS_RW [=n]
Prompt: NTFS write support
Defined at fs/Kconfig:733
Depends on: NTFS_FS
-> File systems
-> DOS/FAT/NT Filesystems
-> NTFS file system support (NTFS_FS [=m])
Why am I unable to get sound after setting up a graphical login program?
Slackware automatically adds a user authenticated via the console to
certain groups such as audio and cdrom. However, the graphical login
managers shipped with Slackware don’t support this feature. You’ll
need to manually add those users to those groups, or change
permissions on certain /dev files.
I have a question about <slackware derivative>…
Although there may be someone on the alt.os.linux.slackware newsgroup
who knows enough about the derivative distribution you’re using,
please keep in mind that readers of the newsgroup are likely not as
familiar with the derivative ditribution as they are with Slackware.
There’s a very good chance that the distribution you’re using has
its own support channels, and its own user community that may be
able to provide better help with that distribution than the folks
who frequent alt.os.linux.slackware can.
That said, if you believe that a post to alt.os.linux.slackware is
likely to get the help you’re looking for, or you’re unable to get
sufficient help from the derivative distribution’s own user community,
you’ll find that the more clearly you describe the problem, without
forgetting to mention which Linux distribution you’re using, the
easier it will be for others to try and help.
Why does Slackware use gz/xz instead of bz2?
Slackware is one of the few major linux distributions that can still
install fairly easily on many older computers including Pentiums and
486s. (is this still true with Slackware-13.x?) While bz2 might
offer slightly better compression of packages, the amount of time
these older machines take to decompress bz2 files is far greater than
that required for gz. Thus, Slackware has traditionally used gzip for
compression of its packages. With the release of Slackware-13.0,
the distribution now ships packages compressed with "xz" instead,
in an effort to find a true compromise between compression ratio
and decompression performance.
Why is KDE-4.2 on Slackware-13.0 so slow?
KDE-4.2, as distributed with Slackware-13.0, includes a file indexing
daemon that runs by default. Strigi is designed to provide full file
indexing in KDE that’s supposed to perform better than alternatives.
However, the Strigi File indexer included with KDE-4.2 consumes
excessive amounts of resources, and does so almost constantly.
This causes the system to appear to bog down. If you are experiencing
performance problems, such as the hard drive constantly in use,
or the CPU always active, you may try disabling Strigi by going
into the System Settings, going to the Advanced tab, and Desktop
Search. From there, you can disable the file indexer. This should
speed things up considerably.
PART II: Installing Slackware
Where can I get a Slackware ISO image?
Find the Slackware mirror nearest you from the list on Slackware’s
web site, at http://www.slackware.com/getslack/
The following sites also provide lists of Slackware mirror sites:
This link shows a history of Slackware versions:
How do I install Slackware?
Installation instructions are included with each Slackware CD set, in
the form of a small booklet, and as text files on the installation CD.
The Slackware web site also has helpful documentation at
Newer versions of Slackware (since Slackware-8.1) include an
installation HOWTO document, in the root directory of the first
installation disk, and also available at the following URL:
The HOWTO should also be available at the various mirrors. See the
"getslack" URL above for more details on mirrors.
How can I install Slackware via FTP?
Slackware has never given the option to install via FTP. The only
network-based installation option is NFS. You could configure NFS on
an already running system, and download the installation files there,
to install onto your target system. Unless you already use NFS for
other reasons, or you have no other option (for example no CD drive
on the target system), this approach may not be worth the effort.
How should I partition my hard disk?
This question will normally receive as many different answers as
there are people answering it, and any of them might be right for your
target system. Still, what’s presented here is a generally accepted
approach to partitioning a single hard disk for a Linux installation.
The easiest way to partition your system is of course to not partition
at all. Or rather, to create a swap partition at the beginning of
the disk, and leave the rest as one large partition for /. Note,
however, that the BIOSes on most older systems were unable to boot
from a partition that occupied space beyond some number of cylinders
on the disk. On such systems, the first disk partition should be
created so that it is no larger than that limit, and this partition
should be the one containing the operating system kernel, (many people
mount this as /boot, while others move the system kernels out to the
"/" root directory and use this smaller first partition as "/")
It is usually necessary to have at least a swap partition, and there
are various reasons why you might decide to divide various other
parts of the system onto separate disk partitions.
For example, it can be a good idea to put /home and /usr/local on
separate partitions. That way, you can upgrade to a newer version
of Slackware without having to overwrite your personal data and
the programs you installed from source. It’s still advisable to
take complete backups of any information you consider important, but
having these directory trees as separate filesystems will help ensure
that upgrades and new installations won’t cause you to lose your data.
Instead of creating two partitions for /home and /usr/local, you can
also create only one. Create a directory /usr/local/home on this
partition, and then make a sym-link from /home to /usr/local/home.
This way, /home and /usr/local make use of the same partition, which
means you don’t have to decide which partition you want to make the
The next question is usually how big the various other partitions
should be. This of course greatly depends on what you want to install
and how you want to use your system. A full install of Slackware
10.x (with KDE) takes some 4-5GB, to which you will have to add
some free space. So for a full install, you will need to give /
at least 4GB (5GB would be better). You can of course use less if
you don’t do a full install. The rest of the hard disk can be split
up between /home and /usr/local.
It might help you gain additional insight to read A Quick Guide to
Linux Partition Schemes, at
How much swap space should I use?
The trick is to know two numbers.
First determine how much memory the system will use under its expected
peak loads. Most often this number will be an educated guess under
the best circumstances, so it’s worth being generous here.
Second, determine how much physical memory you can afford to put into
the computer system, or that the system will be able to recognize
and use. This may be already determined by the memory that is
presently installed in the target system.
Swap space should be at least as large as the difference between
the above two numbers.
There have been various "rules-of-thumb" over the years that swap
space for a Unix or Linux system should be equal to an even multiple
of the amount of physical RAM on the system (with, in some cases,
an extra amount large enough to hold a copy of the system kernel).
On operating systems that produce a kernel+core file when recovering
from a system crash, such a rule of thumb is reasonably applicable,
but Linux isn’t such a system, so the only real requirement for
swap space is determined by the difference between how much memory
the system will need to use, and how much physical memory can be
installed into it.
Note that the Linux kernel’s suspend option uses the swap partition
to store the memory image. If you plan to use this feature, be sure
to setup an appropriately-sized swap partition.
Why are there so many stories about allocating swap space?
Well, there is a logical reason for the rule of thumb that swap
should be 2 times the amount of RAM, it just doesn’t apply to Linux
On systems derived from older versions of BSD (I’m not sure exactly
which version of BSD, but Ultrix and SunOS 4 are examples of
commercial UNIXen for which this is true) the swapping algorithm
allocates swap space immediately for all memory allocated by the
kernel. Which means when a program is loaded, swap space is
encumbered. Also when a program calls brk() or sbrk() for more
memory, swap space is immediately allocated.
Hence at an absolute minimum, for the system to even use its RAM,
there must be a 1:1 relationship between RAM and swap space. If
the system is to have virtual memory beyond the limits of physical
RAM, swap must be increased beyond 1:1. The size of virtual memory
is exactly the size of swap.
Hence the "Rule of Thumb: Swap should be twice the size of RAM",
which allows just about exactly twice as much memory for loaded
programs as there is physical RAM. (And that was about the maximum
load it was reasonable to put on a Sparc Station 1 used for general
However, Linux has never used that algorithm for swapping/paging of
memory. Linux doesn’t allocate memory at all when brk() or sbrk()
are called! It waits until that memory is actually used. Hence,
no matter how much RAM or swap a system has, you can call malloc()
(which calls sbrk() to get more memory) and get 2.1Gb of memory!
(One way of looking at this, is that it is faster. Another way is
that BSD is safer.) Each individual page of that memory will only be
actually allocated if it is used. And the way Linux does that
allocates either RAM or swap. Hence while the total virtual memory
for BSD is the size of swap, for Linux it is the sum of RAM and swap.
The immediately obvious result of that difference is that a BSD
system with swap space twice the size of RAM has virtual memory twice
the size of RAM, but a Linux system with swap space twice the size of
RAM has virtual memory three times the size of RAM.
OK, how do we calculate swap space for Linux?
(See "How much swap space should I use?" above)
With the old BSD swap algorithm, swap space would be the amount of
virtual memory desired, and that is actually unrelated to RAM size
other than it must be greater than RAM. However, in a practical
sense with typical systems and typical use patterns, it made little
sense to have more programs swapped out than were running due to the
slowness involved. And of course that "rule of thumb" was developed
when disk space was relatively more expensive than it is now. (But
RAM was more expensive too, and I’ve heard of Sun workstations that
had 16Mb of RAM and 300Mb of swapping which were running modeling
programs that took a month to finish. Today, I can do that on my home
machine in what, an hour?)
What happens if that rule is applied to Linux?
On todays systems a home work station might have 256-512Mb of RAM,
and probably never goes into swapping! Why would I want 1500Mb of
virtual memory on my box with 512Mb of RAM? The reason I bought
512Mb of RAM is because I’ve never ever used that much VM that I know
On the other hand there are servers which might have hundreds of
processes that are always running, but are inactive 99% of the time.
Why put in 2Gb of RAM, when only 256Mb of those programs are actively
being used? In that case it makes sense to use 256Mb of RAM and have
1800Mb of swap!
How do I upgrade from a previous version of Slackware?
Instructions, caveats, and notes for performing an upgrade between
Slackware versions are provided in the file UPGRADE.TXT on the first
disk of the Slackware distribution. This file should be your first
source of information, followed closely by CHANGES_AND_HINTS.TXT on
the same disk, but also check on the same disk for other .TXT files
that may be relevant to your situation.
Upgrades between major version releases, however, usually represent
significant changes, and may prove to be more work than they’re worth.
You may be better off installing the new version from scratch, on
the same disk as the previous version you have been using. This may
mean needing to take backups of certain directories, such as /home,
/usr/local, /var/spool/mail, /var/spool/cron/crontabs, and others,
and reloading them after the new OS has been installed.
If it does, plan for the same situation to occur the next time
you want/need to upgrade Slackware on your system, and adjust your
partition layout accordingly. One suggestion would be to keep /home
and /usr/local, and perhaps /var/spool/mail if you have many users
or lots of email stored there, on separate partitions that are not
involved when you perform the OS installation, but instead added
to /etc/fstab later. You would still need to backup then restore
files from /var/spool/cron/crontabs, (for example) and perhaps
Whichever method you use, your best bet would be to have a well
thought out plan before you start, and a complete backup of all files
you consider important on your system, taken right at the moment
before you start the upgrade. Even if you’re keeping important files
on separate disk partitions that won’t be overwritten during the
installation, having a backup will ensure that if you need to, you’ll
be able to recover from any mistakes. More importantly, not having
a backup ensures that you’ll wish you had taken one before starting.
Where can I find packages built specifically for Slackware?
If the package you’re looking for is one that ships with
Slackware, see the mirror nearest you from the list at
Software compiled and pre-packaged for Slackware, but not by
Slackware can often be found at http://pkgs.org/
Remember, you need to do your own checks to make sure you have
the right libraries installed for packages you install, whether
you obtained them from a Slackware mirror or from the Linux
Packages site. installpkg won’t do that for you.
There are also build-script repositories where you can find scripts
that will help you build Slackware-compatible packages on your
own system for software that isn’t included with Slackware. These
enable you to audit the build process used to create the package
and to avoid broken packages built on other systems with different
libraries installed. They’re also an easy way to install software
that may not be available in pre-packaged form on your Slackware
system. For a popular example, see the SlackBuilds.org project
at http://slackbuilds.org/. There’s also a really convenient
front-end for the SlackBuilds.Org collection of scripts available
Can I use RPMs with Slackware?
Yes. There are a number of options for doing this. Slackware ships
an rpm package with recent versions of the distribution, and also
includes a tool, "rpm2tgz" to convert RPM packages into a format
that can be installed with Slackware’s own installpkg tool.
There is also a package called Alien
which will convert files between many package formats.
It’s worth considering, however, that you will have more control
over what goes onto your system, how it’s compiled, and where it’s
installed if you download and compile software from the original
source code, or install it (if available) from the main Slackware
Is there a package manager for Slackware?
Slackware’s pkgtools package provides the tools for package
management. The following is quoted from its description file:
Included are the command line utilities "installpkg", "removepkg",
"makepkg", "explodepkg", and "upgradepkg" that install, remove,
build, examine, and upgrade software packages. Also included are
"pkgtool", a menu based program for installing packages, removing
packages, or viewing the packages that are installed on the system,
documentation (man pages), and a few other system admin scripts.
pkgtool is a front end to most of the other scripts, but those
that are used most often are:
installpkg: installs a Slackware package
removepkg: removes an installed package
upgradepkg: upgrades an installed package to a newer version
Most of these scripts are in action when you first install your
system, and are installed along with the rest of Slackware’s packages.
They are very easy to use: to install a Slackware package called
"package.tgz", type "installpkg package.tgz". To remove it, type
Much more documentation is available in the manual pages for these
There are also third-party package-management tools for Slackware,
such as slackpkg, slapt-get, swaret, and others. Used carefully,
any of these have been very helpful to some, but others have found
that as much as they can help, they also can damage a Slackware
installation if the user is not careful about certain details.
As with most software, careful study of the included documentation
will be required to get the most out of any of these package
How do I uninstall software?
If you installed the software as a standard Slackware package, you
can use removepkg to remove the files in the package. Remember that
removepkg doesn’t do any dependency checking, so if you remove a
package that your system depends on (such as glibc, but there are
others) you will run into difficulties.
If you installed the software from source, there are a few options.
Sometimes there is an uninstall target, in which case you should issue
a "make uninstall" command from within the package’s source tree.
If you haven’t already installed software to help you manage
software installations, any of the following might be worth your
while to investigate. Look in Slackware’s /extra packages on the
installation CD for these or any other similar packages.
Is there any updating tool in Slackware like Debian’s apt-get or RedHat’s up2date?
No. Slackware doesn’t come with any auto-updating tool like apt-get
or up2date. There are some third-party updating tools like swaret,
but most people download and update packages by hand or through a
custom script. (A search of the alt.os.linux.slackware archives on
Google Groups will bring up a lot of scripts that you could utilize
for your own uses).
It’s worth noting that patches and updates to Slackware are announced
in the Changelog and/or the slackware-security mailing list, so it
would be a good idea to keep an eye on both of these to find out
about new updates.
The slackware-security list can be found here:
The changelog for the stable version of Slackware can be found here:
The changelog for the "-current" development version of Slackware can
be found here:
Which package contains <insert filename here>?
It’s commonly considered the best way to find this information is through
searching Slackware’s MANIFEST.bz2 file. You can find this file on the
Slackware CD in the slackware directory or on a Slackware mirror. (Note
that in older distributions, the file is called MANIFEST.gz, and is
found in the slakware directory).
One way to search MANIFEST.bz2 is to type the following:
less -p filename MANIFEST.bz2
(press n for next match found. Press q to exit. If you’re not using
Slackware to run this command, you may have to decompress the bz2 file
with bunzip2 or "bzcat MANIFEST.bz2 |less".)
Sometimes a file won’t be listed in MANIFEST.bz2, (usually because
it’s created by a package’s doinst.sh). In this case, see if it’s
installed on your system already, using the following command:
grep -rl filename /var/log/packages
Most of the time, if you are searching for a program, the following
should produce more relevant results:
grep -rl filename$ /var/log/packages
Why doesn’t my <insert hardware here> work in Slackware? It worked in <insert distribution name here>!
In all distributions of Linux, hardware support is provided by the
kernel or user-land software. If a hardware device doesn’t work, then
a) the software that uses the device is misconfigured,
b) hardware support for that device hasn't been built into your
kernel (the driver might be experimental, so check for this
if you need to build a new kernel),
c) linux doesn't support your hardware at all, or
d) the thing (or the connector) is broken.
Examine these possibilities in the above order to diagnose
the problem. If the device works with another distribution,
items c) (probably) and d) (certainly) can immediately be
ruled out. Various "Linux-on-CD" distributions can be useful for
troubleshooting hardware problems. Most common hardware devices
that have support in Linux are usually detected and configured by
such distributions, and you might be able to learn how to make your
Slackware Linux installation work with your hardware by reviewing
relevant configurations from CD-based Linux distributions.
There are various hardware-compatibility lists for the different
components of a Linux system, (ALSA and X have their own
hardware-compatibility lists, for example). There is a general
(though perhaps outdated) hardware-compatibility list in the Linux
Documentation Project web site:
Where can I get information about what’s installed on my system?
The directory /var/log contains the subdirectories packages, scripts,
removed_packages, and removed_scripts. The *scripts dirs contain the
doinst.sh scripts that were run on install/uninstall. The *packages
dirs contain the package lists from installed and uninstalled
packages. These last files contain the package name, size, location
it was installed from, description, and file list. These are plain
text files, so using basic tools like grep, awk, and less will get
you the information you need.
I installed the latest kernel from the Slackware distribution. Where are the kernel modules for that version?
If you install a kernel from "extras" or "testing" on the Slackware
distribution CD, you will need to manually install the matching
kernel modules from the same directory. Installpkg will install
the package containing the kernel modules if you take this route.
PART III: Slackware Linux system administration:
Slackware is installed. Now what?
You might want to harden your system, setup hardware, etc…
The following URLs provide useful tips for fine-tuning and
administering a Slackware Linux system:
How do I find out what updates are available?
There is the slackware-security mailing list,
The slackware-security mailing list also has a corresponding web page:
The changelog for the stable version of Slackware can be found here:
Users testing Slackware-current can monitor the ChangeLog file at
Users of the S/390 port will likely want to monitor its changelog
instead, at http://www.slackware.com/changelog/current.php?cpu=s390
What’s the difference between Slackware startup scripts and System V startup scripts?
Slackware’s startup sequence is pretty clearly described at the
What follows may also help:
Unlike most other Linux distributions, which use System-V style init
scripts, Slackware’s boot-time startup scripts are largely (though
not entirely) based on the BSD-style rc.* scripts. At the same
time, Slackware uses a System-V style init program, with numbered
run-levels. It’s an unusual combination, but it works well, and
once understood, is very easy to manage.
Both SysV scripts and BSD scripts are human-readable, in that they
are shell scripts, not compiled programs. The main difference is in
how the scripts are designed.
System-V style scripts tend to be designed to start or stop a single
service or system function per script, and take arguments like start,
stop, restart, and others, depending on the service it’s controlling.
So you could say something like /etc/init.d/bind start to start BIND,
and /etc/init.d/bind stop to stop BIND.
SysV-style init scripts also tend to use symlinks in per-run-level
directories to organize the boot sequence: in /etc/rc.d/rc.4/, there
might be various symlinks to actual scripts in another directory.
The symlinks are named like S10network, S25xdm, and so on, where the
S is used to mean the service is started when the system enters that
run level, and K means it is stopped ("killed"). The sorting order
of the link names define the order that the scripts run. The example
scripts mentioned here would have "S10network" run before "S25xdm".
BSD-style scripts tend to place the startup commands for multiple
related system functions and services into relatively few scripts.
This makes it easy to setup the network interfaces and start network
daemons, for example, from one or two scripts.
In the BSD-style, processes are killed (with SIGKILL, which usually
causes a graceful shutdown) when the system shuts down, without
explicitly calling a series of scripts in any particular order to shut
Since Slackware uses a SystemV-like init program, however, a system
shutdown is synonymous with switching to run-level 0 (or run-level
6 for a reboot, but from the point of view of the shutdown stage
of a reboot, these are identical, and indeed Slackware’s "rc.0"
script is a symbolic link to "rc.6"), and there is an init script
(/etc/rc.d/rc.0 for a shutdown, and /etc/rc.d/rc.6 for a reboot,
but note that these are the exact same script in a stock Slackware
installation) that runs when that run level is entered. This script
takes care of gracefully shutting down any services that were started
when the system booted.
If a system administrator needs to change the order of the startup or
shutdown sequence, on a BSD style system, the appropriate sections of
a small number of scripts need to be modified, moved, added to, etc.
On a SystemV-like system (including most Linux distributions), this
change is done simply by renaming symbolic links in per-run-level
directories, pointing to the init scripts. Disabling a service can
easily be done by removing execute permissions on the appropriate init
script, or renaming it so that the symbolic links in the per-run-level
directories no longer point to it.
Slackware’s approach here is much closer to the BSD style, though in
recent years, several individual per-service scripts have crept in,
making it easier to disable the starting of a service by removing
execute permission from the appropriate script, or renaming it,
but changing the startup or shutdown sequence (which isn’t likely to
be done in most installations) still involves modifying the larger
As of Slackware 10, /etc/X11/XF86Config has been replaced with
/etc/X11/xorg.conf. This is because Slackware 10 and later uses the
X11 (X.org) system as opposed to XFree86. The syntax and layout for
both files is virtually identical.
How come I get "--MARK--" appearing in my syslogs every few minutes? How can I turn that off?
It appears every 20 minutes (by default) as a way for the system to
confirm that syslogd is running. This has some value on systems
used as servers, but you may wish to turn it off (or change the
time interval) on a desktop workstation. To do so, use the -m
option to syslogd in /etc/rc.d/rc.syslog: -m 0 will turn off the
message entirely, and -m 60 will change the interval to 60 minutes,
for example. Check out man syslogd for more details.
How come I can play sound as root, but not as a normal user?
As of Slackware 9.2, sound devices belong to the audio
group. Users are automagically part of this group (through
/etc/login.defs), so all users should (hopefully) have access to
the sound device by default.
On older Slackware versions, simply adding users to the same
group that owns the sound device(s) resolves this problem.
See also the above answer to "Why am I unable to get sound after
setting up a graphical login program". Graphical display managers
do not apply settings in /etc/login.defs (they may have their own
settings). Again, the simplest fix is to add users with physical
access to the system to the same group that owns audio devices
(group "audio" on a stock modern Slackware system).
How can I start up my computer with an X login, rather than a console login?
As with most things Linux, there’s more than one way to accomplish
this, and either method may seem more appropriate for some systems
than for others.
The most common method is to edit /etc/inittab. This file configures
init which runs programs that use the virtual terminals (among
Change the line that says
Then cause init to re-read the file by signalling it with either of
the following commands (run as root):
kill -HUP 1
It’s also possible to use LILO to boot straight to an X login.
(i.e Boot to runlevel 4).
Create a stanza in /etc/lilo.conf that uses the "append" command to
tell the system to boot into runlevel 4 (which Slackware uses for
launching X at boot-time):
image = /boot/vmlinuz
root = /dev/hda1
label = Linux-GUI
append = "4"
You can also tell LILO which runlevel to use at boot time. Assuming
you have lilo configured to prompt and wait for a boot command,
you can type <label> <runlevel>. The label is whatever you set
"label" to in /etc/lilo.conf. For example, if you have set your
kernel’s label to "linux", you would type "linux 4" to boot into
the X system (or "linux 1" to boot into single-user mode, though
that should really be described in a separate FAQ entry).
I made changes to /etc/motd. Why are they overwritten when I reboot?
Because /etc/rc.d/rc.S overwrites this file at boot time. Comment out
the following lines in that file to change this behaviour:
# Setup the /etc/motd to reflect the current kernel level:
# THIS WIPES ANY CHANGES YOU MAKE TO /ETC/MOTD WITH EACH BOOT.
# COMMENT THIS OUT IF YOU WANT TO MAKE A CUSTOM VERSION.
echo "$(/bin/uname -sr)." > /etc/motd
Are there any guides on compiling a new kernel?
I get a huge font in the console / a blank screen on boot since I’ve installed a new kernel
It’s possible that you didn’t select the framebuffer options in the
kernel, which give you the nice high-resolution in the console.
To fix this, go back in to "make menuconfig" or "make xconfig", and
under "code maturity level options", select the "Prompt for
development and/or incomplete code/drivers". Then under "Console
drivers", go in to "Frame-buffer support" and then select "VESA VGA
graphics console". Then recompile and boot.
2.6 Kernel users may also want to take note of the following, which
can be found in more detail at
A lot of people have discovered that taking their .config from 2.4
and running make oldconfig to pick up new options leads to problems,
notably with CONFIG_VT not being set.
How do I stop $DRIVER_OLD from loading at boot time? I want to use $DRIVER_NEW.
echo $DRIVER_OLD >> /etc/hotplug/blacklist
Slackware uses the hotplug feature of recent 2.4.x kernels to
automatically load drivers for detected hardware. If you want to
use a different driver for your hardware, such as an ALSA sound card
driver, you can disable the hotplug system from using the previous
driver in this way.
As an alternative you can disable the hotplug feature. As root,
chmod -x /etc/rc.d/rc.hotplug
or remove the entire package with:
Hotplug is especially useful for PCMCIA and USB devices. For more
information see the Linux-hotplug Web site:
In Slackware 11.0 and later versions, the hotplug subsystem has been
replaced by udev when using 2.6.15 and newer kernels. Documentation
on udev is relatively scarce, but this site should be of assistance:
It’s also prudent to note that module loadtime options and blacklisting
is now handled in /etc/modprobe.d/* files instead of the old
/etc/modules.conf (for 2.4.x kernels) or /etc/modprobe.conf (2.6.x).
A reasonable set of default values should be present in a normal
installation of Slackware 11.0, but blacklisting of modules that you
don’t want to load is done in /etc/modprobe.d/blacklist, and any
load-time options you wish to specify makes the most sense in
/etc/modprobe.d/options (this file does not exist by default - you
must create it).
After recompiling the kernel, the sound doesn’t work!
Slackware now uses the ALSA sound drivers by default. The ALSA
drivers are not native to the 2.4 kernel, so they need to be
recompiled, reinstalled separately from a Slackware package, or
be moved before kernel compilation. If you have installed and are
using a 2.6 kernel, then this issue shouldn’t effect you, as long
as you’ve enabled ALSA support within the new kernel configuration.
There are several ways in which you can restore the ALSA drivers on
a newly compiled 2.4 kernel. Note that only one of these methods
should be necessary.
If you have (re)installed a 2.4.x kernel of the same version number
that shipped with your Slackware distribution, the following options
are available to you:
Reinstall the alsa-driver package from the Slackware installation
media. (E.g installpkg /cdrom/slackware/a/alsa-driver-*.tgz).
/lib/modules/```uname -r``/kernel/driver/sound ` directory to
/lib/modules/```uname -r``/sound. ` That way, they will be safe
from being overwritten by steps taken to recompile the kernel.
This has to be done before recompiling the kernel.
Recompile new drivers from source. The ALSA driver source can be
downloaded from http://www.alsa-project.org. It may be necessary
to recompile the ALSA libraries, utilities or tools. Check the
documentation on the ALSA web site for details.
If you have upgraded to a newer kernel than shipped with the Slackware
version you’re using, then re-installing the ALSA sound driver (and
possibly library and utilities) from source is your only option.
The good news is that it isn’t difficult to do.
It has been noted that if you enable module version support in the
kernel, (CONFIG_MODVERSIONS=y), and recompile the alsa drivers,
you’ll be able to use the drivers with different kernel versions
without the need to recompile again.
Why do I get all these messages "Unresolved symbol" and/or "can’t locate module" when I boot my system?
Did you just rebuild the system kernel?
|The following applies to rebuilding a kernel of the same version
as was on the system before the problem described above started to
occur. Upgrades to newer kernels are not susceptible to this problem.
If your rebuilt kernel doesn’t include the same drivers built as
modules as the kernel it replaces, you need to remove the modules
directory from the kernel it replaces, and replace it with modules
built specifically for this new kernel. The easiest way to do this,
while still ensuring that you can back out of the change and return
to the previous working kernel (and its modules) should things go
wrong, is to rename the relevant modules directory prior to calling
"make modules-install" during the kernel building process:
make -s modules
mv /lib/modules/`uname -r` /lib/modules/`uname -r`.`date +%Y%m%d`
make -s modules_install
This problem can be avoided altogether by setting the "EXTRAVERSION"
variable for your custom kernel. In 2.4, edit the top-level Makefile,
in 2.6 change the kernelrelease name from "make menuconfig".
How do I change to KDE/other window manager?
The easiest way is to type
But note that if you have made changes to the files in /etc/X11/xinit,
these changes will be lost because xwmconfig replaces files in that
directory, rather than edits them. If you did make changes to such
files, make a point to create a backup copy of the files you editted.
You can then use these to merge your changes into the files created
If the window manager you want is installed but not listed by
xwmconfig, you can usually add its name to the last line of
~/.xinitrc like so:
echo "exec windowmanager" >> ~/.xinitrc
Alternatively, to get a window manager listed on the xwmconfig
screen, look in /etc/X11/xinit/ and create a similar xinitrc file for
your window manager in that directory.
Why do I get a weird saying (or fortune) whenever I log in?
The command is being run out of /etc/profile (or /etc/csh.profile),
which call additional scripts like so:
for file in /etc/profile.d/*.sh ; do
if [ -x $file ]
This translates to "Run every file in the /etc/profile.d directory if
the filename ends in .sh and it’s executable." There’s a file called
bsd-games-login-fortune.sh which has a call to the program fortune.
fortune is the actual program that prints out the weird saying or
quote when users login.
If you don’t like the message, disable it by Removing execute
permission on the script permission (this needs to be done as root):
chmod a-x /etc/profile.d/bsd-games-login-fortune.sh
You’ll need to do the same with bsd-games-login-fortune.csh, so that
users on your system that use csh or tcsh as their login shell will
not see these fortune messages either.
My scrollmouse won’t work in X
This is because X does not know how many buttons your mouse has, and
what to do with the extra buttons. There are two buttons (up and
down) per wheel. If the scroll wheel can also be pressed, or you’re
emulating three buttons (pressing left and right mouse buttons at the
same time to create a middle mouse button), then you have 5 buttons,
for most basic scoll mice. To configure X to use your mouse
correctly, ensure the following is in your /etc/X11/xorg.conf
Option "Protocol" "IMPS/2"
Option "Device" "/dev/psaux"
#Option "Buttons" "3"
Option "Buttons" "5"
Option "ZAxisMapping" "4 5"
You may need to edit Device and Protocol to suit your mouse. If its
a PS/2, then use IMPS/2. Should you be using a Logitech device,
either mouse or trackball, use MouseManPlusPS/2 as your protocol.
More information can be found in /usr/X11R6/lib/X11/doc/README.mouse
Removable devices aren’t auto-mounting on Slackware-12.0 with HAL
Please note that this is not a Slackware-specific issue. This problem
has been encountered with other Linux distributions, and is discussed
on the various Linux forums.
Console users are automatically added to the cdrom and plugdev
groups at login via /etc/login.defs. The intention was that HAL and
auto-mounting of removable devices would just work without the need
for admins to manually add users to the plugdev and cdrom groups,
but due to the way dbus functions, this turns out not to be the case.
When the messagebus service is started, it reads the content of
/etc/group and then determines whether users have rights to mount
removable devices based on that. This is why the reload option
was added to /etc/rc.d/rc.messagebus, as you need to make it aware
of any changes to /etc/group if you happen to edit that file to add
users to plugdev, cdrom, power, or video groups while dbus is running.
The solution is to manually add users to the necessary groups (cdrom
and plugdev) - do not rely on the output of groups(1) to determine
whether a user is in the appropriate group as it pertains to dbus
Help! I think I’ve been hacked!!!
Every so often you’re going to run across something strange and
unusual, perhaps so strange and unforeseen that you immediately
think someone else must have done it, and that can only mean that
your computer must have been compromised.
The first thing you should always remember is to remain calm.
Very often people suspect a system compromise when there is some
other more likely explanation for the observed behaviour. You may
have created the behaviour yourself without knowing it, or you may
have stumbled across something slackware has been doing all along
without your knowledge.
Of course your system might indeed have been compromised. But how
can you be sure? The following checklist can guide you through
some simple checks that will help you confirm whether the behaviour
you’re seeing from your system is expected, something you created,
or the result of a system compromise (or some other event):
Check /root/.bashrc /root/.bash_profile /root/.bash_history
and /etc/profile for any unexpected modifications. Remember
that if you’re using tcsh (or csh) as your root user’s shell,
that you need to check instead (or perhaps "also") /root/.cshrc
and /root/.login. One thing you definitely want to look for is
history redirection. Many root kits and script kiddies set the
HISTFILE environment variable to "/dev/null" so their activities
aren’t ever logged anywhere.
Check /etc/passwd and /etc/shadow for unespected additions.
Look especially for multiple accounts with uid 0.
Note that the Slackware installation CD (especially disk 2 in
some older versions of a full Slackware distribution) can make an
excellent emergency investigation/rescue disk in the event that
your system has been compromised and you suspect some important
binaries may have been over-written.
If possible, portscan your system with both TCP and UDP scanners,
from another system on the same network. Run a packet logger
(such as tcpdump) (preferably not on the system you believe
has been compromised) to see where traffic (if any) is going.
If something out of the ordinary shows up, try using "lsof" or
"fuser" to determine the PID of the process that is using the
port associated with the suspect traffic.
If the system you're concerned about is directly connected (ie. not
through any sort of IP masquerading or "NAT" device, and not through
a restrictive firewall) to the Internet, and you don't have access
to another system you can use to run a portscan against it, you
might find it worth using one of the online portscanning sites
against your system. There are any number of these, but the one
listed here has been tested by folks on the alt.os.linux.slackware
newsgroup, and is believed to be legitimate:
Search through /dev, /tmp, /var/tmp, and /home for unexpected
contents. Many rootkits and intruders like to hide their binaries
in here. In particular, search for anything executable using
Check all your boot scripts under /etc/rc.d and /etc/inittab for
unexpected modifications. It’s worth keeping backup copies of
these, perhaps on the same removable media you use to keep copies
of the commonly modified tools listed above, so you can compare
the versions on the system with the known good copies. However,
you’ll need to establish some sort of routine to make sure
the backup copies are updated whenever you make ("authorized")
changes to any of these files.
Check also the /etc/sudoers file and other critical configuration
files for unexpected modifications, and check /etc/groups to make
sure an attacker hasn’t added a userid to the gid 0 group (usually
"system" or "root") or some group that has sudo privillages.
Look in /usr/local for any unexpected new binaries. Intruders
don’t typically put new binaries in places like that, but it
never hurts to be a little catious.
If necessary, install a known good kernel (bare.i, scsi.s from
the Slackware cds) and reboot. It’s best to have a monolithic
kernel without support for modules in this case. Sometimes an
intruder might slip in a kernel module that gives them elevated
privilege on your system.
After all the above have been checked, if you still haven’t found any
indication of compromise, you can be pretty confident that either
a) your system wasn’t actually compromised, or b) it was compromised
by an intruder who is very skilled at covering up his or her tracks!
How do I get vmware to work on Slackware?
Have a look at the following web page for a guide:
Can I create encrypted Filesystems in Linux?
Yes, with a little work.
1) Read the Cryptoloop-HOWTO in the Linux-HOWTOs dir, or from
http://www.tldp.org/. You MUST patch and modify source code,
so be careful.
2) Get the source for the util-linux module, and unpack it. BE SURE
TO USE THE SLACKWARE SOURCE which has a config file already setup.
DO NOT UNINSTALL any packages since util-linux is part of a larger
group of packages.
3) Get the two patches mentioned in the HOWTO and apply. Current
versions of Slackware ship util-linux-2.12a and the patches are
for 2.12, but they work.
4) compile using ./configure make and su -c "make install"
4a) You may also need to add modules to your kernel and recompile it
as well as modifying startup scripts (I use rc.local for loading
the crypto modules).
5) follow the directions for formatting your encrypted disk.
One nice thing about Cryptoloop is that you can create a virtual
disk (i.e. a fixed size file that you can mount as a filesystem)
to keep sensitive data in your home directory or any other place,
without having to waste a whole partition.
6) As of 2005, there is a very easy to set up kernel module for
encrypting filesystems. It is based on FUSE and it is called EncFS.
It can be compiled and installed without recompiling your kernel.
Can I use packages from Slackware-current on my Slackware-$VERSION system?
No. DO NOT MIX PACKAGES FROM -CURRENT INTO A STABLE RELEASE!
There are a few notable exceptions to this that will work fine, but
for the most part, the above applies. Either upgrade your system
completely to Slackware -current, or stick with the stable release
packages (plus applicable patches).
If you decide to upgrade to -current, you have a lot of reading
to do. Start with UPGRADE.TXT in the -current tree, and also
have a look at http://slackwiki.org/Release_Changes
How do I create my own Slackware packages?
The following URLS are good references:
PART IV: not Slackware, but Slackware-related
Why do most package builders and SlackBuild scripts use prefix=/usr instead of /usr/local
The SlackBuilds.Org maintainers cite, as their rationale for this
Software installed by a means other than packages needs to go to
/usr/local so that it’s easier to track. Ideally, you build it in
/usr/local/src (and leave the source directory there) so that if
you ever need/want to uninstall it, you can go back to the source
dir and call "make uninstall" (assuming the uninstall target is
present in the software’s Makefile).
On the other hand, when you build a package of some software and
then install that package, the whole maintenance issue is, well,
not an issue. The package can be managed just like the remainder
of the packages installed on the distribution.
PART V: about the FAQ
Where can I find the most current version of this FAQ?
This FAQ currently resides at:
An HTML-converted version can be found at:
It is based on and hopefully will ultimately replace the FAQ-O-Matic
May I mirror/modify the FAQ?
Sure, but if you make any changes to the copy you’re mirroring, please
make a point to give proper credit for the source you started from.
May I contribute to the FAQ?
Contributions are encouraged, though no promise is made that they
will be accepted verbatim. Any contributions that are accepted,
will of course result in due credit given. To contribute to the
FAQ, send your suggested updates or new entries either to the FAQ
maintainer directly (, as of this
writing), or to the alt.os.linux.slackware newsgroup.
This is a list of people who have contributed to the answers in this
FAQ, in no particular order, other than the order in which their
contributions were found when looking to compile this list. Wherever
possible, listed here are contribitors' full names or best-known
aliases. Otherwise, the email address used when the contribution
was made is listed. Anyone who is listed by email address but would
prefer to be listed by full name, or whose name is misspelled should
contact to submit the correction.
Patrick Volkerding (quoted without permission)
Jack S. Lai
Aaron W. Hsu
Hans de Bruin