Hi to all,

I have a E450 with Solaris 8, there is a command on Solaris which tell me the
model of machine without read it from hardware but with software. I try with
uname, prtconf, isainfo but nothing.

Thanks to all for help.

Andrea

Andrea wrote:

> I have a E450 with Solaris 8, there is a command on Solaris which tell 
> me the
> model of machine without read it from hardware but with software. I 
> try with
> uname, prtconf, isainfo but nothing.

Both uname(1) and prtconf(1M) print the platform name and I can't 
believe you've missed that, so what do you mean by model?

$ uname -i
SUNW,Sun-Blade-100

-- 
Wishing you good fortune,
--Robin Kay-- (komadori)

Robin KAY wrote:

> Andrea wrote:
> 
>> I have a E450 with Solaris 8, there is a command on Solaris which tell
>> me the
>> model of machine without read it from hardware but with software. I
>> try with
>> uname, prtconf, isainfo but nothing.
> 
> Both uname(1) and prtconf(1M) print the platform name and I can't
> believe you've missed that, so what do you mean by model?
> 
> $ uname -i
> SUNW,Sun-Blade-100
> 

$ uname -i
SUNW,Ultra-4

But I thinked which it tell me UltraE450 as on Sun-Fire-280R.
Excuse me but on Sun Enterprise 420R which item print?
On Sun Enterprise 250 print SUNW,Ultra-250 not SUNW,Ultra-2.

Andrea.

Robin KAY wrote:
> Andrea wrote:
> 
>> I have a E450 with Solaris 8, there is a command on Solaris which tell 
>> me the
>> model of machine without read it from hardware but with software. I 
>> try with
>> uname, prtconf, isainfo but nothing.
> 
> 
> Both uname(1) and prtconf(1M) print the platform name and I can't 
> believe you've missed that, so what do you mean by model?
> 
> $ uname -i
> SUNW,Sun-Blade-100
> 
/usr/platform/`uname -m`/sbin/prtdiag | head -1
System Configuration:  Sun Microsystems  sun4u Sun Fire 280R (2 X 
UltraSPARC-III)

Regards,
Thomas

Andrea wrote:

> $ uname -i
> SUNW,Ultra-4
>
> But I thinked which it tell me UltraE450 as on Sun-Fire-280R.

Sun may sell, for example, two machines as being different 'models' but 
which have same system board only in a different case. Solaris can only 
tell you what information it has available so the output of `uname -i` 
may not correspond exactly to a particular 'model'.

> Excuse me but on Sun Enterprise 420R which item print?

SUNW,Ultra-80

> On Sun Enterprise 250 print SUNW,Ultra-250 not SUNW,Ultra-2.

That's because the E250 and the Ultra 2 have different hardware. All 
supported platforms have their own directory in /usr/platform.

-- 
Wishing you good fortune,
--Robin Kay-- (komadori)

Thomas Beneke wrote:

>> $ uname -i
>> SUNW,Sun-Blade-100
>>
> /usr/platform/`uname -m`/sbin/prtdiag | head -1
> System Configuration:  Sun Microsystems  sun4u Sun Fire 280R (2 X 
> UltraSPARC-III)

   'uname' is hopeless.  It reports just about whatever for various 
systems.  For instance, on a Netra t1405, the uname returns:

foxtrot# uname -a
SunOS foxtrot 5.8 Generic_108528-29 sun4u sparc SUNW,Ultra-80

   "prtdiag" is by far more accurate, but it still fails in some cases, 
we have a 'Netra[tm] 20' (as stated on the front panel), but prtdiag 
reports the other name, 'Netra T4'

bash-2.03# /usr/platform/sun4u/sbin/prtdiag
System Configuration: Sun Microsystems  sun4u Sun Netra T4 (UltraSPARC-III+)

   At one point we tried to make some scripts which could register 
machines into a database automatically, but... We have given up on Sun 
to fix it's naming problems.  Prtdiag also fails to distinguish between 
a Netra t1400 and t1405 (ok, its hard to tell them apart anyway), it 
can't distinguis between different models of  Netra T1 (AC200 or DC200), 
and perhaps more.  We have a limited range of machines here, so some 
other models can produce some other non-expected results.

   Models we have: Netras X1, T1, t1405 and 20 (T4); V100, V120, V210, 
V240, V280, V440, V480 and V880. Enterprise 220 and 420, blade 100 
(although reported as 150), and some older machines like Ultra-80, 
ultra-1 and possibly something else.

   /Marcin

   PS. prtdiag also has an annoying feature of reporting the number, 
type and speed of the processor(s) on the machine in different ways 
depending on machine/os_version, which makes for even more fun.

On Thu, 24 Jun 2004, Andrea wrote:

> $ uname -i
> SUNW,Ultra-4
>
> But I thinked which it tell me UltraE450 as on Sun-Fire-280R.

OK, Ultra 4 was one of the internal names for the E450 before
it shipped, and for some reason that name has stuck.

-- 
Rich Teer, SCNA, SCSA

President,
Rite Online Inc.

Voice: +1 (250) 979-1638
URL: http://www.rite-online.net

In comp.sys.sun.admin Marcin Dobrucki <Marcin.Dobrucki@takethisaway.nokia.com> wrote:
>>> $ uname -i
>>> SUNW,Sun-Blade-100
> 
>   'uname' is hopeless.  It reports just about whatever for various 
> systems.  For instance, on a Netra t1405, the uname returns:

It's not hopeless, it's just returning something different to what you're
expecting.  The man page says :
     -i    Prints the name of the hardware implementation  (platform)

Where the platform is NOT the same thing as the marketing name on the
front of the box.

> foxtrot# uname -a
> SunOS foxtrot 5.8 Generic_108528-29 sun4u sparc SUNW,Ultra-80

That's because the board in a t1405 is exactly the same as the board in
the Ultra-80 (not to mention the E420R), so the 'hardware implementation'
is exactly the same for each.

>   "prtdiag" is by far more accurate, but it still fails in some cases, 
> we have a 'Netra[tm] 20' (as stated on the front panel), but prtdiag 
> reports the other name, 'Netra T4'

Blame marketing for that one.  To quote the Sun System Handbook, 
"The name of this system was changed from Netra T4 to Netra 20.
The old name will be found in some system documentation and Solaris
output, as well as in the logo on the front of the chassis on some units."

> to fix it's naming problems.  Prtdiag also fails to distinguish between 
> a Netra t1400 and t1405 (ok, its hard to tell them apart anyway), it 
> can't distinguis between different models of  Netra T1 (AC200 or DC200), 

These ones are completely understandable. The only difference between a
t1400 and a t1405, or a T1 AC200 and a T1 DC200 is the power supply.
Pull a DC power supply out of a T1 DC200 and put in an AC power supply
and you've got an AC200. Given this, there's no physical way the system
could know what type of power supply it's got in it, and thus which
type of machine it is, without having some form of logic flowing to the
power supply, which is something these machines don't have.

Things _are_ getting better.  prtfru on a newer machine will not only
give you the part numbers of the critical components (which can then
easily be mapped back to a system type/etc), but even the serial numbers
of them. All of the new Volume and above products have this feature for
pretty much everything in the machine.

>   PS. prtdiag also has an annoying feature of reporting the number, 
> type and speed of the processor(s) on the machine in different ways 
> depending on machine/os_version, which makes for even more fun.

The output of prtdiag has never been a fixed interface. To quote the
man page, the output is "uncommitted and subject to change".  If you want
predictability, use prtconf which will give you the same info for CPUs
as prtdiag does.

  Scott

   Hey Scott, thanks for the other comments...

> Things _are_ getting better.  prtfru on a newer machine will not only
> give you the part numbers of the critical components (which can then
> easily be mapped back to a system type/etc), but even the serial numbers
> of them. All of the new Volume and above products have this feature for
> pretty much everything in the machine.

   Ah, nice indeed.  Run in across one of our 880's... especially the 
part number info is useful for us, when we have to write those parts 
replacement tags to Sun ;)

   Shame it doesn't work on all systems, checked the V100 i use for 
development, and it says "no fru data".  Seems like a couple of other 
older systems have the same problem.

> The output of prtdiag has never been a fixed interface. To quote the
> man page, the output is "uncommitted and subject to change".  If you want
> predictability, use prtconf which will give you the same info for CPUs
> as prtdiag does.

   My problem with prtdiag was that on different platforms with the same 
OS level, the data was reported differently.  I think the reason we 
prefered prtconf was that for the machines we actually have at the lab, 
it printed the model info a bit better (eg. prtconf returns Ultra-80 for 
a t1405 while prtdiag returns netra t1400/1405).

   /Marcin