The Linux Bootdisk HOWTO Tom Fawcett (fawcett@croftj.net) 3.4, May 1999 This document describes how to design and build your own boot/root diskettes for Linux. These disks could be used as rescue disks or to test new system components. If you haven't read the Linux FAQ and related documents, such as the Linux Installation HOWTO and the Linux Install Guide, you should not be trying to build boot diskettes. If you just want a rescue disk to have for emergencies, see Appendix . Preface.

Note: This document may be outdated. If the date on the title page is more than six months ago, please check the Linux Documentation Project homepage to see if a more recent version exists. Although this document should be legible in its text form, it looks Version notes.

grahamc@zeta.org.au) wrote the original Bootdisk-HOWTO and he supported it through version 3.1. Tom Fawcett (fawcett@croftj.net) added a lot of material for kernel 2.0, and he is the document's maintainer as of version 3.2. Much of Chapman's original content remains. This document is intended for . This information is intended for Linux on the Feedback and credits.

We welcome any feedback, good or bad, on the content of this document. We have done our best to ensure that the instructions and information herein are accurate and reliable. Please let us know if you find errors or omissions. We thank the many people who assisted with corrections and suggestions. Their contributions have made it far better than we could ever have done alone. Send comments, corrections and questions to the author at the email address above. I don't mind trying to answer questions, but please read section first. Distribution policy.

Copyright © 1995,1996,1997,1998,1999 by Tom Fawcett and Graham Chapman. This document may be distributed under the terms set forth in the Linux Documentation Project License at . Please contact the authors if you are unable to get the license.

This is free documentation. It is distributed in the hope that it will be useful, but without any warranty; without even the implied warranty of merchantability or fitness for a particular purpose.

Introduction.

Linux boot disks are useful in a number of situations, such as: Testing a new kernel. Recovering from a disk failure -- anything from a lost boot sector to a disk head crash. Fixing a disabled system. A minor mistake as root can leave your system unusable, and you may have to boot from diskette to fix it. Upgrading critical system files, such as There are several ways of obtaining boot disks: Use one from a distribution such as Slackware. This will at least allow you to boot. Use a rescue package to set up disks designed to be used as rescue disks. Learn what is required for each of the types of disk to operate, then build your own. Some people choose the last option so they can do it themselves. That way, if something breaks, they can work out what to do to fix it. Plus it's a great way to learn about how a Linux system works. This document assumes some basic familiarity with Linux system administration concepts. For example, you should know about directories, filesystems and floppy diskettes. You should know how to use /etc/passwd and fstab files are for and what they look like. You should know that most of the commands in this HOWTO should be run as root. Constructing your own bootdisk from scratch can be complicated. If you haven't read the Linux FAQ and related documents, such as the Linux Installation HOWTO and the Linux Installation Guide, you should not be trying to build boot diskettes. If you just need a working bootdisk for emergencies, it is much easier to download a prefabricated one. See Appendix , below, for where to find these. Bootdisks and the boot process.

The boot process.

A: in DOS and /dev/fd0 in Linux). The BIOS then tries to execute this sector. On most bootable disks, sector 0, cylinder 0 contains either: code from a boot loader such as LILO, which locates the kernel, loads it and executes it to start the boot proper. the start of an operating system kernel, such as Linux. If a Linux kernel has been raw-copied to a diskette, the first sector of the disk will be the first sector of the Linux kernel itself. This first sector will continue the boot process by loading the rest of the kernel from the boot device. Once the kernel is completely loaded, it goes through some basic device initialization. It then tries to load and mount a from some device. A root filesystem is simply a filesystem that is mounted as ``/''. The kernel has to be told where to look for the root filesystem; if it cannot find a loadable image there, it halts. In some boot situations -- often when booting from a diskette -- the root filesystem is loaded into a , which is RAM accessed by the system as if it were a disk. There are two reasons why the system loads to ramdisk. First, RAM is several orders of magnitude faster than a floppy disk, so system operation is fast; and second, the kernel can load a from the floppy and uncompress it onto the ramdisk, allowing many more files to be squeezed onto the diskette. Once the root filesystem is loaded and mounted, you see a message like: VFS: Mounted root (ext2 filesystem) readonly. init inittab sysinit At this point the system finds the /bin or /sbin) and executes it. /etc/inittab, looks for a line designated /etc/rc or /etc/init.d/boot. This script is a set of shell commands that set up basic system services, such as: Running on all the disks, Loading necessary kernel Starting swapping, Initializing the network, Mounting disks mentioned in . This script often invokes various other scripts to do modular initialization. For example, in the common SysVinit structure, the directory /etc/rc.d/ contains a complex structure of subdirectories whose files specify how to enable and shut down most system services. However, on a bootdisk the sysinit script is often very simple. When the sysinit script finishes control returns to , which is responsible for handling commununications through the console and ttys. It is the program to handle login validation and to set up user sessions. Disk types.

Having reviewed the basic boot process, we can now define various kinds of disks involved. We classify disks into four types. The discussion here and throughout this document uses the term ``disk'' to refer to floppy diskettes unless otherwise specified, though most of the discussion could apply equally well to hard disks. root A disk with a filesystem containing files required to run a Linux system. Such a disk does not necessarily contain either a kernel or a boot loader. boot/root A disk which contains both the kernel boot/root disk and a root filesystem. In other words, it contains everything necessary to boot and run a Linux system without a hard disk. The advantage of this type of disk is that is it compact -- everything required is on a single disk. However, the gradually increasing size of everything means that it is increasingly difficult to fit everything on a single diskette, even with compression. utility A disk which contains a filesystem, but is not intended to be mounted as a root file system. It is an additional data disk. You would use this type of disk to carry additional utilities where you have too much to fit on your root disk. In general, when we talk about ``building a bootdisk'' we mean creating both the boot (kernel) and root (files) portions. They may be either together (a single boot/root disk) or separate (boot + root disks). The most flexible approach for rescue diskettes is probably to use separate boot and root diskettes, and one or more utility diskettes to handle the overflow. Building a root filesystem.

A root filesystem must contain everything needed to support a full Linux system. To be able to do this, the disk must include the minimum requirements for a Linux system: The basic file system structure, Minimum set of directories: /dev, /proc, /bin, /etc, /lib, /usr, /tmp, Basic set of utilities: sh, ls, cp, mv, etc., Minimum set of config files: rc, inittab, fstab, etc., Devices: /dev/hd*, /dev/tty*, /dev/fd0, etc., Runtime library to provide basic functions used by utilities. Of course, any system only becomes useful when you can run something on it, and a root diskette usually only becomes useful when you can do something like: Check a file system on another drive, for example to check your root file system on your hard drive, you need to be able to boot Linux from another drive, as you can with a root diskette system. Then you can run on your original root drive while it is not mounted. Restore all or part of your original root drive from backup using archive and compression utilities such as We will describe how to build a Creating the filesystem.

If you do not have a loop device (/dev/loop0, /dev/loop1, etc.) on your system, you will have to create one with ``mknod /dev/loop0 b 7 0''. One you've installed these special /tmp/fsfile). You can use a command like dd if=/dev/zero of=/tmp/fsfile bs=1k count= to create an -o loop'' to tell mount to use a loopback device. mount -o loop -t ext2 /tmp/fsfile /mnt will mount /tmp/fsfile (via a loopback device) at the mount point /mnt. A After you've chosen one of these options, prepare the DEVICE with: dd if=/dev/zero of=DEVICE bs=1k count=3000 This command zeroes out the device. This step is important because the filesystem on the device will be compressed later, so all unused portions should be filled with zeroes to achieve maximum compression. -i option to specify more inodes than the default; /dev files. /dev directory then you will easily exceed 360. Using a compressed root filesystem allows a larger filesystem, and hence more inodes by default, but you may still need to either reduce the number of files or increase the number of inodes. So the command you use will look like: mke2fs -m 0 -i 2000 DEVICE (If you're using a loopback device, the disk file you're using should be supplied in place of this DEVICE. In this case, mount -t ext2 DEVICE /mnt (You must create a mount point /mnt if it does not already exist.) In the remaining sections, all destination directory names are assumed to be relative to /mnt. Populating the filesystem.

Here is a reasonable minimum set of directories for your root filesystem: /dev -- Devices, required to perform I/O /proc -- Directory stub required by the proc filesystem /etc -- System configuration files /sbin -- Critical system binaries /bin -- Basic binaries considered part of the system /lib -- Shared libraries to provide run-time support /mnt -- A mount point for maintenance on other disks /usr -- Additional utilities and applications (The directory structure presented here is for root diskette use only. Real Linux systems have a more complex and disciplined set of policies, called the Filesystem Hierarchy Standard, for determining where files should go.) /proc directory is basically a stub under which the proc filesystem is placed. The directories /mnt and /usr are only mount points for use after the boot/root system is running. Hence again, these directories only need to be created. The remaining four directories are described in the following sections. /dev

/dev directory containing a special file for all devices to be used by the system is mandatory for any Linux system. The directory itself is a normal directory, and can be created with command. There is a shortcut, though -- copy your existing /dev directory contents, and delete the ones you don't want. The only requirement is that you copy the device special files using Be sure to use an upper case R. If you use the lower case switch cp -dpR /dev /mnt assuming that the diskette is mounted at /mnt. The uses tape devices, so you will need to copy all of these if you intend to access your floppy tape drive from the bootdisk. Note that one inode is required for each device special file, and /dev directory. Many devices are obviously unnecessary on specific systems. For example, if you do not have SCSI disks you can safely remove all the device files starting with Be sure to include the following files from this directory: console, kmem, mem, null, ram, tty1. /etc

Required at all times, May be required, but no-one is too sure. Junk that crept in. Files which are not essential can be identified with the command: ls -ltru This lists files in reverse order of date last accessed, so if any files are not being accessed, they can be omitted from a root diskette. On my root diskettes, I have the number of config files down to 15. This reduces my work to dealing with three sets of files: The ones I must configure for a boot/root system: rc.d/* -- system startup and run level change scripts -- list of file systems to be mounted -- parameters for the The ones I should tidy up for a boot/root system: -- list of users, home directories, etc. If security is important, contains at least The rest. They work at the moment, so I leave them alone. Out of this, I only really have to configure two files, and what they should contain is surprisingly small. #!/bin/sh /bin/mount -av /bin/hostname Kangaroo Be sure the directories are right. You don't really need to run -- it just looks nicer if you do. should contain at least: /dev/ram0 / ext2 defaults /dev/fd0 / ext2 defaults /proc /proc proc defaults You can copy entries from your existing Your should be changed so that its line runs rc or whatever basic boot script will be used. Also, if you want to ensure that users on serial ports cannot login, comment out all the entries for file looks like this: id:2:initdefault: si::sysinit:/etc/rc 1:2345:respawn:/sbin/getty 9600 tty1 2:23:respawn:/sbin/getty 9600 tty2 The file defines what the system will run in various states including startup, move to multi-user mode, etc. Be sure to check carefully the filenames mentioned in /etc/shutdown has hardcoded in it /etc/reboot. If I move /bin/reboot, and then issue a /etc directory, plus all the executables in your /etc directory that you cannot be sure you do not need. As a guide, consult the sample listing in Section . Probably it will suffice to copy only those files, but systems differ a great deal, so you cannot be sure that the same set of files on your system is equivalent to the files in the list. The only sure method is to start with /etc/rc.d/ directory containing shell scripts for different run levels. The minimum is a single and the /etc/rc.d directory from your existing system, and prune the shell scripts in the /bin and /sbin

/bin directory is a convenient place for extra utilities you need to perform basic operations, utilities such as for an example list of files that go in a /bin and /sbin directories. It does not include any of the utilities required to restore from backup, such as /usr. Creation of a . It is probably desirable to maintain a copy of the same version of backup utilities used to write the backups so you don't waste time trying to install versions that cannot read your backup tapes. Make sure you include the following programs: /lib

/lib you place necessary shared libraries and loaders. If the necessary libraries are not found in your /lib directory then the system will be unable to boot. If you're lucky you may see an error message telling you why. libc.so., where /lib directory. % ls -l /lib/libc* -rwxr-xr-x 1 root root 4016683 Apr 16 18:48 libc-2.1.1.so* lrwxrwxrwx 1 root root 13 Apr 10 12:25 libc.so.6 -> libc-2.1.1.so* In this case, you want command. For example: % ldd /sbin/mke2fs libext2fs.so.2 => /lib/libext2fs.so.2 (0x40014000) libcom_err.so.2 => /lib/libcom_err.so.2 (0x40026000) libuuid.so.1 => /lib/libuuid.so.1 (0x40028000) libc.so.6 => /lib/libc.so.6 (0x4002c000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Each file on the right-hand side is required. The file may be a symbolic link. Note that some libraries are quite large and will not fit easily on your root filesystem. For example, the for instructions. /lib you must also include a loader for the libraries. The loader will be either % file/lib/libc.so.4.7.2 /lib/libc.so.5.4.33 /lib/libc-2.1.1.so /lib/libc.so.4.7.2: Linux/i386 demand-paged executable (QMAGIC), stripped /lib/libc.so.5.4.33: ELF 32-bit LSB shared object, Intel 80386, version 1, stripped /lib/libc-2.1.1.so: ELF 32-bit LSB shared object, Intel 80386, version 1, not stripped The Providing for PAM and NSS.

If your system uses PAM (Pluggable Authentication Modules), you must make some provision for it on your bootdisk or you will not be able to login. PAM, briefly, is a sophisticated modular method for authenticating users and controlling their access to services. An easy way to determine if your system uses PAM is to check your hard disks's /etc directory for a file pam.conf or a pam.d directory; if either exists, you must provide some minimal PAM support. (Alternatively, run ldd on your login executable; if the output includes libpam.so, you need PAM.) Fortunately, security is usually of no concern with bootdisks since anyone who has physical access to a machine can usually do anything they want anyway. Therefore, you can effectively disable PAM by creating a simple /etc/pam.conf file in your root filesystem that looks like this: OTHER auth optional /lib/security/pam_permit.so OTHER account optional /lib/security/pam_permit.so OTHER password optional /lib/security/pam_permit.so OTHER session optional /lib/security/pam_permit.so Also copy the file /lib/security/pam_permit.so to your root filesystem. This library is only about 8K so it imposes minimal overhead. Note that this configuration allows anyone complete access to the files and services on your machine. If you care about security on your bootdisk for some reason, you'll have to copy some or all of your hard disk's PAM setup to your root filesystem. Be sure to read the PAM documentation carefully, and copy any libraries needed in /lib/security onto your root filesystem. You must also include /lib/libpam.so on your bootdisk. But you already know this since you ran ldd on /bin/login, which showed this dependency. NSS (Name Service Switch).

If you are using glibc (aka libc6), you will have to make provisions for name services or you will not be able to log in. The file /etc/nsswitch.conf controls database lookups for various servies. If you don't plan to access services from the network (eg, DNS or NIS lookups), you need only prepare a simple nsswitch.conf file that looks like this: passwd: files shadow: files group: files hosts: files services: files networks: files protocols: files rpc: files ethers: files netmasks: files bootparams: files automount: files aliases: files netgroup: files publickey: files This specifies that every service be provided only by local files. You will also need to include /lib/libnss_files.so.1, which will be loaded dynamically to handle the file lookups. If you plan to access the network from your bootdisk, you may want to create a more elaborate nsswitch.conf file. See the nsswitch man page for details. Keep in mind that you must include a file /lib/libnss_service.so.1 for each service you specify. Modules.

/lib/modules. You should also include /etc/conf.modules. However, the main advantage to using modules is that you can move non-critical modules to a utility disk and load them when needed, thus using less space on your root disk. If you may have to deal with many different devices, this approach is preferable to building one huge kernel with many drivers built in. Some final details.

Some system programs, such as /var/run/utmp and the directory /var/log do not exist. mkdir -p /mnt/var/{log,run} touch /mnt/var/run/utmp Finally, after you have set up all the libraries you need, run /etc/ld.so.cache on the root filesystem. The cache tells the loader where to find the libraries. To remake chdir /mnt; chroot /mnt /sbin/ldconfig The Wrapping it up.

/usr/src/linux. If you have trouble building a kernel, you should probably not attempt to build boot/root systems anyway. Remember to compress the kernel with ``Putting them together: Making the diskette(s).

At this point you have a kernel and a compressed root filesystem. If you are making a boot/root disk, check their sizes to make sure they will both fit on one disk. If you are making a two disk boot+root set, check the root filesystem to make sure it will fit on a single diskette. You should decide whether to use LILO to boot the bootdisk kernel. The alternative is to copy the kernel directly to the diskette and boot without /etc/lilo.conf on your system. If it exists and has a line like ``. Transferring the kernel with LILO

The last step is to transfer the root filesystem. If the root filesystem will be placed on the dd if=rootfs.gz of=/dev/fd0 bs=1k seek=KERNEL_BLOCKS If the root filesystem will be placed on a dd if=rootfs.gz of=/dev/fd0 bs=1k Congratulations, you are done! You should always test a bootdisk before putting it aside for an emergency! If it fails to boot, read on. Troubleshooting, or The Agony of Defeat.

If Id xxx respawning too fast: disabled for 5 minutes /etc/inittab are correct. If you get strange messages from /etc/inittab is wrong. The options of the . The problem may also be that you use shadow passwords and didn't copy /etc/shadow to your bootdisk. If you try to run some executable, such as Miscellaneous topics.

Reducing root filesystem size.

. In this case, binaries could be placed into a /bin directory on your utility disk, so that placing /usr/bin in your path will access them. Additional libraries needed by the binaries are placed in /lib on the utility disk. There are several important points to keep in mind when designing a utility disk: Do not place critical system binaries or libraries onto the utility disk, since it will not be mountable until after the system has booted. You cannot access a floppy diskette and a floppy tape drive simultaneously. This means that if you have a floppy tape drive, you will not be able to access it while your utility disk is mounted. Access to files on the utility disk will be slow. Appendix shows a sample of files on a utility disk. Here are some ideas for files you may find useful: programs for examining and manipulating disks (How the pros do it.

Q. I boot from my boot/root disks and nothing happens. What do I do?

See section , above. Q. How does the Slackware/Debian/RedHat bootdisk work?

See section , above. Q. How can I make a boot disk with a XYZ driver?

The easiest way is to obtain a Slackware kernel from your nearest Slackware mirror site. Slackware kernels are generic kernels which atttempt to include drivers for as many devices as possible, so if you have a SCSI or IDE controller, chances are that a driver for it is included in the Slackware kernel. Go to the rdev zImage /dev/sda2, but my root SCSI partition is /dev/sda8. To use a root diskette, you would have to use the command: rdev zImage /dev/fd0 If you want to know how to set up a Slackware root disk as well, that's outside the scope of this HOWTO, so I suggest you check the Linux Install Guide or get the Slackware distribution. See the section in this HOWTO titled ``References''. Q. How do I update my boot diskette with a new kernel?

Q. How do I update my root diskette with new files?

, above). Then mount the filesystem and make the changes. You have to remember where your root filesystem started and how many blocks it occupied: dd if=/dev/fd0 bs=1k skip=ROOTBEGIN count=BLOCKS | gunzip > DEVICE mount -t ext2 DEVICE /mnt After making the changes, proceed as before (in Section ) and transfer the root filesystem back to the disk. You should not have to re-transfer the kernel or re-compute the ramdisk word if you do not change the starting position of the new root filesystem. Q. How do I remove LILO so that I can use DOS to boot again?

/sbin/lilo -u You can also use the FDISK /MBR MBR stands for Master Boot Record, and it replaces the boot sector with a clean DOS one, without affecting the partition table. Some purists disagree with this, but even the author of LILO, Werner Almesberger, suggests it. It is easy, and it works. Q. How can I boot if I've lost my kernel

If you don't have a boot disk standing by, probably the easiest method is to obtain a Slackware kernel for your disk controller type (IDE or SCSI) as described above for ``How do I make a boot disk with a XXX driver?''. You can then boot your computer using this kernel, then repair whatever damage there is. The kernel you get may not have the root device set to the disk type and partition you want. For example, Slackware's generic SCSI kernel has the root device set to /dev/sda2, whereas my root Linux partition happens to be /dev/sda8. In this case the root device in the kernel will have to be changed. You can still change the root device and ramdisk settings in the kernel even if all you have is a kernel, and some other operating system, such as DOS. HEX DEC DESCRIPTION 0x01F8 504 Low byte of RAMDISK word 0x01F9 505 High byte of RAMDISK word 0x01FC 508 Root minor device number - see below 0X01FD 509 Root major device number - see below The interpretation of the ramdisk word was described in Section , above. The major and minor device numbers must be set to the device you want to mount your root filesystem on. Some useful values to select from are: DEVICE MAJOR MINOR /dev/fd0 2 0 1st floppy drive /dev/hda1 3 1 partition 1 on 1st IDE drive /dev/sda1 8 1 partition 1 on 1st SCSI drive /dev/sda8 8 8 partition 8 on 1st SCSI drive Once you have set these values then you can write the file to a diskette using either Norton Utilities Disk Editor, or a program called Q. How can I make extra copies of boot/root diskettes?

Because magnetic media may deteriorate over time, you should keep several copies of your rescue disk, in case the original is unreadable. The easiest way of making copies of any diskettes, including bootable and utility diskettes, is to use the dd if=DEVICENAME of=FILENAME where DEVICENAME is the device name of the diskette drive and FILENAME is the name of the (hard-disk) output file Omitting the dd if=FILENAME of=DEVICENAME Note that the above discussion assumes that you have only one diskette drive. If you have two of the same type, you can copy diskettes using a command like: dd if=/dev/fd0 of=/dev/fd1 Q. How can I boot without typing in "ahaxxxx=nn,nn,nn" every time?

aha152x=0x340,11,3,1 This parameter string can be supplied in several ways using LILO: By entering it on the command line every time the system is booted via LILO. This is boring, though. By using the LILO ``By using the For example, a sample command line using the above parameter string would be: zImage aha152x=0x340,11,3,1 root=/dev/sda1 lock This would pass the device parameter string through, and also ask the kernel to set the root device to /dev/sda1 and save the whole command line and reuse it for all future boots. A sample APPEND statement is: APPEND = "aha152x=0x340,11,3,1" Note that the parameter string must NOT be enclosed in quotes on the command line, but it MUST be enclosed in quotes in the APPEND statement. Note also that for the parameter string to be acted on, the kernel must contain the driver for that disk type. If it does not, then there is nothing listening for the parameter string, and you will have to rebuild the kernel to include the required driver. For details on rebuilding the kernel, cd to /usr/src/linux and read the README, and read the Linux FAQ and Installation HOWTO. Alternatively you could obtain a generic kernel for the disk type and install that. Readers are strongly urged to read the LILO documentation before experimenting with LILO installation. Incautious use of the Q. At boot time, I get error "A: cannot execute B". Why?

Shutdown in some versions has /etc/reboot hardcoded, so reboot must be placed in the /etc directory. To fix these problems, either move the programs to the correct directory, or change configuration files (e.g. /etc/rc.d files as they appear on your hard disk. Q. My kernel has ramdisk support, but initializes ramdisks of 0K

Where this occurs, a kernel message like this will appear as the kernel is booting: Ramdisk driver initialized : 16 ramdisks of 0K size This is probably because the size has been set to 0 by kernel parameters at boot time. This could possibly be because of an overlooked LILO configuration file parameter: ramdisk= 0 This was included in sample LILO configuration files in some older distributions, and was put there to override any previous kernel setting. If you have such a line, remove it. Note that if you attempt to use a ramdisk which has been set to 0K the behaviour can be unpredictable, and can result in kernel panics. Resources and pointers

When retrieving a package, always get the latest version unless you have good reasons for not doing so. Pre-made bootdisks.

Several packages for creating rescue disks are available on metalab.unc.edu. With these packages you specify a set of files for inclusion and the software automates (to varying degrees) the creation of a bootdisk. See for more information. Graham Chapman's shell scripts

Graham Chapman has written a set of scripts that may be useful as examples of how to create bootdisks. In previous versions of this HOWTO the scripts appeared in an appendix, but they have been deleted from the documented and placed on a web page: You may find it convenient to use these scripts, but if so, read the instructions carefully -- for example, if you specify the wrong swap device, you will find your root filesystem has been throroughly and permanently erased. Be sure you have it correctly configured before you use it! LILO -- the Linux loader.

. It is also available on Metalab and mirrors. Linux FAQ and HOWTOs.

These are available from many sources. Look at the usenet newsgroups and the HOWTOs from . Most documentation for Linux may be found at . If desperate, send mail to Ramdisk usage.

/usr/src/linux/Documentation/ramdisk.txt. It is written by Paul Gortmaker and includes a section on creating a compressed ramdisk. The Linux boot process.

The Linux System Administrators' Guide has a section on booting, See The LILO ``Technical overview'' has the definitive technical, low-level description of the boot process, up to where the kernel is started. The source code is the ultimate guide. Below are some kernel files related to the boot process. If you have the Linux kernel source code, you can find these under /usr/src/linux on your machine; alternatively, Shigio Yamaguchi (shigio@wafu.netgate.net) has a very nice hypertext kernel browser at . Here are some relevant files: arch/i386/boot/bootsect.S,setup.S Contain assembly code for the bootsector. arch/i386/boot/compressed/misc.c Contains code for uncompressing the kernel. arch/i386/kernel/ Directory containing kernel initialization code. drivers/block/rd.c Contains the ramdisk driver. The procedures LILO boot error codes.

. When LILO loads itself, it displays the word `` (nothing) No part of LILO has been loaded. LILO either isn't installed or the partition on which its boot sector is located isn't active. /boot/boot.b without running the map installer. If the BIOS signals an error when LILO is trying to load a boot image, the respective error code is displayed. These codes range from Sample rootdisk directory listings.