QA » openQA Project » openQA Tests » qe-yam

The root cause is autoyast file change the default setting of kdump for s390, so if you want openqa show correct result, do not set any specific kdump setting, or you change script to check specific setting for s390. My proposal currently is change correct yast auto install file.

<kdump t="map">
<add_crash_kernel t="boolean">true</add_crash_kernel>
<crash_kernel>147M</crash_kernel>
<crash_xen_kernel>147M\<4G</crash_xen_kernel>
<general t="map">
<KDUMP_AUTO_RESIZE>false</KDUMP_AUTO_RESIZE>
<KDUMP_COMMANDLINE/>
<KDUMP_COMMANDLINE_APPEND/>
<KDUMP_CONTINUE_ON_ERROR>true</KDUMP_CONTINUE_ON_ERROR>
<KDUMP_CPUS/>
<KDUMP_DUMPFORMAT>lzo</KDUMP_DUMPFORMAT>  <<<<<<<<<<<<<<<< 
<KDUMP_DUMPLEVEL>31</KDUMP_DUMPLEVEL>
<KDUMP_FREE_DISK_SIZE>64</KDUMP_FREE_DISK_SIZE>
<KDUMP_HOST_KEY/>
<KDUMP_IMMEDIATE_REBOOT>yes</KDUMP_IMMEDIATE_REBOOT>
<KDUMP_KEEP_OLD_DUMPS>5</KDUMP_KEEP_OLD_DUMPS>
<KDUMP_KERNELVER/>
<KDUMP_NETCONFIG>auto</KDUMP_NETCONFIG>
<KDUMP_NET_TIMEOUT>30</KDUMP_NET_TIMEOUT>
<KDUMP_NOTIFICATION_CC/>
<KDUMP_NOTIFICATION_TO/>
<KDUMP_POSTSCRIPT/>
<KDUMP_PRESCRIPT/>
<KDUMP_REQUIRED_PROGRAMS/>
<KDUMP_SAVEDIR>/var/crash</KDUMP_SAVEDIR>
<KDUMP_SMTP_PASSWORD/>
<KDUMP_SMTP_SERVER/>
<KDUMP_SMTP_USER/>
<KDUMP_TRANSFER/>
<KDUMP_VERBOSE>3</KDUMP_VERBOSE>
<KEXEC_OPTIONS/>
</general>
</kdump>

coolgw wrote in #note-2:

The root cause is autoyast file change the default setting of kdump for s390, so if you want openqa show correct result, do not set any specific kdump setting, or you change script to check specific setting for s390. My proposal currently is change correct yast auto install file.

<kdump t="map">
<add_crash_kernel t="boolean">true</add_crash_kernel>
<crash_kernel>147M</crash_kernel>
<crash_xen_kernel>147M\<4G</crash_xen_kernel>
<general t="map">
<KDUMP_AUTO_RESIZE>false</KDUMP_AUTO_RESIZE>
<KDUMP_COMMANDLINE/>
<KDUMP_COMMANDLINE_APPEND/>
<KDUMP_CONTINUE_ON_ERROR>true</KDUMP_CONTINUE_ON_ERROR>
<KDUMP_CPUS/>
<KDUMP_DUMPFORMAT>lzo</KDUMP_DUMPFORMAT>  <<<<<<<<<<<<<<<< 
<KDUMP_DUMPLEVEL>31</KDUMP_DUMPLEVEL>
<KDUMP_FREE_DISK_SIZE>64</KDUMP_FREE_DISK_SIZE>
<KDUMP_HOST_KEY/>
<KDUMP_IMMEDIATE_REBOOT>yes</KDUMP_IMMEDIATE_REBOOT>
<KDUMP_KEEP_OLD_DUMPS>5</KDUMP_KEEP_OLD_DUMPS>
<KDUMP_KERNELVER/>
<KDUMP_NETCONFIG>auto</KDUMP_NETCONFIG>
<KDUMP_NET_TIMEOUT>30</KDUMP_NET_TIMEOUT>
<KDUMP_NOTIFICATION_CC/>
<KDUMP_NOTIFICATION_TO/>
<KDUMP_POSTSCRIPT/>
<KDUMP_PRESCRIPT/>
<KDUMP_REQUIRED_PROGRAMS/>
<KDUMP_SAVEDIR>/var/crash</KDUMP_SAVEDIR>
<KDUMP_SMTP_PASSWORD/>
<KDUMP_SMTP_SERVER/>
<KDUMP_SMTP_USER/>
<KDUMP_TRANSFER/>
<KDUMP_VERBOSE>3</KDUMP_VERBOSE>
<KEXEC_OPTIONS/>
</general>
</kdump>

Thanks @coolgw, makes sense.

PR#19287 created.
I changed the settings to the values that are expected. The intersting thing is that the faulty test passed last time around 4 weeks ago, the "recent" work on all files that might contribute to the problem was done much before. So there is a sligth chance that we have a regression here.

rainerkoenig wrote in #note-6:

PR#19287 created.
I changed the settings to the values that are expected. The intersting thing is that the faulty test passed last time around 4 weeks ago, the "recent" work on all files that might contribute to the problem was done much before. So there is a sligth chance that we have a regression here.

Exactly, that is why we should not open PR to make it green. The first thing would be to use default settings and see if we see these two (or more?) new values, we can do that removing the all sections if possible or cloning from an interactive installation. Before our changes we were linking to parent with interactive installation and was passing, then we switch to our autoyast when we might be forcing things and not using defaults. Another way to test this is to clone with the previous parent and if it passes our settings are wrong, but if still fails, then we should file a bug.

Good point @JERiveraMoya, I now had a deeper look at the history and compared the failure above with the last good job. The interesting thing is that in the last good we already had that dependency to our create_hdd_textmode_yast parent test suite. The difference was then revealed when I compared the variables of the "good" and the "bad" parent. It turned out that the bad one shows this line:

"PUBLISH_HDD_1" : "sle-15-SP6-s390x-88.1-textmode-yast@s390x-kvm.qcow2",

This means, that with the good parent we were not using any autoyast generated qcow2 but we hijacked the qcow2 created by create_hdd_textmode in the functional group which places its qcow2 under the same name. And yes, this is a non autoyast installation, not even one with a YAML schedule, so there is no special taking care of KDUMP settings.

The PR that I filed changes the settings in our autoyast profile to macht the expectations of this test, which were not so easy to spot where they are coming from.
One thing that made me confused was that the error message says

Setting "KDUMP_DUMPFORMAT" with value "compressed" not found in /etc/sysconfig/kdump.

It would have been easier if the message would say

Setting "KDUMP_DUMPFORMAT" value mismatch! Expected: "compressed" Found: "lzo".

So from my point of view we have 2 options now:

• Reduce the autoyast profile to not mention any KDUMP variables and see what happens when default settings are applied, even if this might affect other tests.
• User the PR with the now correct settings for this test.

We also should think about changing the PUBLISH_HDD_1 and HDD_1 settings for this combination to use a qqcow name that is not also used by a job in the functional group, otherwise we will mess things up.

actually this ticket is even more simple, we just have wrong test data :) Check last GMC.
https://openqa.suse.de/tests/11162529/settings/test_data/yast/yast2_ncurses/textmode_lzo.yaml

Please also apply also for ppc64le:
https://openqa.suse.de/tests/11163227/settings/test_data/yast/yast2_ncurses/textmode_lzo_fadump.yaml