Ok, now that you've gotten Slackware installed on your system, you should learn exactly what controls the boot sequence of your machine, and how to fix it should you manage to break it somehow. Use Linux long enough, and sooner or later you will make a mistake that breaks your bootloader. Fortunately, this doesn't require a re-install to fix. Unlike many other operating systems that hide the underlying details of how they work, Linux (and in particular, Slackware) gives you full control over the boot process. Simply by editing a configuration file or two and re-running the boot-loader installer, you can quickly and easily change (or break) your system. Slackware even makes it easy to dual-boot between multiple operating systems such as other Linux distributions or Microsoft Windows.

Before we go any further, a quick discussion on the Linux kernel is warranted. Slackware Linux includes several different kernels. While they are all compiled from the same source code, and hence are the "same", they are not identical. Depending on your architecture and Slackware version, the installer may have loaded your system with several kernels. There are kernels for single-processor systems and kernels for multi-processor systems. In the old days, there were tons of kernels for installing on different kinds of hard drive controllers. More importantly for our discussion, there are "huge" kernels and "generic" kernels. If you look inside your /boot directory, you'll see the various kernels installed on your system. darkstar:~# ls -l /boot/vmlinuz* /boot/vmlinuz-huge-2.6.29.4 /boot/vmlinuz-generic-2.6.29.4 Here you can see that I have two kernels installed, vmlinuz-huge-2.6.29.4 and vmlinuz-generic-2.6.29.4. Each Slackware release includes different kernel versions and sometimes even slightly different names, so don't be alarmed if what you see doesn't exactly match what I have listed here. Huge kernels are exactly what you might think; they're huge. These kernels are built to support nearly every conceivable computer Slackware is supported on. They most certainly contain support for hardware your machine does not, and never will, have. These are included for several reasons, but the most important perhaps is in use by the installer. These are the kernels the Slackware installation disks run. If you chose to let the installer configure your bootloader for you, it chooses to use these kernels due to the incredible variety of hardware they support. By contrast, the generic kernels support very little hardware without the use of external modules. If you want to use one of the generic kernels, you'll need to make use of something called an initrd, and the tool to make them, mkinitrd(8). So why should you use a generic kernel? Currently the Slackware development team recommends use of a generic kernel for a variety of reasons. Perhaps the most obvious is size. The huge kernels are currently about twice the size of the generic kernels before they are uncompressed and loaded into memory. If you are running an older machine, or one with some small ammount of RAM, you will appreciate the savings the generic kernels offer you. Other reasons are somewhat more difficult to quantify. Conflicts between drivers included in the huge kernels do appear from time-to-time, and generally speaking, the huge kernels do not perform as well as the generic ones. Also, by using the generic kernels, special arguments can be passed to hardware drivers seperately, rather than requiring these options be passed on the kernel command line. Some of the tools included with Slackware work better if your kernel uses some drivers as modules rather than "hard-coding" them into the kernel. If you're having trouble understanding this, don't be alarmed, just think "huge kernel: good, generic kernel: better". Unfortunately, using the generic kernels isn't as straight-forward as using the huge kernels. In order for the generic kernel to boot your system, you must also usually include a few basic modules in an initird. Modules are pieces of compiled kernel code that can be inserted or removed from a running kernel. This makes the system somewhat more flexible at the cost of a tiny bit of added complexity. You might find it easier to think of modules as device drivers, at least for this section. Typically you will need to add the module for whatever filesystem you chose to use for your root partition during the installer. If your root partition is located on a SCSI disk or RAID controller, you'll need to load those modules as well. Finally, if you're using software RAID, disk encryption, or LVM, you'll also need to create an initrd whether you're using the generic kernel or not. initrds are compressed cpio(1) archives, so creating them isn't very straightforward. Fortunately for you, Slackware includes a tool that makes this very easy, mkinitrd. A full discussion of mkinitrd is a bit beyond the scope of this book, but we'll show you all the highlights. For a more complete explanation, check the manpage or run mkinitrd with the --help argument. darkstar:~# mkinitrd --help mkinitrd creates an initial ramdisk (actually an initramfs cpio+gzip archive) used to load kernel modules that are needed to mount the root filesystem, or other modules that might be needed before the root filesystem is available. Other binaries may be added to the initrd, and the script is easy to modify. Be creative. :-) .... many more lines deleted .... When using mkinitrd, you'll need to know a few items of information: your root partition, your root filesystem, any hard disk controllers you're using, and whether or not you're using LVM, software RAID, or disk encryption. Unless you're using some kind of SCSI controller (and have your root partition loaded on the SCSI controller), you should only need to know your root filesystem and partition type. Assuming you've booted into your Slackware installation using the huge kernel, you can easily find this information with the mount command. darkstar:~# mount /dev/sda1 on / type ext4 (rw,barrier=1,data=ordered) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) usbfs on /proc/bus/usb type usbfs (rw) /dev/sda2 on /home type jfs (rw) tmpfs on /dev/shm type tmpfs (rw) In the example provided, you can see that the root partition is located on /dev/sda1 and is an ext4 type partition. If we want to create an initrd for this system, we simply need to tell this information to mkinird. darkstar:~# mkinitrd -f ext4 -r /dev/sda1 Note that in most cases, mkinitrd is smart enough to determine this information on its own, but it never hurts to specify it manually. Now that we've created out initrd, we simply need to tell LILO where to find it. We'll focus on that in the next section. Looking up all those different options for mkinitrd or worse, memorizing them, can be a real pain though, especially if you try out different kernels consistently. This became tedious for the Slackware development team, so they came up with a simple configuration file, mkinitrd.conf(5). You can find a sample file that can be easily customized for your system under the /etc directory. Here's mine. # mkinitrd.conf.sample # See "man mkinitrd.conf" for details on the syntax of this file # SOURCE_TREE="/boot/initrd-tree" CLEAR_TREE="0" OUTPUT_IMAGE="/boot/initrd.gz" KERNEL_VERSION="$(uname -r)" #KEYMAP="us" MODULE_LIST="ext3:ext4:jfs" #LUKSDEV="/dev/hda1" ROOTDEV="/dev/raven/64root" ROOTFS="ext4" #RESUMEDEV="/dev/hda2" #RAID="0" LVM="1" #WAIT="1" For a complete description of each of these lines and what they do, you'll need to consulte the man page for mkinitrd.conf. Once each of these is setup, you need only run mkinitrd with the -F argument. A proper initrd file will be constructed and installed for you, without you having to remember all those obscure arguments.

LILO is the Linux Loader, and currently the default boot loader installed with Slackware Linux. If you've used other Linux distributions before, you may be more familiar with GRUB. If you prefer to use it, you can easily find it in the extra/ directory on one of your Slackware CDs. Since LILO is the default Slackware bootloader however, we'll focus exclusively on it. Configuring LILO can be a little daunting for new users, so Slackware comes with a special setup tool, liloconfig. Normally, liloconfig is first run by the installer, but you can run it at anytime from a terminal. FILL THIS IN!!!! Picture of liloconfig liloconfig has two modes of operation: simple and expert. The simple mode tries to automatically configure lilo for you. If Slackware is the only operating system installed on your computer, the simple mode will almost always do the right thing quickly and easily. It is also very good at detecting Windows installations and adding them to the lilo.conf file so that you can choose which operating system to boot when you turn your computer on. In order to use expert mode, you'll need to know Slackware's root partition. You can also setup other linux operating systems if you know their root partitions, but this may not work as well as you'd expect. liloconfig will try to boot each linux operating system with Slackware's kernel, and this is probably not what you want. Fortunately, setting up Windows partitions in expert mode is trivial. One hint when using expert mode. You should almost always install LILO to the Master Boot Record (MBR). Once upon a time, it was recommended to install the boot loader onto the root partition and set that partition as bootable. Today, LILO has matured greatly and is safe to install on the MBR. In fact, you will encounter fewer problems if you do so. liloconfig is a great way to quickly setup your boot loader, but if you really need to know what's going on you'll need to look at LILO's configuration file, lilo.conf(5) under the /etc directory. The lilo.conf file is seperated into several sections. At the top you'll find a global section where you specify things like where to install LILO (generally the MBR), any special images or screens to show on boot, and the timeout after which LILO will boot the default operating system. Here's what the global section of my lilo.conf file looks like in part. # LILO configuration file boot = /dev/sda bitmap = /boot/slack.bmp bmp-colors = 255,0,255,0,255,0 bmp-table = 60,6,1,16 bmp-timer = 65,27,0,255 append=" vt.default_utf8=0" prompt timeout = 50 # VESA framebuffer console @ 1024x768x256 vga = 773 .... many more lines ommitted .... For a complete listing of all the possible LILO options, you should consult the man page for lilo.conf. In brief, we'll discuss the most common in this document. The first thing that should draw your attention is the boot line. This determines where the bootloader is installed. In order to install the the MBR of your hard drive, you simply list the hard drive's device entry on this line. In my case, I'm using a SATA hard drive that shows up as SCSI device /dev/sda. If you're using an IDE drive, you will probably have to use /dev/hda. In order to install to the boot block of a partition, you'll have to list the partition's device entry. For example, if you are installing to the first partition on the only SATA hard drive in your computer, you would probably use /dev/sda1. The prompt option simply tells LILO to ask (prompt) you for which operating system to boot. Operating systems are each listed in their own section deeper in the file. We'll get to them in a minute. The timeout option tells LILO how long to wait (in tenths of seconds) before booting the default OS. In my case, this is 5 seconds. Some systems seem to take a very long time to display the boot screen, so you may need to use a larger timeout value than I have set. This is in part why the simple LILO installation method utilizes a very long timeout (somewhere around 2 whole minutes). The append line in my case was setup by liloconfig. You may (and probably should) see something similar when looking at your own lilo.conf. I won't go into the details of why this line is needed, so you're just going to have to trust me that things work better if it is present. :^) Now that we've looked into the global section, let's take a look at the operating systems section. Each linux operating system section begins with an "image" line. Microsoft Windows operating systems are specified with an "other" line. Let's take a look at a sample lilo.conf that boots both Slackware and Microsoft Windows. # LILO configuration file ... global section ommitted .... # Linux bootable partition config begins image = /boot/vmlinuz-generic-2.6.29.4 root = /dev/raven/64root initrd = /boot/initrd.gz label = Slackware64 read-only # Linux bootable partition config ends # Windows bootable partition config begins other = /dev/sda3 label = Windows table = /dev/sda # Windows bootable partition config ends For Linux operating systems like Slackware, the image line specifies which kernel to boot. In this case, we're booting /boot/vmlinuz-generic-2.6.29.4. The remaining sections are pretty self-explainatory. The tell LILO where to find the root filesystem, what initrd (if any) to use, and to initially mount the root filesystem read-only. That initrd line is very important for anyone running a generic kernel, or using LVM or software RAID. It tells LILO (and the kernel) where to find the initrd you created using mkinitrd. Once you've gotten your lilo.conf setup for your machine, simply run lilo(8) to install it. Unlike GRUB and other bootloaders, LILO requires you re-run lilo anytime you make changes to its configuration file in order for those changes to be installed. darkstar:~# lilo Warning: LBA32 addressing assumed Warning: '/proc/partitions' does not match '/dev' directory structure. Name change: '/dev/dm-0' -> '/dev/raven/swap' Warning: Name change: '/dev/dm-1' -> '/dev/raven/root' Warning: Name change: '/dev/dm-2' -> '/dev/raven/home' Warning: Name change: '/dev/dm-3' -> '/dev/raven/src' Warning: Name change: '/dev/dm-4' -> '/dev/raven/64root' Added Slackware * Added Backup 6 warnings were issued. Don't be scared by many of the warnings you may see when running lilo. In my case, most of these warnings are issued by the use of LVM. Unless you see a fatal error, things should be just fine.