DISCLAIMER : Please note that blog owner takes no responsibility of any kind for any type of data loss or damage by trying any of the command/method mentioned in this blog. You may use the commands/method/scripts on your own responsibility.If you find something useful, a comment would be appreciated to let other viewers also know that the solution/method work(ed) for you.
Showing posts with label dump. Show all posts
Showing posts with label dump. Show all posts
Using VRTSexplorer utility to gather information useful for Symantec Corporation Technical Support
VRTSexplorer , also known as
Veritas Explorer, VxExplorer, vxexplorer, and vxexplore,
is a tool provided by Symantec Corporation Technical Support that is executed
on a host to gather some of the information that may be needed by a Support
Engineer to troubleshoot an issue. The output of this utility is a compressed
tar file that must be sent to Support. The information collected may not be
sufficient to resolve the issue, but it is likely to give very relevant
information about it. This utility will run on Solaris, Solaris x64, SUSE
Linux, Red Hat Linux, AIX, and HP-UX.
Note: No user data is collected by the VRTSexplorer utility. Only the technical information about some server configuration and the installed Veritas products are collected. For the exact information that is collected by the VRTSexplorer utility, and other additional information refer to the README located in the VRTSexplorer directory after downloading and untarring.
The use of VRTSexplorer utility involves three different steps:
Note: No user data is collected by the VRTSexplorer utility. Only the technical information about some server configuration and the installed Veritas products are collected. For the exact information that is collected by the VRTSexplorer utility, and other additional information refer to the README located in the VRTSexplorer directory after downloading and untarring.
The use of VRTSexplorer utility involves three different steps:
1. Obtaining
VRTSexplorer
2. Executing the VRTSexplorer binary
3. Sending the output to Symantec Technical Support
2. Executing the VRTSexplorer binary
3. Sending the output to Symantec Technical Support
These
steps are detailed below:
1. Obtaining the package that contains the VRTSexplorer utility:
1. Obtaining the package that contains the VRTSexplorer utility:
Note: The VRTSexplorer utility is
packaged with the Symantec Support Tools, VRTSspt, package which is
included on the product CDs and available for download. If this package is
installed on the host, this step can be skipped unless the latest VRTSexplorer
utility is to be run, as the utility is located in the /opt/VRTSspt/VRTSexplorer
directory. For more information about the Symantec Support Tools package and
the tools that it contains (VRTSexplorer, FirstLook, metasave, vxbench, etc.),
please refer to the Related Documents section below. Otherwise, the VRTSexplorer
utility must be downloaded from the Symantec FTP site. The latest version
will always be on the FTP site. The package can be downloaded and the binary
executed from any directory. However, to remain consistent with installed
applications, extract the package in the /opt directory.
To download the VRTSexplorer utility, follow the below instructions:
Connect to the FTP site:
# ftp ftp.veritas.com
The below message appears with a prompt for a login name. Please see technote TECH66995 in related items below for logon credentials.
Connected to ftp.veritas.com
220-ftp
220-***********************************************************************
220- This system is for the use of authorized users only. Individuals
220- using this computer system without authority, or in excess of their
220- authority, are subject to having all of their activities on this
220- system monitored and recorded.
220- In the course of monitoring individuals improperly using this
220- system, or in the course of system maintenance, the activities of
220- authorized users also are monitored.
220- Anyone using this system expressly consents to such monitoring
220- and recording. Please be advised that unauthorized access to this
220- system is a violation of State and Federal law. If monitoring
220- reveals possible evidence of criminal activity, system personnel
220- may provide that evidence to law enforcement officials.
220-***********************************************************************
220
Name (ftp.veritas.com <ftp://ftp.veritas.com/>): Please see technote TECH66995
331 User symsupport okay, need password.
Password: Please see technote TECH66995
230 Restricted user logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
While logged into the FTP server as the customer user , it is not possible to list any files or directories. It is important that the below steps are followed exactly:
Change directories to /pub/support:
ftp> cd /pub/support
Set FTP mode to binary:
ftp> bin
Download the file that contains utility:
ftp> get vxexplore.tar.Z
Close the ftp connection:
ftp> bye
Untar the download:
Untar the downloaded file (only if the VRTSexplorer utility has been downloaded and not installed with the VRTSspt package) :
# zcat vxexplore.tar.Z | tar xvf -
The above command will create a VRTSexplorer directory containing everything that is needed. Change into this directory:
# cd VRTSexplorer
To download the VRTSexplorer utility, follow the below instructions:
Connect to the FTP site:
# ftp ftp.veritas.com
The below message appears with a prompt for a login name. Please see technote TECH66995 in related items below for logon credentials.
Connected to ftp.veritas.com
220-ftp
220-***********************************************************************
220- This system is for the use of authorized users only. Individuals
220- using this computer system without authority, or in excess of their
220- authority, are subject to having all of their activities on this
220- system monitored and recorded.
220- In the course of monitoring individuals improperly using this
220- system, or in the course of system maintenance, the activities of
220- authorized users also are monitored.
220- Anyone using this system expressly consents to such monitoring
220- and recording. Please be advised that unauthorized access to this
220- system is a violation of State and Federal law. If monitoring
220- reveals possible evidence of criminal activity, system personnel
220- may provide that evidence to law enforcement officials.
220-***********************************************************************
220
Name (ftp.veritas.com <ftp://ftp.veritas.com/>): Please see technote TECH66995
331 User symsupport okay, need password.
Password: Please see technote TECH66995
230 Restricted user logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
While logged into the FTP server as the customer user , it is not possible to list any files or directories. It is important that the below steps are followed exactly:
Change directories to /pub/support:
ftp> cd /pub/support
Set FTP mode to binary:
ftp> bin
Download the file that contains utility:
ftp> get vxexplore.tar.Z
Close the ftp connection:
ftp> bye
Untar the download:
Untar the downloaded file (only if the VRTSexplorer utility has been downloaded and not installed with the VRTSspt package) :
# zcat vxexplore.tar.Z | tar xvf -
The above command will create a VRTSexplorer directory containing everything that is needed. Change into this directory:
# cd VRTSexplorer
2. Execute the VRTSexplorer utility:
Some notes on the
execution of VRTSexplorer:
· To determine the version of VRTSexplorer that is on the host, along with other options, execute # ./VRTSexplorer -help:
# ./VRTSexplorer -help
VRTSexplorer: version 5.6c
· To run the VRTSexplorer utility for only one particular product, such as Veritas Volume Manager, execute:
# ./VRTSexplorer vxvm
· To run the VRTSexplorer utility to exclude a particular product, such as Veritas NetBackup, execute:
# ./VRTSexplorer -nbu
Refer to the README file for additional options that are available with the VRTSexplorer utility.
The below messages will appear requesting input for the case number, destination directory (BE CAREFUL TO NOT USE SPACES OR OTHER SPECIAL CHARACTERS IN THE DIRECTORY YOU SPECIFY!), restart of vxconfigd (do not choose to do this if PowerPath is installed or if this is a node in a cluster), etc. The program will output several messages and finish by tarring and compressing the collected information. Please note that this operation can take some time to complete.
Below is partial example of what might be seen (the messages below are from VRTSexplorer version 5.5o and will be different from earlier versions of the utility) when executing the VRTSexplorer utility to gather information about a host, output is dependant on which product packages are installed:
# ./VRTSexplorer
VRTSexplorer: Initializing.
VRTSexplorer: Please enter case number, or just hit enter: 150-175-206
VRTSexplorer: Please select a destination directory (default: /tmp): /tmp
VRTSexplorer: Using /tmp as destination directory.
VRTSexplorer: Collecting system configuration information for SunOS system.
VRTSexplorer: Collecting VERITAS package version information.
VRTSexplorer: Collecting loadable module information.
VRTSexplorer: Collecting SLIM information.
VRTSexplorer: Collecting SLIM Agent installer logs.
VRTSexplorer: Collecting SLIM Server installer logs.
VRTSexplorer: Collecting Cross Product/Platform Installation (CPI) information.
VRTSexplorer: Collecting ISIS configuration information.
VRTSexplorer: Collecting VERITAS SANPoint Control Console configuration information.
##### All information and files will be placed under /tmp/VRTSexplorer_150-175-206_server1/spc
Logfile is /tmp/VRTSexplorer_150-175-206_server1/spc/LOG
##### Capturing SAL/VAIL/VEA information from host server1'
##### Saving VERITAS Package Information..........
##### Logging VEA Information #####
+Copying vxisis.log files.
+Copying /var/vx/isis vxsvc corefiles
+Copying /opt/VRTSob/bin vxsvc corefiles
##### Logging VRTSvail Information #####
Checksum /opt/VRTSvail/providers/vx*:...............
##### Saving Detailed information for all VERITAS packages..........................
##### Saving Host syslogs #####
+Copying syslog files.....
VRTSexplorer: Collecting SIG licensing information.
VRTSexplorer: Collecting VRW configuration information.
VRTSexplorer: Collecting VxFS configuration information.
VRTSexplorer: Determining current VxVM operating mode.
VRTSexplorer: Collecting VxVM configuration information.
VRTSexplorer: Collecting DMP configuration information.
NOTICE: This section will stop and restart the VxVM Configuration Daemon,
vxconfigd. This may cause your VxVA, VMSA and/or VEA session to exit.
This may also cause a momentary stoppage of any VxVM configuration
actions. This should not harm any data; however, it may cause some
configuration operations (e.g. moving subdisks, plex
resynchronization) to abort unexpectedly. Any VxVM configuration
changes should be completed before running this section.
If you are using EMC PowerPath devices with Veritas Volume Manager,
you must run the EMC command(s) 'powervxvm setup' (or 'safevxvm
setup') and/or 'powervxvm online' (or 'safevxvm online') if this
script terminates abnormally.
Restart VxVM Configuration Daemon? [y,n] (default: n) n
VRTSexplorer: Collecting VRAS configuration information.
VRTSexplorer: Collecting Web GUI Engine information.
VRTSexplorer: Collecting Cross Product/Platform Installation (CPI) information.
VRTSexplorer: Script finished.
VRTSexplorer: The cksum for the tarfile is:
2113302371 2569248 /tmp/VRTSexplorer_150-175-206_server1.tar.gz
VRTSexplorer: Please ftp /tmp/VRTSexplorer_150-175-206_server1.tar.gz
VRTSexplorer: to ftp.veritas.com:/incoming or work with your
VRTSexplorer: support representative for other upload options.
#
· To determine the version of VRTSexplorer that is on the host, along with other options, execute # ./VRTSexplorer -help:
# ./VRTSexplorer -help
VRTSexplorer: version 5.6c
· To run the VRTSexplorer utility for only one particular product, such as Veritas Volume Manager, execute:
# ./VRTSexplorer vxvm
· To run the VRTSexplorer utility to exclude a particular product, such as Veritas NetBackup, execute:
# ./VRTSexplorer -nbu
Refer to the README file for additional options that are available with the VRTSexplorer utility.
The below messages will appear requesting input for the case number, destination directory (BE CAREFUL TO NOT USE SPACES OR OTHER SPECIAL CHARACTERS IN THE DIRECTORY YOU SPECIFY!), restart of vxconfigd (do not choose to do this if PowerPath is installed or if this is a node in a cluster), etc. The program will output several messages and finish by tarring and compressing the collected information. Please note that this operation can take some time to complete.
Below is partial example of what might be seen (the messages below are from VRTSexplorer version 5.5o and will be different from earlier versions of the utility) when executing the VRTSexplorer utility to gather information about a host, output is dependant on which product packages are installed:
# ./VRTSexplorer
VRTSexplorer: Initializing.
VRTSexplorer: Please enter case number, or just hit enter: 150-175-206
VRTSexplorer: Please select a destination directory (default: /tmp): /tmp
VRTSexplorer: Using /tmp as destination directory.
VRTSexplorer: Collecting system configuration information for SunOS system.
VRTSexplorer: Collecting VERITAS package version information.
VRTSexplorer: Collecting loadable module information.
VRTSexplorer: Collecting SLIM information.
VRTSexplorer: Collecting SLIM Agent installer logs.
VRTSexplorer: Collecting SLIM Server installer logs.
VRTSexplorer: Collecting Cross Product/Platform Installation (CPI) information.
VRTSexplorer: Collecting ISIS configuration information.
VRTSexplorer: Collecting VERITAS SANPoint Control Console configuration information.
##### All information and files will be placed under /tmp/VRTSexplorer_150-175-206_server1/spc
Logfile is /tmp/VRTSexplorer_150-175-206_server1/spc/LOG
##### Capturing SAL/VAIL/VEA information from host server1'
##### Saving VERITAS Package Information..........
##### Logging VEA Information #####
+Copying vxisis.log files.
+Copying /var/vx/isis vxsvc corefiles
+Copying /opt/VRTSob/bin vxsvc corefiles
##### Logging VRTSvail Information #####
Checksum /opt/VRTSvail/providers/vx*:...............
##### Saving Detailed information for all VERITAS packages..........................
##### Saving Host syslogs #####
+Copying syslog files.....
VRTSexplorer: Collecting SIG licensing information.
VRTSexplorer: Collecting VRW configuration information.
VRTSexplorer: Collecting VxFS configuration information.
VRTSexplorer: Determining current VxVM operating mode.
VRTSexplorer: Collecting VxVM configuration information.
VRTSexplorer: Collecting DMP configuration information.
NOTICE: This section will stop and restart the VxVM Configuration Daemon,
vxconfigd. This may cause your VxVA, VMSA and/or VEA session to exit.
This may also cause a momentary stoppage of any VxVM configuration
actions. This should not harm any data; however, it may cause some
configuration operations (e.g. moving subdisks, plex
resynchronization) to abort unexpectedly. Any VxVM configuration
changes should be completed before running this section.
If you are using EMC PowerPath devices with Veritas Volume Manager,
you must run the EMC command(s) 'powervxvm setup' (or 'safevxvm
setup') and/or 'powervxvm online' (or 'safevxvm online') if this
script terminates abnormally.
Restart VxVM Configuration Daemon? [y,n] (default: n) n
VRTSexplorer: Collecting VRAS configuration information.
VRTSexplorer: Collecting Web GUI Engine information.
VRTSexplorer: Collecting Cross Product/Platform Installation (CPI) information.
VRTSexplorer: Script finished.
VRTSexplorer: The cksum for the tarfile is:
2113302371 2569248 /tmp/VRTSexplorer_150-175-206_server1.tar.gz
VRTSexplorer: Please ftp /tmp/VRTSexplorer_150-175-206_server1.tar.gz
VRTSexplorer: to ftp.veritas.com:/incoming or work with your
VRTSexplorer: support representative for other upload options.
#
3. Send the file created above to Symantec Technical Support:
Example:
Change directory to the destination directory (default: /tmp):
# cd /tmp
Connect to the FTP site:
# ftp ftp.veritas.com
The below message appears with a prompt for a login name. Please see technote TECH66995 in related items below for logon credentials.
Connected to ftp.veritas.com
220-ftp
220-***********************************************************************
220- This system is for the use of authorized users only. Individuals
220- using this computer system without authority, or in excess of their
220- authority, are subject to having all of their activities on this
220- system monitored and recorded.
220- In the course of monitoring individuals improperly using this
220- system, or in the course of system maintenance, the activities of
220- authorized users also are monitored.
220- Anyone using this system expressly consents to such monitoring
220- and recording. Please be advised that unauthorized access to this
220- system is a violation of State and Federal law. If monitoring
220- reveals possible evidence of criminal activity, system personnel
220- may provide that evidence to law enforcement officials.
220-***********************************************************************
220
Name (ftp.veritas.com <ftp://ftp.veritas.com/>): See technote TECH66995
331 User symsupport okay, need password.
Password: See technote TECH66995
230 Restricted user logged in.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>
While logged into the FTP server as the customer user, it is not possible to list any files or directories. It is important that the below steps are followed exactly:
Change into the /incoming directory:
ftp> cd /incoming
Set FTP mode to binary:
ftp> bin
Upload the file that was created above:
ftp> put VRTSexplorer_150-175-206_server1.tar.gz
Close the ftp connection:
ftp> bye
If this is an existing case, call or email the Technical Support Engineer assigned to the case to let them know the VRTSexplorer data is available along with the name of the file that was uploaded. If a case has not been created for the issue, contact Technical Support via your local support hotline to create a new case, or create a new case on the Web via MySymantec at https://mysymantec.symantec.com/ and provide the name of the file that was uploaded along with a description of the issue.
System dump devices - AIX
Traditionally the default dump device for system dumps was: /dev/hd6 (paging space) and still is on a lot of systems. If there is not enough space to copy over the dump file after a crash, then the system administrator is prompted upon restart to copy the dump file over to some removable media , like a tape or DVD. This can be time consuming and it is sometimes the case that you want to get your system back up quickly. I can sympathise with system administrators who just ignore the prompt to get the system back up due to business pressure, thus deleting the dump, so then one does not know why it crashed in the first place. If you do not have enough space on your dump device to copy the dump, then during the start-up process, the copydumpmenu menu utility is invoked to give the system administrator the opportunity to copy the dump to a removable media, for example to a tape device if present. The copydumpmenu utility can also be called from the command line when the system is up. The copy directory by default is /var/adm/ras with the file-name:vmcore.<X>.BZ , where X is a sequence number. The dump file is a BZ (BZIP) and not a Z compressed file format.
The snap command can be used to gather information about the dump file, be-sure to include the -D flag, it gathers the information from the primary dump device.
With systems now having more memory available, this has provided more flexibility as to where the primary dump device could be placed. Typically, for systems with over 4 GB of memory there is now a dedicated dump device, called: lg_dumplv
# lsvg -l rootvg |grep sysdump
Using the sysdumpdev command, one can determine what devices are used for the system dumps.
The following output shows a system using AIX 7.1 having the lg_dumplv as its primary dump device:
# sysdumpdev -l
Looking more closely at the above output fields. Notice that an extra field is now present for AIX 6.1 onwards: type of dump. Currently set to traditional, here you can have it set at (firmware) fw-assisted, if your hardware supports it. For the secondary field, there is no dump device. This is denoted by using the sysdumpnull device. This means all system dumps are lost if it goes to that device. The copy directory is /var/adm/ras, this is where the system dump will be copied to , for either further examination, or to be copied off to go to IBM support. Note that 'always allow dump' is set to true, this must be the case if a dump is to be successfully initiated. Dump compression is on by default.
Common settings using sysdumpdev are:
To change the primary device use: sysdumpdev -P -p <device_name>
To change the secondary device use: sysdumpdev -P -s <device_name>
To change the copy directory use: sysdumpdev -D <path_name>
To change the always dump condition use: sysdumpdev -k for false, sysdumpdev -K for true
To change the type of dump use: sysdumpdev -t <fw-assisted | traditional>
Few Commands:
1. To view the current dump configuration :
# sysdumpdev -l
primary /dev/hd6
secondary /dev/sysdumpnull
copy directory /var/adm/ras
forced copy flag TRUE
always allow dump FALSE
dump compression OFF
2. To change the primary dump device temporarily :
# sysdumpdev -p /dev/dumplv
3. To change the primary dump device permanently :
# sysdumpdev -P -p /dev/dumplv
4. To change the secondary dump device temporarily :
# sysdumpdev -s /dev/dumplv
5. To change the secondary dump device permanently :
# sysdumpdev -P -s /dev/dumplv
6. To set the copy flag :
# sysdumpdev -K
7. To unset the copy flag :
# sysdumpdev -k
8. To estimate the dump size :
# sysdumpdev -e
9. To list the last dump information :
# sysdumpdev -L
Device name: /dev/lg_dumplv
Major device number: 12
Minor device number: 4
Size: 42123543 bytes
Date/Time: Wed Jan 01 12:03:00 CDT 2009
Dump status: 0
dump completed successfully
Dump copy filename: /var/adm/ras/vmcore.1
10. To copy the saved vmcoren file to tape :
# snap -gfkD -o /dev/rmt0
11. To read the dump file :
# crash dump unix
>
12. To change the dump file location and if the copy fails it should ask external media to copy the dump file:
# sysdumpdev -D /opt/dumpfiles
13. To change the dump file location and if the copy fails it should ignore the system dump:
# sysdumpdev -d /opt/dumpfiles
14. To specify the dumps should not be compressed :
# sysdumpdev -c
15. To specify the dumps should be always compress :
# sysdmpdev -C
16. To find out whether a new systemp dump has occured before the last reboot :
# sysdumpdev -z
The compressed dump is now on the LV lg_dumplv. The dump was not copied across to the copy directory when issuing a user initiated dump. To copy the most recent system dump from a system dump device to a directory, use the savecore command. For example, to copy the dump to the directory /var/adm/ras. I could use:
If you need to uncompress the file use the dmpuncompress utility. The format of the command is:
After uncompressing, the dump file is now ready for further investigation using kdb or for transfer to IBM support.
The fields are populated with the current dump that is on the primary dump device. This is the default setting, after the copy, the dump file is present in: /var/adm/ras:
After a dump has occurred there may well be a minidump generated as a well. Contained in the errorlog output listing earlier in the article, there was an entry for:
The minidump is a small compress dump that will be present in: /var/adm/ras. This file contains a snapshot of the system when the system was dumped or crashed. This file can be used for diagnosing if the main dump is not present, due to the dump being removed or not captured.
The snap command can be used to gather information about the dump file, be-sure to include the -D flag, it gathers the information from the primary dump device.
With systems now having more memory available, this has provided more flexibility as to where the primary dump device could be placed. Typically, for systems with over 4 GB of memory there is now a dedicated dump device, called: lg_dumplv
# lsvg -l rootvg |grep sysdump
lg_dumplv sysdump 8 8 open/syncd N/A
Using the sysdumpdev command, one can determine what devices are used for the system dumps.
The following output shows a system using AIX 7.1 having the lg_dumplv as its primary dump device:
# sysdumpdev -l
primary /dev/lg_dumplv
secondary /dev/sysdumpnull
copy directory /var/adm/ras
forced copy flag TRUE
always allow dump TRUE
dump compression ON
type of dump traditional
Looking more closely at the above output fields. Notice that an extra field is now present for AIX 6.1 onwards: type of dump. Currently set to traditional, here you can have it set at (firmware) fw-assisted, if your hardware supports it. For the secondary field, there is no dump device. This is denoted by using the sysdumpnull device. This means all system dumps are lost if it goes to that device. The copy directory is /var/adm/ras, this is where the system dump will be copied to , for either further examination, or to be copied off to go to IBM support. Note that 'always allow dump' is set to true, this must be the case if a dump is to be successfully initiated. Dump compression is on by default.
Common settings using sysdumpdev are:
To change the primary device use: sysdumpdev -P -p <device_name>
To change the secondary device use: sysdumpdev -P -s <device_name>
To change the copy directory use: sysdumpdev -D <path_name>
To change the always dump condition use: sysdumpdev -k for false, sysdumpdev -K for true
To change the type of dump use: sysdumpdev -t <fw-assisted | traditional>
Few Commands:
1. To view the current dump configuration :
# sysdumpdev -l
primary /dev/hd6
secondary /dev/sysdumpnull
copy directory /var/adm/ras
forced copy flag TRUE
always allow dump FALSE
dump compression OFF
2. To change the primary dump device temporarily :
# sysdumpdev -p /dev/dumplv
3. To change the primary dump device permanently :
# sysdumpdev -P -p /dev/dumplv
4. To change the secondary dump device temporarily :
# sysdumpdev -s /dev/dumplv
5. To change the secondary dump device permanently :
# sysdumpdev -P -s /dev/dumplv
6. To set the copy flag :
# sysdumpdev -K
7. To unset the copy flag :
# sysdumpdev -k
8. To estimate the dump size :
# sysdumpdev -e
9. To list the last dump information :
# sysdumpdev -L
Device name: /dev/lg_dumplv
Major device number: 12
Minor device number: 4
Size: 42123543 bytes
Date/Time: Wed Jan 01 12:03:00 CDT 2009
Dump status: 0
dump completed successfully
Dump copy filename: /var/adm/ras/vmcore.1
10. To copy the saved vmcoren file to tape :
# snap -gfkD -o /dev/rmt0
11. To read the dump file :
# crash dump unix
>
12. To change the dump file location and if the copy fails it should ask external media to copy the dump file:
# sysdumpdev -D /opt/dumpfiles
13. To change the dump file location and if the copy fails it should ignore the system dump:
# sysdumpdev -d /opt/dumpfiles
14. To specify the dumps should not be compressed :
# sysdumpdev -c
15. To specify the dumps should be always compress :
# sysdmpdev -C
16. To find out whether a new systemp dump has occured before the last reboot :
# sysdumpdev -z
The compressed dump is now on the LV lg_dumplv. The dump was not copied across to the copy directory when issuing a user initiated dump. To copy the most recent system dump from a system dump device to a directory, use the savecore command. For example, to copy the dump to the directory /var/adm/ras. I could use:
# savecore -d /var/adm/ras
vmcore.0.BZ
|
If you need to uncompress the file use the dmpuncompress utility. The format of the command is:
dmpuncompress < filename>
|
After uncompressing, the dump file is now ready for further investigation using kdb or for transfer to IBM support.
# dmpuncompress vmcore.0.BZ
replaced with vmcore.0
Alternatively you can use the smit dump menu option and select,Copy a system dump
. The following screen displays:Copy dump image to: Type or select values in entry fields. Press Enter after making all desired changes. [Entry Fields] * Copy dump image from: [/dev/lg_dumplv] / * Copy dump image to: [/var/adm/ras/dump_fil> * Input and output file blocksize for copy [4096] # Size in bytes of dump image 63894528 Date of last dump Thu Oct 27 18-02-28 B> |
The fields are populated with the current dump that is on the primary dump device. This is the default setting, after the copy, the dump file is present in: /var/adm/ras:
# ls -l dump_file_copy.BZ -rw-r--r-- 1 root system 63894528 Oct 27 18:15 dump_file_copy.BZ |
After a dump has occurred there may well be a minidump generated as a well. Contained in the errorlog output listing earlier in the article, there was an entry for:
F48137AC 1027180411 U O minidump COMPRESSED MINIMAL DUMP |
The minidump is a small compress dump that will be present in: /var/adm/ras. This file contains a snapshot of the system when the system was dumped or crashed. This file can be used for diagnosing if the main dump is not present, due to the dump being removed or not captured.