Hi,<snip>
our professorship's Sparc Enterprise M4000 heavily used for student labs suddenly went down (power off) with lighting amber LED. :-(((
Here the related outputs:
You see the huge problem: What can I do to get the M4000 back in service?
Many thanks in advance for every hint.
Kind regards
Kay-Uwe Loebel
In all honesty, the quickest (and time cheapest) method would be to get
on Ebay and buy another one, then swap the disks etc. (They are quite
cheap).
Then thing about your DR policy :-)
If you have another M series handy, get the disks in that and take flash archives of the OS and backup of the data.
The hostid is probably an easy solution. Many ways to skin a cat.
Perhaps it's possible to install a more recent firmware (we have 1081),
which allows the status reset by a simple power on/off with the key in
the service position?
And that is an old FW at that.
Do you /someone know, why a further test of the PSB fails?
XSCF> testsb 0
Initial diagnosis is about to start, Continue?[y|n] :y
The current configuration does not support this operation.
This thread may help, as you have been reseting the system <url:https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=12587jyhco_4&_afrLoop=366634817834842>
I do, and some functions are already ported to a linux server.
Booo, hisss !!!!
We have the only one Mxxx in the university.
What about any other Sparc boxes ? T series ? V series ?
Am 11.09.2019 um 09:42 schrieb YTC#1:
In all honesty, the quickest (and time cheapest) method would be to get
on Ebay and buy another one, then swap the disks etc. (They are quite
cheap).
A pragmatic solution of course, but I fear, that the university will not advocate the purchase of a second obsolete piece of hardware.
Moreover the licence server for our CAD software is bound till the end
of the year to the current hostid.
Perhaps it's possible to install a more recent firmware (we have 1081),
which allows the status reset by a simple power on/off with the key in
the service position?
Do you /someone know, why a further test of the PSB fails?
XSCF> testsb 0
Initial diagnosis is about to start, Continue?[y|n] :y
The current configuration does not support this operation.
Then thing about your DR policy :-)
;-)
I do, and some functions are already ported to a linux server.
Nevertheless the M4000 has 2 PSUs and 2 system disks, the main causes of desasters ...
If you have another M series handy, get the disks in that and take flash
archives of the OS and backup of the data.
We have the only one Mxxx in the university.
Am 11.09.2019 um 12:26 schrieb YTC#1:
The hostid is probably an easy solution. Many ways to skin a cat.
I know the LD_PRELOAD disguise. ;-)
Perhaps it's possible to install a more recent firmware (we have 1081),
which allows the status reset by a simple power on/off with the key in
the service position?
And that is an old FW at that.
Okay, the 1050 should enable this feature?
But where get from and is it possible to install firmware in the faulted state?
Do you /someone know, why a further test of the PSB fails?
XSCF> testsb 0
Initial diagnosis is about to start, Continue?[y|n] :y
The current configuration does not support this operation.
This thread may help, as you have been reseting the system
<url:https://support.oracle.com/epmos/faces/SearchDocDisplay?_adf.ctrl-state=12587jyhco_4&_afrLoop=366634817834842>
Unfortunately I can't access the thread without Support Identifier ...
I do, and some functions are already ported to a linux server.
Booo, hisss !!!!
Don't blame me, since at least 5 years I'm the last SPARC / Solaris user
here ... ;-)
We have the only one Mxxx in the university.
What about any other Sparc boxes ? T series ? V series ?
UltraSPARC 45 and SunBlade 2000 are still working excellently.
Am 11.09.2019 um 09:42 schrieb YTC#1:[...]
In all honesty, the quickest (and time cheapest) method would be to get
on Ebay and buy another one, then swap the disks etc. (They are quite
cheap).
A pragmatic solution of course, but I fear, that the university will not advocate the purchase of a second obsolete piece of hardware.
Moreover the licence server for our CAD software is bound till the end
of the year to the current hostid.
Kay-Uwe Loebel <loebel@etit.tu-chemnitz.de> writes:
Am 11.09.2019 um 09:42 schrieb YTC#1:[...]
In all honesty, the quickest (and time cheapest) method would be to get
on Ebay and buy another one, then swap the disks etc. (They are quite
cheap).
A pragmatic solution of course, but I fear, that the university will not
advocate the purchase of a second obsolete piece of hardware.
Moreover the licence server for our CAD software is bound till the end
of the year to the current hostid.
Can you talk to your vendor about changing the hostid for the license
server? I would hope they have provisions for dying hardware.
Okay, the 1050 should enable this feature?
But where get from and is it possible to install firmware in the faulted
state?
I take it you don't any Oracle support ?
Oh, looks like I attached the wrong link anyway :-( <url:https://community.oracle.com/community/support/oracle_sun_technologies/sparc_m-series_servers>
It is suggesting no CPU is attached to the domain
Am 11.09.2019 um 17:17 schrieb YTC#1:
Okay, the 1050 should enable this feature?
But where get from and is it possible to install firmware in the faulted >>> state?
I take it you don't any Oracle support ?
Right, it wouldn't be an easy thing of course.
Oh, looks like I attached the wrong link anyway :-(
<url:https://community.oracle.com/community/support/oracle_sun_technologies/sparc_m-series_servers>
It is suggesting no CPU is attached to the domain
Thanks for the hint - I guess you meant the motherboard (XSB) is not
assigned to the domain.
It is, but I de- and re-assigned it just to be sure:
XSCF> showboards -v -d 0
XSB R DID(LSB) Assignment Pwr Conn Conf Test Fault COD
---- - -------- ----------- ---- ---- ---- ------- -------- ----
00-0 * 00(00) Assigned n n n Unknown Faulted n
XSCF> testsb 0
Initial diagnosis is about to start, Continue?[y|n] :y
The current configuration does not support this operation.
XSCF> deleteboard -c unassign 00-0
XSB#00-0 will be unassigned from domain immediately. Continue?[y|n] :y
XSCF> showboards -v -d 0
XSB R DID(LSB) Assignment Pwr Conn Conf Test Fault COD
---- - -------- ----------- ---- ---- ---- ------- -------- ----
00-0 SP Unavailable n n n Unknown Faulted n
XSCF> testsb 0
Initial diagnosis is about to start, Continue?[y|n] :y
The current configuration does not support this operation.
XSCF> addboard -c assign -d 0 00-0
XSB#00-0 will be assigned to DomainID 0. Continue?[y|n] :y
It seems that one condition is still missing to re-test the board.
Perhaps the XSB must be _connected_ the the domain, but there's no
special option / command to perform this. :-(
Alternatively I look for a way to perform a "clearstatus /MBU_A" ...
or to prevent the XSCF from starting the /scf/sbin/fmd daemon ...
There must be a way for _my_ purchased machine. ;-)
It has been a while since I touched an Mx000, never mind trouble shot
one :-(
What does
fmdump -v -u 5fa5d831-1d4b-4344-a6c9-5939d01886bb
Show ?
There must be a way for _my_ purchased machine. ;-)
Yeah, but it is old and broken.
Am 12.09.2019 um 21:36 schrieb YTC#1:
It has been a while since I touched an Mx000, never mind trouble shot
one :-(
a fortiori I appreciate your help!
What does
fmdump -v -u 5fa5d831-1d4b-4344-a6c9-5939d01886bb
Show ?
Now: nothing, because I did carry out a factory reset. ;-)
TIME UUID MSG-ID
fmdump: /var/opt/sun/fm/fmd/fltlog is empty
Of course I saved the outputs before:
XSCF> fmdump -v -u 5fa5d831-1d4b-4344-a6c9-5939d01886bb TIME UUID MSG-ID
Aug 27 08:37:47.6128 5fa5d831-1d4b-4344-a6c9-5939d01886bb SCF-8003-HA
100% fault.chassis.SPARC-Enterprise.asic.mbc.fe
Problem in: hc:///chassis=0/cmu=0/mbc=0
Affects: hc:///chassis=0/cmu=0/xsb=0 FRU: hc://:product-id=SPARC Enterprise M4000:chassis-id=BC********:server-id=******:serial=BC********:part=CF00541-0893
06 \541-0893-06:revision=0101/component=/MBU_A
Location: /MBU_A
XSCF> fmdump -v -u 8852b041-6bc0-4fe9-b972-d373dfd0f10c TIME UUID MSG-ID
Aug 27 08:38:07.3002 8852b041-6bc0-4fe9-b972-d373dfd0f10c SCF-8003-LS
100% fault.chassis.SPARC-Enterprise.asic.mbc.se
Problem in: hc:///chassis=0/cmu=0/mbc=0
Affects: hc:///chassis=0/cmu=0 FRU: hc://:product-id=SPARC Enterprise M4000:chassis-id=BCF092404K:server-id=******:serial=BC********:part=CF00541-0893
06 \541-0893-06:revision=0101/component=/MBU_A
Location: /MBU_A
XSCF> fmdump -m -M
MSG-ID: SCF-8003-LS, TYPE: Fault, VER: 1, SEVERITY: Critical
EVENT-TIME: Tue Aug 27 08:38:07 CEST 2019
PLATFORM: SPARC Enterprise M4000, CSN: BC********, HOSTNAME: ******
SOURCE: sde, REV: 1.16
EVENT-ID: 8852b041-6bc0-4fe9-b972-d373dfd0f10c
DESC: A non-fatal uncorrectable error was detected within a MBC chip.
Refer to http://www.sun.com/msg/SCF-8003-LS for more information. AUTO-RESPONSE: No immediate action is taken by XSCF software due to this fault.
Resources associated with the faulty FRU will be deconfigured after the platform is power cycled or after the domain reboots or after a Dynamic Reconfiguration operation is performed. This resource deconfiguration
may cause the platform to become unbootable. Please consult the detail section of the knowledge article for additional information.
IMPACT: The non-fatal uncorrectable error trap may cause the domain to
panic.
REC-ACTION: Schedule a repair action to replace the affected Field Replaceable Unit (FRU), the identity of which can be determined using
fmdump -v -u EVENT_ID.
Please consult the detail section of the knowledge article for
additional information.
One reason to insist on a software-related trial is the "Current Issues
Page" in the "Sun SPARC(R) Enterprise M3000/M4000/M5000/M8000/M9000
(OPL) Servers" from 2012:
M5000 - MBC failures SCF-8003-LS and/or SCF-8003-HA
Specifically looking for cases that have a fatal error immediately
before the serious error. ->
Still under investigation by engineering. Current action is to replace
the faulted MBU.
Perhaps the guys found a solution meanwhile ...
The above mentioned web page http://www.sun.com/msg/SCF-8003-LS has been unfortunately moved behind the pay wall. :-(
There must be a way for _my_ purchased machine. ;-)
Yeah, but it is old and broken.
I meant, for a machine without any service contract I should have access
to all functions / features IMHO (also to execute a "clearstatus /MBU_A").
On 09/13/19 09:29, YTC#1 wrote:
On 13/09/2019 06:51, Kay-Uwe Loebel wrote:
Am 12.09.2019 um 21:36 schrieb YTC#1:
It has been a while since I touched an Mx000, never mind trouble shot
one :-(
a fortiori I appreciate your help!
What does
fmdump -v -u 5fa5d831-1d4b-4344-a6c9-5939d01886bb
Show ?
Now: nothing, because I did carry out a factory reset. ;-)
TIME UUID MSG-ID
fmdump: /var/opt/sun/fm/fmd/fltlog is empty
Of course I saved the outputs before:
XSCF> fmdump -v -u 5fa5d831-1d4b-4344-a6c9-5939d01886bb
TIME UUID MSG-ID
Aug 27 08:37:47.6128 5fa5d831-1d4b-4344-a6c9-5939d01886bb SCF-8003-HA
100% fault.chassis.SPARC-Enterprise.asic.mbc.fe
Problem in: hc:///chassis=0/cmu=0/mbc=0
Affects: hc:///chassis=0/cmu=0/xsb=0
FRU: hc://:product-id=SPARC Enterprise
M4000:chassis-id=BC********:server-id=******:serial=BC********:part=CF00541-0893
06 \541-0893-06:revision=0101/component=/MBU_A
Location: /MBU_A
XSCF> fmdump -v -u 8852b041-6bc0-4fe9-b972-d373dfd0f10c
TIME UUID MSG-ID
Aug 27 08:38:07.3002 8852b041-6bc0-4fe9-b972-d373dfd0f10c SCF-8003-LS
100% fault.chassis.SPARC-Enterprise.asic.mbc.se
Problem in: hc:///chassis=0/cmu=0/mbc=0
Affects: hc:///chassis=0/cmu=0
FRU: hc://:product-id=SPARC Enterprise
M4000:chassis-id=BCF092404K:server-id=******:serial=BC********:part=CF00541-0893
06 \541-0893-06:revision=0101/component=/MBU_A
Location: /MBU_A
XSCF> fmdump -m -M
MSG-ID: SCF-8003-LS, TYPE: Fault, VER: 1, SEVERITY: Critical
EVENT-TIME: Tue Aug 27 08:38:07 CEST 2019
PLATFORM: SPARC Enterprise M4000, CSN: BC********, HOSTNAME: ******
SOURCE: sde, REV: 1.16
EVENT-ID: 8852b041-6bc0-4fe9-b972-d373dfd0f10c
DESC: A non-fatal uncorrectable error was detected within a MBC chip.
Refer to http://www.sun.com/msg/SCF-8003-LS for more information.
AUTO-RESPONSE: No immediate action is taken by XSCF software due to this >>> fault.
Resources associated with the faulty FRU will be deconfigured after the
platform is power cycled or after the domain reboots or after a Dynamic
Reconfiguration operation is performed. This resource deconfiguration
may cause the platform to become unbootable. Please consult the detail
section of the knowledge article for additional information.
IMPACT: The non-fatal uncorrectable error trap may cause the domain to
panic.
REC-ACTION: Schedule a repair action to replace the affected Field
Replaceable Unit (FRU), the identity of which can be determined using
fmdump -v -u EVENT_ID.
Please consult the detail section of the knowledge article for
additional information.
One reason to insist on a software-related trial is the "Current Issues
Page" in the "Sun SPARC(R) Enterprise M3000/M4000/M5000/M8000/M9000
(OPL) Servers" from 2012:
M5000 - MBC failures SCF-8003-LS and/or SCF-8003-HA
Specifically looking for cases that have a fatal error immediately
before the serious error. ->
Still under investigation by engineering. Current action is to replace
the faulted MBU.
As you can, it is a H/W fault. The part needs replacing.
Sometimes you have to give up and accept defeat :-(
Perhaps the guys found a solution meanwhile ...
It is broken.
The above mentioned web page http://www.sun.com/msg/SCF-8003-LS has been >>> unfortunately moved behind the pay wall. :-(
It says it is broken, contact your support provider and organise a
replacement.
There must be a way for _my_ purchased machine. ;-)
Yeah, but it is old and broken.
I meant, for a machine without any service contract I should have access >>> to all functions / features IMHO (also to execute a "clearstatus
/MBU_A").
Why ? Even Sun would not have agreed to that. Fujitsu must have had good
reason to hold end users back from that command level, probably because
it can completely fubar the server. To get to escalation mode you need
to put get a password .... using a support call.
When you buy a car, does the manufacture supply you with free fixes for
life ? There is a warranty period and when that is over you pay for an
extended one, or take your chances and pay per breakage.
Don't know if this would help, but had a similar problem on an M3000 in
April this year. That needed a password to clear the fault, but searched around for a bit and found a procedure to reset the service processor by moving a jumper. Here are the notes made at the time:
* remove service processor and fit jumper to J505, external terminal to serial management port, 9600,n,8,1
* Plug in power cord
* To interrupt the sp boot process, type in xyzzy when you see the line: Booting linux in n seconds. May take a couple of attempts.
* At the preboot prompt, Preboot > type in reset all
* The preboot menu exits, SP restarts, erases flash, sets defaults and reboots SP
* At the login prompt, root, pwd, changeme
Might be worth a try...
Chris
On 13/09/2019 06:51, Kay-Uwe Loebel wrote:
Am 12.09.2019 um 21:36 schrieb YTC#1:
It has been a while since I touched an Mx000, never mind trouble shot
one :-(
a fortiori I appreciate your help!
What does
fmdump -v -u 5fa5d831-1d4b-4344-a6c9-5939d01886bb
Show ?
Now: nothing, because I did carry out a factory reset. ;-)
TIME UUID MSG-ID
fmdump: /var/opt/sun/fm/fmd/fltlog is empty
Of course I saved the outputs before:
XSCF> fmdump -v -u 5fa5d831-1d4b-4344-a6c9-5939d01886bb
TIME UUID MSG-ID
Aug 27 08:37:47.6128 5fa5d831-1d4b-4344-a6c9-5939d01886bb SCF-8003-HA
100% fault.chassis.SPARC-Enterprise.asic.mbc.fe
Problem in: hc:///chassis=0/cmu=0/mbc=0
Affects: hc:///chassis=0/cmu=0/xsb=0
FRU: hc://:product-id=SPARC Enterprise
M4000:chassis-id=BC********:server-id=******:serial=BC********:part=CF00541-0893
06 \541-0893-06:revision=0101/component=/MBU_A
Location: /MBU_A
XSCF> fmdump -v -u 8852b041-6bc0-4fe9-b972-d373dfd0f10c
TIME UUID MSG-ID
Aug 27 08:38:07.3002 8852b041-6bc0-4fe9-b972-d373dfd0f10c SCF-8003-LS
100% fault.chassis.SPARC-Enterprise.asic.mbc.se
Problem in: hc:///chassis=0/cmu=0/mbc=0
Affects: hc:///chassis=0/cmu=0
FRU: hc://:product-id=SPARC Enterprise
M4000:chassis-id=BCF092404K:server-id=******:serial=BC********:part=CF00541-0893
06 \541-0893-06:revision=0101/component=/MBU_A
Location: /MBU_A
XSCF> fmdump -m -M
MSG-ID: SCF-8003-LS, TYPE: Fault, VER: 1, SEVERITY: Critical
EVENT-TIME: Tue Aug 27 08:38:07 CEST 2019
PLATFORM: SPARC Enterprise M4000, CSN: BC********, HOSTNAME: ******
SOURCE: sde, REV: 1.16
EVENT-ID: 8852b041-6bc0-4fe9-b972-d373dfd0f10c
DESC: A non-fatal uncorrectable error was detected within a MBC chip.
Refer to http://www.sun.com/msg/SCF-8003-LS for more information.
AUTO-RESPONSE: No immediate action is taken by XSCF software due to this
fault.
Resources associated with the faulty FRU will be deconfigured after the
platform is power cycled or after the domain reboots or after a Dynamic
Reconfiguration operation is performed. This resource deconfiguration
may cause the platform to become unbootable. Please consult the detail
section of the knowledge article for additional information.
IMPACT: The non-fatal uncorrectable error trap may cause the domain to
panic.
REC-ACTION: Schedule a repair action to replace the affected Field
Replaceable Unit (FRU), the identity of which can be determined using
fmdump -v -u EVENT_ID.
Please consult the detail section of the knowledge article for
additional information.
One reason to insist on a software-related trial is the "Current Issues
Page" in the "Sun SPARC(R) Enterprise M3000/M4000/M5000/M8000/M9000
(OPL) Servers" from 2012:
M5000 - MBC failures SCF-8003-LS and/or SCF-8003-HA
Specifically looking for cases that have a fatal error immediately
before the serious error. ->
Still under investigation by engineering. Current action is to replace
the faulted MBU.
As you can, it is a H/W fault. The part needs replacing.
Sometimes you have to give up and accept defeat :-(
Perhaps the guys found a solution meanwhile ...
It is broken.
The above mentioned web page http://www.sun.com/msg/SCF-8003-LS has been
unfortunately moved behind the pay wall. :-(
It says it is broken, contact your support provider and organise a replacement.
There must be a way for _my_ purchased machine. ;-)
Yeah, but it is old and broken.
I meant, for a machine without any service contract I should have access
to all functions / features IMHO (also to execute a "clearstatus /MBU_A").
Why ? Even Sun would not have agreed to that. Fujitsu must have had good reason to hold end users back from that command level, probably because
it can completely fubar the server. To get to escalation mode you need
to put get a password .... using a support call.
When you buy a car, does the manufacture supply you with free fixes for
life ? There is a warranty period and when that is over you pay for an extended one, or take your chances and pay per breakage.
On 11/09/2019 22:24, Keith Thompson wrote:
Can you talk to your vendor about changing the hostid for the license
server? I would hope they have provisions for dying hardware.
Bet they have not got support for that either :-)
* remove service processor and fit jumper to J505, external terminal to
serial management port, 9600,n,8,1
* Plug in power cord
* To interrupt the sp boot process, type in xyzzy when you see the line:
Booting linux in n seconds. May take a couple of attempts.
* At the preboot prompt, Preboot > type in reset all
* The preboot menu exits, SP restarts, erases flash, sets defaults and
reboots SP
* At the login prompt, root, pwd, changeme
Might be worth a try...
Chris
The fault here was reported as: SCF XSCF watchdog timeout
To get into service mode, must have mode privs, which needs a password.
so the command, enableservice, asks for one. But, service mode
can be entered via the keyswitch.
Don't remember more deatils, but assume defaults have been set via the
jumper J505, when rebooted with keyswitch in diags mode, you can access service mode withoiut a password.
In my case, a spurious faultt message, which disappeared after the above...
Chris
Am 12.09.2019 um 09:20 schrieb YTC#1:
On 11/09/2019 22:24, Keith Thompson wrote:
Can you talk to your vendor about changing the hostid for the license
server? I would hope they have provisions for dying hardware.
Bet they have not got support for that either :-)
We have, but compared to Oracle's hardware support for the M4000 it's
quite cheap. ;-)
Am 13.09.2019 um 14:37 schrieb Chris:
* remove service processor and fit jumper to J505, external terminal to
serial management port, 9600,n,8,1
* Plug in power cord
* To interrupt the sp boot process, type in xyzzy when you see the line: >>> Booting linux in n seconds. May take a couple of attempts.
* At the preboot prompt, Preboot > type in reset all
* The preboot menu exits, SP restarts, erases flash, sets defaults and
reboots SP
* At the login prompt, root, pwd, changeme
Might be worth a try...
Chris
The fault here was reported as: SCF XSCF watchdog timeout
To get into service mode, must have mode privs, which needs a password.
so the command, enableservice, asks for one. But, service mode
can be entered via the keyswitch.
Don't remember more deatils, but assume defaults have been set via the
jumper J505, when rebooted with keyswitch in diags mode, you can
access service mode withoiut a password.
In my case, a spurious faultt message, which disappeared after the
above...
Chris
Sounds like a very hot tip!
I pulled the XSCF Unit (FFSCFB) but found only a very small 4x jumper
block labelled CN21 (nothing put).
One could say 4 jumpers - 4 chances (or 3 to brick the unit). ;-)
Is there a cost to your department to the service not being available to users ? (as in they only pay when it is available).
On 16/09/2019 07:34, Kay-Uwe Loebel wrote:
Am 13.09.2019 um 14:37 schrieb Chris:
* remove service processor and fit jumper to J505, external terminal to >>>> serial management port, 9600,n,8,1
* Plug in power cord
* To interrupt the sp boot process, type in xyzzy when you see the line: >>>> Booting linux in n seconds. May take a couple of attempts.
* At the preboot prompt, Preboot> type in reset all
* The preboot menu exits, SP restarts, erases flash, sets defaults and >>>> reboots SP
* At the login prompt, root, pwd, changeme
Might be worth a try...
Chris
The fault here was reported as: SCF XSCF watchdog timeout
To get into service mode, must have mode privs, which needs a password.
so the command, enableservice, asks for one. But, service mode
can be entered via the keyswitch.
Don't remember more deatils, but assume defaults have been set via the
jumper J505, when rebooted with keyswitch in diags mode, you can
access service mode withoiut a password.
In my case, a spurious faultt message, which disappeared after the
above...
Chris
Sounds like a very hot tip!
I pulled the XSCF Unit (FFSCFB) but found only a very small 4x jumper
block labelled CN21 (nothing put).
One could say 4 jumpers - 4 chances (or 3 to brick the unit). ;-)
It is a brick already.... what could you do to make it worse ? :-)
But bear in mind, his issue was a spurious one. Ones defo indicates a
H/W issue.
*if* you do manage to clear it (which I have my doubts without the
escalated password) you may end up corrupting something. After all the
system has done it's job, spotted an issue and stopped things going from
bad to worse.
The machine is back in service!
The solution was finally to install a firmware update (amazingly
possible despite faultet MBU), execute the clearfault command and
perform a power cycling.
Many thanks for all the help in this seemingly abandoned group!
On 19/09/2019 09:13, Kay-Uwe Loebel wrote:
The machine is back in service!
The solution was finally to install a firmware update (amazingly
possible despite faultet MBU), execute the clearfault command and
perform a power cycling.
Many thanks for all the help in this seemingly abandoned group!
Good that it is up and working.
But bear in mind, you had a fault. You have cleared that fault. But the
fault may re-occur.
Now would be a good time to hunt out another Sparc server and get a backup/migration to it. If a nice T series is available, run up some
LDoms :-)
On 19.09.19 12:49, YTC#1 wrote:
On 19/09/2019 09:13, Kay-Uwe Loebel wrote:
The machine is back in service!
The solution was finally to install a firmware update (amazingly
possible despite faultet MBU), execute the clearfault command and
perform a power cycling.
Many thanks for all the help in this seemingly abandoned group!
Good that it is up and working.
But bear in mind, you had a fault. You have cleared that fault. But the
fault may re-occur.
Now would be a good time to hunt out another Sparc server and get a
backup/migration to it. If a nice T series is available, run up some
LDoms :-)
Well here is another M4000 still in service, it runs and runs and runs.
And the old gem is still certified to run Solaris 11.
We are currently migrating our application (SAM/FS with 600TB active
data) to a LDOM running on a S7.
I've got an M3000 with the same issue. Chris, if you still read here, "xyzzy" doesn't seem to want to work for me as that password -- it doesn't really acknowledge that I made any input and then keeps going after 5 seconds.https://pastebin.com/9xM6Zwbp
On Thursday, December 16, 2021 at 11:27:41 PM UTC-5, larbob wrote:
I've got an M3000 with the same issue. Chris, if you still read here, "xyzzy" doesn't seem to want to work for me as that password -- it doesn't really acknowledge that I made any input and then keeps going after 5 seconds.https://pastebin.com/9xM6Zwbp
I found this but I'm not sure what the root password is either.
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 296 |
Nodes: | 16 (2 / 14) |
Uptime: | 24:43:06 |
Calls: | 6,646 |
Calls today: | 1 |
Files: | 12,193 |
Messages: | 5,327,716 |