Special 5.0.7 Installation...

[Marc Champagne]

Hi Folks,

I have been trying to fresh install 5.0.7 lately on a system
that has a Adaptec 2940U2w card.

I have read that the higher the SCSI ID the higher is the priority
(At least with adaptec), so I have been trying to do a fresh install
with my HD being at ID 6 (ID 7 is reserved for the controller itself).

Now, this controller has 2 hosts of which:

channel A (host 0)
Is used for legacy devices
(wide ultra, Wide Fast, Ultra SCSI, Fast SCSI, SCSI-1)

channel B (host 1)
Is use for Ultra2 devices (which is my case)


So I have my HD on Host 1, SCSI ID 6 and would like to know the
right sequences of boot commandes to get this going.

I was able to install the whole OS using this boot command:

boot: defbootstr Sdsk=ad160(1,0,6,0) link="blad325"

but, when I reboot after installion, the system is able to
boot by pressing enter at the boot: prompt.

Both adapters (controllers) show up during the boot up sequence
with type=ad160.

Then I get the following...

hd: no root disk controller was found
hd: a Boot-Time loadable driver my be required

Any help would be appreciated.

Marc

[Bela Lubkin]

Marc Champagne wrote:

> I have been trying to fresh install 5.0.7 lately on a system
> that has a Adaptec 2940U2w card.
>
> I have read that the higher the SCSI ID the higher is the priority
> (At least with adaptec), so I have been trying to do a fresh install
> with my HD being at ID 6 (ID 7 is reserved for the controller itself).

It's true that higher SCSI IDs have higher bus priority. I'm not sure
it has a noticable effect in actual system performance. If it makes
your installation not work, that's a bit more of a negative than the
small theoretical performance gain you're trying for...

> Now, this controller has 2 hosts of which:
>
> channel A (host 0)
> Is used for legacy devices
> (wide ultra, Wide Fast, Ultra SCSI, Fast SCSI, SCSI-1)
>
> channel B (host 1)
> Is use for Ultra2 devices (which is my case)
>
> So I have my HD on Host 1, SCSI ID 6 and would like to know the
> right sequences of boot commandes to get this going.
>
> I was able to install the whole OS using this boot command:
>
> boot: defbootstr Sdsk=ad160(1,0,6,0) link="blad325"

The driver for 2940U2W is built into OSR507, why are you using a BTLD?
And why are you mentioning "ad160"? "ad160" and "blad" are drivers for
two different generations of Adaptec card. "blad" is the driver for the
2940U2 family. (My guess: you meant to type "Sdsk=blad(1,0,6,0)" above,
that's what you actually typed during install.)

> but, when I reboot after installion, the system is able to
> boot by pressing enter at the boot: prompt.
>
> Both adapters (controllers) show up during the boot up sequence
> with type=ad160.
>
> Then I get the following...
>
> hd: no root disk controller was found
> hd: a Boot-Time loadable driver my be required

Try booting the hard disk with:

Boot
: defbootstr Sdsk=blad(0,0,6,0)

(or "ad160", if that's really what you're using). That is, direct it to
the _other_ adapter number. There's an issue with the "blad" and
possibly later Adaptec drivers, that they sometimes order the adapter
numbers one way during ISL and the other way when booting from the hard
disk.

If that bootstring works, then what you'll want to do is edit
/etc/conf/cf.d/mscsi and toggle the adapter numbers of all "blad" (or
"ad160") lines, which should include at least your root disk, possibly
other devices. When editing mscsi, do not change anything other than
the adapter numbers; in particular, do _not_ change the order of the
lines within the file. Just change 0 to 1 and 1 to 0 in the 3rd column
of any "blad" (or "ad160") lines.

Then relink, reboot without a bootstring.

>Bela<

[Marc Champagne]

Bela Lubkin <belal@sco.com> wrote in news:20030811225415.GF24551@sco.com:

> The driver for 2940U2W is built into OSR507, why are you using a BTLD?
> And why are you mentioning "ad160"? "ad160" and "blad" are drivers for
> two different generations of Adaptec card. "blad" is the driver for the
> 2940U2 family. (My guess: you meant to type "Sdsk=blad(1,0,6,0)" above,
> that's what you actually typed during install.)

Well, my mistake! With the multitude of machines here, I managed to grab
the wrong installation kit for this machine (I was using 2940U2W kit and my
card is a 39160).

That was part of my problem.

I managed to install proper kit for 39160 and tried (as you proposed below)

> Try booting the hard disk with:
>
> Boot
> : defbootstr Sdsk=blad(0,0,6,0)

defbootstr Sdsk=ad160(0,0,6,0), that did the trick.

> (or "ad160", if that's really what you're using). That is, direct it to
> the _other_ adapter number. There's an issue with the "blad" and
> possibly later Adaptec drivers, that they sometimes order the adapter
> numbers one way during ISL and the other way when booting from the hard
> disk.

This host ID swap problem (I now recall) was existant with 2940U2W
(blad/blad325) also.

> If that bootstring works, then what you'll want to do is edit
> /etc/conf/cf.d/mscsi and toggle the adapter numbers of all "blad" (or
> "ad160") lines, which should include at least your root disk, possibly
> other devices. When editing mscsi, do not change anything other than
> the adapter numbers; in particular, do _not_ change the order of the
> lines within the file. Just change 0 to 1 and 1 to 0 in the 3rd column
> of any "blad" (or "ad160") lines.

Done, rebooted all is fine.


Thanks for this last tip.


On another note, what has changed with the registration process?

from what I saw after I rebooted, unregistered systems will
shutdown after an hour.

I'm leaving it run to see if that is the case.

I have been using SCO since the early days of Xenix and this is the first
time that I get a bad taste in my mouth "register or else..."

Shesh, We have paid and have a license, isn't that enough!

Thanks

Marc

[Bela Lubkin]

Marc Champagne wrote:

> Bela Lubkin <belal@sco.com> wrote in news:20030811225415.GF24551@sco.com:
>

> > The driver for 2940U2W is built into OSR507, why are you using a BTLD?
> > And why are you mentioning "ad160"? "ad160" and "blad" are drivers for
> > two different generations of Adaptec card. "blad" is the driver for the
> > 2940U2 family. (My guess: you meant to type "Sdsk=blad(1,0,6,0)" above,
> > that's what you actually typed during install.)

>
> Well, my mistake! With the multitude of machines here, I managed to grab
> the wrong installation kit for this machine (I was using 2940U2W kit and my
> card is a 39160).
>
> That was part of my problem.
>
> I managed to install proper kit for 39160 and tried (as you proposed below)
>

> > Try booting the hard disk with:
> >
> > Boot
> > : defbootstr Sdsk=blad(0,0,6,0)

>
> defbootstr Sdsk=ad160(0,0,6,0), that did the trick.
>

> > (or "ad160", if that's really what you're using). That is, direct it to
> > the _other_ adapter number. There's an issue with the "blad" and
> > possibly later Adaptec drivers, that they sometimes order the adapter
> > numbers one way during ISL and the other way when booting from the hard
> > disk.

>
> This host ID swap problem (I now recall) was existant with 2940U2W
> (blad/blad325) also.
>

> > If that bootstring works, then what you'll want to do is edit
> > /etc/conf/cf.d/mscsi and toggle the adapter numbers of all "blad" (or
> > "ad160") lines, which should include at least your root disk, possibly
> > other devices. When editing mscsi, do not change anything other than
> > the adapter numbers; in particular, do _not_ change the order of the
> > lines within the file. Just change 0 to 1 and 1 to 0 in the 3rd column
> > of any "blad" (or "ad160") lines.

>
> Done, rebooted all is fine.
>
> Thanks for this last tip.

Good.

> On another note, what has changed with the registration process?
>
> from what I saw after I rebooted, unregistered systems will
> shutdown after an hour.
>
> I'm leaving it run to see if that is the case.
>
> I have been using SCO since the early days of Xenix and this is the first
> time that I get a bad taste in my mouth "register or else..."
>
> Shesh, We have paid and have a license, isn't that enough!

I know as little about the licensing stuff as I can and still get by.
So treat this as little better than hearsay: I seem to think that there
are licenses which _require_ registration, and others which only ask for
it -- controlled by some bit or bits in the license code. If you're
seeing a behavior change it is probably because you're using a different
kind of license from before. That is something to chase up the chain
from which you purchase licenses.

>Bela<