action #33859: [sles][functional][saga][s390x][u] Review s390x Bugs found by IBM and see what can be implemented in the future
action #33862: [sles][functional][epic][s390x][yast][y] Review and extend test coverage of YaST2 modules on s390x
[functional][y][s390][epic] Create new test suite for s390 specific yast modules
|Target version:||SUSE QA tests - Milestone 30|
There are several Yast modules that are specific to s390, not tested in Openqa, and barely tested in general. Those modules are part of the yast2-s390 package:
- A new test suite is created for yast2-s390 modules
- At least a smoke test for each of those modules exists
For each module:
1. Learn what module is for.
2. Understand what the underlying command-line tools are doing. Those are very specific, and may require some study.
3. Test manually on zVM and zKVM.
4. Develop automated test scenario to verify functionality of the YaST module.
Note: some manual testing was already done for the dump module, see related ticket.
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
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¶
- 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.