[EMAIL PROTECTED] wrote:
>
> On Fri, 31 Dec 1999 [EMAIL PROTECTED] wrote:
>
> > I understand that I can manipulate the order of module loads once I've
> > got a booting a machine. The point is that loading Linux (Redhat in this
> > case) in the configuration in question results in a machine that will not
> > boot, due to the device names are not the same as when the box was
> > installed. Therefore, I can't make new kernels, edit files, etc.
>
> When you did the install, both controllers were detected, but the
> installation left your conf.modules with the SCSI host order swapped?
No, I think he means that he had the system running, then he added the
adaptec, and now it croaks. The fact that he has been compiling kernels would
seem to suggest this alternative. It's impossible for him to have been
compiling a kernel that panics due to a modified host order without having
some machine up and running, and from the description, it sounded like this
very machine. In that case, he should either stick to using modules (instead
of compiling the driver into the kernel) or he should *only* put the AMD SCSI
driver into the kernel and leave the aic7xxx driver as a module. Regardless
though, there is no reason he can't get the system to work as it is by simply
passing the root= parameter on the lilo boot prompt. If his root device used
to be /dev/sda5 or something, and the aic7xxx has one drive on it, then the
original root device would now be /dev/sdb5 and all he needs to do is tell
that to the kernel. That will at least bring him up to a filesystem repair
prompt (assuming /usr or /home are also needed and they still point to
/dev/sda something or other then the initscripts will get confused even though
there isn't really anything wrong with the drives, this is to be expected)
from which he could modify his /etc/fstab to point to the new drive locations
and also modify lilo to add a root= parameter that points to the new drive
location and add a section to lilo.conf that reads
disk=/dev/sdb
bios=0x80
and also change the boot= line to read /dev/sdb then rerun lilo and the system
will now work fine with the drives reordered.
Or he could recompile his kernel from this state instead and get things fixed
that way. In short, I can think of about 5 different ways to solve this
problem, and most of them start with just passing a root=/dev/sdb? parameter
to lilo.
> > The point is that there should be a simple way for the average joe to
> > specify these sorts of details about the boot proceedure without
>
> If you post more info (i.e. exactly what drives are on each host, exactly
> what data (partitions) are on each disk), I'll see if I can suggest
> something that'll work for you. If I can't perhaps someone else will.
>
> A few questions though...you mentioned the EISA config utils are on one of
> the drives on the AM53C974 and this drive must be C:. Which drive did you
> install lilo on? Did you disable the BIOS on the Adaptec?
>
> ----------------------------------------------------------------------
> Jon Lewis *[EMAIL PROTECTED]*| Spammers will be winnuked or
> System Administrator | nestea'd...whatever it takes
> Atlantic Net | to get the job done.
> _________http://www.lewis.org/~jlewis/pgp for PGP public key__________
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to [EMAIL PROTECTED]
--
Doug Ledford <[EMAIL PROTECTED]>
Opinions expressed are my own, but
they should be everybody's.
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
