Bugzilla – Bug 1211980
[Build 20230602] Internal Error Crash: openQA test fails in yast2_apparmor
Last modified: 2023-09-13 08:20:54 UTC
## Observation No textdomain configured error shown when starting yast apparmor module openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-yast2_ncurses@64bit fails in [yast2_apparmor](https://openqa.opensuse.org/tests/3334529/modules/yast2_apparmor/steps/9) ## Test suite description Maintainer: qsf-y Test for yast2 UI, ncurses only. Running on created gnome images which provides both text console for ncurses UI tests as well as the gnome environment for the GUI tests. riafarov set TIMEOUT_SCALE to improve stability of the test. ## Reproducible Fails since (at least) Build [20221123](https://openqa.opensuse.org/tests/2899189) ## Expected result Last good: [20210718](https://openqa.opensuse.org/tests/1847178) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensuse&flavor=DVD&machine=64bit&test=yast2_ncurses&version=Tumbleweed)
Created attachment 867398 [details] Screenshot: Internal Error
No y2logs at that OpenQA test (why not?), "Details" at that internal error pop-up not opened.
What little we can read in that error pop-up: Caller: .../yast/i18n.rb:59 in '_' Details: No textdomain configured in AppArmor::Profiles, cannot translate "Cannot evaluate current status via..." (Rest cut off)
There are also several more red frames all over that OpenQA test. Something deeper might be wrong in that build.
(In reply to Stefan Hundhammer from comment #4) > There are also several more red frames all over that OpenQA test. Something > deeper might be wrong in that build. The other failed yast modules are the long-known issue https://bugzilla.opensuse.org/show_bug.cgi?id=1207390
Error location in yast/i18n.rb:59: https://github.com/yast/yast-ruby-bindings/blob/master/src/ruby/yast/i18n.rb#L59
Indeed there is no "textdomain" call in the AppArmor::Profiles class, but there is one single '_(...)' call that could cause this error: https://github.com/yast/yast-apparmor/blob/master/src/lib/apparmor/profiles.rb#L87 > Yast::Report.Error(_("Cannot evaluate current status via aa-status.")) The fix to add the textdomain is easy, but then the next problem will probably be WHY that 'aa-status' command failed.
This problem is also present in SLE-15 SP4 and SP5.
(In reply to Stefan Hundhammer from comment #7) > > The fix to add the textdomain is easy, but then the next problem will > probably be WHY that 'aa-status' command failed. the 'why' is likely the update for AppArmor to 3.1.4; if yast parses output of aa-status, there is a chance the output format might have changed sufficiently
PR for SLE-15-SP4: https://github.com/yast/yast-apparmor/pull/59 (a merge to SLE-15-SP5 and master / Factory will follow)
yast uses the command aa-status --pretty-json this seems not to give any output on an apparmor 3.1.4 based TW install aa-status without parameters gives output. @cboltz: does that sound right or possibly a known regression upstream?
This yast-apparmor module is flawed by design: It's only a very thin wrapper around the AppArmor Python scripts. So the JSON output was added years later to make the YaST module at least less dependent on the exact format of the script output. But that of course means that this JSON output needs to remain reasonably stable.
See also https://github.com/yast/yast-apparmor/issues/58 Conclusion: The YaST AppArmor module offers little benefit over using the AppArmor Python scripts directly.
Merge to SLE-15-SP5: https://github.com/yast/yast-apparmor/pull/59 Merge to master / Factory: https://github.com/yast/yast-apparmor/pull/61 SR to IBS SLE-15-SP4: https://build.suse.de/request/show/300584 SR to IBS SLE-15-SP5: https://build.suse.de/request/show/300587
Maintenance team, this could become maintenance updates for SLE-15-SP4 / SP5, but since this is only a very rare problem, waiting for the QU is sufficient AFAICS. There were no customer complaints about this, and I doubt that there will be any: This happens only if the "aa-status" reported an error, and that error could not be parsed.
SR to OBS master / Factory: https://build.opensuse.org/request/show/1090867
So the original part of this is now fixed: The internal error about the missing textdomain.
Reassigning to the apparmor maintainers for the underlying problem: The changed output format of the "aa-status" script (see comment #12).
(In reply to Dominique Leuenberger from comment #12) > yast uses the command > aa-status --pretty-json > > this seems not to give any output on an apparmor 3.1.4 based TW install > > aa-status without parameters gives output. > > @cboltz: does that sound right or possibly a known regression upstream? This is indeed a known upstream bug - aa-status produces invalid json, which also causes --pretty-json to be empty. This was fixed upstream, but it seems the fix didn't make it into 3.1.4 :-( I'll add the patch to the AppArmor package tonight.
Actually the fix made it into 3.1.4, but it was slightly faulty because he 3.1 branch needed a slightly different patch than master. There's "only" a } missing in the json, but that's enough to make the json invalid. SR 1091163 sent.
This is an autogenerated message for OBS integration: This bug (1211980) was mentioned in https://build.opensuse.org/request/show/1091163 Factory / apparmor
Fix confirmed by openQA: https://openqa.opensuse.org/tests/3347767#step/yast2_apparmor/19