During the “booting” of my installation of the 64-bit, openSUSE, Leap-15.3, Linux operating system within Oracle VM (Virtual Machine) VirtualBox 6.1.32, r149290 with a verbose display of messages I received the message “Failed to start Load AppArmor profiles” in red-colored text. What should I do to eliminate the appearance of that message in a good way during my “booting” into Leap 15.3?
More details are always helpful.
Try adding here the, the actual error(s) and the output of “sudo systemctl status apparmor -l” and “sudo aa-status” Using Code Tags Around Your Paste.
For me running Thumbleweed the profiles are located in /etc:
$ ls /etc/apparmor.d/
**abi** nvidia_modprobe usr.lib.dovecot.config usr.lib.dovecot.managesieve-login usr.sbin.identd
**abstractions** php-fpm usr.lib.dovecot.deliver usr.lib.dovecot.pop3 usr.sbin.mdnsd
**apache2.d** samba-bgqd usr.lib.dovecot.dict usr.lib.dovecot.pop3-login usr.sbin.nmbd
bin.ping sbin.klogd usr.lib.dovecot.dovecot-auth usr.lib.dovecot.script-login usr.sbin.nscd
cache sbin.syslogd usr.lib.dovecot.dovecot-lda usr.lib.dovecot.ssl-params usr.sbin.ntpd
cache.d sbin.syslog-ng usr.lib.dovecot.imap usr.lib.dovecot.stats usr.sbin.smbd
**disable ****tunables** usr.lib.dovecot.imap-login usr.sbin.apache2 usr.sbin.smbldap-useradd
ghostscript usr.bin.lessopen.sh usr.lib.dovecot.lmtp usr.sbin.avahi-daemon usr.sbin.traceroute
**local** usr.lib.dovecot.anvil usr.lib.dovecot.log usr.sbin.dnsmasq usr.sbin.winbindd
lsb_release usr.lib.dovecot.auth usr.lib.dovecot.managesieve usr.sbin.dovecot usr.share.git-web.gitweb.cgi
$ ls /etc/apparmor
easyprof.conf logprof.conf notify.conf parser.conf severity.db
Thank you, poster marel, for kindly taking some time to respond to my posting. During the “booting” into Leap 15.3 after “Failed to start Load AppArmor profiles” I noticed a suggestion to enter the command
systemctl status apparmor.service
. So in Leap 15.3 I decided to enter that command as a “root” user to see the resulting output. Below is the entry of that command and its result. (My Leap-15.3 regular user name is “newbie”.)
linux-hdi0:/home/newbie # systemctl status apparmor.service
● apparmor.service - Load AppArmor profiles
Loaded: loaded (/usr/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2022-02-05 14:50:06 EST; 7min ago
Process: 365 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, status=1/FAILURE)
Main PID: 365 (code=exited, status=1/FAILURE)
Feb 05 14:50:01 linux-hdi0 apparmor.systemd[365]: Restarting AppArmor
Feb 05 14:50:01 linux-hdi0 apparmor.systemd[365]: Reloading AppArmor profiles
Feb 05 14:50:01 linux-hdi0 apparmor.systemd[439]: Found reference to variable run, but is never declared
Feb 05 14:50:01 linux-hdi0 apparmor.systemd[365]: Error: /etc/apparmor.d/samba-bgqd failed to load
Feb 05 14:50:06 linux-hdi0 systemd[1]: apparmor.service: Main process exited, code=exited, status=1/FAILURE
Feb 05 14:50:06 linux-hdi0 systemd[1]: apparmor.service: Failed with result 'exit-code'.
Feb 05 14:50:06 linux-hdi0 systemd[1]: Failed to start Load AppArmor profiles.
linux-hdi0:/home/newbie #
Partially overlapping my own situation I found situations posted in an arch Linux operating system on https://bbs.archlinux.org/viewtopic.php?id=197250 and in a Solus operating system, which appears to be based on a Linux operating system, on https://discuss.getsol.us/d/6600-still-got-that-nagging-apparmor-problem on the Internet.
Following your advice:
linux-hdi0:/home/newbie # sudo systemctl status apparmor -l
● apparmor.service - Load AppArmor profiles
Loaded: loaded (/usr/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2022-02-05 14:50:06 EST; 40min ago
Process: 365 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, status=1/FAILURE)
Main PID: 365 (code=exited, status=1/FAILURE)
Feb 05 14:50:01 linux-hdi0 apparmor.systemd[365]: Restarting AppArmor
Feb 05 14:50:01 linux-hdi0 apparmor.systemd[365]: Reloading AppArmor profiles
Feb 05 14:50:01 linux-hdi0 apparmor.systemd[439]: Found reference to variable run, but is never declared
Feb 05 14:50:01 linux-hdi0 apparmor.systemd[365]: Error: /etc/apparmor.d/samba-bgqd failed to load
Feb 05 14:50:06 linux-hdi0 systemd[1]: apparmor.service: Main process exited, code=exited, status=1/FAILURE
Feb 05 14:50:06 linux-hdi0 systemd[1]: apparmor.service: Failed with result 'exit-code'.
Feb 05 14:50:06 linux-hdi0 systemd[1]: Failed to start Load AppArmor profiles.
linux-hdi0:/home/newbie #
linux-hdi0:/home/newbie # sudo aa-status
apparmor module is loaded.
50 profiles are loaded.
50 profiles are in enforce mode.
/usr/bin/lessopen.sh
/usr/lib/apache2/mpm-prefork/apache2
/usr/lib/apache2/mpm-prefork/apache2//DEFAULT_URI
/usr/lib/apache2/mpm-prefork/apache2//HANDLING_UNTRUSTED_INPUT
/usr/lib/apache2/mpm-prefork/apache2//phpsysinfo
/usr/lib/colord
/usr/lib/dovecot/anvil
/usr/lib/dovecot/auth
/usr/lib/dovecot/config
/usr/lib/dovecot/deliver
/usr/lib/dovecot/dict
/usr/lib/dovecot/dovecot-auth
/usr/lib/dovecot/dovecot-lda
/usr/lib/dovecot/dovecot-lda//sendmail
/usr/lib/dovecot/imap
/usr/lib/dovecot/imap-login
/usr/lib/dovecot/lmtp
/usr/lib/dovecot/log
/usr/lib/dovecot/managesieve
/usr/lib/dovecot/managesieve-login
/usr/lib/dovecot/pop3
/usr/lib/dovecot/pop3-login
/usr/lib/dovecot/ssl-params
/usr/lib/dovecot/stats
/usr/sbin/dnsmasq
/usr/sbin/dnsmasq//libvirt_leaseshelper
apache2
apache2//DEFAULT_URI
apache2//HANDLING_UNTRUSTED_INPUT
apache2//phpsysinfo
avahi-daemon
dovecot
dovecot-script-login
identd
klogd
lsb_release
mdnsd
nmbd
nscd
ntpd
nvidia_modprobe
nvidia_modprobe//kmod
ping
smbd
smbldap-useradd
smbldap-useradd///etc/init.d/nscd
syslog-ng
syslogd
traceroute
winbindd
0 profiles are in complain mode.
4 processes have profiles defined.
4 processes are in enforce mode.
/usr/sbin/avahi-daemon (993) avahi-daemon
/usr/sbin/nscd (1038) nscd
/usr/sbin/ntpd (1294) ntpd
/usr/sbin/ntpd (1315) ntpd
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
linux-hdi0:/home/newbie #
linux-hdi0:/home/newbie # ls /etc/apparmor.d/
abstractions sbin.syslog-ng usr.lib.dovecot.imap usr.sbin.avahi-daemon
apache2.d tunables usr.lib.dovecot.imap-login usr.sbin.dnsmasq
bin.ping usr.bin.lessopen.sh usr.lib.dovecot.lmtp usr.sbin.dovecot
cache usr.lib.apache2.mpm-prefork.apache2 usr.lib.dovecot.log usr.sbin.identd
cache.d usr.lib.colord usr.lib.dovecot.managesieve usr.sbin.mdnsd
disable usr.lib.dovecot.anvil usr.lib.dovecot.managesieve-login usr.sbin.nmbd
local usr.lib.dovecot.auth usr.lib.dovecot.pop3 usr.sbin.nscd
lsb_release usr.lib.dovecot.config usr.lib.dovecot.pop3-login usr.sbin.ntpd
nvidia_modprobe usr.lib.dovecot.deliver usr.lib.dovecot.script-login usr.sbin.smbd
samba-bgqd usr.lib.dovecot.dict usr.lib.dovecot.ssl-params usr.sbin.smbldap-useradd
sbin.klogd usr.lib.dovecot.dovecot-auth usr.lib.dovecot.stats usr.sbin.traceroute
sbin.syslogd usr.lib.dovecot.dovecot-lda usr.sbin.apache2 usr.sbin.winbindd
linux-hdi0:/home/newbie #
linux-hdi0:/home/newbie # ls /etc/apparmor
easyprof.conf logprof.conf notify.conf parser.conf severity.db subdomain.conf
linux-hdi0:/home/newbie #
In just a portion of a very large, 423,735-line file /var/log/boot.log file:
#[0;32m OK #[0m] Started #[0;1;39mJournal Service#[0m.
Starting #[0;1;39mFlush Journal to Persistent Storage#[0m...
[#[0;32m OK #[0m] Finished #[0;1;39mFlush Journal to Persistent Storage#[0m.
[#[0;32m OK #[0m] Started #[0;1;39mRule-based Manager for Device Events and Files#[0m.
[#[0;1;31mFAILED#[0m] Failed to start #[0;1;39mLoad AppArmor profiles#[0m.
See 'systemctl status apparmor.service' for details.
[#[0;32m OK #[0m] Finished #[0;1;39mMonitoring of LVM… dmeventd or progress polling#[0m.
[#[0;32m OK #[0m] Reached target #[0;1;39mLocal File Systems (Pre)#[0m.
Starting #[0;1;39mFile System Check…K_VB5ea4bc46-2f2e8201-part3#[0m...
Starting #[0;1;39mShow Plymouth Boot Screen#[0m...
[#[0;32m OK #[0m] Started #[0;1;39mShow Plymouth Boot Screen#[0m.
[#[0;32m OK #[0m] Finished #0;1;39mFile System Check…ISK_VB5ea4bc46-2f2e8201-part3#0m.
For my installed Linux kernel version:
linux-hdi0:/home/newbie # uname -a
Linux linux-hdi0.site 5.3.18-150300.59.43-default #1 SMP Sun Jan 23 19:27:23 UTC 2022 (c76af22) x86_64 x86_64 x86_64 GNU/Linux
linux-hdi0:/home/newbie #
As a “root” user I entered
linux-hdi0:/home/newbie # zypper info apparmor
Loading repository data...
Reading installed packages...
package 'apparmor' not found.
Information for pattern apparmor:
---------------------------------
Repository : Main Repository
Name : apparmor
Version : 20200505-lp153.6.1
Arch : x86_64
Vendor : openSUSE
Installed : Yes
Visible to User : Yes
Summary : AppArmor
Description :
AppArmor is an application security framework that provides mandatory access control for programs. It protects from
exploitation of software flaws and compromised systems. It offers an advanced tool set that automates the
development of per-program application security without requiring additional knowledge.
Contents :
S | Name | Type | Dependency
---+----------------------------+---------+------------
i+ | apparmor-abstractions | package | Required
i+ | apparmor-parser | package | Required
i+ | apparmor-profiles | package | Required
i+ | audit | package | Required
i+ | patterns-base-apparmor | package | Required
i+ | patterns-base-minimal_base | package | Required
i+ | apparmor-docs | package | Recommended
i+ | apparmor-utils | package | Recommended
i+ | yast2-apparmor | package | Recommended
Information for srcpackage apparmor:
------------------------------------
Repository : Update repository with updates from SUSE Linux Enterprise 15
Name : apparmor
Version : 2.13.6-150300.3.11.2
Arch : noarch
Vendor : SUSE LLC <https://www.suse.com/>
Summary : AppArmor userlevel parser utility
Description :
The AppArmor Parser is a userlevel program that is used to load in
program profiles to the AppArmor Security kernel module.
This package is part of a suite of tools that used to be named
SubDomain.
Builds binary package :
S | Name | Version
--+-----------------------+---------------------
| apache2-mod_apparmor | 2.13.6-150300.3.11.2
i | apparmor-abstractions | 2.13.6-150300.3.11.2
i | apparmor-docs | 2.13.6-150300.3.11.2
i | apparmor-parser | 2.13.6-150300.3.11.2
i | apparmor-parser-lang | 2.13.6-150300.3.11.2
i | apparmor-profiles | 2.13.6-150300.3.11.2
i | apparmor-utils | 2.13.6-150300.3.11.2
i | apparmor-utils-lang | 2.13.6-150300.3.11.2
| pam_apparmor | 2.13.6-150300.3.11.2
| pam_apparmor-32bit | 2.13.6-150300.3.11.2
i | perl-apparmor | 2.13.6-150300.3.11.2
i | python3-apparmor | 2.13.6-150300.3.11.2
| ruby-apparmor | 2.13.6-150300.3.11.2
linux-hdi0:/home/newbie #
I guess that “i”s at the beginnings of some above lines indicate software packages which are installed in my Leap-15.3 installation.
The variable “run” is defined in file /etc/apparmor.d/tunables/run which is included from /etc/apparmor.d/tunables/global which is included from /etc/apparmor.d/samba-bgqd. Please post full content of all three files.
. Builds binary package : S | Name | Version --+-----------------------+--------------------- | apache2-mod_apparmor | 2.13.6-150300.3.11.2 i | apparmor-abstractions | 2.13.6-150300.3.11.2 i | apparmor-docs | 2.13.6-150300.3.11.2 i | apparmor-parser | 2.13.6-150300.3.11.2 i | apparmor-parser-lang | 2.13.6-150300.3.11.2 i | apparmor-profiles | 2.13.6-150300.3.11.2 i | apparmor-utils | 2.13.6-150300.3.11.2 i | apparmor-utils-lang | 2.13.6-150300.3.11.2 | pam_apparmor | 2.13.6-150300.3.11.2 | pam_apparmor-32bit | 2.13.6-150300.3.11.2 i | perl-apparmor | 2.13.6-150300.3.11.2 i | python3-apparmor | 2.13.6-150300.3.11.2 | ruby-apparmor | 2.13.6-150300.3.11.2
Yes, these are the latest versions. Try as root “rpm -Va apparmor-*”. Do you get any error?
Thank you, poster avidjaar, for kindly taking some time to respond to my postings here. Fulfilling your requests, the contents of my file /etc/apparmor.d/tunables/run are
@{run}=/run/ /var/run/
; the contents of my file /etc/apparmor.d/tunables/global are
# ------------------------------------------------------------------
#
# Copyright (C) 2006-2009 Novell/SUSE
# Copyright (C) 2010-2014 Canonical Ltd.
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of version 2 of the GNU General Public
# License published by the Free Software Foundation.
#
# ------------------------------------------------------------------
# All the tunables definitions that should be available to every profile
# should be included here
#include <tunables/home>
#include <tunables/multiarch>
#include <tunables/proc>
#include <tunables/alias>
#include <tunables/kernelvars>
#include <tunables/xdg-user-dirs>
#include <tunables/share>
; and the contents of my file /etc/apparmor.d/samba-bgqd are
#include <tunables/global>
profile samba-bgqd /usr/lib*/samba/samba-bgqd {
#include <abstractions/base>
#include <abstractions/cups-client>
#include <abstractions/nameservice>
#include <abstractions/samba>
signal receive set=term peer=smbd,
@{PROC}/sys/kernel/core_pattern r,
@{run}/samba/samba-bgqd.pid wk,
/usr/lib*/samba/samba-bgqd m,
# Site-specific additions and overrides. See local/README for details.
#include <local/samba-bgqd>
}
. A puzzle for me is that among the files in /etc/apparmor.d one group of them was indented in my installation of the Konqueror file manager; and another group of files, including samba-bgqd, in that directory was not indented in that listing.
Concerning the command
rpm -Va apparmor-\*
from https://linux.die.net/man/8/rpm I learned that the “V” in that command stands for “Verify”. Is the purpose of this Verify “switch” in the command
rpm -Va apparmor-\*
to verify that the contents of the downloaded files match the contents of the corresponding files available for their downloading from the Internet, in other words to check for errors in the downloading process or for corruption in the apparmor-* files? Why is it necessary to include the “\” in “rpm -Va apparmor-*”? In other words why wouldn’t
rpm -Va apparmor-*
be an acceptable command?
With my entry of the command
rpm -Va apparmor-\*
as a “root” user I obtained
linux-hdi0:/home/newbie # rpm -Va apparmor-\*
S.5....T. c /etc/apparmor.d/abstractions/X
S.5....T. c /etc/apparmor.d/abstractions/base
S.5....T. c /etc/apparmor.d/abstractions/enchant
..5....T. c /etc/apparmor.d/abstractions/fonts
S.5....T. c /etc/apparmor.d/abstractions/gnome
S.5....T. c /etc/apparmor.d/abstractions/mesa
S.5....T. c /etc/apparmor.d/abstractions/nameservice
S.5....T. c /etc/apparmor.d/abstractions/postfix-common
S.5....T. c /etc/apparmor.d/abstractions/samba
S.5....T. c /etc/apparmor.d/abstractions/vulkan
S.5....T. c /etc/apparmor.d/tunables/global
linux-hdi0:/home/newbie #
So I was not notified of an error right after entering the command
rpm -Va apparmor-\*
.
On https://bbs.archlinux.org/viewtopic.php?id=197250 on the Internet in an Arch Linux operating system there were syntax errors reported in syslog-ng. Do the following contents of my installed file sbin.syslog-ng in the directory /etc/apparmor.d look okay to an expert on this file?
# ------------------------------------------------------------------
#
# Copyright (C) 2006-2009 Novell/SUSE
# Copyright (C) 2006 Christian Boltz
# Copyright (C) 2010 Canonical Ltd.
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of version 2 of the GNU General Public
# License published by the Free Software Foundation.
#
# ------------------------------------------------------------------
#include <tunables/global>
#define this to be where syslog-ng is chrooted
@{CHROOT_BASE}=""
profile syslog-ng /{usr/,}{bin,sbin}/syslog-ng {
#include <abstractions/base>
#include <abstractions/consoles>
#include <abstractions/nameservice>
#include <abstractions/mysql>
#include <abstractions/openssl>
#include <abstractions/python>
capability chown,
capability dac_override,
capability dac_read_search,
capability fsetid,
capability fowner,
capability sys_tty_config,
capability sys_resource,
capability syslog,
unix (receive) type=dgram,
unix (receive) type=stream,
/dev/log w,
/dev/syslog w,
/dev/tty10 rw,
/dev/xconsole rw,
/dev/kmsg r,
/etc/machine-id r,
/etc/syslog-ng/* r,
/etc/syslog-ng/conf.d/ r,
/etc/syslog-ng/conf.d/* r,
@{PROC}/kmsg r,
/etc/hosts.deny r,
/etc/hosts.allow r,
/{usr/,}{bin,sbin}/syslog-ng mr,
@{sys}/devices/system/cpu/online r,
/usr/share/syslog-ng/** r,
/var/lib/syslog-ng/syslog-ng-?????.qf rw,
# chrooted applications
@{CHROOT_BASE}/var/lib/*/dev/log w,
@{CHROOT_BASE}/var/lib/syslog-ng/syslog-ng.persist* rw,
@{CHROOT_BASE}/var/log/** w,
@{CHROOT_BASE}/{,var/}run/syslog-ng.pid krw,
@{CHROOT_BASE}/{,var/}run/syslog-ng.ctl rw,
/{var,var/run,run}/log/journal/ r,
/{var,var/run,run}/log/journal/*/ r,
/{var,var/run,run}/log/journal/*/*.journal r,
/{var/,}run/syslog-ng.ctl a,
/{var/,}run/syslog-ng/additional-log-sockets.conf r,
# Site-specific additions and overrides. See local/README for details.
#include <local/sbin.syslog-ng>
}
Sorry, I misspelled Arch Linux as arch Linux earlier in this “thread” of postings.
Is it really full content? It is not obvious. You did not indicate where file ends.
Assuming it is full file it is missing necessary include which is confirmed by
linux-hdi0:/home/newbie # rpm -Va apparmor-\* S.5....T. c /etc/apparmor.d/abstractions/X S.5....T. c /etc/apparmor.d/abstractions/base S.5....T. c /etc/apparmor.d/abstractions/enchant ..5....T. c /etc/apparmor.d/abstractions/fonts S.5....T. c /etc/apparmor.d/abstractions/gnome S.5....T. c /etc/apparmor.d/abstractions/mesa S.5....T. c /etc/apparmor.d/abstractions/nameservice S.5....T. c /etc/apparmor.d/abstractions/postfix-common S.5....T. c /etc/apparmor.d/abstractions/samba S.5....T. c /etc/apparmor.d/abstractions/vulkan **S.5....T. c /etc/apparmor.d/tunables/global** linux-hdi0:/home/newbie #
The file on disk is different from file in RPM package. You also have a lot of other files that are different from files delivered by openSUSE package. Did you modify all those files intentionally?
Thank you again, poster avidjaar, for kindly taking some time to respond to my postings in this “thread” of postings. Yes, the contents of the file “global” in the directory /etc/apparmor.d/tunables, which I posted in posting number five in this “thread” of postings, were the entire contents of that file, which was last modified on 7/23/2020, meaning July 23, 2020. You kindly provided me with the following command,
rpm -Va apparmor-\*
which together with my ensuing output from it and the line of code
#include <tunables/global>
in the file /etc/apparmor.d/samba-bgqd led me to performing a test, or experiment, which led to determining the cause of my major trouble in this “thread” of postings! That is you wrote, “Assuming it” (/etc/apparmor.d/tunables/global) “is full file it is missing necessary include which is confirmed by…” And thereafter was a copy of my output from the command
rpm -Va apparmor-\*
, which included
S.5....T. c /etc/apparmor.d/tunables/global
. In retrospect that line may have indicated that AppArmor was using that “global” file instead of the file “global.rpmnew”, which was last modified on 1/27/2022, meaning January 27, 2022, was located in that same directory /etc/apparmor.d/tunables in my Leap-15.3 installation, and has the following contents:
# ------------------------------------------------------------------
#
# Copyright (C) 2006-2009 Novell/SUSE
# Copyright (C) 2010-2014 Canonical Ltd.
#
# This program is free software; you can redistribute it and/or
# modify it under the terms of version 2 of the GNU General Public
# License published by the Free Software Foundation.
#
# ------------------------------------------------------------------
# All the tunables definitions that should be available to every profile
# should be included here
#include <tunables/home>
#include <tunables/multiarch>
#include <tunables/proc>
#include <tunables/alias>
#include <tunables/kernelvars>
#include <tunables/xdg-user-dirs>
#include <tunables/share>
#include <tunables/run>
. According to https://www.linux.com/news/dealing-rpmnew-and-rpmsave-files/ on the Internet, “An .rpmnew file contains the new default configuration file and leaves your original configuration file untouched.” So in my case I suppose that might have meant that the function of “global.rpmnew” would replace the function of the file “global” and leave that file “global” undisturbed and maybe functionally dormant. (However, before making the computer software changes and given the results I subsequently report here, I wonder if the files global and global.rpmnew in the directory /etc/apparmor.d/tunables, which, as far as execution is concerned, those two files functionally contain nothing but “include”-containing lines of code, could be called configuration files or not.) But supposing a possible function contrary to that ideal function in my situation, including even that “global” might not be considered a configuration file, since the file /etc/apparmor.d/samba-bgqd contains the statement
#include <tunables/global>
, I performed an experiment, or test, of changing “global” to “global.rpmnew” in the above include statement in the file /etc/apparmor.d/samba-bgqd to see if, as a result of that change, “Failed to start Load AppArmor profiles” would not appear during my “booting” into Leap 15.3. And afterward gratefully the result was that that error message in fact did not appear while “booting” into my Leap-15.3 installation!
So that gratefully was a solution to my major problem! Thank you, poster avidjaar, for your part in it! Although that made a working state for AppArmor computer software in my Leap-15.3 installation, in the future some AppArmor computer software could be updated in that installation. So that working state might not be a good state for such future AppArmor updates. It seems reasonable to me that a future update of the file /etc/apparmor.d/samba-bgqd might more likely contain
#include <tunables/global>
than
#include <tunables/global.rpmnew>
in it, unless there would be that type of sophisticated adjustment in updating and automatically configuring such computer software in a particular Leap-15.3 installation. So with the possibility of future updating of AppArmor computer software in mind, I made the following changes:
- In the file /etc/apparmor.d/samba-bgqd I restored the line of code
#include <tunables/global.rpmnew>
back to
#include <tunables/global>
.
2) Although perhaps unnecessary, I copied the files “global”, which was last modified on July 23, 2020, and “global.rpmnew”, which was last modified on January 27, 2022, to my Lightweight, X Windows System, version 11 (X11) Desktop Environment (LXDE) “desktop.” Such desktop storage of those file copies could be a temporary measure.
-
I deleted the file “global” in the directory /etc/apparmor.d/tunables.
-
I renamed the file “global.rpmnew” to “global” in that same directory /etc/apparmor.d/tunables.
-
I tested this arrangement with a “rebooting” into my Leap-15.3 installation and gratefully still found that the message “Failed to start Load AppArmor profiles” did not appear during such “booting” into my Leap-15.3 installation!
Really I don’t consider myself an expert on the AppArmor computer software. This outcome, for which I am grateful, was a matter of inspecting your writing, poster avidjaar, and my output from a command you suggested, and then thinking and performing a test, or experiment, to see if something was a cause or not of my major problem here.
Concerning the dates of last modification of July 23, 2020 for my file “global”, before my above “fix” of things, and January 27, 2022 for my file “global.rpmnew”, July 23, 2020 was the date that I gratefully could successfully upgrade my Leap-15.1 installation to my Leap-15.2 installation. In most instances I performed upgrades of openSUSE or OpenSUSE installations rather than made installations of openSUSE or OpenSUSE on a blank virtual hard-disk drive, which in computer jargon is a so-called “clean” installation. I need to keep in mind that the date of last modification of a file would probably usually be earlier than the date that I installed a file in a Leap installation of mine. Nevertheless I suppose that a file last modified 10-11 months before I upgraded Leap 15.2 to Leap 15.3 would more likely have come from Leap 15.2 or Leap 15.1 than from Leap 15.3. So I suppose that the July 23, 2020 version of that file “global” might have been a remnant from my Leap-15.2 or Leap-15.1 installation such that it remained on my virtual computer’s virtual hard-disk drive when I upgraded my Leap-15.2 installation to Leap 15.3. Assuming so, in retrospect now I suppose that that old file “global” should have been removed after my upgrading from Leap 15.2 to Leap 15.3, if not earlier in time. I suppose that that old file “global” was apparently likely not automatically replaced by a file of the same name during one of my past Leap upgradings. When upgrading from Leap-15.2 to Leap 15.3 as a “root” user I should have included the command
zypper dist-upgrade
(with “dist-upgrade” standing for “distribution upgrade”), from section 2.1.4 entitled “Updating software with Zypper” on https://doc.opensuse.org/documentation/leap/reference/html/book-reference/cha-sw-cl.html on the Internet. Perhaps another lesson here is that a file one, like “samba-bgqd” here, which makes use of another file two, like “global” here, may not have been designed to replace the function of the older file two with a new version of it having the new name with .rpmnew appended to the older name, like global.rpmnew here, of the older version of that file two, which was global here. So, like I did here, with some saving of files before making changes in a computer-software setup, to protect against the possibility mentioned in my previous sentence, perhaps it could be appropriate to delete an old file after a newer file of the same initial name, but with .rpmnew appended to its name appears, and then to excise .rpmnew from the newer file’s name.
From Yet another Software Tool 2’s (YaST2’S) Software Management I report from which online software repository or repositories I obtained some presently installed apparmor software packages in my Leap-15.3 installation. (I installed some updates to my Leap-15.3 installation on February 7, 2022, including the new Linux kernel-default-5.3.18-150300.59.46.1.x86_64. But none of those updated software packages had apparmor in their names.) The vendor for my installed software package patterns-base-apparmor is openSUSE. For all of my other Leap-15.3 installed software packages with apparmor in their names the vendor is SUSE (Software Und System Entwicklung, German for Software and Systems Development, according to https://en.wikipedia.org/wiki/SUSE) LLC (Limited Liability Company, according to https://www.nolo.com/legal-encyclopedia/what-is-a-limited-liability-company.html on the Internet). So I presently don’t have any software packages in my Leap-15.3 installation with apparmor in their names from the vendor Packman. In fact, in checking on http://packman.links2linux.org/search?scope=name&q=apparmor on the Internet, assuming using the search edit control there will report any software package with apparmor anywhere in its name, just like it does for vlc, I found that a Packman repository very likely does not supply any software package with apparmor in its name.
On February 8, 2022 here was the list of my installed software packages in my Leap-15.3 installation with apparmor anywhere in their names:
apparmor-abstractions
apparmor-docs
apparmor-parser
apparmor-parser-lang
apparmor-profiles
apparmor-utils
apparmor-utils-lang
libapparmor1
patterns-base-apparmor
perl-apparmor
python3-apparmor
yast2-apparmor
.
I noticed that the versions of all of the 12 above software packages had part of the then-installed Linux kernel version in them, except for apparmor-base-patterns, version 20200505-lp153.6.1. The net results of my changes numbered one through five above were in the directory /etc/apparmor.d/tunables the deletion of the file “global”, which was last modified on July 23, 2020, and the renaming of the file global.rpmnew in that same directory to global. In the file /etc/apparmor.d/samba-bgqd the changing of the line of code reading
#include <tunables/global>
to
#include <tunables/global.rpmnew>
and then back to
#include <tunables/global>
resulted in no net change in that file. I don’t think I have ever made any other changes within any other AppArmor files in any openSUSE or OpenSUSE, if AppArmor even existed in an old, OpenSUSE installation of mine. It is likely that I have more software packages installed in my Leap-15.3 installation than I need to be installed in it.