zgetdump - Copy and convert kernel dumps

The zgetdump tool reads or converts a dump.

The dump can be located either on a dump device or on a file system. The dump content is written to standard output, unless you redirect it to a specific file. You can also mount the dump content, print dump information, or check whether a DASD device contains a valid dump tool.

zgetdump syntax

Parameters

<dump>

is the file, DASD device or partition, multipath partition of a SCSI disk, or channel-attached tape device where the source dump is located:

Regular dump file (for example /testdir/dump.0)
DASD partition device node (for example /dev/dasdc1)
DASD device node for multi-volume dump (for example /dev/dasdc)
Device mapper multipath partition device node of a SCSI disk (for example /dev/mapper/36005076303ffd40100000000000020c0-part1)
Tape device node (for example /dev/ntibm0)

Note: For a DASD multi-volume dump it is sufficient to specify only one of the multi-volume DASDs as <dump>.

<dump_file>

Is the file to which the output is redirected. The default is standard output.

<dumpdevice>

Specifies the dump device for the -d option. The device node of the DASD device, for example /dev/dasdb, or a multipath device node of a SCSI disk, for example /dev/mapper/36005076303ffd40100000000000020c0.

-s <system> or --select <system>

for dumps that capture two systems, selects the system of interest. To check whether a dump contains two systems, use zgetdump -i. The -s option is mandatory when accessing the dump of a crashed kdump instance, but returns an error if applied to a regular dump.

A dump can contain data for a crashed production system and for a crashed kdump system. A dump like this is created if a stand-alone dump tool is used to create a dump for a kdump instance that crashed while creating a dump for a previously crashed production system. <system> can be:

prod: to select the data for the crashed production system.
kdump: to select the data for the kdump instance that crashed while creating a dump for the previously crashed production system.
all: to select the data for both prod and kdump.

-m <dump> <dir> or --mount <dump> <dir>

Mounts the <dump> to mount point <dir> and generates a virtual target dump file instead of writing the content to standard output. The virtual dump file is named dump.FMT, where FMT is the name of the specified dump format (see the --fmt option).

-u <dir> or --umount <dir>

Unmounts the dump that is mounted at mount point <dir>. You can specify the dump itself instead of the directory, for example /dev/dasdd1. This option is a wrapper for fusermount -u.

-i <dump> or --info <dump>

Displays the dump header information from the dump and performs a validity check.

-d <dumpdevice> or --device <dumpdevice>

Checks whether the specified ECKD, FBA, or SCSI disk device contains a valid dump tool and prints information about it.

-f <format> or --fmt <format>

Uses the specified target dump format <format> when writing or mounting the dump. The following target dump formats are supported:

elf: Executable and Linking Format core dump (default)
s390: S/390® dump

-V or --verbose

Shows the detailed memory-map layout when printing the dump header information for s390_ext and ELF dump formats.

-h or --help

Displays the help information for the command.

-v or --version

Displays the version information for the command.

Using zgetdump to copy a dump

Assuming that the dump is on DASD partition /dev/dasdb1 and that you want to copy it to a file named dump_elf:

# zgetdump /dev/dasdb1 > dump_elf

Using zgetdump to transfer a dump with ssh

Assuming that the dump is on DASD partition /dev/dasdd1 and that you want to transfer it to a file on another system with ssh:

# zgetdump /dev/dasdd1  | ssh user@host "cat > dump.elf"

Using zgetdump to transfer a dump with FTP

Follow these steps to transfer a dump with FTP:

Establish an FTP session with the target host and log in.
To transfer a file in binary mode, enter the FTP binary command:
```
ftp> binary
```
To send the dump file to the host issue a command of the following form:
```
ftp> put |"zgetdump /dev/dasdb1" <dump_file_on_target_host>
```

Using zgetdump to copy a multi-volume dump

Assuming that the dump is on DASD devices /dev/dasdc and /dev/dasdd spread along partitions /dev/dasdc1 and /dev/dasdd1, and that you want to copy it to a file named dump.elf:

# zgetdump /dev/dasdc > dump.elf

For an example of the output from this command, see Using DASD devices for multi-volume dump.

Using zgetdump to copy a tape dump

Assuming that the tape device is /dev/ntibm0:

# zgetdump /dev/ntimb0 > dump.elf
Format Info:
  Source: s390tape
  Target: elf

Copying dump:
  00000000 / 00001024 MB
  00000171 / 00001024 MB
  00000341 / 00001024 MB
  00000512 / 00001024 MB
  00000683 / 00001024 MB
  00000853 / 00001024 MB
  00001024 / 00001024 MB

Success: Dump has been copied

Checking whether a tape dump is valid, and printing the dump header

Assuming that the tape device is /dev/ntibm0:

# zgetdump -i /dev/ntibm0
Checking tape, this can take a while...
General dump info:
  Dump format........: s390tape
  Version............: 5
  Dump created.......: Thu, 24 Oct 2019 09:09:49 +0000 
  Dump ended.........: Thu, 24 Oct 2019 09:11:09 +0000 
  Dump CPU ID........: ff00012320948000
  UTS kernel release.: 4.18.0-144.el8.s390x
  UTS kernel version.: #1 SMP Thu Sep 12 14:45:38 UTC 2019
  Build arch.........: s390x (64 bit)
  System arch........: s390x (64 bit)
  CPU count (online).: 2
  CPU count (real)...: 2
  Dump memory range..: 1024 MB
  Real memory range..: 1024 MB

Memory map:
  0000000000000000 - 000000003fffffff (1024 MB)

Checking whether a DASD dump is valid and printing the dump header

Assuming that the dump is on a partition, part1, of a DASD device /dev/dasdb1:

# zgetdump -i /dev/dasdb1
General dump info:
  Dump format........: s390_ext
  Version............: 1
  Dump created.......: Fri, 25 Oct 2019 20:00:52 +0200
  Dump ended.........: Fri, 25 Oct 2019 20:00:55 +0200
  Dump CPU ID........: ff3fec8729648000
  UTS node name......: s8360020
  UTS kernel release.: 4.18.0-144.el8.s390x
  UTS kernel version.: #1 SMP Thu Sep 12 14:45:38 UTC 2019
  Build arch.........: s390x (64 bit)
  System arch........: s390x (64 bit)
  CPU count (online).: 2
  CPU count (real)...: 2
  Dump memory range..: 2048 MB
  Real memory range..: 2048 MB
  Dump file size.....: 493 MB

Memory map:
  0000000000000000 - 000000007fffffff (2048 MB)

Checking whether a SCSI dump is valid and printing the dump header

Assuming that the dump is on the first partition of a SCSI disk, for example /dev/mapper/36005076303ffd40100000000000020c0-part1:

# zgetdump -i /dev/mapper/36005076303ffd40100000000000020c0-part1
General dump info:                                      
  Dump format........: elf                              
  Version............: 1                                
  UTS node name......: r3545010                         
  UTS kernel release.: 4.18.0-144.el8.s390x
  UTS kernel version.: #1 SMP Thu Sep 12 14:45:38 UTC 2019
  System arch........: s390x (64 bit)                   
  CPU count (online).: 3                                
  Dump memory range..: 1024 MB                          
                                                        
Memory map:                                             
  0000000000000000 - 000000003fffffff (1024 MB)

Checking whether a device contains a valid dump record

Checking DASD device /dev/dasdb, which is a valid dump device:

# zgetdump -d /dev/dasdb
Dump device info:
  Dump tool.........: Single-volume DASD dump tool
  Version...........: 2
  Architecture......: s390x (64 bit)
  DASD type.........: ECKD
  Dump size limit...: none

Checking DASD device /dev/dasdc, which is not a valid dump device:

# zgetdump -d /dev/dasdc
zgetdump: No dump tool found on "/dev/dasdc"

Checking whether a SCSI disk contains a valid dump record

Checking SCSI multipath device /dev/mapper/36005076303ffd40100000000000020c0, which is a valid dump device:

# zgetdump -d /dev/mapper/36005076303ffd40100000000000020c0
Dump device info:
Dump tool.........: Single-volume SCSI dump tool
Version...........: 1
Architecture......: s390x (64 bit)

Partition info:
Partition number..: 1
Maximum dump size.: 20473 MB

Checking SCSI multipath device /dev/mapper/36005076307ffc5e300000000000084cf, which is not a valid dump device:

# zgetdump -d /dev/mapper/36005076307ffc5e300000000000084cf
zgetdump: No dump tool found on "/dev/mapper/36005076307ffc5e300000000000084cf"

Using the mount option

Mounting is useful for multi-volume DASD dumps. After a multi-volume dump has been mounted, it is shown as a single dump file that can be accessed directly with dump processing tools such as crash.

The following example mounts a multi-volume DASD dump as an ELF dump, processes it with crash, and unmounts it with zgetdump:

# zgetdump -m /dev/dasdx /dumps
# crash vmlinux /dumps/dump.elf
# zgetdump -u /dumps

Mounting can also be useful when you want to process the dump with a tool that cannot read the original dump format. Use the --fmt option to mount the dump with a format other then the default format.

Selecting data from a dump that includes a crashed kdump

The following example mounts dump data for a crashed production system from a DASD backup dump for a failed kdump (see Failure recovery and backup tools for details).

# zgetdump -s prod -m /dev/dasdb1 /mnt

Checking whether a dump has captured two systems

A dump can contain data from two systems. To check for this use zgetdump -i, for example, assuming that the previous dump example contains both a dump from the production system and a kdump kernel dump:

# zgetdump -i /dev/mapper/36005076303ffd40100000000000020c0-part1
zgetdump: The dump contains "kdump" and "production system"
          Access "production system" with "-s prod"
          Access "kdump" with "-s kdump"
          Access the complete dump with "-s all"
          Send both dumps to your service organization