There are several different test types that cause reboot/crash of the SUT. Examples are reboot(), kexec() syscalls, MCE error injection, kernel crash dump testing, etc. Currently such tests are impossible to implement and many of the features are untested.
To get this working we need:
add .reeboots_sut flag into the tst_test structure
kirk has to parse the metadata and expect the SUT to be rebooted after such tests
such test cannot run in parallel
kirk has to be able to reestablish the connection to SUT after it booted up
these tests would need additional command line parameter since the test binary will be executed twice
first time the test is executed before reboot
second time it's executed after reboot
these test must just print warning and do not do anything if this parameter is not provided
Example workflow would be:
kirk executes reboot01 -P1 that calls reboot() syscall to trigger the system reboot
kirk waits for the machine to shutdown and boot
once machine is up again kirk executes reboot01 -P2 which would check that system is freshly booted
(uptime is small enough or something similar)
metan-ucw
commented
8 months ago
There are several different test types that cause reboot/crash of the SUT. Examples are
reboot(),kexec()syscalls, MCE error injection, kernel crash dump testing, etc. Currently such tests are impossible to implement and many of the features are untested.To get this working we need:
.reeboots_sutflag into thetst_teststructureExample workflow would be:
reboot01 -P1that callsreboot()syscall to trigger the system rebootreboot01 -P2which would check that system is freshly booted (uptime is small enough or something similar)