After updating today this issue has disappeared.  I suspect that this was due to these packages:

isc-dhcp-client
isc-dhcp-common

I haven't verified this but it makes sone sense considering the Apparmor profile that was having the issues.

Closing.

Does not seem possible.

I have not found a way to disable any of those modules.
ie: ima, evm, selinux, etc. 

Whatever methods I found searching on-line did not work.

The main thing to disable would be LSM which seems to orchestrate all of them, including this latest Microsoft contribution to the Linux kernel.
But I have not been able to find a working method.

Right ...  8^°

Debian obviously does, no options to disable or heads-up given.
No surprise there ...

As a result, Devuan is stuck with all this crap.

Best,

A.

Linux kernel with Microsoft security module integration doing all of that.

I would assume one could disable this kernel module either modularly or when building the kernel (ie: Gentoo) if one doesn't want it,  Some distros may integrate and others will scrutinize it heavily (hopefully).

As far as the Apparmor issues:

I have worked on this a bit and have found that after a restart of the apparmor service, the problematic apparmor profile will load properly.  Here is a diff of the before/after of the aa-status showing the module that is started:

→ diff aa-status1 aa-status2
9a10
> 		"/usr/{lib/NetworkManager,libexec}/nm-dhcp-helper":	"enforce",

This matches Debian without needing to restart the service.  I am starting to think it is a timing issue of some sort or Debian restarts the service for you.  Haven't got that far.

If I try to enable this profile manually prior to restarting the service, it will fail complaining of a duplicate profile (sbin.dhclient/usr.sbin.dhclient).

That's about as far as I've gotten thus far.

EDIT: Changed codeblock to quote.

Some fresh news with respect to LSM (Linux Security Modules).
Yes, those modules.
The ones you cannot disable or have any control over.

About eBPF

TL;DR

Absolutely wonderful !!!

Just what we were needing.
Linux kernel with Microsoft security module integration doing all of that.

Check the Phoronix note here.

Best,

A.

... same errors at boot time.

These are not errors.
What you are seeing is information related to EVM being enabled, not errors.

And it seems that there is no easy or documented way to avoid / disable security which (for a desktop system) is probably not needed.
As always, YMMV.

That said, the usual/basic way to check for errors is to look at dmesg in a terminal:

1. in a line by line fashion:
sudo dmesg | more

2. using grep:
sudo dmesg | grep -i "error\|warning\|fail\|segfault\|fatal\|not"

3. sifting by type of message
sudo dmesg --level=alert,crit,err,warn

4. with a real time rolling printout:
sudo dmesg -wH

As this is Linux*, there are probably more ways to get that done as there are other logfies in human readable format which you can look at to get a more detailed idea as to what is going on.
* 8^D !

Best,

A.

I do have the same errors at boot time. I think of disabling it too, isn't it redundant with SELinux ?

[    0.087692] LSM: initializing lsm=lockdown,capability,l
[    0.928368] evm: Initialising EVM extended attributes:
[    0.928370] evm: security.selinux
[    0.928372] evm: security.SMACK64 (disabled)
[    0.928373] evm: security.SMACK64EXEC (disabled)
[    0.928374] evm: security.SMACK64TRANSMUTE (disabled)
[    0.928375] evm: security.SMACK64MMAP (disabled)
[    0.928376] evm: security.apparmor
[    0.928377] evm: security.ima
[    0.928377] evm: security.capability
[    0.928378] evm: HMAC attrs: 0x1

Indeed ...

That is one of the basic characteristics these security features have.
The main one one being that they are both installed and enabled by default / without your consent or knowledge.
Something that should be getting everyone thinking about it and the reasons for it being so.

We are slowly but steadily arriving at the point where booting a computer will require signatures, code or features over which you will have no control or access to.

Unless certain requirements are met, of course.

Best,

A.

It was installed and enabled from the minimal installation iso, otherwise I would not have it either.  It hadn't really given me any issues until the update.

The only reason I don't disable it (yet) is because it is working on Sid (why not here?)  I'll fight with it a bit before disabling completely (or a new update fixes).

I'd file a bug but I don't like Debian or Devuan bug systems, but that's a whole different topic.

EDIT: We were typing at the same time.  I will say that it sounds like a pain to get rid of and/or disable (completely) too.  I haven't looked into that but have seen many people looking for info. on how to do it.

Have a good one.

I disabled apparmor from the first time I saw it has been installed and enabled without my intervention.
So no, I do not have the problem you have.

My way of dealing with it is adding security=none apparmor=0 nmi_watchdog=0 to my kernel command line.

That said, I am not too sure the stanza is quite as effective as I believe it is because early on, my dmesg printout also reveals this:

--- snip ---
[    3.066032] evm: Initialising EVM extended attributes:
[    3.066218] evm: security.selinux    # <-
[    3.066338] evm: security.SMACK64 (disabled)
[    3.066493] evm: security.SMACK64EXEC (disabled)
[    3.066660] evm: security.SMACK64TRANSMUTE (disabled)
[    3.066842] evm: security.SMACK64MMAP (disabled)
[    3.067009] evm: security.apparmor   # <- 
[    3.067132] evm: security.ima        # <-
[    3.067239] evm: security.capability # <-
[    3.067369] evm: HMAC attrs: 0x1
--- snip --- 

As you can see, evm* does not indicate apparmor (and other security features) as being disabled.
ie: adding security=none to the kernel command line should have disabled all that.

* https://linux-ima.sourceforge.net/linux … l-20110907

Edit:

At some point, someone posted a request to disable EVM and IMA.

I have tried (adding lsm=    to the kernel command line but it does not work, at least in the latest Daedalus 6.1.0-33-amd64:

$ grep -o "lsm=.*" /proc/cmdline
lsm=
$ 
$ ls /sys/kernel/security/
evm  ima  integrity  lockdown  lsm       # <- this should read "integrity  lsm"
$ 

Apparently it requires a patch. (?)

Best,

A.

After updating 2 days ago, Apparmor was updated:

(apparmor:amd64 (4.1.0~beta5-6, 4.1.0-1), libapparmor1:amd64 (4.1.0~beta5-6, 4.1.0-1))

Following the update I am getting this error when booting:

Starting: AppArmorLoading AppArmor profiles...Error: Could not load profile /var/cache/apparmor/ac27e0ee.0/usr.sbin.dhclient: File exists
Sun Apr 13 06:20:10 2025: /sbin/apparmor_parser: Unable to add "/usr/lib/NetworkManager/nm-dhcp-client.action".  Profile already exists
Sun Apr 13 06:20:10 2025: At least one profile failed to load ... failed!
Sun Apr 13 06:20:10 2025: failed.

I have disabled the usr.sbin.dhclient profile temporarily and that removes the error upon boot:

ln -s /etc/apparmor.d/usr.sbin.dhclient /etc/apparmor.d/disable

I run a few different distros on my computer, one being Debian-Sid, and it is not producing these errors.  I've compared related apparmor files/configs and they are all identical.

I've checked bug reports and the Apparmor Gitlab and nothing mentioned about this.

Anyone else having this issue (if you haven't disabled apparmor already :) ) and how did you deal with this?  I'm no apparmor expert and mostly let it do it's thing.

Thanks in advance!

EDIT: I forgot to mention that the 'usr.sbin.dhclient' apparmor profile is new with the latest update to apparmor.  There was only 'sbin.dhclient' profile, now there are both.