[roach-commuter]

Ok so, I have tried the following swaps to no avail :

1) Different RAM

2) Different CPU

3) Different Motherboard

4) Different EISA/GIO Backplane

5 ) I have tried with both internal and external cdrom drive, I have tried installing via the booterizer

6) I have tried both 6.5.22 and 6.2 (For 10K)

7) I have tried removing the Solid Impact graphics and doing an install via serial

8) I have tried a different PROM chip

9) I have run 'resetenv' before install

10) I have tried different disks (both native 50 pins SCSI2 and some SCA80 with an adapter)

The result is always the same. I can run sash64/fx.64 manually with no problems (either via network or cdrom). Partitioned the disk ok. Installation starts copying miniroot it goes up to 100% says Copy Completed then A) If using keyboard/mouse/monitor the monitor goes black and cdrom spins for a few more seconds then stalls and stops and B) If installing via serial with no graphics I can see the text up to the "CopyCompleted" then stalls and cdrom stops to spin eventually.

This pic is from 6.2 installation


Suggestions I've had by far more experienced people is to try and use a preinstalled hard drive with the proper Irix version. So now I am about to ask if anybody has such an image that I can dd to a clean disk. Else I just have to buy a preinstalled hard drive somewhere somehow and I am about to give up and install OpenBSD instead. Which used to work the last time I tried it.

[jan-jaap]

I've seen this happen and I think it has to to with an existing filesystem on the disk.

I've fixed it like this:

* boot the correct version of sash
* boot fx -x from sash
* from fx, proceed to wipe the entire disk, like this: 'e'xecise > 'seq'uential > wr-o > [select all blocks] > go. This will take a while.
* before you leave fx, create a new disk label (use 'root disk' layout)

Now you can boot the miniroot and proceed with the installation.

NB: I allways erase disks these days. Nothing more annoying than sitting through three attempts at an installation throwing weird errors, only to find out the disk was duff. If it gives you reallocated sectors when erasing it, it's time to bin the disk.

[roach-commuter]

I've seen this happen and I think it has to to with an existing filesystem on the disk.

I've fixed it like this:

* boot the correct version of sash
* boot fx -x from sash
* from fx, proceed to wipe the entire disk, like this: 'e'xecise > 'seq'uential > wr-o > [select all blocks] > go. This will take a while.
* before you leave fx, create a new disk label (use 'root disk' layout)

Now you can boot the miniroot and proceed with the installation.

NB: I allways erase disks these days. Nothing more annoying than sitting through three attempts at an installation throwing weird errors, only to find out the disk was duff. If it gives you reallocated sectors when erasing it, it's time to bin the disk.

Alas, I just tried that. And it didn't help

---

OpenBSD runs happily though

[Raion]

It's probably not a hardware issue. It's more than likely operator error.

We don't support using alternative OSes on SGI/MIPS hardware though, if you decide to stick with that I suggest seeking support on the OpenBSD mailing list for best results.

[jan-jaap]

It says "wdsc1: 8 targets, initiator 0"

It's been a while since I last played with OpenBSD, but I'm pretty sure you jumpered your harddisk as SCSI ID #0. This is the ID of the controller and the result is chaos. Symptoms: a 'hinv' from PROM console shows 8 disks when you have only one.

Try to set the system disk to ID #1

[roach-commuter]

It says "wdsc1: 8 targets, initiator 0"

It's been a while since I last played with OpenBSD, but I'm pretty sure you jumpered your harddisk as SCSI ID #0. This is the ID of the controller and the result is chaos. Symptoms: a 'hinv' from PROM console shows 8 disks when you have only one.

Try to set the system disk to ID #1

Uhm, interesting. Thanks for pointing that out. To be honest I did not pay much attention to the jumpering of the disks. For one thing it's a disk with a SCA connector that I managed to ram onto the Indigo2 sled via an adapter. The disk itself has ID jumpers and it's set to ID 0 and it's seen by hinv as controller(0) disk (1) . But the sled itself has one extra cable with what I presume is the jumpering/ID bits and I never used that. I haven't used that for the tape (there is a tape that is hard jumpered as scsi 4 and  a cdrom that is jumpered as scsi 6. Do you have any suggestions for the correct cabling/jumpering  And most of all, do I need to worry about termination?
Here is a pic of my hinv

---

It's probably not a hardware issue. It's more than likely operator error.

We don't support using alternative OSes on SGI/MIPS hardware though, if you decide to stick with that I suggest seeking support on the OpenBSD mailing list for best results.

It could be a curse
I appreciate your stance on using or not using specific OS'es but my point is not about OpenBSD itself. It's the bloody machine that is defying me and I will have irix installed onto it, even if I'll have to kill it.

[weblacky]

If the SCA Adapter is jumpered ID0 that’s a problem! The fact that detected ID and jumpered ID don’t match should have been a major red flag.

Please do as Jan-Jaap suggested and set booting HDD to ID1.

See if it still says ID1 on HINV. Then try install again.

Normally lowest bay is ID1, highest 3.5” bay is ID2, CDROM bay is ID3. But you can be anything except ID0, that’s the only requirement.

SGIs tend to have built in termination. Don’t enable termination on any drive!

Also SGIs love SCSI parity. Make the ID change but you may need to enable parity as well on all 3 devices to get best behavior.

[roach-commuter]

If the SCA Adapter is jumpered ID0 that’s a problem!  The fact that detected ID and jumpered ID don’t match should have been a major red flag. 

Please do as Jan-Jaap suggested and set booting HDD to ID1. 

See if it still says ID1 on HINV.  Then try install again.

Normally lowest bay is ID1, highest  3.5” bay is ID2, CDROM bay is ID3.  But you can be anything except ID0, that’s the only requirement. 

SGIs tend to have built in termination. Don’t enable termination on any drive! 

Also SGIs love SCSI parity.  Make the ID change but you may need to enable parity as well on all 3 devices to get best behavior.

Great tips! I'll try that tomorrow and we'll see. Thank you

[robespierre]

For one thing it's a disk with a SCA connector.... The disk itself has ID jumpers and it's set to ID 0

That's pretty unusual. I don't think I've seen a disk like that...
What is the model of the disk?

[weblacky]

You might as well post the disk model number so we can find the datasheet on it.