action #45149
closed
[sle][functional][y][rt][bsc#1119412] validate booted kernel (or workaround for kernel selection)
Added by mloviska over 5 years ago.
Updated about 5 years ago.
Target version:
SUSE QA - Milestone 22
Description
Observation¶
openQA test in scenario sle-15-SP1-Installer-DVD-x86_64-rt-product@64bit has false positive results, because test does not evaluate what kind of kernel has been booted
grub_test
I would personally prefer to fail test suite as long as SUT does not boot rt kernel by default.
Expected result¶
Linux zoidberg 4.12.14-7-rt #1 SMP PREEMPT RT Wed Oct 24 07:40:06 UTC 2018 (f4a4855) x86_64 x86_64 x86_64 GNU/Linux
Acceptance criteria¶
- Instructions from Release Notes are validated
- There is a test module which enables RT kernel and validates it
Suggestions¶
- Parent task set to #43199
- Subject changed from [sle][functional][y][RT][bsc#1119412] validate booted kernel to [sle][functional][y][rt][bsc#1119412] validate booted kernel
- Category changed from Bugs in existing tests to New test
- Target version set to Milestone 22
Good that you have this reported. I will change category to "New test" though as this is what we commonly use according to https://progress.opensuse.org/projects/openqatests/wiki#ticket-workflow do describe any "extension of test coverage". "Bugs in existing tests" means basically: "It fails now but worked in before" which might be misleading to some because the test actually is "green" :)
- Status changed from New to Blocked
- Assignee set to okurz
waiting for clarification (question in bug)
okurz wrote:
Good that you have this reported. I will change category to "New test" though as this is what we commonly use according to https://progress.opensuse.org/projects/openqatests/wiki#ticket-workflow do describe any "extension of test coverage". "Bugs in existing tests" means basically: "It fails now but worked in before" which might be misleading to some because the test actually is "green" :)
It worked in the past because RT planned to be released 3 months later after SLES FCS. At that time, RT kernel version higher than the SLES GA version and thus it can always boot to RT kernel.
For SLE15, RT aligned the release cycle with SLES, thus RT kernel version always behind SLES. It is due to RT accept the commit that has been stable in SLES and not update the kernel as frequent as SLES.
The current workaround is to mention this in RT Release Notes
Jeffreycheung wrote:
The current workaround is to mention this in RT Release Notes
As long as we are talking about workarounds, do we plan to ship adequate grub configs for RT in the future ? So the system boots RT kernel without any user intervention.
mloviska wrote:
Jeffreycheung wrote:
The current workaround is to mention this in RT Release Notes
As long as we are talking about workarounds, do we plan to ship adequate grub configs for RT in the future ? So the system boots RT kernel without any user intervention.
Well, I left comment in bug that this would be WONFIX in RT15 SP1, I will try to fix it in RT15 SP2.
Jeffreycheung wrote:
mloviska wrote:
Jeffreycheung wrote:
The current workaround is to mention this in RT Release Notes
As long as we are talking about workarounds, do we plan to ship adequate grub configs for RT in the future ? So the system boots RT kernel without any user intervention.
Well, I left comment in bug that this would be WONFIX in RT15 SP1, I will try to fix it in RT15 SP2.
Alright then, so basically this means that we need to come with a workaround in our test suites as long as we want keep rt test modules as they are designed (kmp_modules, rt_is_realtime, rt_peak_pci, rt_preempt_test). I guess that rt_devel_packages can stay as it is in any case.
https://openqa.suse.de/tests/2226731#
- Subject changed from [sle][functional][y][rt][bsc#1119412] validate booted kernel to [sle][functional][y][rt][bsc#1119412] validate booted kernel (or workaround for kernel selection)
- Description updated (diff)
- Due date set to 2019-02-12
- Status changed from Blocked to Workable
- Assignee deleted (
okurz)
Exactly. Rephrased the ticket accordingly to acommodate the workaround.
- Description updated (diff)
- Estimated time set to 5.00 h
- Status changed from Workable to In Progress
- Assignee set to mloviska
- Related to action #45152: [sle][functional][y][rt] extend test coverage of RT installation added
- Status changed from In Progress to Feedback
awesome you could reuse that :)
- Status changed from Feedback to In Progress
I will update openQA test suites
- Status changed from In Progress to Feedback
- Status changed from Feedback to Resolved
Needle issue has been already fixed.
https://openqa.suse.de/tests/2436306#step/kmp_modules/37
Sure we can exclude rt_preempt_test, I just intended to make it visible that it has a problem. Beside that, I have already labeled the job run with a bug report and poo, to make it easier for reviewers.
Also available in: Atom
PDF