NVRAM/IDPROM

[cxb...@gmail.com]

I am a new graduate student at UMKC-Physics. I have been put in charge of getting a lab back up and running that has not ran in quit some time. We have a Omicron sun4m running Solaris controlling our STM. Luckily It had turned on, however it seems to have forgotten its boot device, has hostid errors and doesn't remember its time if shut off and turned back on. I believe this is because of a bad NVRAM but would like to be damn sure before proceeding as if it is. I believe this bad NVRAM is causing the workstation to not know what its hostid is and therefore when the hostid is compared to that listed in the license.dat file I get errors that keep me from using my omicron software with the full privileges I have.
I have found this link, which seem very helpfully and pointed me here: http://www.menet.umn.edu/~bob/FAQ/sun-nvram-hostid.faq

I have little to know knowledge/experience with this computer, just one week worth of trying to diagnose it. And my UNIX knowledge is limited at best. I

I was hoping I might be able to get in contact with someone that might be capable of walking me through a procedure to verify that this is indeed the issue, and how to address it. As the last thing I wanna do I render this workstation UNBOOTABLE or mess up anything.

You can post here or email me directly at : cxb...@mail.umkc.edu

I would attach pictures of the errors I can find/teas out but I don't see an attach button, please let me know how to do so or inquire for them.

Abridged errors:
Forgotten boot device (disk)
Incorrect configuration checksum;
IDPROM contents are invalid
invalid format code in IDprom.
WARNING:TOD clock not initialized
LICENSE MANAGER: Invalid license key (inconsistent encryption code) (-8, 130)
license file can not be checked out (FLEXlm error: -15)
inconsistent incription code for idl_rt
bad hostid format
hostid: hostid string returned by sysinfo not numaric ""


these are not all the errors but the ones that I fell or know to date that support a bad NVRAM hypothesis.

I would also like to know if replacing the chip will effect my license and if there is anything i can do do get it back up and running

[Andrew Smallshaw]

On 2018-06-13, cxb...@gmail.com <cxb...@gmail.com> wrote:
> I am a new graduate student at UMKC-Physics. I have been put in
> charge of getting a lab back up and running that has not ran in
> quit some time. We have a Omicron sun4m running Solaris controlling
> our STM. Luckily It had turned on, however it seems to have forgotten
> its boot device, has hostid errors and doesn't remember its time
> if shut off and turned back on. I believe this is because of a bad
> NVRAM but would like to be damn sure before proceeding as if it
> is. I believe this bad NVRAM is causing the workstation to not know
> what its hostid is and therefore when the hostid is compared to
> that listed in the license.dat file I get errors that keep me from
> using my omicron software with the full privileges I have.

The general issues you describe certainly sound like a dead NVRAM,
can't comment on the licensing issues with your specific software
but tying to HostID seems quite plausible to me. Without any
specific issue I would say follow the FAQ - it's too long ago that
this cropped up for me to have anything worth adding except if you
have a specific issue.

The problem I do anticipate is recovering the original HostID,
which sounds like is going to be significant here. Ideally you
will have some documentation to refer to, for example I routinely
print off a dmesg after an OS install or major reconfiguration in
part for issues just like this. Sounds like they might be hard to
come by but may be worth asking around for.

Alternatively have a good look at the machine, inside and out: if
it has been used at all in the last 10-15 years it is likely this
is not the first time it has needed replacing and the previous chap
may have done you a favour and noted the HostID and/or MAC address
somewhere - I know I generally put them on a sticker either on the
PSU or the lid of the case for future reference - documents can
easily get lost after all.

The other place I'd look would the BOOTP (or more likely DHCP)
server for the LAN: even if the machine generally booted off the
local disk with a static IP address it isn't too unusual to find
an entry for the system there even if only for netbooting on OS
installation, especially likely if there is no optical drive. If
you can track down the MAC address for the system from there the
initial byte of the HostID is determined by the type of the system
and the remaining three bytes are the last three bytes of the MAC
address. Again, it's quite possible the DHCP server has inself
been replaced over the years but those settings are often copied
over without even considering whether the machine in question is
in active use, just to avoid the risk of breaking something.

--
Andrew Smallshaw
and...@sdf.org

[cxb...@gmail.com]

Thank you for you reply.
I have read through the FAQ and think I have a better understanding of things.
Correct me if i'm mistaken but my actions here forth will be something like
1.) get the corresponding chip and replace (model dependent )
2.) have the default values set (excluding the IDPROM info ) .
3.) set idprom with the procedure describe in the FAQ.
"General sun4c, sun4m, sun4d, sun4u IDPROM Programming" or do I use the
"A Quick-and-Dirty Guide to Restoring the NVRAM of a sun4c/m/u machine" ?

3.a.1) I will need to set the hostid, where the fist byte is set specific to the machine. (Its here I get confused as I am unaware of my model or how to find it. all I know is sun4m, sparc )
3.a.2) set last 3 bytes, which as you said can be found from the MAC id. (You listed a few ways to find this. The FAQ mentions a way to reconstruct the HOST ID and Ethernet id ..

"The NVRAM chip will usually have a white or yellow barcode label on it
(except for sun4d). Given the barcode, Sun can reconstruct your original
hostid and ethernet address. On newer machines (some SS5, SS20, all Ultras)
the number printed on the barcode is the last three bytes of the ethernet
address and also the last three bytes of the hostid. The first three bytes
of the ethernet address are always 8:0:20 and the first byte of the hostid
is determined by the system type (see table below), so on these machines you
can trivially reconstruct the hostid. I have no idea how to do it on the
machines with the old style barcode label, but if nothing else, the label
makes the NVRAM chip easy to identify.
"

..but it is unclear to me if this applies to the sun4m or just the "newer models") . Should this not be a option for recovery, is the another spot to look or command to use?
4.) Set Ethernet id. (if the above applies then this is simple as it the same as the last three bytes of the hostid. If not I would like to do a bit more reading before asking a question on this matter.)
5.) Am I done after running the command to set these? do I just go to booting or restart?
5.b) How do I set the boot info as this is also stored by the NVRAM?
6.) Is there anything else that needs to be done?


I am felling more confident on how to move forward from here, I would just like to get some of this ambiguity cleared up. Thank you very much for your time and help.

[Doug McIntyre]

cxb...@gmail.com writes:
>I have read through the FAQ and think I have a better understanding of things.

The FAQ is very very good, but the information is dated. The FAQ
generally covers machiens from 1985 to 1995 or so, and your Sun4m is
near the tail of that. :-)

>1.) get the corresponding chip and replace (model dependent )

In this day and age, this may well be the hardest step. Finding
even a comparable replacement with a good battery may well be an
exercise in futility. Things change in the 20 years+ the FAQ was
last maintained.

It may be better to wire a new battery set to your old chip.

https://gigawa.lt/gigawa.lt/Sun_NVRAM.html

>2.) have the default values set (excluding the IDPROM info ) .
>3.) set idprom with the procedure describe in the FAQ.
>"General sun4c, sun4m, sun4d, sun4u IDPROM Programming" or do I use the
>"A Quick-and-Dirty Guide to Restoring the NVRAM of a sun4c/m/u machine" ?

It isn't that critical.

>3.a.1) I will need to set the hostid, where the fist byte is set
>specific to the machine. (Its here I get confused as I am unaware of
>my model or how to find it. all I know is sun4m, sparc )

sun4m doesn't really look at the first byte of the hostid anyway.
I think eventually it was all 80 or 83 or something like that. That
was more a sun3 thing.

>3.a.2) set last 3 bytes, which as you said can be found from the MAC id. (You listed a few ways to find this. The FAQ mentions a way to reconstruct the HOST ID and Ethernet id ..

This information wasn't necessarly true when written.

But your most reliable way, and for matching something in your original post,
you have FlexLM wanting to look for a hostid.

Look at your FlexLM license file

SERVER my_server 17007ea8 1700
VENDOR sampled
FEATURE f1 sampled 1.000 01-jan-2005 10 SIGN=9BFAC0316462
FEATURE f2 sampled 1.000 01-jan-2005 10 SIGN=1B9A308CC0F7


The hostID should be 17007ea8 for this example.

FlexLM on Sun4m didn't bother with the Ethernet MAC address. Make up
whatever you want, or use the formula (I cut out). As long as it is
unique on your layer2 network, it doesn't matter what you use.

>5.b) How do I set the boot info as this is also stored by the NVRAM?

You should be able to find some openboot documents like this one
http://www.adminschoice.com/sun-openboot-parameters-and-commands

I don't remember having to put in specific device boot paths after
doing up a new NVRAM, but your computer may be different.


--
Doug McIntyre
do...@themcintyres.us

[DoN. Nichols]

On 2018-06-13, cxb...@gmail.com <cxb...@gmail.com> wrote:

If you use the info from the FAQ -- you can render the system
bootable again -- but your FlexLM will be unhappy, because it involves
creating a different hostID. The first bytes need to match the system
type, the last ones should be selected near the high end of the values
which will fit so they won't conflict with any machines which were
actually produced.

You say "Omicron sun4m" -- is this a computer which was made by
Sun, and Omicron supplied it loaded with licensed software?

If the computer was from Sun -- typically the HostID NVRAM has a
bar-code label on it. And it used to be that you could pay Sun for a
replacement NVRAM with the same HostID derived from that bar code. This
would solve your problems. (I say *if* because I have used some SPARC
computers which were made by Solbourne. They had a different way to do
this. The HostID, and the ethernet MAC address were stored in a bipolar
PROM chips, and the setup info like the boot drive were in a CMOS RAM
maintained by a separate coin cell. If you had this setup in the
computer, you would have no problems other than needing to replace the
coin cell, and and perhaps re-enter the proper "boot-device-" string.
(That is likely easy to determine from the jumpering of the disk drive.
And in some of the Sun4M systems, the drive ID is defined by the slot it
is plugged into.)

The question is whether Oracle maintains the data to continue
this service. And whether they will do so.

The alternative is to use the info in the FAQ, create a new
HostID (the first bytes tell what kind of system it is, and the last are
a serial number), and see whether Omicron can give you a new license key
for the new HostID. (Or perhaps they still have a record of the HostID
they issued the license key for, and can provide that to you. -- Then
you re-build the NVRAM with that HostID)

Note, that if the computer had been kept powered up all this
time, the NVRAM likely would still have charge, as the drain from the
coin cell potted into the chip package would have been minimal. The
longer it is powered down, the faster that cell discharges. (However,
the disk drives would likely have failed by now, unless they were stored
separate from the computer.) IIRC, the NVRAM chips were supposed to
have a ten-year life, but powered up most of the time increases that
life significantly.)

Good Luck,
DoN.

--
Remove oil spill source from e-mail
Email: <BPdnic...@d-and-d.com> | (KV4PH) Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---

[Doug McIntyre]

"DoN. Nichols" <BPdnic...@d-and-d.com> writes:
> The question is whether Oracle maintains the data to continue

>this (replacement NVRAM) service. And whether they will do so.

Ha ha ha, even Sun didn't maintain that service at the end.


--
Doug McIntyre
do...@themcintyres.us

[cxb...@gmail.com]

UPDATE:

I have found documentation stating what I believe to be my original Hostid and Ethernet id.
Host-id: 808bc7f5
Ethernet id: 0:80:42:10:57:f5
From the first byte of the host ID and the FAQ, I surmise that the system model is one of the following
SPARCstation Classic, LX, 4, 5, SS1000, Voyager, Ultra 1
But I don't understand which one it is? Or why both of these dot match the conventional way of doing things.
Also the data sheet (customer sheet) where I found the hostid and the Ethernet id also lists:
SN#
Operating System: Solaris V2.5
Driver type: omicron v2.3
some setup info

When I use the command "uname -a" I get the following back
" SunOS scala 5.5 Generic_103093-08 Sun4m sparc sun4m"
The workstation information also says
"SunOS 5.5 Gen..."

And the start of the workstation it loads Sunos

I am wondering if/why/what is causing the workstation to load as sun and not Solaris.

Also, I found this line in the FAQ

"The hostid on Solaris 2.5 x86

Intel processor machines don't have an IDPROM. Sun uses a different
mechanism to generate the hostid. When the operating system is initially
installed a pseudo-random hostid is generated. It appears that this
pseudo-randomly generated hostid will always be between 1 and 3b9aca00. The
hostid is based on eight bytes of serialisation information in the kernel
module /kernel/misc/sysinit. This is in contrast to the situation on SPARC
machines where the hostid is based on the IDPROM.

/kernel/misc/sysinit contains code which initialises the variable hw_serial
in the kernel based on the serialisation information. On both SPARC and x86
versions of Solaris 2.5, hw_serial stores the hostid as a decimal C string.

Other than the eight bytes of serialisation information the
/kernel/misc/sysinit files do not differ between machines. Four of the
serialisation bytes depend upon the other four bytes, so the hostid is
somewhat tamper resistant. If the serialisation information is tampered with
carelessly or the sysinit module fails to load for some other reason, the
hostid of the machine will be 0. A little more obfuscation is done in the
code, i.e. hw_serial is not referenced directly in the module, but
indirectly via the pointer _hs1107."

What I find confusing is whether or not to treat this workstation as a sun, sparc, or solaris.

Furthermore, the line about the host id being zero is directly applicable to what is happening. the work station info yields it as a zero and the licnse.dat file dose so to. I think I got hostid to say it one time but now all i get is the aforementioned errors.

I have no idea the ramifications of this new info or how to proceed.
I have found what I believe to be a new NVRAM for the sun4m, but would like to hold off on getting it till I am certain how to proceed.

I could not find a "/kernel/misc/sysinit " file

I do not know where to find a FLEXlm.dat license file


My thoughts: I assume that the pc is defaulting to the sun operation system, the reason is unknown but it either has to do with the NVRAM or telling it "boot disk" .

You say "Omicron sun4m" -- is this a computer which was made by

Sun, and Omicron supplied it loaded with licensed software? --------------------------------------------------------------------------------------------Yes I believe so


@Don , thanks for your response, Looks like it will be helpful, but at the moment I do not fully understand what you are saying I will need to think on it and formulate some questions.

There Is just so much new information involved with trying to get this up and running figuring out what information is good and bad, much less keeping it all strait and understanding it is a bit difficult. I thank you all for your help and patience on this matter.


If any of you are available to call at your convince , Being able to verbally discus or bounce back ideas would be very helpful as this form has been really the only and best source of information to me.

[Winston]

cxb...@gmail.com writes:
> I am wondering if/why/what is causing the workstation to load as sun and not Solaris.

Solaris = SunOS + additional (non-kernel) stuff.
-WBE

[DoN. Nichols]

On 2018-06-17, cxb...@gmail.com <cxb...@gmail.com> wrote:
> UPDATE:
>
> I have found documentation stating what I believe to be my original Hostid and Ethernet id.
> Host-id: 808bc7f5
> Ethernet id: 0:80:42:10:57:f5

> From the first byte of the host ID and the FAQ, I surmise that the
> system model is one of the following

> SPARCstation Classic, LX, 4, 5, SS1000, Voyager, Ultra 1

Classic will probably not say so -- that was added later to
distinguish it from the later versions. It will probably only say
"Sparcstation" on the front.

"LX" is an almost square box. It has a line around the middle
of the height, and by removing a single screw in the back, it will pivot
open along the front edge. The hard drive and the floppy drive live in
the top half, and the rest of the system, including the "framebuffer"
(graphics card) to allow it to talk to a monitor, and possibly another
card, perhaps the Omicron special card, whatever it is.

SS4 (SparcStation 4), SS5 are about 3" tall and maybe 14" wide
and deep -- same as the original SparcStation. SS1000 is a much bigger
box. Ultra 1 is also a bigger box than the SS5 (about twice as tall),
but smaller than the SS1000. I forget what the Voyager looked like.

But it does not matter much, you have a system which boots,
(based on later things you typed, including your "uname -a" output) and
the only reason for the hostid to matter now is for the Flex License
Manager to allow the special software which is in it (and which I
presume is why you are trying to get it to run again). (And the
ethernet in the NVRAM matters only if you are trying to network it,
instead of use it as a stand-alone system.)

> But I don't understand which one it is? Or why both of these dot match
> the conventional way of doing things.

And what does the last sentence above mean?

> Also the data sheet (customer sheet) where I found the hostid and the
> Ethernet id also lists:

> SN#
> Operating System: Solaris V2.5
> Driver type: omicron v2.3
> some setup info
>
> When I use the command "uname -a" I get the following back
> " SunOS scala 5.5 Generic_103093-08 Sun4m sparc sun4m"
> The workstation information also says
> "SunOS 5.5 Gen..."

"scala" was the system's assigned name. Only matters when it is
networked and talking to other systems. If it is stand alone, don't
worry.

The "Sun4m" says that it is a SPARC based system, not x86, so
the information below where you mention things about x86 systems do not
apply. Note that it even *says* "sparc" (which, IIRC, stood for
"Scalable Processor Architecture RISC Computer". (And which says that
this is in no way a "PC". :-)

> And the start of the workstation it loads Sunos

Don't worry. SunOs is the name that Sun used to use, back in
the days of Motorola MC 68000 and MC 68010, 68020 systems, as well as
the early Sparc systems. (All were made by Sun.) SunOs up through
SunOs 4.x.y were based on BSD unix, while those starting with SunOs 5.x
were System V based -- and they started calling the combination Solaris
2.x (corresponding to SunOs 5.x) -- until they eventually threw away the
"2." part of the Solaris name, and started calling them Solaris 8,
Solaris 9, Solaris 10, and Solaris 11. Just games with the names, with
no real effect other than the underlying unix version. And with the
early Solaris 2.x versions, they even had libraries to allow programs
compiled for the BSD based SunOs 4.x.y. Those were abandoned, so you
had to re-compile programs at some point.

> I am wondering if/why/what is causing the workstation to load as sun
> and not Solaris.

Solaris was what was on the box when you bought the OS, But it
identifies itself during boot and from "uname -a" as SunOs 5.5 (in your
case) which would be Solaris 2.5. Don't worry about what it is calling
itself.

> Also, I found this line in the FAQ
>
> "The hostid on Solaris 2.5 x86

Yours is *not* an x86 (that is Intel processor) computer. Ignore
the following paragraph or two.

> Intel processor machines don't have an IDPROM. Sun uses a different
> mechanism to generate the hostid. When the operating system is initially
> installed a pseudo-random hostid is generated. It appears that this
> pseudo-randomly generated hostid will always be between 1 and 3b9aca00. The
> hostid is based on eight bytes of serialisation information in the kernel
> module /kernel/misc/sysinit. This is in contrast to the situation on SPARC
> machines where the hostid is based on the IDPROM.
>
> /kernel/misc/sysinit contains code which initialises the variable hw_serial
> in the kernel based on the serialisation information. On both SPARC and x86
> versions of Solaris 2.5, hw_serial stores the hostid as a decimal C string.
>
> Other than the eight bytes of serialisation information the
> /kernel/misc/sysinit files do not differ between machines. Four of the
> serialisation bytes depend upon the other four bytes, so the hostid is
> somewhat tamper resistant. If the serialisation information is tampered with
> carelessly or the sysinit module fails to load for some other reason, the
> hostid of the machine will be 0. A little more obfuscation is done in the
> code, i.e. hw_serial is not referenced directly in the module, but
> indirectly via the pointer _hs1107."

> What I find confusing is whether or not to treat this workstation as a
> sun, sparc, or solaris.

They are all the same. (Sun did make some x86 ones which were
*not* SPARC, but this is *not* one.)

> Furthermore, the line about the host id being zero is directly
> applicable to what is happening.

No. *Yours* is zero because the cell (battery) in the NVRAM
chip is dead, so when the system is powered down, it forgets everything,
including the hostid.

> the work station info yields it as a
> zero and the licnse.dat file dose so to. I think I got hostid to say it
> one time but now all i get is the aforementioned errors.

Any value you get from the hostid command will be either zeros
or garbage. The NVRAM is really a "forgettary". :-)

> I have no idea the ramifications of this new info or how to proceed.

> I have found what I believe to be a new NVRAM for the sun4m, but would
> like to hold off on getting it till I am certain how to proceed.

> I could not find a "/kernel/misc/sysinit " file

That is only in the x86 (Intel based) systems. Not to be found
in SPARC based systems.

> I do not know where to find a FLEXlm.dat license file

I find it in a file of a different name and location:

/etc/opt/licenses/licenses_combined

And I found it by looking at the /etc/init.d/lic_mgr file, where
the section of the file:

======================================================================
#
# /etc/opt/licenses holds the license manager, links to
# several license management utilities and the license
# files. This directory is only required on the license
# server.
#
licdir=/etc/opt/licenses
======================================================================

Tells you where it is. And later in the /etc/init.d/lic_mgr you find
something like this:

======================================================================
#
# licenses_combined is the file which should contain all the
# licenses for this server.
#
licfile=licenses_combined
======================================================================

Giving the actual file name.

> My thoughts: I assume that the pc is defaulting to the sun operation
> system, the reason is unknown but it either has to do with the NVRAM or
> telling it "boot disk" .

It is *not* a PC. It can't run any Microsoft OS (while some of
the x86 ones can).

> You say "Omicron sun4m" -- is this a computer which was made by
> Sun, and Omicron supplied it loaded with licensed software?
> --------------------------------------------------------------------------------------------Yes
> I believe so

Likely so. Color is likely a light blue-gray. It should have
some identifying text on the front, such as the "Sparcstation 5" on my
example system. (Which happens to be running Solaris 2.6 (and uname -a
says:

======================================================================
SunOS izalco 5.6 Generic_105181-05 sun4m sparc SUNW,SPARCstation-5
======================================================================

Perhaps a bit more information because it is Solaris 2.6 instead
of your Solaris 2.5 -- I don't have that to see what it does. It also
happens to be the only system I have which is running a FlexLM -- just
for the compiler.

> @Don , thanks for your response, Looks like it will be helpful, but at
> the moment I do not fully understand what you are saying I will need to
> think on it and formulate some questions.

> There Is just so much new information involved with trying to get this
> up and running figuring out what information is good and bad, much less
> keeping it all strait and understanding it is a bit difficult. I thank
> you all for your help and patience on this matter.


> If any of you are available to call at your convince , Being able to
> verbally discus or bounce back ideas would be very helpful as this form
> has been really the only and best source of information to me.

It would probably be quicker if I could ask you to look at
something and describe it -- perhaps identify which system you have, for
example. But treat "SunOs", "Solaris" and "sun" as identical for your
purposes. That might simplify things.

Find where your flexlm file is (like my "licenses_combined" file
which I both pointed you to if it is the same, and showed you where to
find the information if it is not -- your /etc/init.d/lic_mgr file which
is what starts the license manager. And it *may* have a different name,
but look for "lic" as part of the name.

I do have a phone number in my .sig below -- but *please* don't
call me before about 2:00 PM Eastern Daylight Time -- I go to sleep very
late, and get up very late, thanks to being retired.

And maybe what you are using to read e-mails hides the .sig, and
you need to give it a command to show the .sig. (The .sig always
follows a line of "-- " (Two dashes and a space) which is how some
news clients detect and hide it.

[Doug McIntyre]

cxb...@gmail.com writes:
>I have found documentation stating what I believe to be my original Hostid and Ethernet id.
>Host-id: 808bc7f5
>Ethernet id: 0:80:42:10:57:f5
>From the first byte of the host ID and the FAQ, I surmise that the system model is one of the following

Cool, that should help you out very much. The FAQ you reference
covered 20 years of computerdom and is now 20 years old again. Most
people reading it at the time knew certain assumption. Again, as I've
stated, for most of the '90s, the HostID all started with 80. Don't
worry about the format of HostID. Don't worry too much about *what*
you have, other than a Sun SPARC, which is a RISC workstation/server
that you need to get working again. You probably need to worry if you
want to start doing things like adding RAM (each model can take
extremely specific special different memory). But basic things like
disks are all the same plus or minus whatever technology Sun used at
the time, and the keyboard/mouse/framebuffer/monitor are all unique
different technology that lost to the steam-roller of cheapo x86 PCs
taking over everything.

>"SunOS 5.5 Gen..."=20

>And the start of the workstation it loads Sunos

>I am wondering if/why/what is causing the workstation to load as sun
>and not Solaris.

SunOS = Solaris. They played some marketing games over time, the
definition was a slippery slope. For all intensive purposes, they are
the same.

>"The hostid on Solaris 2.5 x86

As Don said, you don't have an x86 machine, ignore anything x86.

>What I find confusing is whether or not to treat this workstation as a sun,
> sparc, or solaris.

You have a Sun workstation, with a SPARC (4m) processor, and running
SunOS or Solaris, depending on whatever marketing was doing that year.

>Furthermore, the line about the host id being zero is directly
>applicable to what is happening.

Yes, because your NVRAM battery is dead. You'll also find the Ethernet
MAC address is all zeros, and the machine can't talk on a LAN. It was
PCs that started burning the station address into the EEPROM BIA on
the NICs, before PCs, workstations did all sorts of different things.

>I do not know where to find a FLEXlm.dat license file

find / -name "*license*"

Look especially at files in /etc or /opt and then more or cat them.

But, you already seem to know the hostid off the documentation. Match
that on your NVRAM battery rebuild, and go from there. The most
important thing to match the hostid is for licensing. The OS doesn't
care what the hostid is, the hardware doesn't care, only the licensed
software running on the OS does.


>My thoughts: I assume that the pc is defaulting to the sun operation system=
>, the reason is unknown but it either has to do with the NVRAM or telling i=
>t "boot disk"

It sounds like you are booting already? You are failing to function
either on a network, or with whatever software is licensed because
of the dead NVRAM battery.
--
Doug McIntyre
do...@themcintyres.us

[Volker Borchert]

Doug McIntyre wrote:
> the keyboard/mouse/framebuffer/monitor are all unique
> different technology that lost to the steam-roller of cheapo x86 PCs
> taking over everything.

But any sun4m should automagically use ttya 9600@8?1 as console
if it can't find a keyboard at power-up.

> Yes, because your NVRAM battery is dead. You'll also find the Ethernet
> MAC address is all zeros, and the machine can't talk on a LAN.

IIRC the MAC address will be FF:FF:FF:FF:FF:FF (all-ones).

--

"I'm a doctor, not a mechanic." Dr Leonard McCoy <mc...@ncc1701.starfleet.fed>
"I'm a mechanic, not a doctor." Volker Borchert <v_bor...@despammed.com>

[cxb...@gmail.com]

I wanted to give an update for to whom it may concern.

I have got my workstation up and running.

It was ended bad NVRAM-battery.

I had my department engineer take the Workstation apart and he found 2 NVRAM. I believe he said on was on the video board and the other on the mother board. He has had experience with replacing NVRAMs in the past. He clames that sometime despite being lucky enough to get you hands on a new NVRAM it dosen't work. So what he did was find where the battery was with in the NVRAM using a magnet, took a magnifying glass and dermal drill to cut open the top of the NVRAM to gain access to the battery. He then wired up external coin bateries for both NVRAM. He did this in the even that they leak they don't ruin the NVRAM.

We then put it all back together, Reprogrammed using the "## # mkp" commands followed by "0 f 0 do i idprom@ xor loop f mkp" then "reset"

at first this put my WS in an infinite loop trying to boot from the Ethernet to which it is not hooked up. But i learned that "stop + a" gets me to the "ok" prompt. At which point "boot disk" worked with no issue.

After reinstalling my license.dat file so its hostid matched that of the WS, my program worked as it should. It was/is a beautiful thing.

I read that making the WS boot to disk default is an easy short command but never did it as we arn't supposed to turn the WS off anyways.

But, I would like to get the TOD set right. I still have issues with this. I'm trying "date 081311452118" as the format should be date MMddhhmm[[cc]yy] where cc was to be century minus one. however I can never get all the bytes to mach what i enter. For example. I may get the month and time right , but the day and year will be way off. If tried many combos of this command and could not get it to work. The only way i could get it to a date 20xx was with ccyy=2418 but that yielded 2010. which made my day and i believe time wrong. I have no idea whats going on as there is no clear correlation between what i enter and what i get. some times i enter 08 = MM and get July . If any one know how to solve this last issue I would be grateful, well more grateful than I already am. Thank you all for your help. Without it my lab would be nothing more than scrap metal

[DoN. Nichols]

On 2018-08-15, cxb...@gmail.com <cxb...@gmail.com> wrote:
> I wanted to give an update for to whom it may concern.
>
> I have got my workstation up and running.

Congratulations!

> It was ended bad NVRAM-battery.

> I had my department engineer take the Workstation apart and he found 2
> NVRAM. I believe he said on was on the video board and the other on the
> mother board.

O.K. Only some framebufers (video/graphics boards) will have
that -- the fancier and more complex ones. But the system board should
always have that for something of that vintage.

> He has had experience with replacing NVRAMs in the past.
> He clames that sometime despite being lucky enough to get you hands on a
> new NVRAM it dosen't work.

Yes -- the chip used had a bug which Sun used in its driver.
Newer chips don't have that bug, and don't work with the driver. So
replacing the cell in the chip was the better approach.

> So what he did was find where the battery was
> with in the NVRAM using a magnet, took a magnifying glass and dermal
> drill to cut open the top of the NVRAM to gain access to the battery. He
> then wired up external coin bateries for both NVRAM. He did this in the
> even that they leak they don't ruin the NVRAM.

Great!

> We then put it all back together, Reprogrammed using the "## # mkp"
> commands followed by "0 f 0 do i idprom@ xor loop f mkp" then "reset"

> at first this put my WS in an infinite loop trying to boot from the
> Ethernet to which it is not hooked up. But i learned that "stop + a"
> gets me to the "ok" prompt. At which point "boot disk" worked with no
> issue.

From a booted system:

eeprom boot-device=disk

from a system at the EPROM level:

setenv boot-device disk

note the '=' sign in the eeprom command, but the space in the EPROM
setenv command.

[ ... ]

> But, I would like to get the TOD set right. I still have issues with
> this. I'm trying "date 081311452118" as the format should be date
> MMddhhmm[[cc]yy] where cc was to be century minus one. however I can
> never get all the bytes to mach what i enter. For example. I may get the
> month and time right , but the day and year will be way off. If tried
> many combos of this command and could not get it to work. The only way i
> could get it to a date 20xx was with ccyy=2418 but that yielded 2010.
> which made my day and i believe time wrong. I have no idea whats going
> on as there is no clear correlation between what i enter and what i get.
> some times i enter 08 = MM and get July . If any one know how to solve
> this last issue I would be grateful, well more grateful than I already
> am. Thank you all for your help. Without it my lab would be nothing more
> than scrap metal

The man page for Solaris 2.6 "date" says:

/usr/bin/date [-u] [[mmdd]HHMM | mmddHHMM[cc]yy][.SS]

or

/usr/xpg4/bin/date [-u] [[mmdd]HHMM | mmddHHMM[cc]yy][.SS]

It looks like your numbers were right, but the case of the letters in
your template was wrong.

Is it possible that you have a version old enough so it has not
been made Y2K compliant? There were patches as Y2K approached. The
version I have give the following in Solaris 2.6:

# sum /bin/date
9830 16 /bin/date

or:

# md5 /bin/date
MD5 (/bin/date) = 1f79e886fe37b3cce672c318788848b8

If your numbers are different perhaps you have a non Y2K compliant
version of the date command.

I could send you mine, if you want to accept a binary and try

[cxb...@gmail.com]

>
> Is it possible that you have a version old enough so it has not
> been made Y2K compliant? There were patches as Y2K approached. The
> version I have give the following in Solaris 2.6:
>
> # sum /bin/date
> 9830 16 /bin/date
>
> or:
>
> # md5 /bin/date
> MD5 (/bin/date) = 1f79e886fe37b3cce672c318788848b8
>
> If your numbers are different perhaps you have a non Y2K compliant
> version of the date command.
>
> I could send you mine, if you want to accept a binary and try
> it.
>
> Good Luck,
> DoN.
>

I got it to work , but oddly so. I entered "date 120305252426" to get aug 16 10:00 am 2018

from what prompt do i use the eeprom command. it did not work in shell

[Chris]

On 08/16/18 15:59, cxb...@gmail.com wrote:

> I entered "date 120305252426" to get aug 16 10:00 am 2018

That's good, whatever makes it work, right:-)...

Chris

[DoN. Nichols]

On 2018-08-16, cxb...@gmail.com <cxb...@gmail.com> wrote:
>
>>
>> Is it possible that you have a version old enough so it has not
>> been made Y2K compliant? There were patches as Y2K approached. The
>> version I have give the following in Solaris 2.6:

> I got it to work , but oddly so. I entered "date 120305252426" to get
> aug 16 10:00 am 2018

Weird. Now, with a modified version of "date", I could use
"int-date 1534642370" -- using the integer number of seconds since the
start of 1970 GMT. That is 10 characters. Yours is 12 characters. 12
is the proper number for this format:

mmddHHMM [cc] yy]

excluding the seconds option -- but the values are really weird. They
*should* be "081610002018". What time zone are you in?

Note that the modified version of "date" I speak of is one which
I wrote myself to gain easy access to the integer value the
system stores -- and a companion program to write that value
into a system which had no Y2K setting ability, though it would
*display* the time properly once set. It was the lack of
library routines to convert lines with the century value into
the proper 32-bit integer.

What do you get if you type:

"echo $TZ"

In my case, I get:

US/Eastern

> from what prompt do i use the eeprom command. it did not work in shell

What does it say: If it says:

======================================================================
>eeprom
eeprom: Command not found.
======================================================================

then the PATH is not set to look in the right place. Immediately below
is the first part dealing that that problem. Near the bottom is the
other possible problem:

It should work in any shell -- sh, csh, bash (if installed), zsh
(if installed), tcsh (if installed), and a number of other possibilities.

However, it is sensitive to your PATH environment variable. It
is located in /usr/sbin/eeprom. You can type the full path as shown, or
you can edit the PATH environment variable to add that to the path. You
can see what it is set to by typing:

echo $PATH

and will see a long listing of possible directories separated by ':'
characters.

You can temporarily add it by typing:

setenv PATH ${PATH}:/usr/sbin
and then type "rehash"

if using csh or a variant like tcsh.

If using sh instead, it should be something like this:

PATH=${PATH}:/usr/sbin
export PATH

and you can follow either version with:
echo $PATH

and you should see ":/usr/sbin" at the end of the shown path.

This will work until you log out and back in, or reboot, or
change to a different user.

I don't include my path as an example because I have expanded
it greatly, including a number of directories which you will not have
unless you add them. This shows how many entries are in my $PATH
environment variable:

# echo $PATH | tr ':' '\n' | wc -l
63

If you get:

======================================================================
> eeprom testarea=0
eeprom: cannot open /dev/openprom: Permission denied
======================================================================

Note the '>' prompt, which shows that it is being commanded by a
non-privileged user.

Consider this line from the man page for eeprom:

======================================================================
Only the super-user may alter the EEPROM contents.
======================================================================

So -- you must be root to do it. Then your prompt will be '#' instead.

You can always find some helpful information by typing:


======================================================================
man eeprom
======================================================================

In this case, or "man whatever-command" as needed for other commands.

Of course, when using the "setenv" command from the OPENBOOT
PROM, there is no question of permissions. If you are sitting there at
the console, and it has the "ok" prompt, you have the permissions
needed.

[YTC#1]

/usr/sbin/eeprom

>
>



--
Bruce Porter
"The internet is a huge and diverse community but mainly friendly"
http://ytc1.blogspot.co.uk/
There *is* an alternative! http://www.openoffice.org/