LILO problem whith dual linux boot on seperate drives

From Rich Price

Answered By Matthias Posseldt, Jim Dennis, Mike "Iron" Orr, John Karns, Heather Stern, Benjamin A. Okopnik

I recently bought a new IDE disk drive and installed it as /dev/hdb in my server. While leaving my current [Slackware] distribution on /dev/hda, I wish to install the Debian distribution on /dev/hdb.

After completing the basic Debian install, I edited the lilo.conf file to include a second image. The original file was:

See attached rich-price.slack.lilo-conf.txt

The newly modified file is:

See attached rich-price.slack-debian.lilo-conf.txt

when I tested this config file i got:

See attached rich-price.slack-debian.lilo-complains.txt

/boot/vmlinuz-2.2.20-idepci does exist on /dev/hdb1 but not of course on /dev/hda1. Is this the problem? If so, how do I access an image on a different hard drive?

I downloaded the "LILO User's Guide" and read about the alternate image format:

   image=/dev/hdb1
      range=sss-eee

where sss-eee is the starting and ending sector range of the image, but I don't know how to find out what to use for sss-eee.

Rich Price

[Matthias] Just mount the corresponding partition and use this path then, e.g.

image = /mnt/newdebianroot/boot/vmlinuz-2.2.20-idepci
root = /dev/hdb1
label = Debian

A different option is to separate boot and root partitions and mount the /boot partition in both Slackware and Debian while also keeping /etc/lilo.conf in sync, so that you can easily use the /boot/vmlinuz-debian-2.a.b and /boot/vmlinuz-slackware.2.x.y kernel images and use the /boot path. An easy way would be to symlink /etc/lilo.conf to /boot/lilo.conf in both installations and you can happily run lilo from Debian and Slackware.

[JimD] I'd personally avoid the esoterica of any "alternate image format" (if possible) and simply put the desired kernel and any required initrd (compressed initial RAMdisk) images unto the /boot partition (or into the /boot directory of any rootfilesystem) back on /dev/hda.

There is no problem sharing one /boot directory among multiple Linux distributions --- and it's the easiest way to do it.

Thanks to both of you for your answers.

I have sidesteped the problem for now by booting off of a floppy. But I think Jim's suggestion will make a better long term solution.

[Iron] Jim's method is the easiest and most convenient. However, there's no reason the other kernel has to be in /boot as long as it's mounted somewhere when "lilo" is run. Older Linux distributions used to put the kernel in / by default.

I am not a programmer [any more] but I think that an enhansement to LILO which would allow the use of different file systems for different boot images would be good. Something like this:

image = /boot/vmlinuz-2.2.20-idepci
root = /dev/hdb1
imagefs=/dev/hdb1
label = Debian

Where imagefs is a new parameter used to specify the file system that contains the boot image file.

[Jim] Unfortunately this suggestion exhibits a fundamental misunderstanding of how LILO works. The "image" files are access as regular files, and thus they must reside on some locally mounted filesystem when you run /sbin/lilo. /sbin/lilo then issues ioctl()s to get the low-level block address information about where the image file's parts are located. Those raw device/block addresses are written into the map file (usually found in /boot). The address of the map file is written into the boot block (usually in the MBR of the hard drive).

Your hypothetical imagefs= would require that /sbin/lilo either incorporate all the code to directly access the device/partition as a filesystem (which is infeasible for a large number of filesystem and is just bad engineering --- code duplication for even a single type), or it would have to do something like: make a temporary mount point, mount the imagefs, use this temp mount as a relative chroot point?, then proceed as before. It's VASTLY easier for you to mount the fs up yourself and simply manually refer the appropriate entries in your /etc/lilo.conf to the kernel image (and initrd images, etc) before running /sbin/lilo.

In my MANY discussions about LILO I find it convenient to distinguish between LILO (the whole package) and /sbin/lilo (the utility that reads the /etc/lilo file and various command line options and produces/writes a map file and a bootloader (into the MBR, unto a floppy or into a filesystem superblock or "logical boot record).

Run strace on /sbin/lilo some time and you may find enlightenment.

[John] Yes, Linux is nirvana! :^)

[Ben] I've found that running "strace" _often precedes enlightenment. Also, like reading the dictionary (who the heck can stop at just one entry?), it's usually enlightenment on topics far beyond the original one.

[Iron] What would the information be useful for? "lilo" uses the image= path to determine the kernel's physical location, the boostrapper uses the physical location, and at no time is /boot required to be mounted (except when running "lilo").

However, a few programs use /boot/System.map (or /boot/System.map-VERSION), and these may behave funny if it's not accessible or is out of sync with the running kernel. Currently I see that klogd (the kernel logging daemon) has it open while it's running. But stopping klogd, unmounting /boot and restarting klogd does not cause any errors, although it does generate a log message of:

Jan 10 14:55:28 rock kernel: Cannot find map file.
Jan 10 14:55:28 rock kernel: No module symbols loaded.

"man klogd" says it uses System.map to translate the numeric traceback of a kernel error to a list of functions that were active at the time, which makes it easier for kernel developers to track down what caused the problem.

Dan says modprobe also uses System.map. "strings /sbin/modprobe | grep System.map" shows that word exists in the code, although the manpage doesn't mention it. So you may need /boot mounted when loading modules.

Is there anything else that likes to have System.map around?

[Ben] Oddly enough, Netscape. I remember doing some complicated messing around with multiple kernels, way back when, where I'd hosed System.map in some way or another. It didn't seem to affect too many things, but the annoying error message I got every time I fired up Netscape finally got me to straighten it all out. I was a young Linux cub then...

[John] For a time I used to unmount the /boot partition in the init scripts to avoid risking corruption of the ext2fs there during normal operation. Then I noticed the above errors (didn't seem to affect loading modules though), and switched to remounting as ro instead, which rid me of the error, and avoids the problem of having it mounted rw. Alternatively I suppose that one might be able to change the fstab entry to mount it ro. Not sure if there is a requirement to have it rw in the early boot process.

[Iron] I have had /boot mounted read-only for years and have had no problem.

[Heather] On my multi-distro setup, I also mount /boot read-only; depmod tries to run during every boot, and complains that it cannot write. As long as I deliberately run depmod while my /boot is read-write whenever I'm adding modules or new kernels, then this is an ignorable warning because I already did that. When running depmod by hand on a kernel which you do not yet have booted, you definitely need a copy of its System.map on hand, for use with the -F parameter. If I fail to do this, the distro that wants this is a very unhappy camper, because with no depmod information at all, it cannot load any modules.

I occasionally build monolithic kernels deliberately, but that's barely viable with today's huge list of kernel features.

Thanks, Jim.

This information makes LILO much more understandable to me. It enables me to see why my suggestion doesn't make any sense. It also makes the light bulb go on about Matthias's original answer which I admit I didn't understand until now. This is great! I now have two ways to solve my problem and enough understanding about what I am doing to finally be dangerous ;-}>

I think that adding something similar to your comments to the LILO User's Guide would be helpful to part time LINUX hackers like me. Perhaps in section 3.3.1 a second paragraph could be added saying:

"The image file is accessed as a regular file, and thus it must reside on a locally mounted filesystem at the time that /sbin/lilo is run.

[JimD] ... kernel and initrd images files are accessed by /sbin/lilo ...

/sbin/lilo will then issue ioctl()s to get the low-level block address information which shows where the image file's parts are located in the file system. This file system does not have to be on the same physical drive as the root file system."

[JimD] ... but must be accessible to the bootloader code (generally via BIOS functions).

Did I get it right? Do you think I should suggest this to the maintainers?

[JimD] I've touched it up a bit --- their maintainers would, undoubtedly tweak it more to their likely if they choose to incorporate it.

Please feel free to send this to John Coffman and to the maintainers of the appropriate HOWTOs (as referenced in my earlier post).

I'd also highly recommend pointing them at the years of Linuz Gazette Answer Guy/Gang material on this topic --- so they can understand how frequently these questions come up and glean some ideas for how we people in the "support trenches" have been trying to dispel the confusion that plagues so many LILO users. (Did I mix too many metaphors there?)

In particular if they explain LILO as analogous to programming: /etc/lilo.conf is the "program source", /sbin/lilo is the compiler and the bootloader and map files are "objects" --- then a large number of people will "get it." Even people with the barest modicum of (compiler) programming experience understand why changing the source code doesn't change the program until it's recompiled.

Meet the Gang   1   2   3