402 lines
16 KiB
HTML
402 lines
16 KiB
HTML
<!--startcut ==============================================-->
|
|
<!-- *** BEGIN HTML header *** -->
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<HTML><HEAD>
|
|
<META NAME="generator" CONTENT="lgazmail v1.4G.c">
|
|
<TITLE>The Answer Gang 87: LILO problem whith dual linux boot on seperate drives</TITLE>
|
|
</HEAD><BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#0000AF"
|
|
ALINK="#FF0000">
|
|
<!-- *** END HTML header *** -->
|
|
<!-- begin 1 -->
|
|
<H3 align="left"><img src="../../gx/dennis/bbubble.gif"
|
|
height="50" width="60" alt="(!) " border="0"
|
|
>LILO problem whith dual linux boot on seperate drives</H3>
|
|
|
|
|
|
<p><strong>From Rich Price
|
|
</strong></p>
|
|
<p align="right"><strong>Answered By Matthias Posseldt, Jim Dennis, Mike "Iron" Orr, John Karns, Heather Stern, Benjamin A. Okopnik
|
|
<p></strong></p>
|
|
<P><STRONG>
|
|
<IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
I recently bought a new IDE disk drive and installed it as <TT>/dev/hdb</TT> in my
|
|
server.
|
|
While leaving my current [<A HREF="http://www.slackware.org/">Slackware</A>] distribution on <TT>/dev/hda</TT>, I wish to
|
|
install the <A HREF="http://www.debian.org/">Debian</A> distribution on <TT>/dev/hdb.</TT>
|
|
</STRONG></P>
|
|
<P><STRONG>
|
|
After completing the basic Debian install, I edited the lilo.conf file to
|
|
include a second image. The original file was:
|
|
</STRONG></P>
|
|
<p align="center">See attached <tt><a href="../misc/tag/rich-price.slack.lilo-conf.txt">rich-price.slack.lilo-conf.txt</a></tt></p>
|
|
<P><STRONG>
|
|
The newly modified file is:
|
|
</STRONG></P>
|
|
<p align="center">See attached <tt><a href="../misc/tag/rich-price.slack-debian.lilo-conf.txt">rich-price.slack-debian.lilo-conf.txt</a></tt></p>
|
|
<P><STRONG>
|
|
when I tested this config file i got:
|
|
</STRONG></P>
|
|
<p align="center">See attached <tt><a href="../misc/tag/rich-price.slack-debian.lilo-complains.txt">rich-price.slack-debian.lilo-complains.txt</a></tt></p>
|
|
<P><STRONG>
|
|
<TT>/boot/vmlinuz-2.2.20-idepci</TT> does exist on <TT>/dev/hdb1</TT> but not of course on
|
|
/dev/hda1.
|
|
Is this the problem? If so, how do I access an image on a different hard
|
|
drive?
|
|
</STRONG></P>
|
|
<P><STRONG>
|
|
I downloaded the "LILO User's Guide" and read about the alternate image
|
|
format:
|
|
</STRONG></P>
|
|
|
|
<pre><strong> image=/dev/hdb1
|
|
range=sss-eee
|
|
</strong></pre>
|
|
<P><STRONG>
|
|
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.
|
|
</STRONG></P>
|
|
<P><STRONG>
|
|
Rich Price
|
|
</STRONG></P>
|
|
<blockQuote>
|
|
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
> [Matthias]
|
|
Just mount the corresponding partition and use this path then, e.g.
|
|
</blockQuote>
|
|
|
|
<blockquote><pre>image = /mnt/newdebianroot/boot/vmlinuz-2.2.20-idepci
|
|
root = /dev/hdb1
|
|
label = Debian
|
|
</pre></blockquote>
|
|
<blockQuote>
|
|
A different option is to separate boot and root partitions and mount the
|
|
<TT>/boot</TT> partition in both Slackware and Debian while also keeping
|
|
<TT>/etc/lilo.conf</TT> in sync, so that you can easily use the
|
|
<TT>/boot/vmlinuz-debian-2.a.b</TT> and <TT>/boot/vmlinuz-slackware.2.x.y</TT> kernel images
|
|
and use the <TT>/boot</TT> path. An easy way would be to symlink <TT>/etc/lilo.conf</TT> to
|
|
<TT>/boot/lilo.conf</TT> in both installations and you can happily run lilo from
|
|
Debian and Slackware.
|
|
</blockQuote>
|
|
<blockQuote>
|
|
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
> [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 <TT>/boot</TT> partition
|
|
(or into the <TT>/boot</TT> directory of any rootfilesystem) back on <TT>/dev/hda.</TT>
|
|
</blockQuote>
|
|
<blockQuote>
|
|
There is no problem sharing one <TT>/boot</TT> directory among multiple
|
|
Linux distributions --- and it's the easiest way to do it.
|
|
</blockQuote>
|
|
<P><STRONG>
|
|
<IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
Thanks to both of you for your answers.
|
|
</STRONG></P>
|
|
<P><STRONG>
|
|
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.
|
|
</STRONG></P>
|
|
<blockQuote>
|
|
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
> [Iron]
|
|
Jim's method is the easiest and most convenient. However, there's no reason
|
|
the other kernel has to be in <TT>/boot</TT> as long as it's mounted somewhere when
|
|
"lilo" is run. Older Linux distributions used to put the kernel in <TT>/</TT> by
|
|
default.
|
|
</blockQuote>
|
|
<P><STRONG>
|
|
<IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
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:
|
|
</STRONG></P>
|
|
|
|
<pre><strong>image = /boot/vmlinuz-2.2.20-idepci
|
|
root = /dev/hdb1
|
|
imagefs=/dev/hdb1
|
|
label = Debian
|
|
</strong></pre>
|
|
<P><STRONG>
|
|
Where imagefs is a new parameter used to specify the file system
|
|
that contains the boot image file.
|
|
</STRONG></P>
|
|
<blockQuote>
|
|
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
> [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 <TT>/sbin/lilo.</TT> <TT>/sbin/lilo</TT> 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 <TT>/boot</TT>). The address of the map file is written
|
|
into the boot block (usually in the MBR of the hard drive).
|
|
</blockQuote>
|
|
<blockQuote>
|
|
Your hypothetical imagefs= would require that <TT>/sbin/lilo</TT> 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 <TT>/etc/lilo.conf</TT> to the kernel image (and initrd images,
|
|
etc) before running <TT>/sbin/lilo.</TT>
|
|
</blockQuote>
|
|
<blockQuote>
|
|
In my MANY discussions about LILO I find it convenient to distinguish
|
|
between LILO (the whole package) and <TT>/sbin/lilo</TT> (the utility that reads
|
|
the <TT>/etc/lilo</TT> 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).
|
|
</blockQuote>
|
|
<blockQuote>
|
|
Run strace on <TT>/sbin/lilo</TT> some time and you may find enlightenment.
|
|
</blockQuote>
|
|
<blockQuote>
|
|
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
> [John]
|
|
Yes, Linux is nirvana! :^)
|
|
</blockQuote>
|
|
<blockQuote>
|
|
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
> [Ben]
|
|
I've found that running "strace" <em> _often</em> 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.
|
|
</blockQuote>
|
|
<blockQuote>
|
|
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
> [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 <TT>/boot</TT> required to be mounted (except when running
|
|
"lilo").
|
|
</blockQuote>
|
|
<blockQuote>
|
|
However, a few programs use <TT>/boot/System.map</TT> (or <TT>/boot/System.map-VERSION</TT>), 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 <TT>/boot</TT> and restarting
|
|
klogd does not cause any errors, although it does generate a log message of:
|
|
</blockQuote>
|
|
|
|
<blockquote><pre>Jan 10 14:55:28 rock kernel: Cannot find map file.
|
|
Jan 10 14:55:28 rock kernel: No module symbols loaded.
|
|
</pre></blockquote>
|
|
<blockQuote>
|
|
"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.
|
|
</blockQuote>
|
|
<blockQuote>
|
|
Dan says modprobe also uses System.map. "strings <TT>/sbin/modprobe</TT> | grep
|
|
System.map" shows that word exists in the code, although the manpage doesn't
|
|
mention it. So you may need <TT>/boot</TT> mounted when loading modules.
|
|
</blockQuote>
|
|
<blockQuote>
|
|
Is there anything else that likes to have System.map around?
|
|
</blockQuote>
|
|
<blockQuote>
|
|
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
> [Ben]
|
|
Oddly enough, <EM>Netscape</EM>. 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...
|
|
<IMG SRC="../../gx/dennis/smily.gif" ALT=":)"
|
|
height="24" width="20" align="middle">
|
|
</blockQuote>
|
|
<blockQuote>
|
|
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
> [John]
|
|
For a time I used to unmount the <TT>/boot</TT> 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.
|
|
</blockQuote>
|
|
<blockQuote>
|
|
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
> [Iron]
|
|
I have had <TT>/boot</TT> mounted read-only for years and have had no problem.
|
|
</blockQuote>
|
|
<blockQuote>
|
|
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
> [Heather]
|
|
On my multi-distro setup, I also mount <TT>/boot</TT> read-only; depmod tries to
|
|
run during every boot, and complains that it cannot write. As long as
|
|
I deliberately run depmod while my <TT>/boot</TT> 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.
|
|
</blockQuote>
|
|
<blockQuote>
|
|
I occasionally build monolithic kernels deliberately, but that's barely
|
|
viable with today's huge list of kernel features.
|
|
</blockQuote>
|
|
<P><STRONG>
|
|
<IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
Thanks, Jim.
|
|
</STRONG></P>
|
|
<P><STRONG>
|
|
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 ;-}>
|
|
</STRONG></P>
|
|
<P><STRONG>
|
|
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:
|
|
</STRONG></P>
|
|
<P><STRONG><BLOCKQuote>
|
|
"The image file is accessed as a regular file, and thus it must reside
|
|
on a locally mounted filesystem at the time that <TT>/sbin/lilo</TT> is run.
|
|
</BLOCKQuote></STRONG></P>
|
|
<blockQuote>
|
|
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
> [JimD]
|
|
... kernel and initrd images files are accessed by <TT>/sbin/lilo</TT> ...
|
|
</blockQuote>
|
|
<P><STRONG>
|
|
<IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
/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."
|
|
</STRONG></P>
|
|
<blockQuote>
|
|
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
> [JimD]
|
|
... but must be accessible to the bootloader code (generally via BIOS functions).
|
|
</blockQuote>
|
|
<P><STRONG>
|
|
<IMG SRC="../../gx/dennis/qbub.gif" ALT="(?)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
>
|
|
Did I get it right? Do you think I should suggest this to the maintainers?
|
|
</STRONG></P>
|
|
<blockQuote>
|
|
<IMG SRC="../../gx/dennis/bbub.gif" ALT="(!)"
|
|
HEIGHT="28" WIDTH="50" BORDER="0"
|
|
> [JimD]
|
|
I've touched it up a bit --- their maintainers would, undoubtedly
|
|
tweak it more to their likely if they choose to incorporate it.
|
|
</blockQuote>
|
|
<blockQuote>
|
|
Please feel free to send this to John Coffman and to the maintainers of
|
|
the appropriate HOWTOs (as referenced in my earlier post).
|
|
</blockQuote>
|
|
<blockQuote>
|
|
I'd also <EM>highly</EM> 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?)
|
|
</blockQuote>
|
|
<blockQuote>
|
|
In particular if they explain LILO as analogous to programming:
|
|
<TT>/etc/lilo.conf</TT> is the "program source", <TT>/sbin/lilo</TT> 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.
|
|
</blockQuote>
|
|
|
|
<!-- end 1 -->
|
|
<!-- *** BEGIN copyright *** -->
|
|
<hr>
|
|
<CENTER><SMALL><STRONG>
|
|
<h5>
|
|
<br>Copyright © 2003
|
|
<br>Copying license <A HREF="">http://www.linuxgazette.com/copying.html</A>
|
|
<BR>Published in Issue 87 of <i>Linux Gazette</i>, February 2003</H5>
|
|
</STRONG></SMALL></CENTER>
|
|
<!-- *** END copyright *** -->
|
|
|
|
<SMALL><CENTER><H6 ALIGN="center">HTML script maintained by
|
|
<A HREF="mailto:star@starshine.org">Heather Stern</a> of
|
|
Starshine Technical Services,
|
|
<A HREF="http://www.starshine.org/">http://www.starshine.org/</A>
|
|
</H6></SMALL></CENTER>
|
|
<HR>
|
|
|
|
<!--startcut ======================================================= -->
|
|
<P> <hr>
|
|
<!-- begin tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::-->
|
|
<p align="center">
|
|
<table width="100%" border="0"><tr>
|
|
<td align="right" valign="center"
|
|
><IMG ALT="" SRC="../../gx/navbar/left.jpg"
|
|
WIDTH="14" HEIGHT="45" BORDER="0" ALIGN="middle" border="0"
|
|
><A HREF="../index.html"
|
|
><IMG SRC="../../gx/navbar/toc.jpg" align="middle"
|
|
ALT="[ Table Of Contents ]" border="0"></A
|
|
><A HREF="../lg_answer.html"
|
|
><IMG SRC="../../gx/dennis/answertoc.jpg" align="middle"
|
|
ALT="[ Answer Guy Current Index ]" border="0"></A></td>
|
|
<td align="center" valign="center"><A HREF="../lg_answer.html#greeting"><img align="middle"
|
|
src="../../gx/dennis/smily.gif" alt="greetings" border="0"></A>
|
|
<A HREF="../../tag/bios.html">Meet the Gang</A>
|
|
<A HREF="1.html">1</A>
|
|
<A HREF="2.html">2</A>
|
|
<A HREF="3.html">3</A>
|
|
</td>
|
|
<td align="left" valign="center"><A HREF="../../tag/kb.html"
|
|
><IMG SRC="../../gx/dennis/answerpast.jpg" align="middle"
|
|
ALT="[ Index of Past Answers ]" border="0"></A
|
|
><IMG ALT="" SRC="../../gx/navbar/right.jpg" align="middle"
|
|
WIDTH="14" HEIGHT="45" BORDER="0"></td></tr></table>
|
|
</p>
|
|
<!-- end tagnav ::::::::::::::::::::::::::::::::::::::::::::::::::::-->
|
|
<!--endcut ========================================================= -->
|
|
<P> <hr>
|
|
<!--startcut ======================================================= -->
|
|
<CENTER>
|
|
<!-- *** BEGIN navbar *** -->
|
|
<!-- *** END navbar *** -->
|
|
</CENTER>
|
|
</p>
|
|
<!--endcut ========================================================= -->
|
|
<!--startcut ======================================================= -->
|
|
</BODY></HTML>
|
|
<!--endcut ========================================================= -->
|