action #51374
closed[functional][y] Soft failure for "Console messages writes over any tty" seems irrelevant in this case.
0%
Description
Observation¶
The soft failure in this case seems to be no longer relevant for sle12sp5. I tried to reproduce the issue by doing as in comment 34 of the bug report, and by sending directly a message to dmesg (echo something > /dev/ksmsg), it does not seem trigger the bug.
That soft-failure should be removed where it does not apply anymore, and probably the bug could be closed now.
Some investigation may be necessary to find if some QAM tests still needs it.
Always latest result in this scenario: latest
Updated by JRivrain over 5 years ago
- Subject changed from [functional[y] Soft failure for "Console messages writes over any tty" seems irrelevant in this case. to [functional][y] Soft failure for "Console messages writes over any tty" seems irrelevant in this case.
Updated by riafarov over 5 years ago
- Assignee set to JRivrain
- Target version set to future
I doubt that it's irrelevant. We just applied tons of workarounds. So in case you feel fancy, you could try following: remove workarounds, trigger 1000 runs and see if any of the issues appear.
As there is not much happening on the bug, we could have removed soft-failure, but then it's not clear why we set dmesg log level to lower value.
So, whenever you have a moment, please, take a look. As of now I don't see that as priority (lost my motivation as bug is 2 years old and I doubt that we have a solution for it.
Updated by JRivrain over 5 years ago
- Status changed from New to In Progress
1000 VRs and not even one failure related to this bug.
Scenarios tested ( 250 runs for each case ):
sle 12, console/snapper_cleanup.pm: http://waaa-amazing.suse.cz/tests/582#next_previous
sle 12, ncurses test suite: http://waaa-amazing.suse.cz/tests/583#next_previous
sle 15, ncurses test suite: http://waaa-amazing.suse.cz/tests/1325#next_previous
sle 15, console/snapper_cleanup.pm: http://waaa-amazing.suse.cz/tests/1085#next_previous
I will also do a bunch of VRs on other architectures, just to be sure.
Updated by JRivrain over 5 years ago
- Status changed from In Progress to Feedback
Updated by JRivrain over 5 years ago
So, we found a case where this case was still happening: https://openqa.suse.de/tests/3039960#step/yast2_clone_system/7.
However,
- This does not concern directly this PR, that test would have failed anyway regardless of my changes.
- The problem with the code I removed, was that it was reporting the issue when it was not actually happening, but every time the tests were running.
- bsc#1011815 cannot be reproduced anymore for x86_64, neither by 1000 openqa test runs, nor by writing something to kernel logs, nor by doing as in comment 34
My assumption is that it is fixed for x86_64, but not for aarch64.
Updated by JRivrain over 5 years ago
- Status changed from Feedback to Closed
It looks like 3 months after the PR was merged, it did not cause trouble. The bug remains somehow valid however because it seems to still happen on aarch64.