Jean-Louis Debert wrote:
> Mike Corbeil wrote:
> > Actually, I guess that the boot directory doesn't need to be named /boot, as
> > long as the correct path is specified in the boot configuration. This may be
> > incorrect; however, the reason I say this is because linuxconf lilo boot
> > configuration requires the name of the kernel image file as well as the
> > directory path, at least when linuxconf isn't run in or from the /boot
> > directory, or the directory the kernel image(s) are located in.
> >
> > Otherwise, if /boot is strictly required, then I don't know why linuxconf would
> > require for the directory to be specified.
>
> You're perfectly right: lilo only needs to find the kernel image,
> and you could often, in theory, put that anywhere as long as you
> specify it correctly in lilo.conf
What I was wondering is if not only the vmlinuz kernel file was sufficient, or if
I'ld need to create symlinks to all of the /boot files associated with a kernel
existing only on another configuration's partition, which is invisible if not
mounted.
For example, assume the following:
Linux config #1:
/dev/hda5 - /boot (vmlinuz-2.0.36-3, only)
Config #2:
/dev/hdb2 - /boot (vmlinuz -2.0.34-0.6, 2.0.36-3, only)
Config #3:
/dev/hdb5 - /boot (vmlinuz -2.0.36-3, and 2.2.x, only)
/dev/hdb6 - /root
Config #4:
/dev/hdb13 - /boot (Mdk 7.0.2, vmlinux 2.2.y)
/dev/hdb14 - /root (Mdk 7.0.2)
Configs #1-3 are RH.
Now, let's say I want to configure and run lilo from on config #4, say using
linuxconf.
Can I simply mount /boot for configs #1-3 and create symlinks in #4's /boot
directory to the vmlinuz kernels in the /boot directories of configs #1-3, and then
run linuxconf successfully, without a glitch?
That's what I meant, that is, that this would work and that symlinks to the system
map files would not also be needed.
I think that I was just trying to be safe, before actually doing this. On the other
hand, that was probably just a little nervousness, because linuxconf doesn't ask for
the other files; only for the kernel image file itself. It may be necessary to also
mount the / filesystems, but that's not important, at least not wrt the question I
had in mind.
Hence, between your reply and this additional thinking, while recognizing that I was
just a little nervous about this, I think this is the answer, that is, other than
getting rid of some of my Linux configurations. However, until I get an hd.img file
for the Mandrake 7.0v2 cdrom I got with the Planete Linux mag, I only have one
unnecessary configuration. Once I get this Mandrake cdrom (not made by Mandrake
itself as far as I can tell), then, well, I may still only have one unnecessary
Linux configuration to get rid of, if I don't get rid of any between now and getting
this cdrom installed.
I prefer having at least a couple configurations from each Linux distrib installed.
>
>
> However, the /boot directory is part of the File System Standard (FSS)
> in linux, and this standard has been elaborated for several reasons:
> .. mainly to aim for better interoperability between different
> Linux distributions.
> .. in the case of /boot, this also provides a suitable mount point
> to mount a different partition. This is mostly used for older
> BIOSes that can't deal with the 1024-cylinder limit, so that
> you can make sure that a boot kernel will be physically below
> the limit.
Was aware of most of that. Wasn't thoroughly aware or remembering the first ..,
though.
However, in following the general guideline, I make /boot a separate filesystem or
partition, and do this regardless of the filesystem being above or below the 1024
limit. The reason for this generalized approach is merely to make sure that there's
more flexibility for future modification to the system, and I don't think it can
hurt to make /boot a separate fs, even if the entire configuration fits below cyl
1024.
I'll experiment with creating only symlinks to the vmlinuz kernel images and
omitting do the same for the /boot system map files. Doing that would probably only
be unnecessary extra.
Part of the intent of the question, though, is that some programs seem to not accept
symlinks, and I don't recall which program I recently encountered this problem with,
but this happened within the past couple or few days (am spread over many, varied
tasks and the name of that program is currently, well, absent - still haven't gotten
any sleep, been up all night working on various aspects of my Linux configurations,
so am zonked, deep fried, right now).
Thanks anyway,
mike
