On Mon, 7 Aug 2000, Chad Rismiller wrote:

> > > 
> > > it's worth emphasizing what's really happening in this lilo.conf file.
> > > the kernel you refer to in the "image" directive must be accessible
> > > (that is, mounted) when you run the "lilo" command.
> > > 
> > > thus, if you're in the red hat partition, one option is to create
> > > a mount point called /suse, mount the suse /boot partition there,
> > > then the image line would read
> > > 
> > >   image=/suse/boot/vmlinuz-2.4.0-0.16
> > > 
> 
> that's getting ugly! :)
> 
> 
> > >   the other option is to literally copy the suse kernel into
> > > the red hat /boot directory, then you don't have to do the
> > > mounting business.
> > > 
> 
> even uglier :)

as far as i know, you have to do one or the other.  there is no
choice C.
> 
> > Could you SHARE the /boot directory, such that the SAME boot
> > directory is used by all linux distributions? OTOH, I'm not sure how
> > you'd keep SuSE from overwriting the RedHat kernel with it's own,
> > assuming they have the same filename (which I do NOT know to be the
> > case...)
> >     John
> > 
> 
> This thread took a wrong turn somewhere.  I would believe it would be
> easier to set the root=/dev/hd?  to whatever partition your /boot would
> be for each Linux installation...just as Bero had mentioned earlier in
> the thread.  Example:
> 
> image=/boot/vmlinuz-2.4.0-0.16
>         label=redhat-7.0-2.4
>       read-only
>       root=/dev/hdb2
> 
> image=/boot/vmlinuz-suse
>         label=suse
>       read-only 
>       root=/dev/hdc1
> 
> The first image would be the Red Hat Installation, the second image a
> Suse installation.

you CAN'T simply refer to a kernel by its name like /boot/vmlinuz-suse
that is in another non-mounted partition.  lilo does not store kernel
location by name, it stores it by block address.  unless it's in 
the current /boot directory or somewhere else in the current partition,
or you arrange to mount it and refer to it by its mounted name, 
you can't do this with lilo.

can anyone else confirm this?  this has been my understanding
for as long as i've been using lilo.

rday

referring to the other root partitions by their device name is,
of course, not a problem.  it's access to the kernel that makes
this just a bit messy.



_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list

Reply via email to