Alan Shoemaker wrote:

> Kirk....your designations of boot1, boot2....etc.  Do partitions
> exist with those names....not!?  Ok, do me a favor.  You say
> Caldera is running, so go into a console in Caldera and type
> fdisk /dev/hda  then do a p command and capture the results and
> post them. Ok?

This report is definitely needed to verify this /boot{n} information.

I believe to understand why Kirk might want to create /boot{n} directories or
filesystems next to each other, or what ever, but, as far as I'm aware, the
boot directory for Linux (RedHat and Mandrake anyway) is supposed to be named
/boot.  The reason I think to understand the intent, or a possible intent, is
that LILO or linuxconf doesn't accept kernel images it cannot see.

One way around this, since Kirk seems to want to keep a dos partition, would be
to use System Commander, or any other tool which doesn't need to see all of the
bootable kernel images in the same directory or filesystem, or configuration,
what ever.

I use LILO, have no problems with it, except for the one just mentioned, and
because LILO supports 16 operating systems or configurations, lilo is adequate
for my needs.

What are the advantages and disadvantages between the various boot
managers?  Is there any significant reason to not use lilo?

However, the one problem I have with LILO is the aforementioned, and it bugs
me.  If lilo (or linuxconf anyway) doesn't see the kernel image for a
configuration the user wishes to add, then  linuxconf (and possibly lilo)
rejects the configuration.

Because this thread is somewhat related to what I want to do, one possible work
around which has come to mind is to mount the other /boot filesystems and
create symbolic links in the immediate /boot directory, to the various kernel
images I want to be able to boot using LILO.  These symbolic links would then
be specified as the boot images in linuxconf LILO configuration.

I haven't gotten around to testing this out, yet, though; therefore perhaps
someone here could say whether or not this would or should work.

If this would work, then this would mean that Kirk's SUSE configuration could
be installed such that all of the filesystems for the configuration are
contiguous.  Kirk would merely need to boot into Caldera, mount the /boot
filesystems of the various configurations he wants to be able to boot into,
create the symbolic links, and then modify the boot loader.

However, it seems kind of peculiar that LILO or linuxconf accepts the DOS
partition, without it being mounted, while rejecting kernel images from other
Linux configurations when these images aren't visible.  Why this discrepancy?

Why should lilo or linuxconf "care" and prevent the administrator from doing
this, while the images aren't visible?  So what if the administrator makes a
mistake and when rebooting can't boot into the configurations defined
incorrectly.

Is there any technically valid reason for this to not be allowed?

I don't think it'ld cause any damage to the hardware or system, if an incorrect
configuration is defined for the LILO prompt, or at least there shouldn't be
any such danger.  Many configuration files can be modified without these kinds
of strict restrictions, with errors caught at runtime.

If there's danger of damage to hardware or the system, then the restriction
would be understandable; however, why should this kind of danger exist, if an
invalid configuration was allowed for a boot configuration?

Doesn't presently make any sense to me.

mike


> Alan
>
> Kirk McElhearn wrote:
> >
> > Thanks to all of you who helped me out be explaining how to handle this.
> > I got the HD and installed it, so I thought I would send you a report.
> >
> > Installing the HD was easy.  It came with partitioning software, and I
> > set it up as follows:
> >
> > boot1
> > boot2
> > boot3
> > boot4
> > boot5
> > swap
> > backup
> > data1
> > data2
> > data3
> > data4
> > data5
> >
> > I first created these partitions with the drive's software as dos
> > partitions, then, under Mandrake, used Disk Drake to change them all to
> > Linux partitions, with the exception of the backup partition - I want to
> > be able to access this from Windows as well.
> >
> > So, with the HD set up, I tried to install a few different distributions.
> >  I left Mandrake on the old HD for the meantime, and tried to install the
> > following on the new HD:
> >
> > Caldera OpenLinux
> > Corel Linux
> > Suse
> > Red Hat 6.2 beta
> >
> > Unfortunately, this did not go as planned.  Caldera was the only one I
> > could fully install.  It started up, but there was no option during the
> > install to create a boot disk (I don't want to use Lilo, because of the
> > hassles each time I need to install Windows anew, and I am a bit
> > uncomfortable with liloconf files - I found a floppy based boot loader
> > called gag that seems to do the trick).  I was not able to reboot into
> > Caldera because of this.  I guess it is there, on one of the partitions;
> > I need to see if I can get a boot floppy from the original CD.
> >
> > Then I tried Corel Linux.  This was an instant failure, since it only
> > recognized my HD as having two partitions - one of 32 megs (boot1) and
> > the other having 20 gigs (it is a 20.4 gig HD).
> >
> > Next try was Suse.  This did not work either, because the Suse installer
> > would only let me install it on contiguous partitions.  This seems to be
> > quite stupid, actually, and I can't figure out any reason for it, but
> > that's the way it is.
> >
> > I also tried a RedHat 6.2 beta CD I have from a magazine.  That didn't go
> > very far in the install, it would not recognize my CD-Rom drive.  It gave
> > a list of only a few CD-Roms, and I tried them all, but none of them
> > worked.
> >
> > All in all, I am pleased that the HD questions were so easy to solve, but
> > very disappointed that I had so many problems installing.  The proverbial
> > difficulties in Linux installation are real, except for Caldera, and, of
> > course, Mandrake.  I am trying to get a few other distributions to see
> > what happens, but, all in all, I am quite surprised that I was unable to
> > go any further.
> >
> > Kirk



Reply via email to