%general-entities; ]> Making the CLFS System Bootable Lilo configuring 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 boot loading for other architectures should be available in the usual resource-specific locations for those architectures. 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. 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). Normally, you interact with lilo by using the cursor and enter 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: keytab-lilo.pl uk >/boot/uk.ktl 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. When the x86 LFS 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. The next step is to create /etc/lilo.conf cat > /etc/lilo.conf << "EOF" # Begin /etc/lilo.conf # lilo.conf # # global options boot=/dev/<bootdisk> keytable=/boot/<keytable> lba32 map=/boot/map prompt # set the name of the default image to boot default=lfs # define an image image=/boot/lfskernel label=lfs root=/dev/<partition> 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 Replace <bootdisk> with the name of the disk (or partition) on which the boot sector is to be written, e.g. sda. Replace <keytable> with the name of the keytable file you created, and <partition> with the name of the root partition for the new system. The following command will overwrite the current boot loader. Do not run the command if this is not desired. Run Lilo: /sbin/lilo -v 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 grub 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. 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.