Troubleshooting

There are several potential pitfalls you may run into while following this procedure. Some of them are covered in this section.

/usr/share/terminfo/l/linux May Be Wrong

If you’re not running on Red Hat 6.2, your terminfo database may not be in /usr/share. If this is the case, find out where the terminfo database is and substitute that path for /usr/share/terminfo/l/linux everywhere you see it in the procedure.

You Need /dev/console

Probably the least obvious thing about creating a bootable Linux floppy disk is the fact that you absolutely need the /dev/console device in your initrd filesystem because the kernel specifically attempts to open it before calling /linuxrc. If it doesn’t exist, the initrd filesystem won’t load, and the kernel will panic.

The LABEL Statement in syslinux.cfg Must Be linux

If you choose to call it something else, you must have a DEFAULT statement, or the user will have to type the name at boot time. See the syslinux.doc file in the SYSLINUX distribution for more information about the syslinux.cfg file.

Exiting from Your Application Panics the Kernel

The initrd filesystem was designed to be a short weigh-station in the boot process. All the kernel designers intended for you to do was load a kernel module or two (for SCSI drivers, for example), and then exit. The kernel would then mount the real root device and boot the user-mode part of the operating system.

You use the initrd filesystem differently here—your entire application runs out of it. Because of that, it’s important to prevent the user from exiting the application. If that happens, the user gets a message like this:

hda:driver not present 
VFS: Cannot open root device 03:01 
Kernel panic: VFS: Unable to mount root fs on 03:01 

Use chroot to Test on Your Build Machine

When your build machine is running the same processor as your target, you have several additional debug tricks available to you. One of the handiest is the chroot trick.

During the build process, you’ll create a root filesystem image that the target machine will boot from. Once that image is created, it can be mounted using a loopback device. You can then use the chroot command to change a subshell’s root directory to the mounted filesystem. Any commands you type in the subshell will be limited to using only files within the filesystem image you created. This is quite handy for checking to make sure that your software generally works before committing it to the target device. For instance, if you’re missing a dynamic library, and you run a command that requires it, the command will error out.

Some things won’t work, however. For instance, any command that relies on the /proc filesystem will fail. This is because the /proc file system is not available to the chrooted environment.