ok, let's get down and dirty here, and consider the
layout of a system with at least two different linux
installations on it.
as we've already discussed, there are a couple of
ways to do it, both of which involve configuring
/etc/lilo.conf and running lilo when you're in one
of the installs that has access to ALL of the kernels
in the other installs.
you can get this access one of two ways:
1) mount the /boot partitions of the other installs,
and refer to those other kernels based on their
mounted names
2) literally copy the kernels from the other /boot
partitions into this partition somewhere (doesn't
have to be in /boot, but that'll do), and refer
to them directly
both of these techniques are a bit messy. in addition,
the first technique has a potential problem -- what if the
actual kernel lives beyond the 1024-cylinder limit for the
BIOS? the fact that it's mountable doesn't necessarily
mean that it's available to participate in the boot
process. or is it? anyone want to comment on this?
at least in technique 2), you can guarantee that all
kernels can live in a /boot partition that resides in
the first 1024 cylinders.
a third technique, described earlier, looks a lot like
a proposal i described months ago. the idea was to
eliminate the "cross-contamination" between different
linux installs on the same box.
basically, for each linux install, set it up to
install LILO, not in the MBR, but in the boot sector
of that install's root filesystem. thus, all of the
linux installs are self-contained. then, from any
one of the installs, you can set up /etc/lilo.conf
to refer to all of the installs using just the "other"
stanza in /etc/lilo.conf:
other=/dev/hda9
label=suse
other=/dev/hda6
label=openlinux
and so on.
this just means that booting the machine requires
two phases of LILO: one to get to the particular install,
the second to actually boot that install. not a big
deal, it would seem.
potential problems. is this *really* all you have to do
to refer to an OS of type other from /etc/lilo.conf?
bigger problem. if you scatter these installs across
the drive, chances are your /boot partitions will also
be scattered across the drive, and some of them may once
again fall outside the 1024-cylinder boundary, rendering
them unbootable.
you can fix that by creating all of the necessary /boot
partitions ahead of time at the front of the disk, that just
means you have to plan ahead and know how many different
linuxes you're going to have.
comments?
rday
--
"This is Microsoft technical support. How may I misinform you?"
_______________________________________________
Redhat-list mailing list
[EMAIL PROTECTED]
https://listman.redhat.com/mailman/listinfo/redhat-list
