action #45149
closed[sle][functional][y][rt][bsc#1119412] validate booted kernel (or workaround for kernel selection)
0%
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¶
- Come up with workaround to select the rt kernel and reboot into that kernel with a soft-fail pointing to bsc#1119412
- There should be already implementation for AC2 called something like 'boot_rt': https://github.com/os-autoinst/os-autoinst-distri-opensuse/commit/c488865ca5940539fee59386dc990ef8a1718082#diff-80d0670c5ecbbfe05d63e3ba2cbbd51b
- Might be blocked by https://bugzilla.suse.com/show_bug.cgi?id=1119412
- There might be something implemented to select kernel in grub for the live-patching
Updated by okurz over 5 years ago
- 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" :)
Updated by okurz over 5 years ago
- Status changed from New to Blocked
- Assignee set to okurz
waiting for clarification (question in bug)
Updated by Jeffreycheung over 5 years ago
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
Updated by mloviska over 5 years ago
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.
Updated by Jeffreycheung over 5 years ago
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.
Updated by mloviska over 5 years ago
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#
Updated by okurz over 5 years ago
- 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.
Updated by riafarov about 5 years ago
- Description updated (diff)
- Estimated time set to 5.00 h
Updated by mloviska about 5 years ago
- Status changed from Workable to In Progress
- Assignee set to mloviska
Updated by mloviska about 5 years ago
- Related to action #45152: [sle][functional][y][rt] extend test coverage of RT installation added
Updated by mloviska about 5 years ago
It was not so hard to resurrect boot_rt_kernel
http://eris.suse.cz/tests/11336#step/boot_rt_kernel/7
Updated by mloviska about 5 years ago
- Status changed from In Progress to Feedback
Updated by mloviska about 5 years ago
- Status changed from Feedback to In Progress
I will update openQA test suites
Updated by mloviska about 5 years ago
- Status changed from In Progress to Feedback
Updated by riafarov about 5 years ago
https://openqa.suse.de/tests/2435812 failed, one test suite failed due to mismatching needle. As for rt_preempt_test we could exclude it as we plan to replace it anyway. WDYT?
Updated by mloviska about 5 years ago
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.