Why doesn't probe-scsi work any more?

Would you believe that it now works as documented? I know, nobody reads the documentation, and now probe-scsi appears to hang up systems hard (models from Ultra1 on).

You will find this documented in the Openboot 2.X or 3.X Command Reference Manuals included in Solaris 2.x Manual set. The section is appropriately titled "A Caution About Using Some OpenBoot Prom Commands".

Several OBP commands (notably probe-scsi) will not work reliably if you boot the operating system, then exit directly into the Open Boot Prom without resetting the system. Worse yet, the OBP variable auto-boot? is almost always set, so it will have to be unset to avoid booting the OS immediately after the reset. The following commands should do the trick:

ok setenv auto-boot?=false

ok reset-all

ok probe-scsi

ok setenv auto-boot?=true

This system can't see the network! Everything looks OK, the cable is connected, but it doesn't see the network.

There could be several reasons for this one. If you're using 10Base-T or 100Base-T, the most likely reason is that someone has turned off the "heartbeat" or "link test" on your network interface. Some hubs require that this be disabled. Or possibly, the system was not connected to a network, and the user got tired of seeing:

le0: No carrier - cable disconnected or hub link test disabled?

If this is what has happened, the following OBP command will clear up the problem:

ok setenv tpe-link-test?=true

I've done a sys-unconfig, and now I can't get this system to recognize its network interfaces.

Sys-unconfig (/usr/sbin/sys-unconfig) is a great tool, but it does have one annoying idiosyncrasy. If the system wasn't configured for a network when it was unconfigured, it won't even bother asking you about networks when it comes up again. To set this right, you need to make the system look like it had a network. One of the easiest ways is:

1. Make an entry in /etc/hosts with an IP address and hostname

2. Create a file /etc/hostname.interface (where interface is the primary network interface, usually le0), containing the hostname from step 1.

3. Copy /etc/hostname.interface to /etc/nodename

4. /usr/sbin/sys-unconfig

When I try to boot my system, I get the following error:

The file just loaded does not appear to be executable.

You've tried to boot from a non-bootable disk, probably because the disk you chose isn't the one you thought you chose. This one is most likely to give you trouble in our older accounts.

On SPARC systems prior to the advent of the Sun4d, internal SCSI disks jumpered as target 0 would be addressed as 3 (and target 3 as 0).

The "swap" came to pass with the introduction of the SS1. The reason for it was that a lot of customers would be upgrading from their 3/50's, 3/60's and 3/75's, which did not have internal disks (if they had disks, they were more than likely in the old Sun3 Shoebox). As such, there was a potential conflict between internal disks in the SS1 and external disks in the Shoeboxes (even though we never supported the mixing of embedded and non-embedded scsi disks on the same bus (these were actually ESDI disks with a SCSI "adaptor")). The most probable SCSI ID's used by shoeboxes were (in order): 0, 2, 1 and 3. So, to avoid having customers changing the SCSI ID's on the disks inside the shoeboxes (they weren't the most service-friendly devices), internal disks were mapped to 3 and 1 (which were the least probable SCSI ID's to be used). You might say we've been paying for it ever since.

I just powered up my new Ultra1/Ultra2/Ultra150, and it won't boot!

This one is really deceptive, because the system probably booted just fine right out of the box, and everything was fine until the first time it was powered off.

The Sun4u machines require a Type5 keyboard. If you try to attach an older keyboard, you will not be able to go through the initial POST. You may, however, switch to an older keyboard once the system is running, and it will work fine until the next time it is powered off.

The truly strange part is that these (at least Ultra1 and Ultra2) systems will work with a Type4 keyboard for the first power-on only. The reason this happens is that the system power supply has a "memory" of its last state. This allows the neat feature of automatically rebooting a running system after power has failed and been restored, yet not rebooting machines which were off before the power failure.

This also means that an Ultra150 or Netra150 server running without a keyboard shouldn't be powered off through use of "init 5", the Power Management package, or the OBP "power-off" command. If you have done any of these things, you must either temporarily attach a Type5 keyboard or open up the system and toggle the power switch on the main power supply.

I powered on my Ultra450 server, but the system does not power up. Two of the three lights on each of the power supplies comes on but that is all.

Answer 1: There are interlock tabs on the side panels of the 450. The purpose of these tabs is to prevent the system from booting when the panels are removed (an airflow issue). If you do not seat the panels correctly, the interlock tab will not seat properly and the system will not boot. To fix this simply re-seat the panel (and make sure it's screwed in tight).

Answer 2: If you had a keyboard plugged into the 450 and hit the power off/on key to power off the system (or if you shut down with "init 5"), you must use the Keyboard power off/on key again to turn the 450 back on. Simply turning on the power switch in the back of the 450 won't do it.

For further information, Steve Leung wrote a very good article on OpenBoot in the October '95 issue of SunWorld Online.

Also, refer to the OpenBoot documentation at docs.sun.com.

This page is maintained by Curt Harpold