action #26014
closed[sle][functional][hyperv] svirt-hyperv tests are sometimes losing keys when trying to execute commands, e.g. always "yast2-bootloade-status-0"
Added by Anonymous over 6 years ago. Updated over 6 years ago.
0%
Description
Updated by mgriessmeier over 6 years ago
- Subject changed from ncurses fails as "zypper" was typed wrong to [sles][functional][hyperv] svirt-hyperv tests are sometimes losing keys when trying to execute commands
- Assignee set to michalnowak
see recent example, but not with zypper
https://openqa.suse.de/tests/1236180#step/yast2_bootloader/5
@mnowak: any idea?
Updated by michalnowak over 6 years ago
- Project changed from openQA Tests to openQA Project
- Category deleted (
Bugs in existing tests) - Assignee deleted (
michalnowak)
I don't know of anything we could do, especially in 'openQA tests'. VNC_TYPING_LIMIT is already at 10... I am afraid VNC won't let us do it a smarter way.
Updated by okurz over 6 years ago
- Related to action #25914: [sle][functional][hyperv][easy] test fails in bootloader_hyperv (Command on Hyper-V failed at bootloader_hyperv.pm line 25) added
Updated by okurz over 6 years ago
- Category set to 132
most recent example: https://openqa.suse.de/tests/1249509#step/yast2_bootloader/8
Updated by okurz over 6 years ago
- Subject changed from [sles][functional][hyperv] svirt-hyperv tests are sometimes losing keys when trying to execute commands to [sle][functional][hyperv] svirt-hyperv tests are sometimes losing keys when trying to execute commands
that is strange, https://openqa.suse.de/tests/1261746#step/yast2_bootloader/8 shows exactly the same key lost as mentioned in #26014#note-4 . I don't think this is a "random key lost" issue, it's a specific one. @michalnowak any idea why the "r" of "bootloade*r*" is not correctly typed/forwarded? Seems this problem appears in the same character but also not in every job? Might just be a very strange coincidence though but why again the same test module then?
Updated by okurz over 6 years ago
- Assignee set to michalnowak
Also in https://openqa.suse.de/tests/1261812#step/yast2_bootloader/8 , this can't be a coincidence.
Updated by michalnowak over 6 years ago
The original problem https://openqa.suse.de/tests/1236180#step/yast2_bootloader/5 is a different to https://openqa.suse.de/tests/1261812#step/yast2_bootloader/8. In the former one key on VNC screen is not present, on the latter one a letter did not make it via serial console.
But the latter thing you mention is certainly not a coincidence. The string is not making it quite reliably (I've seen it in the past), interestingly it's a always a 16th character... We are lucky script_run control strings are shorter. I wonder if some combination of baud rate and parity checking could (https://github.com/torvalds/linux/blob/master/Documentation/admin-guide/kernel-parameters.txt#L603) make a difference here.
Updated by okurz over 6 years ago
- Subject changed from [sle][functional][hyperv] svirt-hyperv tests are sometimes losing keys when trying to execute commands to [sle][functional][hyperv] svirt-hyperv tests are sometimes losing keys when trying to execute commands, e.g. always "yast2-bootloade-status-0"
Updated by okurz over 6 years ago
Updated by michalnowak over 6 years ago
Simple workaround would be to shorten the magic control string yast2-bootloader-status-$? to about 8 characters... if anyone feels it's sensible solution for now. (Can't look into it in next ~10 days myself, though.)
Updated by okurz over 6 years ago
- Related to action #28669: [sle][functional][u][svirt-hyperv-uefi] one character from serial output in wait_serial lost (was: /lib/libc.so.* did not match) added
Updated by jorauch over 6 years ago
- Status changed from New to Feedback
- Assignee changed from michalnowak to jorauch
Updated by okurz over 6 years ago
PR merged, the next job https://openqa.suse.de/tests/1311517 was ok but we need more statistics. That worker is quite loaded so I did not trigger a whole bunch of tests to gather statistics. I guess we should just wait.
Updated by michalnowak over 6 years ago
Similar fix done at other place: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/4048.
Updated by okurz over 6 years ago
- Status changed from Feedback to Resolved
with https://openqa.suse.de/tests/1317255#step/yast2_bootloader/8 passed as well I think we are good now. We could keep the ticket open because we just applied workarounds but will we ever be able to fix it? Maybe. If that is the case then we can still apply the changes but let's close this ticket for now.