This chapter introduces various methods for booting your installed
system. First, some of the technical details of the boot process
are explained to help understanding the various methods. This is
followed by a detailed description of GRUB (the current boot
manager of SuSE Linux) and its predecessor LILO.
After turning on your computer, the first thing that happens is that the BIOS (Basic Input Output System) takes control, initializes the screen and keyboard, and tests the main memory. At this point, no storage media or external devices are known to the system.
After that, the system reads the current date and time as well as information about the most important peripheral devices from the CMOS setup. After reading the CMOS, the BIOS should recognize the first hard disk, including details such as its geometry. It can then start to load the operating system (OS) from there.
To load the OS, the system loads a 512-byte data segment from the first hard disk into main memory and executes the code stored at the beginning of this segment. The instructions contained in it determine the rest of the boot process. This is why the first 512 bytes of the hard disk are often called the Master Boot Record (MBR).
Up to this point (loading the MBR), the boot sequence is independent of the installed operating system and is identical on all PCs. Also, all the PC has to access peripheral hardware are those routines (drivers) stored in the BIOS.
The layout of the MBR always follows a standard independent of the operating system. The first 446 bytes are reserved for program code. The next 64 bytes offer space for a partition table for up to four partitions (see Section 1). Without the partition table, no file systems exist on the hard disk -- the disk would be virtually useless without it. The last two bytes must contain a special ``magic number'' (AA55). An MBR containing a different number would be considered as invalid by the BIOS and by any PC operating system.
Boot sectors are the first sectors on a hard disk partition, except in the case of extended partitions which are just ``containers'' for other partitions. Boot sectors offer 512 bytes of space and are designed to contain code capable of launching an operating system on this partition. Boot sectors of formatted DOS, Windows, and OS/2 partitions do exactly that (and in addition, they contain some basic data about the file system structure). In contrast, the boot sector of a Linux partition is empty (even after creating a file system on it). Thus, a Linux partition can not bootstrap itself, even if it contains a kernel and a valid root file system.
A boot sector with a valid start code contains the same ``magic number'' as the MBR in its last two bytes (AA55).
The DOS MBR of the first hard disk contains information that determines which partition of a hard disk is ``active'' -- which partition should be searched for the operating system to boot. Therefore, DOS must be installed on the first hard disk. The executable code in the MBR (``first stage boot loader'') tests whether the marked partition contains a valid boot sector.
If this is the case, the ``second stage boot loader'' can be started from there. DOS system programs can now be loaded and you will see the usual DOS prompt. In DOS, only primary partitions can be marked active. Therefore, you cannot use logical partitions inside an extended partition as bootable DOS partitions.
The simplest boot concept involves only one machine with one operating system installed. The boot process for this case has already been outlined. The same boot concept can be used for a Linux-only machine. In this case, you could theoretically skip the installation of LILO or GRUB. However, in this case you would not be able to pass additional parameters to the system kernel at boot time. As soon as there is more than one operating system installed, there are several possible boot concepts:
One OS can be booted from the hard disk. Other operating systems can be booted using boot disks.
This allows you to use several operating systems on a single machine, and to choose among the installed systems at boot time. Switching to another operating system requires a reboot. The only condition is that the boot manager must be compatible with all the operating systems installed on the machine.
The main obstacle for booting an operating system is the fact the kernel usually is a file within a file system on a partition on a disk. These concepts are unknown to the BIOS. To circumvent this, ``maps'' and ``map files'' were introduced. These maps simply note the physical block numbers on the disk that comprise the logical files. When such a map is processed, the BIOS loads all the physical blocks in sequence as noted in the map, building the logical file in memory.
The main difference between LILO and GRUB is that LILO relies almost entirely on maps, whereas GRUB tries to get rid of fixed maps during boot as early as possible. This is accomplished by integrating file system code to the boot loader, so that files can be found by their path names rather than block numbers.
This difference has historical reasons: in the early days of Linux, many file systems were competing for dominance. Werner Almesberger wrote a boot loader that did not need to know in what kind of file system the kernel to boot actually resided. The idea behind the GRUB approach, however, is even older, from the ages of traditional Unix and BSD. These usually had a single file system of choice and often had a reserved space at its beginning in which to embed a boot loader. This boot loader knew the data structures of the file system in which it was embedded and kernels could be found by name in the root directory of that file system.
The following section describes the installation and configuration of a boot manager, using the Linux boot manager GRUB as an example. This is followed by a description of the differences when using LILO. A complete description of LILO is available in (), which is located in /usr/share/doc/packages/lilo/user.dvi.
You can view the text on screen with an application such as kdvi, or print it with the command: lpr /usr/share/doc/packages/lilo/user.dvi.
Note
[Which boot manager will be installed by default?]If you
update from a previous version of SuSE Linux where LILO was the
boot manager, the new system will continue to use LILO. If you
install SuSE Linux from scratch, the system will use GRUB, except
where the root partition is installed on a RAID system of the
following types:
Similar to LILO, GRUB (the Grand Unified Boot loader) consists of two stages. The first stage is just 512 bytes long. It is written to the MBR or to the boot sector of a disk partition or floppy disk. The second, larger stage is loaded after that and holds the program code as such. The only purpose of the first stage is to load the second one.
From here, however, GRUB works differently than LILO, because the second stage contains code to read file systems. Currently supported are Ext2, Ext3, ReiserFS, JFS, XFS, Minix, and the DOS FAT file system used by Windows. GRUB has the ability to access file systems even before the boot process as such, as long as they are on devices handled by the BIOS (floppies or hard disks). This means that changes to the GRUB configuration do not require a reinstallation of the boot manager. On booting, GRUB just rereads its menu file to gather information about the paths and partitions where the kernel and the initial RAM disk (initrd) reside and is then able to find these files itself.
Another big advantage of GRUB is that all boot parameters can easily be changed before the actual booting. If it turns out that the menu file contains an error, it is still possible to fix it ``on the fly.'' GRUB also allows entering boot commands interactively through a prompt, which makes it possible to boot a system for which no entry has been written into the boot menu. Finally, GRUB is able to locate kernel and initrd images before the actual boot procedure.
GRUB displays a graphical splash screen or a text mode interface with a boot menu. The contents of this screen are controlled by the configuration file /boot/grub/menu.lst. This file contains all the information about the partitions or operating systems that can be selected from the boot menu.
This menu file is loaded by GRUB directly from the file system on each boot, so there is no need to update GRUB when the file has been modified. To reconfigure the boot loader, just edit the file via YaST or with your favorite editor.
The menu file contains commands GRUB should execute and its syntax is quite easy to grasp. Each line consists of a command, optionally followed by arguments that must be seperated by spaces, as is the case with shell commands. For historical reasons, there are some commands that allow an `=' before their first argument. Lines beginning with a hash (`#') are comments.
Each entry that should appear in the boot menu corresponds to a name in the configuration file, which must be preceded by the title keyword. In other words, the text string coming after title (including any spaces) is displayed as a selectable menu item. The following entries up to the next title entry are considered commands to execute when the menu item is selected.
A simple case of such a command is the chain loading of another operating system's boot loader. The command is called chainloader and the argument is usually another partition's boot block, written in the block notation of GRUB, for example:
GRUB's device naming scheme is explained in Section 4. The above example specifies the first block of the fourth partition on the first hard disk.
The command to specify a kernel image is just kernel. The first argument is the path to the kernel image on a partition. The remainder are parameters to pass to that kernel upon booting.
If the kernel does not have the necessary built-in file system or disk drivers to access the root partition, also include the initrd command. This GRUB command takes only one argument, which is the path to the initrd file. The initrd command must follow after the kernel command, because the kernel (already loaded at this point) assumes a certain loading address of the initrd image.
The root command simplifies the specification of kernel and initrd images. root takes a device or partition (in GRUB notation) as its only argument.
GRUB then appends the value of root to the beginning of all kernel, initrd, or other file paths that do not explicitly specify a device. This applies up to the next root command. The command is not used in the default menu.lst file created during the installation.
The boot command is implied and thus automatically executed at the end of each menu entry, so it does not need to be written into the menu file. On the other hand, if you should ever be in a situation where you have to enter GRUB commands interactively at the prompt, remember to issue the boot command at the end. The command itself has no arguments, it just boots the corresponding kernel image or chain loader.
Once you have written all your menu entries, specify which entry to use as the default. Otherwise, the first one (number 0) is booted by default. You can also specify a time-out in seconds after which this should occur. The timeout and default lines are usually written before the menu entries. A sample configuration file is described in Section 4.
GRUB names hard disks and partitions according to conventions which differ from the Linux device names that you might expect (such as /dev/hda1). The first hard disk is always referred to as /dev/hd0. The floppy drive is called /dev/fd0.
Note
[Counting Partitions]With GRUB, partitions are counted
beginning from zero. Accordingly, hd0,0 refers to the first
partition on the first hard disk. On a typical desktop machine with
just one hard drive connected as primary master, this corresponds to
the Linux device called /dev/hda1.
The four primary partitions that are allowed per disk are numbered from 0 to 3, and logical partitions are counted beginning with 4:
(hd0,0) first primary partition on first hard disk (hd0,1) second primary partition (hd0,2) third primary partition (hd0,3) fourth primary partition (usually an extended partition) (hd0,4) first logical partition (hd0,5) second logical partition ...
Note
[IDE, SCSI, and RAID] GRUB does not distinguish between IDE, SCSI, or
RAID devices. All hard disks as detected by the BIOS or other disk controllers
are counted according to the boot sequence as set in the BIOS itself.
The fact that BIOS device names do not correspond to Linux devices is a problem that exists for both LILO and GRUB. Both use similar algorithms to establish a mapping. GRUB, however, stores the result in a file (device.map) which can be edited. For more information about device.map, refer to Section 4.
For GRUB, a path name must be specified as a device name written in parentheses, followed by a file name together with its full path on that device or partition. The path must always start with a slash. For example, on a system with a single IDE disk and Linux on the first partition, the bootable kernel might be specified with:
The following example shows how the GRUB menu file works. This imaginary machine has a Linux boot partition on /dev/hda5, a root partition on /dev/hda7, and a Windows installation on /dev/hda1.
gfxmenu (hd0,4)/message color white/blue black/light-gray default 0 timeout 8 title linux kernel (hd0,4)/vmlinuz root=/dev/hda7 vga=791 initrd (hd0,4)/initrd title windows chainloader(hd0,0)+1 title floppy chainloader(fd0)+1 title failsafe kernel (hd0,4)/vmlinuz.shipped root=/dev/hda7 ide=nodma \ apm=off acpi=off vga=normal nosmp maxcpus=0 3 initrd (hd0,4)/initrd.shipped
The first part defines the splash screen configuration:
The second, larger part defines the different operating systems to boot:
The menu file can be modified at any time. GRUB automatically reads the changes on the next boot. To make changes to the boot procedure that should be permanent, modify this file with the corresponding YaST module or with your favorite editor. To change the GRUB behavior on a temporary basis only, use the interactive edit function provided by GRUB.
The graphical interface of GRUB not only allows selection of the system to boot (moving the cursor with the arrow keys), but also allows kernel parameters to be appended at the boot prompt (provided that the selection represents a Linux system). This was already possible with LILO, but GRUB takes this one step further. If you press to leave the splash screen then E, GRUB enters editing mode, allowing you to directly change individual menu items. Changes made in this way are valid for the current boot action only. They are not be written to the configuration file.
Note
[Keyboard Layout during the Boot Phase]The US keyboard layout
is the only one available at boot time. Thus, you need to remember that some
characters may need to be produced with different keys.
After enabling the editing mode, use the arrow keys to navigate to the entry to change. To make the selected item editable, press E again. You can now correct any partitions or paths that may be wrong to avoid that they affect the boot procedure. Leave the editing mode with and go back to the menu, where the changed entry can be booted by pressing E. In the lower part of the screen, GRUB displays some hints on other actions that you may take.
To make the changed boot options permanent, edit the file menu.lst as SuSE @nohyphen root and append any additional kernel parameters at the end of the existing line, each separated by a space:
title linux kernel (hd0,0)/vmlinuz root=/dev/hda3 <additional parameter> initrd (hd0,0)/initrd
GRUB takes any new parameters into account upon the next boot. An alternative way to make these changes is through the YaST boot loader module. Again, any new parameters need to be appended at the end, after a separating space.
The previously-mentioned file device.map maps GRUB device names to Linux device names. If your system has a hardware mix that includes both IDE and SCSI disks, GRUB tries determine the boot sequence according to a certain algorithm. However, GRUB is not able to access the BIOS setup to obtain this information. GRUB stores the result of this check in the file /boot/grub/device.map. For a system where the BIOS is set up to boot IDE devices before any SCSI devices, the file could look like this:
(fd0) /dev/fd0 (hd0) /dev/hda (hd1) /dev/hdb (hd2) /dev/sda (hd3) /dev/sdb
If GRUB boots with a given device.map file and encounters any problems, check the order of the devices in the file and use the GRUB shell to change it if necessary. Once you have successfully booted your Linux system, you can change the device.map file with the boot loader module of YaST or with any editor.
Any manual change to the device.map file requires that you update your GRUB installation. This is done with the following command:
In addition to menu.lst and device.map, GRUB stores another important part of its configuration in the file grub.conf. This file defines the parameters and options needed by the grub command to correctly install the boot loader:
root (hd0,4) install /grub/stage1 d (hd0) /grub/stage2 0x8000 (hd0,4)/grub/menu.lst quit
The individual entries have the following meaning:
GRUB actually consists of two parts: the boot loader and a normal Linux program (/usr/sbin/grub). This program is also called the GRUB shell. The functionality to install the boot loader on a hard disk or floppy is integrated into the GRUB shell through the internal commands install and setup. In other words, these commands can be executed using the GRUB shell on a running Linux system. However, these commands are also available while the system is booting with GRUB-- before Linux is even running. This makes the repair of a defective system much easier.
The device mapping algorithm as mentioned above only matters when GRUB runs its shell. It then reads the file device.map to map GRUB device names to Linux devices as indicated by each line. Given that the order in which the BIOS addresses IDE, SCSI, and other hard drives depends on several factors and given that Linux cannot reliably determine this order, GRUB uses the device.map file where the correct order can specified by hand. If you have difficulties booting your machine, check that the order in this file is in line with your BIOS settings. The file is found in the directory /boot/grub. To learn more about the topic, read Section 4.
Because GRUB is able to access file systems upon booting, it could also be used to read files that would not be accessible under normal circumstances -- on a running system, users would need SuSE @nohyphen root permissions to read them. To put a stop to this, set a boot password. Such a password can be used to prevent unauthorized access to file systems at boot time and to prevent users from booting certain systems that are installed.
To create a boot password, log in as root SuSE @nohyphen root and perform these steps:
grub> md5crypt Password: **** Encrypted: $1$lS2dv/$JOYcdxIn7CJk9xShzzJVw/
gfxmenu (hd0,4)/message
color white/blue black/light-gray
default 0
timeout 8
password --md5 $1$lS2dv/$JOYcdxIn7CJk9xShzzJVw/
From now on, executing GRUB commands from the boot prompt is impossible
without knowing the password. Permission to do so is only granted after
pressing P and entering the password. However, users can still boot
all operating systems without any restriction.
title linux
kernel (hd0,4)/vmlinuz root=/dev/hda7 vga=791
initrd (hd0,4)/initrd
lock
After rebooting, trying to boot this entry from the menu would result in the
following error message:
Error 32: Must be authenticated
Return to the menu by pressing . From the menu, pressing
P prompts for the password. The selected system (Linux
in our case) should boot after typing the password and pressing .
Note
[Boot Password and Splash Screen]Setting a boot password for GRUB
disables the graphical splash screen as displayed by default.
Note
[Boot Errors with GRUB]The geometry of attached hard disks is checked
by GRUB only upon booting. In those rare cases where the BIOS reports
inconsistent values, GRUB aborts with a ``GRUB Geom Error''. You may then
need to use LILO instead or, if at all possible, update the BIOS.
Extensive information about GRUB in English, German, and Japanese can be obtained at http://www.gnu.org/software/grub/, but the online GRUB manual itself is only available in English.
If you have texinfo installed on your system, you can view the GRUB info pages from a shell prompt by entering info grub. You can also look up ``GRUB'' as a keyword in the support database at http://sdb.suse.de/en/sdb/html/index.html to obtain information about special issues.
The Linux boot loader LILO is suitable for installation in the MBR. LILO has access to two real-mode hard disks and is able to find all the data it needs from the raw hard drives without any partitioning data. Therefore, operating systems can also be booted from the second hard disk. Unlike with the DOS boot process, the entries in the partition table are ignored when using LILO.
The main difference from the standard DOS boot process is the possibility to load diverse installed operating systems when booting. After loading the MBR into memory, LILO is started, allowing the user to select from the list of preinstalled systems. At system start-up, it can load boot sectors from partitions to boot an operating system from the respective partition or load the Linux kernel and boot Linux. It also provides the important possibility of passing a command to the kernel. For security reasons, some or all LILO services can be protected with a password.
The LILO boot mechanism consists of the following components:
Caution
Any write access (even through file movements) to any of these
files corrupts the map file - unless LILO is updated (see
4). This is especially important when
changing kernels.
The following locations are suitable for storing the LILO boot sector:
LILO is a flexible boot manager that offers many ways of adapting a configuration to your needs. The most important options and meanings are described below. For more detail, look at ().
The configuration of LILO is stored in the file /etc/lilo.conf. You should always make a backup of the last working lilo.conf file before changing it. On the other hand, any changes in this file take effect only when reinstalling LILO i.e. after running the lilo command against the changed /etc/lilo.conf file. For details on this, refer to Section 4.
/etc/lilo.conf starts with a global section, followed by one or more system sections for each operating system LILO should start. Each system section starts with a line beginning with either image or other.
The order of entries in /etc/lilo.conf does matter, in the sense that the first one in the list is booted automatically if there is no user input at the boot screen (and unless the default option is used). This may happen after a certain interval which can be set with the delay and timeout options as explained below.
A sample configuration for a computer with both Windows and Linux is shown in File 2. The bootable systems include a newly installed Linux kernel (/boot/vmlinuz) and the original kernel which is used as a fallback (/boot/vmlinuz.shipped). There is also an entry to boot Windows on /dev/hda1, and an additional one to start the program MemTest86.
Anything between a `#' and the end of a line is regarded as a comment. Spaces and comments are ignored by LILO and can be used to improve readability. The entries in the above sample file include mandatory options which are explained in the list below, and others which are described in Section 4.
The device on whose first sector LILO should be installed. <bootdevice> may be a floppy disk drive (/dev/fd0), a partition (e.g. , /dev/hdb3), or an entire disk (e.g. , /dev/hda). In the last case, LILO would be installed in the MBR. If this option is missing, LILO is installed on the current root partition by default.
With this option, ignore the 1024-cylinder limit of LILO if your BIOS supports this.
Forces the LILO prompt to be displayed. The default is not to display any prompt (see Section 4, option delay).
This is recommended if LILO needs to manage more than one system. It should be used together with the timeout option, to guarantee that the default system is automatically booted if nothing is entered at the prompt.
This specifies the name of the kernel image to boot, including its directory location. With a new system, this is most likely /boot/vmlinuz.
A name for the system in question (e.g. , Linux) which may be freely chosen but must be unique as far as the contents of /etc/lilo.conf are concerned. Its maximum length is 15 characters, and it may only consist of letters, numbers, and underscores, i.e. no blanks or special characters. For more about the specific characters that are allowed, see (), Section 3.2.1. The default for this option is the file name of the corresponding kernel image (e.g. , /boot/vmlinuz).
The same name is presented in the boot menu as one of the selectable items. If there are several systems installed, you may want to provide a more detailed description of the bootable systems by creating a message file, (see Section 4, option message).
This is used by LILO to tell the kernel about the name of the root partition (e.g. , /dev/hda2) of your Linux system. You should use this option to be on the safe side: if it is omitted, the kernel just assumes that the root partition is identical with its own root device (as derived from <kernelimage>).
In order to pass on additional boot parameters to the kernel, you can add the append option to an existing lilo.conf file, followed by a = and your parameters. Individual parameters must be seperated by spaces, and the parameter string as a whole must be enclosed in quotation marks. After saving the file, you still need to execute the lilo command as SuSE @nohyphen root, so that LILO reinstalls the boot loader and takes the changes into account during the next boot.
Even if you installed a customized kernel, you are still able to boot the SuSE standard kernel.
If you decide to delete /boot/vmlinuz.shipped (not recommended), this section will be skipped without an error message during LILO installation.
other tells LILO to start the partitions of other systems (e.g. , /dev/hda1).
Select a name for the system. This is recommended, because the default -- the raw device name -- is not very informative.
Entry for the memory test program memtest86.
This section merely covers the basic entries required in /etc/lilo.conf. Other useful settings can be found in lilo.conf.
Caution
Before you install LILO, make sure that any other existing operating
systems can be booted from floppy disk (not possible for Windows XP/2000/NT).
In particular, make sure that fdisk is available. As far as
SuSE Linux is concerned, you can use the installation CD or DVD as a fallback
boot medium.
If any of the LILO components have changed, or if you have modified your configuration in /etc/lilo.conf, you must update the LILO boot loader. This is easily done by launching the map installer as SuSE @nohyphen root:
LILO creates a backup of the target boot sector, writes its first stage into the boot sector, then generates a new map file (also see 4). LILO issues a report on each installed system In the case of the sample configuration described above, it should look like this:
aus:lilo.install.outputOutput After Launching LILO
Added linux *
Added suse
Added windows
Added memtest86
When the boot loader update is completed, you can reboot the machine by issuing this command as SuSE @nohyphen root:
While rebooting, the BIOS first performs its system test. Immediately afterwards, you should see LILO and its command prompt, where you can enter parameters and select a boot image. You can also hit to see a list of the systems installed.
To uninstall GRUB or LILO, the boot sector on which the boot loader is located needs to be overwritten with its original contents. With SuSE Linux, this is easily done provided that there is a valid backup of that former content. The YaST boot loader module can be used to create such a backup, to integrate such a backup in the boot loader menu later on, and to restore a standard MBR. The YaST boot loader module is described in the installation chapter of the User Guide.
Caution
A boot sector backup is no longer valid if the partition in question
has a new file system.
The partition table of an MBR backup becomes invalid if the hard
disk in question has been repartitioned since the backup was created. Obsolete
``backups'' are time bombs. It is best to delete them as soon as possible.
It is very simple to restore a DOS or Windows MBR. Just enter the MS-DOS command (available since DOS version 5.0):
or, on OS/2:
These commands only write the first 446 bytes (the boot code) into the MBR and leave the partition table untouched, unless the MBR as a whole (see sec:lilo.MBR) is treated as invalid due to an incorrect magic number. In this case, the partition table is set to zero. After restoring the MBR, make sure that you mark the desired start partition as bootable (using fdisk again). This is required for the MBR routines of DOS, Windows, and OS/2.
Boot from the Windows XP CD and press the R key during the setup to start the recovery console. Select your Windows XP installation from the list and enter the administrator password. At the input prompt, enter the command FIXMBR and confirm with y when asked to do so. Then reboot the computer with exit.
Boot from the Windows 2000 CD and press the R key and then C in the next menu to start the recovery console. Select your Windows 2000 installation from the list and enter the administrator password. At the input prompt, enter the command FIXMBR and confirm with y when asked to do so. Then reboot the computer with exit.
After restoring the standard Windows MBR, you can set up one of the Linux boot managers available, to continue using the Linux system installed on your machine.
Even when installed in the MBR, GRUB will write its stage1 data into the Linux partition. After having restoring the MBR with YaST or with the Windows tools mentioned above, you need to mark that partition as active, which can be done with fdisk. To do so, log in as SuSE @nohyphen root und execute the command fdisk /dev/<harddisk>. The fdisk screen will prompt you for a command to run. Enter ` m' to obtain a list of the commands that are available. The ` a' command allows you to select one of the existing primary partitions as active, which in our case should be the Linux partition which holds the stage1 copy. After making this change, you can check the partition table by entering ` p' (print) from within fdisk.
LILO can be reinstalled after restoring the Windows MBR if there is a backup file available. Check whether the size of the backup file is exactly 512 bytes, then restore the sector with the following commands:
dd if=/dev/yyyy of=name-of-new-file bs=512 count=1
dd if=name-of-backup-file of=/dev/yyyy
dd if=/dev/zzz of=name-of-new-file bs=512 count=1
dd if=name-of-backup-file of=/dev/zzz bs=446 count=1
The last command is a safe version which does not overwrite the partition table. Again, you still need to use fdisk to mark the corresponding partition as active (bootable).
This concerns problems arising when attempting to boot a system with the LILO boot manager configured with YaST. The creation of a system boot disk fails with more recent SuSE Linux versions because the space available on a floppy disk is no longer sufficient for the start-up files.
It is possible to create a bootable CD-ROM containing the Linux start-up files if your system has an installed CD writer. This solution is only a work-around. It should normally be possible to configure LILO properly. Refer to the documentation about this subject in /usr/share/doc/packages/lilo/README, lilo.conf, and lilo.
It is easiest to create a bootable CD with the ISOLINUX boot manager. The SuSE installation CDs are also made bootable with isolinux.
DEFAULT linux LABEL linux KERNEL linux APPEND initrd=initrd root=/dev/hdXY [boot parameter]
Enter your root partition for the parameter root=/dev/hdXY. It is listed in the file /etc/fstab. Enter additional options for the setting [boot parameter], which should be used during booting. The configuration files could, for example, look like this:
mkisofs -o /tmp/bootcd.iso -b isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table /tmp/CDroot
The complete command must be entered as one line.
The parameter dev=0,0,0 must be changed according to the SCSI ID of the writer. This can be determined with the command cdrecord -scanbus. Also, refer to cdrecord.
ifundefinedsaxii