action #101517
closed[qe-core ] systemtap is failing because latest kenel-devel is installed and linked to and stap is using .config to actual kernel which does not exist
0%
Description
Observation¶
Either manually create the link or just do system update and reboot to be on latest kernel.
openQA test in scenario sle-15-SP2-Server-DVD-Incidents-x86_64-mau-extratests2@64bit fails in
systemtap
Test suite description¶
Testsuite maintained at https://gitlab.suse.de/qa-maintenance/qam-openqa-yml. Run console tests against aggregated test repo
Reproducible¶
Fails since (at least) Build :21389:libvirt (current job)
Expected result¶
Last good: :21403:hwdata (or more recent)
Further details¶
Always latest result in this scenario: latest
Updated by dzedro over 2 years ago
I tried to do update, reboot but then on kernel 5.3.18-24.86-default stap -v -e 'probe vfs.read {printf("read performed\n"); exit()}' failed http://dzedro.suse.cz/tests/19771#step/systemtap/84
Pass 1: parsed user script and 476 library scripts using 158864virt/88112res/7168shr/81204data kb, in 200usr/30sys/242real ms.
semantic error: while resolving probe point: identifier 'kernel' at /usr/share/systemtap/tapset/linux/vfs.stp:976:18
source: probe vfs.read = kernel.function("vfs_read")
^
semantic error: missing x86_64 kernel/module debuginfo [man warning::debuginfo] under '/lib/modules/5.3.18-24.86-default/build'
semantic error: resolution failed in alias expansion builder
semantic error: while resolving probe point: identifier 'vfs' at <input>:1:7
source: probe vfs.read {printf("read performed\n"); exit()}
^
semantic error: no match
Pass 2: analyzed script: 0 probes, 0 functions, 0 embeds, 0 globals using 160580virt/90620res/7872shr/82920data kb, in 20usr/110sys/159real ms.
Pass 2: analysis failed. [man error::pass2]
Updated by VANASTASIADIS over 2 years ago
- Status changed from New to Feedback
Tests is fixed and passing all runs in the past days (https://openqa.suse.de/tests/7589356), will watch for a couple of days and close if no new failure occurs
Updated by dzedro over 2 years ago
I would not call it fixed, it can happen again when not latest kernel is booted. It can be rare.
Updated by VANASTASIADIS over 2 years ago
Correct. But depending on how rare it is, it might not be worth to check and reboot the latest kernel each time.
Updated by VANASTASIADIS over 2 years ago
- Status changed from Feedback to In Progress
As agreed, an explicit message when failing due to version differences would be welcome, so I will implement that.
Updated by VANASTASIADIS over 2 years ago
- Status changed from In Progress to Resolved