QA (public) » openQA Project (public) » openQA Tests (public) » qe-yam

Yast2 dump module test proposal:¶

That module is a front-end for mkdump. It does this:

mkdump --list-dasd
mkdump --list-zfcp
mkdump [--force] /dev/[device]

The mkdump script automatically lists DASD or ZFCP device that can be used as dump device. Such device should be of ECKD type (mkdump does not work with FBA, nor with multipathed zfcp devices, those issues should be subject to some soft failures) it must have exclusive access and have VM's RAM+ 10MB of free space.

The test could be as follows:

1 - Activate some DASD and/or ZFCP device:
This can be done in various ways:

• During installation,
• Later by command line as in bootloader (command: "dasd_configure 0.0.200 1". That disk should be free and "dumpable".)
• By putting this test module after the ones for dasd and/or zfcp, which also allow to enable disks. See also: the SUT for ZFCP, s390x-zfcp.

2 - Start yast2 dump, initialize some disk for dumping.
Don't forget to signal https://bugzilla.suse.com/show_bug.cgi?id=1135241 as soft-failure if an incompatible disk is shown here, and https://bugzilla.suse.com/show_bug.cgi?id=1136864 if you cannot use a multipathed zfcp device.

3 - check if disk is marked as dump disk, either in the module itself or with mkdump --list-dump

Documentation:
About dump devices : https://public.dhe.ibm.com/software/dw/linux390/docu/ljs0dt00.pdf
ZFCP and multipath tutorial (very good): https://share.confex.com/share/117/webprogram/Handout/Session9478/SHARE%20Boston%209222%20-%20SCSI.pdf

Onpanic test proposal¶

The onpanic module uses mkdump and dumpconf. It does not work with multipath zfcp devices, see this bug.

• Put that module after yast2 dump, so a dump device was already initialized, or do it manually as specified in the IBM doc
• Disable kdump, otherwise the dump will be done using kdump instead of dumpconf. A reboot is required after disabling kdump...
• In yast module, enable dumpconf, set delay to 1 and action to dump_reipl.
• Simulate a kernel crash with the following command: "echo c > /proc/sysrq-trigger"
• After reboot, check that the dump worked by typing "zgetdump -i /dev/something" and/or "zgetdump /dev/something > dump.elf"

That one may be tricky, because it requires two reboots to be tested properly, it may add some difficulty since we are on s390.

See for the reason of tracker change: http://mailman.suse.de/mailman/private/qa-sle/2020-October/002722.html