diff options
Diffstat (limited to 'chapter_03.xml')
| -rw-r--r-- | chapter_03.xml | 391 |
1 files changed, 391 insertions, 0 deletions
diff --git a/chapter_03.xml b/chapter_03.xml new file mode 100644 index 0000000..f3fdbf6 --- /dev/null +++ b/chapter_03.xml @@ -0,0 +1,391 @@ +<?xml version="1.0"?> +<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" + "/usr/share/xml/docbook/xml-dtd-4.5/docbookx.dtd"> + +<chapter> +<title>Booting</title> + +<para> +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. +</para> + +<section> +<title><application>mkinitrd</application></title> + +<para> +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. +</para> + +<para> +If you look inside your <filename>/boot</filename> directory, you'll +see the various kernels installed on your system. +</para> + +<screen><prompt>darkstar:~# </prompt><userinput>ls -l /boot/vmlinuz*</userinput> +/boot/vmlinuz-huge-2.6.29.4 /boot/vmlinuz-generic-2.6.29.4 +</screen> + +<para> +Here you can see that I have two kernels installed, +<filename>vmlinuz-huge-2.6.29.4</filename> and +<filename>vmlinuz-generic-2.6.29.4</filename>. 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. +</para> + +<para> +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, +<application>mkinitrd</application>(8). +</para> + +<para> +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". +</para> + +<para> +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. +</para> + +<para> +initrds are compressed <application>cpio</application>(1) archives, so +creating them isn't very straightforward. Fortunately for you, +Slackware includes a tool that makes this very easy, +<application>mkinitrd</application>. A full discussion of +<application>mkinitrd</application> 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 +<application>mkinitrd</application> with the <arg>--help</arg> +argument. +</para> + +<screen><prompt>darkstar:~# </prompt><userinput>mkinitrd --help</userinput> +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 .... +</screen> + +<para> +When using <application>mkinitrd</application>, 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 +<application>mount</application> command. +</para> + +<screen><prompt>darkstar:~# </prompt><userinput>mount</userinput> +/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) +</screen> + +<para> +In the example provided, you can see that the root partition is located +on <filename>/dev/sda1</filename> and is an ext4 type partition. If we +want to create an initrd for this system, we simply need to tell this +information to <application>mkinird</application>. +</para> + +<screen><prompt>darkstar:~# </prompt><userinput>mkinitrd -f ext4 -r /dev/sda1</userinput> +</screen> + +<para> +Note that in most cases, <application>mkinitrd</application> 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. +</para> + +<para> +Looking up all those different options for +<application>mkinitrd</application> 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, +<filename>mkinitrd.conf</filename>(5). You can find a sample file that +can be easily customized for your system under the +<filename>/etc</filename> directory. Here's mine. +</para> + +<screen># 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" +</screen> + +<para> +For a complete description of each of these lines and what they do, +you'll need to consulte the man page for +<filename>mkinitrd.conf</filename>. Once each of these is setup, you +need only run <application>mkinitrd</application> with the +<arg>-F</arg> argument. A proper initrd file will be constructed and +installed for you, without you having to remember all those obscure +arguments. +</para> + +</section> + +<section> +<title>LILO</title> + +<para> +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 <filename>extra/</filename> +directory on one of your Slackware CDs. Since LILO is the default +Slackware bootloader however, we'll focus exclusively on it. +</para> + +<para> +Configuring LILO can be a little daunting for new users, so Slackware +comes with a special setup tool, <application>liloconfig</application>. +Normally, <application>liloconfig</application> is first run by the +installer, but you can run it at anytime from a terminal. +</para> + +<para> +FILL THIS IN!!!! Picture of liloconfig +</para> + +<para> +<application>liloconfig</application> 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 <filename>lilo.conf</filename> +file so that you can choose which operating system to boot when you +turn your computer on. +</para> + +<para> +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. +<application>liloconfig</application> 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. +</para> + +<para> +<application>liloconfig</application> 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, +<filename>lilo.conf</filename>(5) under the <filename>/etc</filename> +directory. The <filename>lilo.conf</filename> 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. +</para> + +<screen># 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 .... +</screen> + +<para> +For a complete listing of all the possible LILO options, you should +consult the man page for <filename>lilo.conf</filename>. In brief, +we'll discuss the most common in this document. +</para> + +<para> +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 <filename>/dev/sda</filename>. If you're using an IDE +drive, you will probably have to use <filename>/dev/hda</filename>. 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 <filename>/dev/sda1</filename>. +</para> + +<para> +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 <application>liloconfig</application>. You may (and +probably should) see something similar when looking at your own +<filename>lilo.conf</filename>. 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. :^) +</para> + +<para> +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 +<filename>lilo.conf</filename> that boots both Slackware and Microsoft +Windows. +</para> + +<screen># 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 +</screen> + +<para> +For Linux operating systems like Slackware, the image line specifies +which kernel to boot. In this case, we're booting +<filename>/boot/vmlinuz-generic-2.6.29.4</filename>. 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 +<application>mkinitrd</application>. +</para> + +<para> +Once you've gotten your <filename>lilo.conf</filename> setup for your +machine, simply run <application>lilo</application>(8) to install it. +Unlike GRUB and other bootloaders, LILO requires you re-run +<application>lilo</application> anytime you make changes to its +configuration file in order for those changes to be installed. +</para> + + +<screen><prompt>darkstar:~# </prompt><userinput>lilo</userinput> +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. +</screen> + +<para> +Don't be scared by many of the warnings you may see when running +<application>lilo</application>. 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. +</para> + +</section> + +</chapter> |