You are not logged in.
Delete this symlinks not help, apparmor is still loading
/etc/rcS.d/S14apparmor
/etc/systemd/system/sysinit.target.wants/apparmor.service
-=linux its buggy crap that have no antifool protection (c)=-
*linux is free software, and comes with ABSOLUTELY NO WARRANTY*
+ALL YOURS ACTIONS at Linux YOU DO at YOUR OWN RISK!+
Offline
Follow the advice given in my wiki link, here it is again:
# mkdir -p /etc/default/grub.d
# tee /etc/default/grub.d/apparmor.cfg >/dev/null <<<'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=0"'
# update-grub
# reboot
To re-enable AppArmor delete /etc/default/grub.d/apparmor.cfg and run the last two commands again.
Last edited by Head_on_a_Stick (2022-10-30 20:53:18)
Brianna Ghey — Rest In Power
Offline
Hi, I add this to grub, similar to HoaS advice above... if apparmor has been setup before...
security=none apparmor=0
All the best.
pic from 1993, new guitar day.
Offline
issue, still loading with errors
root@devuan:/home/freeartist# dmesg | grep -i apparmor
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-6.0.0-2-amd64 root=UUID=b719b471-3b3a-4eda-8fd4-0e5406bf9906 ro quiet mitigations=off apparmor=0
[ 0.048939] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.0.0-2-amd64 root=UUID=b719b471-3b3a-4eda-8fd4-0e5406bf9906 ro quiet mitigations=off apparmor=0
[ 1.036333] evm: security.apparmor
root@devuan:/home/freeartist# service apparmor status
apparmor module is loaded.
apparmor filesystem is not mounted.
root@devuan:/home/freeartist#
/var/log/boot 1109305/1084K 99%
Sun Oct 30 23:38:31 2022: Starting: AppArmorLoading AppArmor profiles - failed, Do you have the correct privileges? ... .[31mfailed!.[0m
Sun Oct 30 23:38:39 2022: startpar: service(s) returned failure: apparmor ... .[31mfailed!.[0m
-=linux its buggy crap that have no antifool protection (c)=-
*linux is free software, and comes with ABSOLUTELY NO WARRANTY*
+ALL YOURS ACTIONS at Linux YOU DO at YOUR OWN RISK!+
Offline
The kernel & user space components are separate so
# update-rc.d apparmor disable
But see the third answer here. This is a disadvantage of sysvinit compared to systemd.
Brianna Ghey — Rest In Power
Offline
Thanks! So hard and complex)
No errors at booting now.
Buy why i still see this? apparmor module is loaded
root@devuan:/home/freeartist# service apparmor status
apparmor module is loaded.
apparmor filesystem is not mounted.
root@devuan:/home/freeartist#
Last edited by deepforest (2022-10-30 22:55:07)
-=linux its buggy crap that have no antifool protection (c)=-
*linux is free software, and comes with ABSOLUTELY NO WARRANTY*
+ALL YOURS ACTIONS at Linux YOU DO at YOUR OWN RISK!+
Offline
This is a disadvantage of sysvinit compared to systemd
What do you mean with that kind of fud?
The "thrid answer" you allude to is just tiny-brain wiffle-woffle with not much relevance, and I'm pretty sure you know that.
Generally it's a stance in Debian that when you install a package that offers a service, then the installation includes deploying that service, so therefore apparmor is deployed when installed, and a user must un-deploy it; there is no difference depending on init systems here.
Online
If you had bothered to read my link then you would know that there is a difference:
systemctl mask apparmor.service
^ That disables the service and prevents it from ever being started again, even if another service calls it and even if dpkg tries to enable it (as it will do after apparmor is upgraded).
Please tell me how to make sysvinit do that. I am very curious.
Brianna Ghey — Rest In Power
Offline
What about
apt remove apparmor
Guarantied to work with every init system.
Offline
Hello:
What about
apt remove apparmor
Yes.
But then you upgrade the kernel and there it is again.
At least that's what happens to me (Beowulf with backported kernel) when I upgrade the kernel.
Even though my kernel command line clearly says apparmor=0 (!)
What I always do is purge apparmor after the upgrade and before rebooting and make sure the kernel comand line has not been edited.
[root@devuan ~]# apt purge apparmor
If it is now a module, one sure way is to blacklist it.
Check if you have some other stuff called tomoyo, another gift from the Debian devs.
You have to add security=none to the kernel command line to avoid that one.
See these two three posts:
https://dev1galaxy.org/viewtopic.php?id=2630
https://dev1galaxy.org/viewtopic.php?id=4329
https://dev1galaxy.org/viewtopic.php?id=4750
Best,
A.
Last edited by Altoid (2022-11-01 16:14:44)
Offline
Installed by exegnu64_chimaera-20220306, apparmor was not installed initially.
Updated kernel to 5.19, apparmor not installed.
And second, but it's up to you, I disabled rsyslog. From experience, it is needed in order to troubleshoot, and with a normally working system for years, I did not look into it. And the ssd drive will be more whole. It will take, you can always turn it on.
Offline
@Head_on_a_Stick, when you get your systemd pants on you really get fanboi tedious; taking any odd behaviour from the systemd bug collective and cast it as an advantage over something else with sysvinit. Now you seem to want to claim that overriding a service definition is the same as disabling a service?
Yes, sysvinit does not have overriding, and I can see how you might use that to override the service definition in a way that ends up not starting the daemon. Obviously this would compete with any prior overriding, but presumably overriding is actually quite unusual to use for any other purpose? (Otherwise I'd expect someone would have revised the rc script to include it)
I suppose a sysvinit way to achieve a similar override could be to add a premature exit into the startup script. Doing so would likely have the effect (advantage?) that the package installation system would query about that change upon upgrade, and you would then again automatically reconsider whether or not that "override" remains appropriate.
Clearly neither systemd nor sysvinit have a way to block package installation from installing into the boot sequence. I think this is more a result of the Debian principle to deploy services when installing them.
In any case, I'd agree that apt-get purge apparmor is best here, and that it also seems to need a security=none setting (or similar) on the boot command line to make the kernel bypass apparmor kernel code.
Online
so, solution here is remove apparmor?
-=linux its buggy crap that have no antifool protection (c)=-
*linux is free software, and comes with ABSOLUTELY NO WARRANTY*
+ALL YOURS ACTIONS at Linux YOU DO at YOUR OWN RISK!+
Offline
What is wrong with apparmor?
Offline
Hello:
so, solution here is remove apparmor?
What is wrong with apparmor?
Please take a few minutes and read the thread and the content of the links posted.
As I see it, both questions have already been answered.
As always, YMMV.
Best,
A.
Offline
Apparmor may offer sand-boxing for programs but it has cost me performance.
Slow boot times, slow shutdowns, and very slow program launches.
pic from 1993, new guitar day.
Offline
Apparmor may offer sand-boxing for programs but it has cost me performance.
Slow boot times, slow shutdowns, and very slow program launches.
Thanks. May be I should get rid of it too. Nothing is slow, but speed is a matter
Offline
Thank to all for suggestions and replys! Its all bit hard for understanding for not expirenced linuxoids. I need time to think:)
so, is it safe to purge appamor, look for system responce and performance, and bring apparmor back if it will be needed?
Last edited by deepforest (2022-11-01 02:58:49)
-=linux its buggy crap that have no antifool protection (c)=-
*linux is free software, and comes with ABSOLUTELY NO WARRANTY*
+ALL YOURS ACTIONS at Linux YOU DO at YOUR OWN RISK!+
Offline
Clearly neither systemd nor sysvinit have a way to block package installation from installing into the boot sequence
Guess again: https://dev1galaxy.org/viewtopic.php?pid=32768#p32768
See also https://freedesktop.org/wiki/Software/systemd/Preset/.
Brianna Ghey — Rest In Power
Offline
Hah! I'm clearly full of wrong! Not only that, but there is also the possible overrides of insserv that can be used an misused in all sorts of ways.
Online
In any case, I'd agree that apt-get purge apparmor is best here, and that it also seems to need a security=none setting (or similar) on the boot command line to make the kernel bypass apparmor kernel code.
Is it really needed to have boot command security=none ?
Ive purged apparmor, was not aware of this extra step.
"A stop job is running..." - SystemD
Offline
Hello:
Is it really needed to have boot command security=none ?
... was not aware of this extra step.
You would be if you had taken the time to read the whole thread. 8^D
Check if you have some other stuff called tomoyo, another gift from the Debian devs.
You have to add security=none to the kernel command line to avoid that one.
Best,
A.
Last edited by Altoid (2022-11-01 16:16:22)
Offline
Evenson wrote:
Is it really needed to have boot command security=none ?
... was not aware of this extra step.
the security module could be apparmor, selinux, ...
ref. https://www.kernel.org/doc/html/latest/admin-guide/LSM/index.html
"Examples include SELinux, Smack, Tomoyo, and AppArmor."
so, security= , requires none.
pic from 1993, new guitar day.
Offline
Evenson wrote:
Is it really needed to have boot command security=none ?
... was not aware of this extra step.the security module could be apparmor, selinux, ...
ref. https://www.kernel.org/doc/html/latest/admin-guide/LSM/index.html
"Examples include SELinux, Smack, Tomoyo, and AppArmor."
so, security= , requires none.
Thanks, i read up on this today from the link you posted. Ive no need for any of these except yama via sysctl.
kernel.yama.ptrace_scope=2
So if i use security=none it should only be for SELinux, Smack, Tomoyo, and AppArmor ?
"A stop job is running..." - SystemD
Offline