source: BOOK/bootable/x86_64-64/lilo.xml@ 0f9d1e9

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE sect1 PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
  "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
  <!ENTITY % general-entities SYSTEM "../../general.ent">
  %general-entities;
]>

<sect1 id="ch-bootable-lilo">
  <?dbhtml filename="lilo.html"?>

  <title>Making the CLFS System Bootable</title>

  <indexterm zone="ch-bootable-lilo">
    <primary sortas="a-Lilo">Lilo</primary>
    <secondary>configuring</secondary>
  </indexterm>

    <para os="a">Your shiny new CLFS system is almost complete. One of the
      last things to do is to ensure that the system can be properly
      booted. The instructions below apply only to computers using Lilo,
      which in the context of this book means x86_64 Pure64 systems.
      Information on <quote>boot loading</quote> for other architectures
      should be available in the usual resource-specific locations for
      those architectures.</para>

  <xi:include xmlns:xi="http://www.w3.org/2003/XInclude"
  href="../x86/grub.xml"
  xpointer="xpointer(//*[@os='b'])"/>

    <para os="c">If you have multiple systems on your machine using a
      different bootloader such as GRUB, you may prefer to use that
      instead - consult the appropriate documentation.  The rest of
      this section assumes you are going to use Lilo.</para> 

    <para os="d">Earlier, we compiled and installed the Lilo boot loader
      software in preparation for this step. The procedure involves
      writing a boot image to a specific location on the hard drive.
      We highly recommend using mkrescue to create a Lilo boot CD
      (using e.g. dvdrecord from dvdrtools) as a backup (this requires
      loopback block device support in the kernel).</para>

    <para os="e">Normally, you interact with Lilo by using the cursor
      and <literal>enter</literal> keys to select from the available
      option(s), but sometimes it is necessary to add other boot
      options, such as e.g. 'init=/bin/bash' to debug boot failures.
      The more your keyboard layout differs from the US qwerty layout,
      the harder it becomes to type boot options unless Lilo knows
      about your keyboard layout. So, we will create a key table for
      Lilo (.ktl) file - at one point in the documentation these are
      referred to as .klt files, which may be a typo, but has been
      followed by some distros.  The name, and location, are not
      important but it is conventional to put these in /boot with
      the name representing the key layout.  For a British keyboard
      layout, the following command will achieve this:</para> 

<screen os="f" role="nodump"><userinput>keytab-lilo.pl uk >/boot/uk.ktl</userinput></screen>

    <para os="g">The argument to the command is the name of the keymap,
      or if necessary you can specify the full path to the keymap.  Use
      whatever is appropriate for your keyboard.</para>

    <para os="h">When the x86 CLFS book used to include Lilo, it
    advised against running it from chroot in case the MBR became
    corrupted. Provided you have /proc mounted and have device special
    files for the disks, it seems to be safe to run recent versions of
    Lilo in chroot, although it is always possible that an updated
    bootloader, or defective configuration file, may render the system
    unbootable.</para>  

    <para os="i">The next step is to create /etc/lilo.conf:</para>

<screen os="j" role="nodump"><userinput>cat &gt; /etc/lilo.conf &lt;&lt; "EOF"
<literal># Begin /etc/lilo.conf
# lilo.conf
#
# global options
boot=/dev/&lt;bootdisk&gt;
keytable=/boot/&lt;keytable&gt;
lba32
map=/boot/map
prompt

# set the name of the default image to boot
default=clfs

# define an image
image=/boot/clfskernel
    label=clfs
    root=/dev/&lt;partition&gt;
    read-only
# optionally add parameters to pass, e.g.
#   append="video=radeonfb:1024x768-16@70"

# repeat for any other kernel images

# optionally, add legacy operating systems
# see man lilo.conf for examples 
EOF</literal></userinput></screen>


    <para os="k">Replace &lt;bootdisk&gt; with the name of the disk (or
      partition) on which the boot sector is to be written, e.g. sda.
      Replace &lt;keytable&gt; with the name of the keytable file you
      created, and &lt;partition&gt; with the name of the root partition
      for the new system.
    </para>

  <warning os="l">
    <para>The following command will overwrite the current boot loader.
    Do not run the command if this is not desired.</para>
  </warning>

    <para os="m">Run Lilo:</para>

<screen os="n" role="nodump"><userinput>/sbin/lilo -v</userinput></screen>

  <note os='o'>
    <para>People who have been used to GRUB need to be aware that
      Lilo works differently - in particular, you cannot edit the
      available choices as you can in the <command>grub</command> shell,
      and Lilo records the block addresses of the kernels into the boot
      blocks each time /sbin/lilo is run. This means that when you
      compile a new kernel, you have to add it to /etc/lilo.conf and
      rerun /sbin/lilo.  It also means that if you recompile an existing
      kernel and save it to the same name you still have to rerun /sbin/lilo
      in case it now occupies different blocks on the filesystem.</para>
  </note>

    <para os="p">If you are running multiple systems on this box and
    using Lilo, it is a good idea to ensure that each system is running
    the same version of Lilo, otherwise an old version may not be able
    to overwrite the bootloader from a newer version.  You will also
    need to ensure that the copies of /etc/lilo.conf on each system are
    kept synchronised.</para>

</sect1>