Sun Microsystems, Inc.  Sun System Handbook - ISO 3.4 June 2011 Internal/Partner Edition
   Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback

Asset ID: 1-71-1017520.1
Update Date:2009-03-29
Keywords:

Solution Type  Technical Instruction Sure

Solution  1017520.1 :   Configuring Red Hat 3.0 netdump on Sun Fire[TM] B100x/B200x blades  


Related Items
  • Sun Fire B200x Blade Server
  •  
  • Sun Fire B100x Blade Server
  •  
  • Sun Fire B1600 Blade System Chassis
  •  
Related Categories
  • GCS>Sun Microsystems>Servers>Blade Servers
  •  

PreviouslyPublishedAs
228662


Description
Netdump is Red Hat Inc.'s crash dump facility which stores the crash dump from a crashed machine on another machine on the network.


This document is how to configure this facility on a x86 Blade in a B1600 chassis running Red Hat 3.0 .


Steps to Follow
This procedure is to set up a netdump server and client on B100x/B200x blades so that if the client panics a crash dump is transferred to the netdump server.

It is written for Red Hat 3.0.

It is based on the information available on the following two URLs but there are specific requirements for the B100x/B200x.

http://www.redhat.com/support/wpapers/redhat/netdump
http://www.redhat.com/support/wpapers/redhat/netdump/setup.html

This procedure assumes both netdump client and server are x86 Blades.

It is advised that the netdump client and server are in the same chassis to minimise the switch connections.

On server.

Ensure netdump is installed

 rpm -q netdump

Set up password for netdump user.

 passwd netdump
 chkconfig netdump-server on
 service netdump-server start

Edit /etc/sysconfig/syslog

add -x and -r to the SYSLOGD_OPTIONS line:

On client.

Ensure netdump is installed

rpm -q netdump

Edit /etc/sysconfig/netdump and update 3 fields

 NETDUMPADDR= (address of netdump server)
SYSLOGADDR=  (address of netdump server)
DEV=snet0  

Note: Red Hat Inc omit to mention the "DEV" entry in the URLs quoted above.

By default netdump will try and use interface eth0 which does not exist on the B100x/200x.

Also note that if the network failover feature is enabled netdump will not function ie netdump cannot be configured with the fail0 interface. For netdump to function the system needs to use the snet interface.

Make sure that the three lines above are uncommented,by default the lines are commented out (remove the #)

 service netdump propagate

answer password question (already set up on netdump server)

 chkconfig netdump on
 service netdump start

On the system controller of the B1600 the automatic reset capability for OS hangs must be disabled for the slot the client is situated. Otherwise the Blade will be restarted before the netdump information is transferred to the netdump-server. (This is done using the command setupsc on the system controller and reconfiguring the managed system interface. see below for reconfiguring slot 15)

 B1600a_sc>setupsc
Entering Interactive setup mode.
Use Ctrl-z to exit & save. Use Ctrl-c to abort.
Do you want to configure the enabled interfaces [y]? n
Do you want to configure the network interface [y]? n
Do you want to configure the managed system interface [y]? y
Should all blades be automatically restarted if OS is hung [y]? n
Should none of the blades be automatically restarted if OS is hung [y]? n
Should S0 be automatically restarted if OS is hung [y]? y
Should S1 be automatically restarted if OS is hung [y]? y
Should S2 be automatically restarted if OS is hung [y]? y
Should S2 be automatically restarted if OS is hung [y]? y
Should S3 be automatically restarted if OS is hung [y]? y
Should S4 be automatically restarted if OS is hung [y]? y
Should S5 be automatically restarted if OS is hung [y]? y
Should S6 be automatically restarted if OS is hung [y]? y
Should S7 be automatically restarted if OS is hung [y]? y
Should S8 be automatically restarted if OS is hung [y]? y
Should S9 be automatically restarted if OS is hung [y]? y
Should S10 be automatically restarted if OS is hung [y]? y
Should S11 be automatically restarted if OS is hung [y]? y
Should S12 be automatically restarted if OS is hung [y]? y
Should S14 be automatically restarted if OS is hung [y]? y
Should S15 be automatically restarted if OS is hung [n]? n
Should all blades be powered on automatically [y]?
Should all blades automatically restart firmware if hung on startup [y]?
Should all blades be configured with the same Boot Timeout [y]?
Enter the Boot Timeout seconds for all blades (0=disabled) [0]:
Do you want to configure the System Controller parameters [y]? n

Note this will mean that the Blade will not restart after a panic but must be reset from the system controller.

To test netdump capability.

Note: the following will panic the system.

First the Alt+SysRq keys must be enabled by making a change to the /etc/sysctl.conf file.

Change the following line:

 kernel.sysrq = 0

to:

 kernel.sysrq = 1

Activate the changes by using the following command:

 sysctl -p

Alternatively:

 echo "1" > /proc/sys/kernel/sysrq

The following will cause a system panic.

 echo "c" > /proc/sysrq-trigger

In /var/crash on the netdump server a directory should be created containing vmcore and log file. Also on the netdump server messages pertaining to the panic and netdump should be logged in /var/log/messages.



Product
Sun Fire B200x Blade Server
Sun Fire B100x Blade Server
Sun Fire B1600 Blade System Chassis

B1600, B100x, B200x, netdump, Linux, Red Hat, panic
Previously Published As
81798

Change History
Date: 2006-05-22
User Name: 97961
Action: Update Canceled
Comment: *** Restored Published Content *** - Audience changed to "Contract" per FvF http://kmo.central/howto/FvF.html
Version: 0
Date: 2006-05-22
User Name: 97961

Attachments
This solution has no attachment
  Copyright © 2011 Sun Microsystems, Inc.  All rights reserved.
 Feedback