Just Hack It Now: How To Recharge Your Mobile Free: Hi friends i have a trick to Recharge your mobile With Amount 50,100,150,200 & 250 . This trick Only for Delhi, Gujarat & Rajasthan ...
Friday, February 24, 2012
Tuesday, February 14, 2012
Netra 240 Faulty Processor Replacement
One of my friends has this Sun Netra 240 Server. Couple
of days back he called me for an amber LED that showed up on it's
front panel LEDs. So I connected my laptop to it's serial management
port to take some logs from it's sc and os. Below are some outputs.
sc>
showenvironment
=============== Environmental Status =============== -------------------------------------------------------------------------------- System Temperatures (Temperatures in Celsius): -------------------------------------------------------------------------------- Sensor Status Temp LowHard LowSoft LowWarn HighWarn HighSoft HighHard -------------------------------------------------------------------------------- MB.P0.T_CORE WARNING 118 -- -- -- 115 125 127 MB.P1.T_CORE OK 82 -- -- -- 115 125 127 MB.T_ENC OK 25 -11 -9 -7 57 60 63 The showenvironment status at service console is showing warning temperature for processor0. #prtdiag -v System Configuration: Sun Microsystems sun4u Netra 240 System clock frequency: 167 MHZ Memory size: 2GB ==================================== CPUs ==================================== E$ CPU CPU CPU Freq Size Implementation Mask Status Location --- -------- ---------- --------------------- ----- ------ -------- 0 1503 MHz 1MB SUNW,UltraSPARC-IIIi 3.4 faulted MB/P0 1 1503 MHz 1MB SUNW,UltraSPARC-IIIi 3.4 on-line MB/P1 Temperature sensors: ----------------------------------------- Location Sensor Status ----------------------------------------- MB/P0 T_CORE warning (118C) MB/P1 T_CORE okay MB T_ENC okay PS0 FF_OT okay PS1 FF_OT okay The prtdiag output at os level is also showing faulted and warning temperature for P0 in temperature sensors section. # dmesg | grep -i err Jan ** **:**:** fmd: [ID 441519 daemon.error] SUNW-MSG-ID: SUN4U-8000-9R, TYPE: Fault, VER: 1, SEVERITY: Major Diagnostics messages too has something related to processor and is showing the severity as major. Now that we are confirmed that there is some problem in the processor 0. It may be because of accumulation of dust in the heat-sink or may be there is some problem with the processor0 heat-sink fan. But after cross checking it again, we found that the fan0 that was associated with the processor0 was in okay condition. Fan Status: ------------------------------------------- Location Sensor Status ------------------------------------------- F2 RS okay F3 RS okay MB/P0/F0 RS okay MB/P0/F1 RS okay PS0 FF_FAN okay PS1 FF_FAN okay Fan status in prtdiag output. So we rule out the fans. Now it may be due to the accumulation of dust in heat-sink, that we will come to know after we open the server. Hence, we decided to order a new processor for the server. After checking the documents and the sun solve website, we found that the processor alone cannot be ordered. So we decided to find out the system board part no from the showfru output at sc. Yes we could have also done it from the OS using the prtfru output. Below is the output of showfru. sc> showfru FRU_PROM at MB.SEEPROM SEGMENT: SD /ManR /ManR/UNIX_Timestamp32: MON SEP 08 13:54:22 2008 /ManR/Description: FRUID,M'BD,2X1.5GHZ,ROHS,R06 /ManR/Manufacture Location: Shunde,China /ManR/Sun Part No: 3753484 /ManR/Sun Serial No: 1X0F5J /ManR/Vendor: Mitac International /ManR/Initial HW Dash Level: 03 /ManR/Initial HW Rev Level: 50 /ManR/Shortname: MOTHERBOARD /SpecPartNo: 885-0963-03 We ordered the sun part no – 3753484 which represents the system board. After we received the system board we shut down the server and opened it to have a look at it's internals. Well opening the server is not that easy. I strongly recommend you to follow the sun documentation. We found that the heat-sink paste on the processor0 was totally vanished which had led the processor0 to attain high temperature for a long time and in result made it faulty. So we took out the processor0 from the good board and replaced it with the faulty one on the server system board. After closing the lid and powering it on again we found all the fault LEDs had cleared. Error from showenvironment at sc and prtdiag outputs also disappeared simultaneously.
Setting up 64-bit Java6 u29 on Solaris10
To install a
higher version of Java on your system, you first need to uninstall
the previous version. If it is a 64-bit version then uninstall the
64-bit first and then 32-bit. While installing you have to follow the
reverse order, first 32-bit and then the 64-bit.
You will find that Java is available in two
formats, .z and .sh. The one with sh extension is a self extracting
binary file whereas the one with the .z extension contains the
Solaris packages. We will go with the Solaris packages with .z
extension.
You can find your Java version with the help of
below mentioned command.
# java -version
Unintallation
We will first uninstall the 64-bit Java that is
installed in the system. Type the below command to remove the
previously installed 64-bit Java.
#
pkgrm
SUNWj6rtx
SUNWj6dvx
SUNWj6dmx
Now
we can go ahead and remove the 32-bit.
#
pkgrm SUNWj6rt SUNWj6dev SUNWj6cfg SUNWj6man SUNWj6dmo
If
you have already downloaded the .z file for both 32-bit and 64-bit,
run gunzip and tar to extract both of them it to some folder. You can
extract both 32-bit and 64-bit packages in the same directory.
Finally from that folder (place where you had extracted the package)
run the below command to install the packages.
#
pkgadd -d . SUNWj6rt SUNWj6dev SUNWj6cfg SUNWj6man SUNWj6dmo
Needless
to say that you have to type yes for every package to get installed.
Similarly,
we can install the 64-bit package using the below command.
#
pkgadd -d . SUNWj6rtx SUNWj6dvx SUNWj6dmx
The
new version of Java is installed. By default Java is installed in
/usr/jdk/1.6.0_<update> directory. To set the PATH permanently
for all users without rebooting the system, we have to declare PATH
in /etc/profile followed by export PATH. Below is the sample
screenshot of /etc/profile on my system.
Tuesday, February 07, 2012
Root Mirroring in Solaris10 Update9 using SVM
To mirror root is
a good practice as
it provides high-availability in
production environments and also minimum
downtime. I have to
make the document as
simple as I could
though I cant help
with the commands that
seem to be so
unfriendly. In this tutorial
I would be ignoring
the installation part of solaris10
update9.
As you can see
that slice 7 is
dedicated for the replicas.
Format command output
As we have two hard disks c0t0d0 and
c0t1d0 and our OS is installed on c0t0d0, we need to partition the second disk
exactly as the first to perform root mirror. So we shall copy the VTOC of
c0t0d0 to c0t1d0.
# prtvtoc /dev/rdsk/c0t0d0s2 |
fmthard -s - /dev/rdsk/c0t1d0s2
Now
that we have partitioned
the second hard disk
same as the first
one we need to
prepare a layout of
what other slices do
we need to mirror
apart from the root
slice.
Preparing
mirroring strategy
/ d10 d11
+ d12 c0t0d0s0 +
c0t1d0s0
swap d20 d21
+ d22 c0t0d0s1 +
c0t1d0s1
/var d30 d31
+ d32 c0t0d0s3 +
c0t1d0s3
/export/home d40 d41 +
d42 c0t0d0s4 +
c0t1d0s4
/data d50 d51
+ d52 c0t0d0s5 +
c0t1d0s5
Once
we have prepared the
strategy, we can go
ahead and carry out
further steps to root
mirroring.
First
of all we need
to create replicas on
the slice 7 of
each disk.
# metadb -afc3 c0t0d0s7
# metadb -afc3 c0t1d0s7
Next
we create mirrors on
both disks, create main mirrors and attach the first mirror
to the main mirror.
Creating
slice 0 mirrors or
root mirrors
# metainit -f d11
1 1 c0t0d0s0 ## slice 0
stripe d11 on disk1
# metainit -f d12
1 1 c0t1d0s0 ## slice 0
stripe d12 on disk2
# metainit d10 -m
d11 ## attaching slice
0 stripe d11 to
main mirror d10
Creating
slice 1 mirrors or
swap mirrors
# metainit -f d21
1 1 c0t0d0s1
# metainit -f d22
1 1 c0t1d0s1
# metainit d20 -m
d21
Creating
slice 3 mirrors
# metainit -f d31
1 1 c0t0d0s3
# metainit -f d32
1 1 c0t1d0s3
# metainit d40 -m
d41
Creating slice 4 mirrors
# metainit -f d41
1 1 c0t0d0s4
# metainit -f d42
1 1 c0t1d0s4
# metainit d50 -m
d51
Creating slice 5 mirrors
# metainit -f d51
1 1 c0t0d0s5
# metainit -f d52
1 1 c0t1d0s5
# metainit d50 -m
d51
After creating the main mirrors, we need to
run metaroot command specifying the root mirror. After which you will see a
notable change in the /etc/vfstab and /etc/system files which in turn will
confirm us about the root mirror.
# metaroot d10
This
line shows in /etc/vfstab,
notice the
partitions and you can find that there are changes in / file system line.
/dev/md/dsk/d10 /dev/md/rdsk/d10 / ufs 1 no -
Before
issuing metaroot
After
issuing metaroot
These lines show in /etc/system file
* Begin MDD root info (do not edit)
rootdev:/pseudo/md@0:0,0,blk
* End MDD root info (do not edit)
Change all the partitions mounted in /etc/vfstab as shown below. The below made changes are
according to the metadevices that were applicable in my case, hence do not copy
unless you are sure about it.
# sync; sync;
# lockfs -fa
# init 6
After the system has rebooted open up the
terminal again and attach rest of the mirrors that were created to the main
mirrors one by one
# metattach d10 d12
# metattach d20 d22
# metattach d40 d42
# metattach d50 d52
# metattach d60 d62
You can check the syncing status of the
mirror using below mentioned commands.
# metastat
# metastat | grep -i %
After attaching all the mirrors one after
the other, run the below mentioned command to check and confirm the mirror
status.
Now that we have set up the mirrors, we have to set
boot device. This can be done as follows.
# ls -ll /dev/md/dsk/d10
We can also set the bootpath as the first
disk and alternate bootpath as second disk. We will go with the root mirror
d10.
#eeprom
bootpath=/devices/pci@0,0/pci8086,2829@d/disk@0,0:a
As soon as the bootpath is set to root
mirror d10, the
file /boot/solaris/bootenv.rc shows these lines:
setprop bootpath
'/devices/pseudo/md@0:0,10,blk'
Now we need to set up grub on the second
disk. The following command does that for us.
# installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c0t1d0s0
Edit
/etc/system file and append the below mentioned lines
to avoid the system to enter the maintenance mode if one of the hard disks
fails.
set
md:mirrored_root_flag=1
That was all we had to do while root mirroring two disks. Cheers !!!
Subscribe to:
Posts (Atom)