This is the most common problem experienced by first-time root disk users, and it can be quite tricky finding the cause. The basic problem is that there is very little that is exactly the same in all Linux systems, but to get a system to boot to the stage where it will talk to you requires several components to be present and correctly configured.
The first thing to be understood is that creating a root disk is usually an iterative process. Requirements change as the kernel changes, and different distributions arrange things in different ways. The normal boot process is for the kernel to execute /sbin/init, which in turn reads /etc/inittab to find out what to execute next... but anything is possible, so to understand things you must RTFM, including:
The general approach to building a root disk is to assemble components from your existing system, and try and get the diskette-based system to the point where it displays messages on the console. Once it starts talking to you, the battle is half over, because you can see what it is complaining about, and you can fix individual problems until the system works smoothly.
Inittab is possibly the trickiest part because its syntax and content depend on the init program used and the nature of the system. The only way to tackle it really is to read the man pages for init and inittab and work out exactly what your existing system is doing when it boots.
The recommended procedure for investigating the problem where the system will not talk to you is as follows:
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 a1 directory and select either IDE or SCSI kernel depending on the type of controller you have. Check the xxxxkern.cfg file for the selected kernel to see the drivers which have been included in that kernel. If the device you want is in that list, then the corresponding kernel should boot your computer. Download the xxxxkern.tgz file and copy it to your boot diskette as described above in the section on making boot disks.
You must then check the root device in the kernel, using the rdev command:
rdev zImage
Rdev will then display the current root device in the kernel. If this is not the same as the root device you want, then use rdev to change it. For example, the kernel I tried was set to /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".
Just copy the kernel to your boot diskette using the dd command for a boot diskette without a filesystem, or the cp command for a boot/root disk. Refer to the section in this HOWTO titled "Boot" for details on creating a boot disk. The description applies equally to updating a kernel on a boot disk.
This is not really a Bootdisk topic, but it is asked so often, so: the answer is, use the DOS command:
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.
You can also use the dd command to copy the backup saved by LILO to the boot sector - refer to the LILO documentation if you wish to do this.
If you don't have a boot disk standing by, then 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.
Rdev changes kernel settings by changing the values at fixed offsets in the kernel file, so you can do the same if you have a hex editor available on whatever systems you do still have running - for example, Norton Utilities Disk Editor under DOS. You then need to check and if necessary change the values in the kernel at the following offsets:
0x01F8 Low byte of RAMDISK size
0x01F9 High byte of RAMDISK size
0x01FC Root minor device number - see below
0X01FD Root major device number - see below
The ramdisk size is the number of blocks of ramdisk to create. If you want to boot from a root diskette then set this to decimal 1440, which is 0x05A0, thus set offset 0x01F8 to 0xA0 and offset 0x01F9 to 0x05. This will allocate enough space for a 1.4Mb diskette.
Note that the meaning of the ramdisk size word changed in kernel version 1.3.48. This meaning is described in the section titled "Advanced Bootdisk Creation".
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 rawrite.exe. This program is included in several distributions, including the SLS and Slackware distributions. It is a DOS program which writes a file to the "raw" disk, starting at the boot sector, instead of writing it to the file system. If you use Norton Utilities, then you must write the file to a physical disk starting at the beginning of the disk.
It is never desirable to have just one set of rescue disks - 2 or 3 should be kept in case one is unreadable.
The easiest way of making copies of any diskettes, including bootable and utility diskettes, is to use the dd command to copy the contents of the original diskette to a file on your hard drive, and then use the same command to copy the file back to a new diskette. Note that you do not need to, and should not, mount the diskettes, because dd uses the raw device interface.
To copy the original, enter the command:
dd if=devicename of=filename
where devicename the device name of the diskette
drive
and filename the name of the file where you
want to copy to
For example, to copy from /dev/fd0 to a temporary file called /tmp/diskette.copy, I would enter the command:
dd if=/dev/fd0 of=/tmp/diskette.copy
Omitting the "count" parameter, as we have done here, means that the whole diskette of 2880 (for a high-density) blocks will be copied.
To copy the resulting file back to a new diskette, insert the new diskette and enter the reverse command:
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, then you can copy diskettes using a command like:
dd if=/dev/fd0 of=/dev/fd1
Where a disk device cannot be autodetected it is necessary to supply the kernel with a command device parameter string, such as:
aha152x=0x340,11,3,1
For example, a sample command line using the above parameter string would be:
zImage aha152x=0x340,11,3,1 root=/dev/sda1 lock
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 "BOOT" statement can damage partitions.
For kernels 1.3.48+, it is best to create a compressed filesystem as described in Advanced Bootdisk Creation. If your kernel is earlier than this, you can either upgrade, or refer to version 2.0 or below of this HOWTO.
A: cannot execute B. Why?There are several cases of program names being hardcoded in various utilities. These cases do not occur everywhere, but they may explain why an executable apparently cannot be found on your system even though you can see that it is there. You can find out if a given program has the name of another hardcoded by using the "strings" command and piping the output through grep.
Known examples of hardcoding are:
/etc/reboot hardcoded, so
reboot must be placed in the /etc directory./etc/rc.d
files as they appear on your hard disk.
Where this occurs, a kernel message similar to:
Ramdisk driver initialized : 16 ramdisks of 0K size
ramdisk 0
This was included in sample LILO configuration files included in some older distributions, and was put there to override any previous kernel setting. Since 1.3.48 it is irrelevant, because the ramdisk_size kernel parameter now sets the maximum ramdisk size, not the size allocated at boot time. No ramdisk memory is allocated at boot time.
The solution is to remove the LILO ramdisk parameter.
Note that if you attempt to use a ramdisk which has been set to 0K, then behaviour can be unpredictable, and can result in kernel panics.