You are not logged in.
Hello:
... only a local vulnerability with a severity of 7.8.
Update available as of early afternoon -03:00 GMT.
Go Devuan !
BTW:
-----------------------------------------------------------------------------------------------------------------------------------
To obtain a root shell use su -. Using just su will result in "command not found" messages.
-----------------------------------------------------------------------------------------------------------------------------------
The slickest stiky I've seen yet. 8^D
Best,
A.
Hello:
... many cases on the web of this <s>ame issue occurring on Linux ...
... gparted was lying to me ...
MS software is and has been for the longest time notorious for not adhering to established standards/rules.
To MS, if it works with their software and the drivers hardware OEMs write for their OSs, it is good enough.
The web is full of examples, the most annoying one being all the horribly written BIOSs Linux OSs have had to deal with for ages.
As long any crap ridden BIOS worked with a MS OS, it was Windows XX Certified.
Obviously, it was not an issue if it did not work with any other OS.
eg: a Linux based OS.
All PCs were/are still sold with a MS OS, whether you want/ed it or not, so what problem could there possibly be?
I doubt that gparted is lying to you.
It does not have a will of its own. 8^D
What is most probably happening is that the data gparted is reading from the drive does not conform to the established standard.
ie: whatever the MS software wrote on the drive is not written in such a way that gparted can understand it correctly.
Like they say: rubbish in, rubbish out.
Best,
A.
Hello:
Yes there is — that's what the --backup option ...
Yes, that is what it is there for.
But (in my opinion) wipefs is a very powerfool tool and --backup gives the user a false sense of security by presenting a remedy/insurance of sorts to not having been thorough enough.
To me (again, my opinion) the only way is to do it right, from the start.
ie: check the drive letter assignment twice or more before you hit Enter, knowing that if you screw it up its contents is all but done for.
It does not make things any harder and keeps you on your toes when using such tools.
A recent example is the JWT launch.
There was no fall back if the 25 year/US$ 10+ billion state of the art telescope's launch went south.
So everything was checked, re-checked and re-checked again.
There are many other albeit less extreme examples.
I've screwed up, by various means, more than a drive in my time.
I eventually learnt what to do and how to do it as well as what not to do.
Of course, YMMV. 8^D
Best,
A.
Hello:
... all done at about the same time, formatted on the same windows PC.
Several of them now seem to have many issues ...
---
... found that I cannot correct the errors by writing an NTFS partition from windows ...
Please *stop* with all the Windows stuff ...
It's probably what screwed up the Micro SDs in the first place.
Now, did you follow Head_on_a_Stick's instructions?
ie:
As root do:
# wipefs --all --backup /dev/sdx
--> Make sure you do this with the proper drive letter and omit the --backup bit<--
There's no turning back from wipefs.
After you have done that, do # partprobe /dev/sdx
The OS will know what the drive is now all about.
Then do sudo fdisk -l /dev/sdx
Please post the terminal output of the whole process.
Best,
A.
Hello:
Would you please run fdisk /dev/sdx -l (as root or sudo) and post the printout?
... and also tried to zap it with dd.
Please post how* you did that, including the terminal printout.
* should be as explained here: https://dev1galaxy.org/viewtopic.php?pid=33887#p33887
Best,
A.
Hello:
... said I wouldn't post about that again...
Again?
Lol !!! 8^D
Maybe there should be a STICKY like this, somewhere appropiate:
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Note:
FOR ALL RELEASES/NEW INSTALLATIONS ------> -----> ---> --> -> READ THE %&$#" RELEASE NOTES
Especially the section with the title "Notes on Specific Packages and Issues".
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Cheers,
A.
... as a caution to never make assumptions ...
As a human, guilty as charged.
But (just for fun) allow me to argue in my defense. 8^)
As I reflected on your reply, I immediately recalled having both seen your post with the chimaera 'fish' photo (strangest I have ever seen, no fin tail) and its being the inspiration to Devuan's current theme, which I hope we keep for the long run.
But here's the thing®: the word chimarea has been in my head for ~ 50 years or more, always associated to a mythical/impossible beast of some sort.
A great many variations have been put forth, most of them take the idea of impossible to really great lengths.
A more reasonable lion headed, winged dragon with horns and two front legs comes to mind.
Nice ...
But never actually seen one, not even in photos.
Which is not the case with the chimaera 'fish' which I assume (again) is real for there are videos/photos etc. which would support its existence.
In my mind (ymmv) if it is real it cannot be a chimaera, hence my (all too human) assumption.
Nice video at the bottom . . .
Quite so. 8^D
Thanks for the heads up.
Have a good week-end.
Best,
A.
Hello:
... a labor of love for Devuan to be beautiful ...
There can be no doubt about that.
Isn't all art ultimately "unnecessary".
No, I don't think so.
I for one find it to be an essential part of human existence/experience.
Now and 64K years ago.
From the Maltravieso cave in Spain to Rembrandt's Night Watch, any Turner, Modigliani, Klimt or Schiele, just to name a few.
All I know is that my efforts have been appreciated ...
Please do count me among them.
... release name could be added to the wallpaper ...
... continuing with Chimaera theming going forward.
Just text would be sufficient ...
Indeed.
I fully agree with that.
Your input is appreciated.
Thank you for that.
Hopefully, I may eventually be able to contribute more.
Best,
A.
Hello:
. . . with one caveat. An associated color identity for each release is helpful.
Yes ...
But as helpful as it may be, (in my opinion, ymmv) I think the amount of work involved is a luxury we cannot afford.
There's more than enough for Devuan to do as things stand to just continue existing.
ie: golinux's brave efforts are pointed at something that is excessively burdensome, complex and (again, imo) unnecessary.
Devuan could, for example, decide on a trademark/specific colour on which we could all vote. (cringes at the prospect ...)
Then each release would have a distict 'seal' so to speak, all seals designed according to a certain defined style.
eg: Beowulf the head of the mythical hero, chimaera the head of the mythical beast, an so on.
There would then be only one thing to change: the 'seal' for each release, like the back side of conmemorative coins, within certain pre-established design parameters.
Now, if that causes any confusion, you could just add a whole number after/above/below it and use uname -a to get the details.
Just an idea.
Best,
A.
Hello:
... kind of involved...
... but if it works ...
It worked for me.
Which is why I posted the process with the terminal output so it would be detailed and easy to follow for anyone with the same problem.
You may want to read the posts after mine for further info.
Some steps I took may have been redundant.
... specific to Devuan?
... referred up the chain to Debian package management?
No idea.
I have not had good experiences with bug reporting.
... proprietary drivers installation needs to be revised.
Probably, but I would not hold my breath.
Best,
A.
Hello:
I'm sorry, I understood you did not have Linux drivers.
... can't find any utility, CLI, GUI ...
See here:
https://support.brother.com/g/b/downloa … dlang=true
Only installation via the command line interface (terminal) is supported.
--- snip ---
It would seem that there isn't one for Linux, but can't say I'm surprised.
I use simple-scan 3.30.1.1-1+b1 amd64 with my trusty ca.1995 Umax S-6E, which is still going strong.
Easy to use and can save scans/series of scans (as *.pdf or *.png) to anything I have available.
But besides cropping, that's about it.
And, quite obviously, my box is definitely required.
Best,
A.
Hello:
... cannot run any Linux program to access the configuration ...
Why not?
https://support.brother.com/g/b/oslist. … ds1200_all
See here: https://support.brother.com/g/b/downloa … ds1200_all
Drivers available (*.deb and *.rpm packages) for both 32 and 64 bit Linux:
See here: https://support.brother.com/g/b/downloa … all&os=128
That should (?) get you set.
Please let us know if it worked. =^)
Best,
A.
Hello:
... same string of errors occurs every time:
I had what seems to be the same problem.
HevyDevy worked it out here:
https://dev1galaxy.org/viewtopic.php?pid=24685#p24685
I followed his instructions, see a step by step here:
https://dev1galaxy.org/viewtopic.php?pid=24694#p24694
Check the thread from that post onwards, there is some more useful information and at least one other example.
Best,
A.
Hello:
... interesting, GParted declares it to be FAT16, but fdisk says FAT32?
... reminds me of some cheap memory sticks ...
I think there's still some problem with your memory stick.
Can't really say what but it may well bring you problems when you least expect/need one.
Murphy and all that.
Like I mentioned before, you may want to back up whatever files are in the stick and nuke it.
In my experience, the best way to do it is with the command line to clear it completely and then format it.
Do sudo dd if=/dev/zero of=/dev/sdx bs=4096 .
It takes a while depending of drive size, just wait for it till the printout shows up.
--> Make sure you do this with the proper drive letter <--
There's no turning back from dd.
To check the drive letter you can use lsblk, dmesg, gparted or all three, just in case.
You don't want to nuke your laptop drive.
Once this is done and unless there's a hardware issue such as a fake USB drive, it should be clear of whatever is going on and you can use gparted or the command line to format it again.
I'd use FAT32 as there's no advantage in using FAT16 unless you have a use case which requires filling it with +50% very small files.
FAT32 is understood by practically every modern device using USB and there's no 8.3 filename restriction.
ie: kingstonusb.txt ends up being kingst~1.txt.
Best,
A.
Hello:
Thanks ...
You're welcome.
... use Gparted to shrink the partition by 2Mb ...
Hmm ...
Would you please run fdisk /dev/sdc -l (as root or sudo) and post the printout?
Best,
A.
Hello:
... not show up in the file manager ...
... do not understand, is that I have quite a few other USB memory sticks ...
I think it is an issue with this specific USB stick, not with your installation.
Maybe a geometry issue?
Invalid cluster numbers?
My on-board memory is a bit foggy ... 8^|
You may want to try running fsck.vfat -n /dev/sdc1 for a read-only check and post the result.
or
fsck.vfat -a /dev/sdc1 to check the file system and directly fix it.
Another possibility would be to just do a full reformat with gparted or disks to FAT16 or whatever you need.
Best,
A.
* Edit: Rolfie beat me to it and explained it much better than me. 8^D
Hello:
... information that leaves the result of that command ...
... don't understand it ...
Seems like read/write errors to a solid state drive, ACPI/BIOS errors and various firmware errors.
Is this a very new laptop?
Brand? Model?
Do you have the latest available BIOS installed?
I suggest you burn a live Devuan Beowulf *.iso to a USB stick, see how it boots from that and post the result of sudo dmesg | grep -i "error\|warning\|fail\|segfault\|fatal".
Let's see what that shows us.
Best,
A.
Hello:
thank you ...
You're welcome.
... already install gentoo ...
Did you install the gentoo image as per the instructions on the page I linked to?
ie: gentoo.img uploaded to CMOS via etherlink and then configuring CMOS.
The boot disk in this CM-iGLX unit (ie: drive C:) is the on-board Flash Disk which holds the gentoo.img file.
... installation that i made with devuan: when i put the cf in a usb reader, all start normal and go well.
I don't understand ...
Devuan boots properly from an image burned on a CF card inserted into a USB-CF reader* and plugged into the unit?
* Like this one: https://i.ebayimg.com/thumbs/images/g/F … s-l225.jpg
Best,
A.
Hello:
... trying to install devuan on a really old pc ...
I'd first check out these links from the OEM:
CM-iGLX Linux documentation
http://mediawiki.compulab.com/w/index.p … iGLX_Linux
This page contains links to information about Linux kernels, packages and software development for CM-iGLX modules.
- Getting started with Linux on CM-iGLX
- Gentoo Linux for CM-iGLX
- CM-iGLX Video Input Port
CM-iGLX Linux Gentoo kernel & filesystem image September 4, 2011
https://www.compulab.com/wp-content/upl … -linux.zip
You may want to check the documentation.
This is not an ordinary old pc, there are specific instructions for installing and booting with the image from the zip file.
When you have been able to get that done, have a look at the dmesg printout to see what hardware is being recognised and which drivers are being loaded.
That will give you an idea as to how to proceed with a Devuan kernel.
Best,
A.
Hello:
Devuan takes a long time to boot ...
dmesg is a good place to start:
Run sudo dmesg | grep -i "error\|warning\|fail\|segfault\|fatal" and see what you get.
For example, if I look at my dmesg printout, I can see that it starts like this ...
~$ sudo dmesg
[ 0.000000] microcode: microcode updated early to revision 0xa0b, date = 2010-09-28
[ 0.000000] Linux version 5.10.0-0.bpo.3-amd64 (debian-kernel@lists.debian.org) (gcc-8 (Debian 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for Debian) 2.31.1) #1 SMP Debian 5.10.13-1~bpo10+1 (2021-02-11)
[ 0.000000] Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-0.bpo.3-amd64 root=UUID=d6841f29-e39b-4c87-9c52-3a9c3bafe2d3 ro acpi_osi=Linux security=none apparmor=0 nmi_watchdog=0 pci_aspm=off agp=off ipv6.disable=1 enable_mtrr_cleanup "Loading initial ramdisk ..."
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[ 0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[ 0.000000] x86/fpu: Enabled xstate features 0x3, context size is 576 bytes, using 'standard' format.
--- snip ---... and ends like this:
--- snip ---
[ 37.892157] vboxdrv: 000000002116db4c VBoxDDR0.r0
[ 37.947857] VBoxNetFlt: attached to 'eth0' / 00:14:4f:4a:a2:81
[ 37.982379] vboxdrv: 00000000384878d7 VBoxEhciR0.r0
[ 37.984508] VMMR0InitVM: eflags=246 fKernelFeatures=0x0 (SUPKERNELFEATURES_SMAP=0)
[ 37.989539] device eth0 entered promiscuous mode
[ 39.843407] logitech-hidpp-device 0003:046D:4096.0004: HID++ 4.5 device connected.
[ 49.257052] elogind-daemon[2112]: New session 1 of user groucho.
[ 49.799164] fuse: init (API version 7.32)
~$ The time stamps (in seconds) at the start of each line tell me how much time each step is taking with respect to the previous one.
eg: loading the Adaptec driver for the card that drives my trusty Umax S-6E scanner takes ~4s.
--- snip ---
[ 17.741513] scsi host0: Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
<Adaptec 2940 Ultra SCSI adapter>
aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
[ 21.823271] process '/usr/bin/fstype' started with executable stack
--- snip ---Check dmesg for errors as suggested above and for long time gaps, you may find a clue there.
Best,
A.
Hello:
This came into my mailbox a while ago:
---
This release fixes several regressions since 1.20.x and 21.1.1.
Adam Jackson (1):
glx/dri: Filter out fbconfigs that don't have a supported pixmap format
Jocelyn Falempe (2):
xf86/logind: Fix compilation error when built without logind/platform bus
xf86/logind: fix missing call to vtenter if the platform device is not paused
Matthieu Herrb (1):
Convert more funcs to use InternalEvent.
Povilas Kanapickas (1):
xserver 21.1.3
nerdopolis (1):
os: Try to discover the current seat with the XDG_SEAT var first
---
xorg-server-21.1.3.tar.gz
https://xorg.freedesktop.org/archive/in … 1.3.tar.gz
xorg-server-21.1.3.tar.gz
PGP: https://xorg.freedesktop.org/archive/in … tar.gz.sig
---
Thanks to Povilas Kanapickas it's moving along nicely ... 8^D
Best,
A.
Hello:
Altoid wrote:But Poettering seems to be in charge
Don't be silly.
Tsk, tsk ...
No name calling ... 8^D !!!
But Poettering massive, faceless, psychopathic corporate entities seem to be in charge.
Better?
So, if not Potty, then it is the MFPCEs but the issue (for me) stands.
ie:
You don't go to the cinema with a bathing trunk under your trousers, just in case you decide to go for a swim at the beach, 400 km. away.
Whoever decided this apparmor setup is a dick should seriously reconsider.
Thanks for taking the time to explain all this and for the humour.
Best,
A.
Hello:
See ...
... which package(s) own(s) those files.
Thanks for the link.
Quite useful.
Debian make several separate packages ...
Arch lump everything together in their apparmor package ...
... *must* have the AppArmor user space utilities installed ...
... not the case in Debian, which seems like an improvement to me.
I'm not in a situation to argue for or against.
But to me it seems like an unwarranted excess on behalf of the Debian crew.
Just like having apparmor installed and enabled by default.
Or ignoring the fact that it is disabled in the kernel command line to reinstall and enable it again when upgrading the kernel.
But Poettering seems to be in charge, so I'm not at all surprised.
My point is that if you want to install apparmor, then do it installing all the needed dependencies/utilities with it.
No need to fill up the system with files I won't be using.
It's like going to the cinema with a bathing trunk under my trousers.
Just in case I decide to go for a swim at the beach.
The nearest one being 400 km. away.
... the AppArmor functionality is actually provided by the kernel itself ...
I'm quite aware of that.
Thank you very much for taking the time to explain this. 8^ )
Best,
A.
Hello:
Because the dbus package has been built with AppArmor support ...
I see.
... AppArmor libraries won't ever be used if AppArmor is disabled ...
... should be able to remove them manually ...
Sure.
I know well enough not to muck with stuff in /etc so I will let that be for the moment.
But it isn't so much that I'm bothered by them.
I'm bothered by the fact that they are quite obviously* apparmor files and not dbus files.
* /etc/apparmor/*, /etc/apparmor.d/*, /etc/apparmor/init/*
In my "non-expert/developer/programmer" opinion, they should not be there unless apparmor is actually installed and enabled.
ie: What do I need them there for? They got there because apparmor is installed and enabled by default.
How come they are not removed/purged when apparmor is removed?
apparmor and tomoyo should not be foisted onto your installation unless you actually want to install them.
I have the idea that something is not right here.
For whatever reason it reminds me of how MS wove IE into Windows 95 so as to make it almost inoperable if it was pulled out*.
* to be able to choose an alternate browser.
Eventually MS were found out and exposed, but by then the damage was already done.
Thanks for your input.
Best,
A.
Hello:
Why is there a dbus dependency on libapparmor1?
I don't understand what is going on.
ascii w/backported kernel installation:
groucho@devuan:~$ aptitude why libapparmor1
i slim Depends dbus
i A dbus Depends libapparmor1 (>= 2.8.94)
groucho@devuan:~$ ascii VM:
groucho@dev-pihole:~$ sudo aptitude why libapparmor1
i dbus-x11 Depends dbus
i A dbus Depends libapparmor1 (>= 2.8.95)
groucho@dev-pihole:~$ chimaera VM:
root@chimaera:~# aptitude why libapparmor1
i dbus Depends libapparmor1 (>= 2.8.94)
root@chimaera:~# apparmor is not installed in any of these three Devuan machines.
Yet, from ascii on, there seems to be a constant apparmor infiltration.
This is the apparmor stuff I have in my main installation:
groucho@devuan:~$ uname -a
Linux devuan 5.10.0-0.bpo.3-amd64 #1 SMP Debian 5.10.13-1~bpo10+1 (2021-02-11) x86_64 GNU/Linux
groucho@devuan:~$ groucho@devuan:~$ apt list | grep installed | grep -i apparmor
--- snip ---
libapparmor1/oldstable,now 2.13.2-10 amd64 [installed]
groucho@devuan:~$ groucho@devuan:~$ locate apparmor
/etc/apparmor.d
/etc/apparmor.d/local
/etc/apparmor.d/usr.sbin.tcpdump
/etc/apparmor.d/local/usr.sbin.tcpdump
/lib/x86_64-linux-gnu/libapparmor.so.1
/lib/x86_64-linux-gnu/libapparmor.so.1.6.0
/usr/share/doc/libapparmor1
/usr/share/doc/libapparmor1/changelog.Debian.gz
/usr/share/doc/libapparmor1/copyright
/usr/share/lintian/overrides/libapparmor1
/usr/src/linux-headers-5.10.0-0.bpo.3-amd64/include/config/default/security/apparmor.h
/usr/src/linux-headers-5.10.0-0.bpo.3-amd64/include/config/security/apparmor
/usr/src/linux-headers-5.10.0-0.bpo.3-amd64/include/config/security/apparmor.h
/usr/src/linux-headers-5.10.0-0.bpo.3-amd64/include/config/security/apparmor/hash
/usr/src/linux-headers-5.10.0-0.bpo.3-amd64/include/config/security/apparmor/hash.h
/usr/src/linux-headers-5.10.0-0.bpo.3-amd64/include/config/security/apparmor/hash/default.h
/var/lib/dpkg/info/libapparmor1:amd64.list
/var/lib/dpkg/info/libapparmor1:amd64.md5sums
/var/lib/dpkg/info/libapparmor1:amd64.shlibs
/var/lib/dpkg/info/libapparmor1:amd64.symbols
/var/lib/dpkg/info/libapparmor1:amd64.triggers
groucho@devuan:~$ This is what I have in one of my VMs:
groucho@dev-pihole:~$ uname -a
Linux dev-pihole 4.9.0-17-amd64 #1 SMP Debian 4.9.290-1 (2021-12-12) x86_64 GNU/Linux
groucho@dev-pihole:~$ groucho@dev-pihole:~$ apt list | grep installed | grep -i apparmor
--- snip ---
libapparmor1/oldoldstable,now 2.11.0-3+deb9u2 amd64 [installed,automatic]
groucho@dev-pihole:~$ groucho@dev-pihole:~$ locate apparmor
/etc/apparmor
/etc/apparmor.d
/etc/apparmor/init
/etc/apparmor/init/network-interface-security
/etc/apparmor/init/network-interface-security/usr.sbin.ntpd
/etc/apparmor.d/local
/etc/apparmor.d/tunables
/etc/apparmor.d/usr.sbin.ntpd
/etc/apparmor.d/usr.sbin.unbound
/etc/apparmor.d/local/usr.sbin.ntpd
/etc/apparmor.d/local/usr.sbin.unbound
/etc/apparmor.d/tunables/ntpdThis is what I have in another one of my VMs:
groucho@chimaera:~$ uname -a
Linux chimaera 5.10.0-9-amd64 #1 SMP Debian 5.10.70-1 (2021-09-30) x86_64 GNU/Linux
groucho@chimaera:~$ root@chimaera:~# apt list | grep installed | grep -i apparmor
--- snip ---
libapparmor1/stable,now 2.13.6-10 amd64 [installed,automatic]
root@chimaera:~# root@chimaera:~# locate apparmor
/etc/apparmor
/etc/apparmor.d
/etc/apparmor/parser.conf
/etc/apparmor.d/abstractions
/etc/apparmor.d/local
/etc/apparmor.d/lsb_release
/etc/apparmor.d/nvidia_modprobe
/etc/apparmor.d/tunables
/etc/apparmor.d/usr.bin.man
/etc/apparmor.d/abstractions/X
/etc/apparmor.d/abstractions/apache2-common
/etc/apparmor.d/abstractions/apparmor_api
/etc/apparmor.d/abstractions/aspell
/etc/apparmor.d/abstractions/audio
/etc/apparmor.d/abstractions/authentication
/etc/apparmor.d/abstractions/base
/etc/apparmor.d/abstractions/bash
/etc/apparmor.d/abstractions/consoles
/etc/apparmor.d/abstractions/cups-client
/etc/apparmor.d/abstractions/dbus
/etc/apparmor.d/abstractions/dbus-accessibility
/etc/apparmor.d/abstractions/dbus-accessibility-strict
/etc/apparmor.d/abstractions/dbus-network-manager-strict
/etc/apparmor.d/abstractions/dbus-session
/etc/apparmor.d/abstractions/dbus-session-strict
/etc/apparmor.d/abstractions/dbus-strict
/etc/apparmor.d/abstractions/dconf
/etc/apparmor.d/abstractions/dovecot-common
/etc/apparmor.d/abstractions/dri-common
/etc/apparmor.d/abstractions/dri-enumerate
/etc/apparmor.d/abstractions/enchant
/etc/apparmor.d/abstractions/exo-open
/etc/apparmor.d/abstractions/fcitx
/etc/apparmor.d/abstractions/fcitx-strict
/etc/apparmor.d/abstractions/fonts
/etc/apparmor.d/abstractions/freedesktop.org
/etc/apparmor.d/abstractions/gio-open
/etc/apparmor.d/abstractions/gnome
/etc/apparmor.d/abstractions/gnupg
/etc/apparmor.d/abstractions/gvfs-open
/etc/apparmor.d/abstractions/hosts_access
/etc/apparmor.d/abstractions/ibus
/etc/apparmor.d/abstractions/kde
/etc/apparmor.d/abstractions/kde-globals-write
/etc/apparmor.d/abstractions/kde-icon-cache-write
/etc/apparmor.d/abstractions/kde-language-write
/etc/apparmor.d/abstractions/kde-open5
/etc/apparmor.d/abstractions/kerberosclient
/etc/apparmor.d/abstractions/ldapclient
/etc/apparmor.d/abstractions/libpam-systemd
/etc/apparmor.d/abstractions/likewise
/etc/apparmor.d/abstractions/mdns
/etc/apparmor.d/abstractions/mesa
/etc/apparmor.d/abstractions/mir
/etc/apparmor.d/abstractions/mozc
/etc/apparmor.d/abstractions/mysql
/etc/apparmor.d/abstractions/nameservice
/etc/apparmor.d/abstractions/nis
/etc/apparmor.d/abstractions/nvidia
/etc/apparmor.d/abstractions/opencl
/etc/apparmor.d/abstractions/opencl-common
/etc/apparmor.d/abstractions/opencl-intel
/etc/apparmor.d/abstractions/opencl-mesa
/etc/apparmor.d/abstractions/opencl-nvidia
/etc/apparmor.d/abstractions/opencl-pocl
/etc/apparmor.d/abstractions/openssl
/etc/apparmor.d/abstractions/orbit2
/etc/apparmor.d/abstractions/p11-kit
/etc/apparmor.d/abstractions/perl
/etc/apparmor.d/abstractions/php
/etc/apparmor.d/abstractions/php5
/etc/apparmor.d/abstractions/postfix-common
/etc/apparmor.d/abstractions/private-files
/etc/apparmor.d/abstractions/private-files-strict
/etc/apparmor.d/abstractions/python
/etc/apparmor.d/abstractions/qt5
/etc/apparmor.d/abstractions/qt5-compose-cache-write
/etc/apparmor.d/abstractions/qt5-settings-write
/etc/apparmor.d/abstractions/recent-documents-write
/etc/apparmor.d/abstractions/ruby
/etc/apparmor.d/abstractions/samba
/etc/apparmor.d/abstractions/smbpass
/etc/apparmor.d/abstractions/ssl_certs
/etc/apparmor.d/abstractions/ssl_keys
/etc/apparmor.d/abstractions/svn-repositories
/etc/apparmor.d/abstractions/ubuntu-bittorrent-clients
/etc/apparmor.d/abstractions/ubuntu-browsers
/etc/apparmor.d/abstractions/ubuntu-browsers.d
/etc/apparmor.d/abstractions/ubuntu-console-browsers
/etc/apparmor.d/abstractions/ubuntu-console-email
/etc/apparmor.d/abstractions/ubuntu-email
/etc/apparmor.d/abstractions/ubuntu-feed-readers
/etc/apparmor.d/abstractions/ubuntu-gnome-terminal
/etc/apparmor.d/abstractions/ubuntu-helpers
/etc/apparmor.d/abstractions/ubuntu-konsole
/etc/apparmor.d/abstractions/ubuntu-media-players
/etc/apparmor.d/abstractions/ubuntu-unity7-base
/etc/apparmor.d/abstractions/ubuntu-unity7-launcher
/etc/apparmor.d/abstractions/ubuntu-unity7-messaging
/etc/apparmor.d/abstractions/ubuntu-xterm
/etc/apparmor.d/abstractions/user-download
/etc/apparmor.d/abstractions/user-mail
/etc/apparmor.d/abstractions/user-manpages
/etc/apparmor.d/abstractions/user-tmp
/etc/apparmor.d/abstractions/user-write
/etc/apparmor.d/abstractions/video
/etc/apparmor.d/abstractions/vulkan
/etc/apparmor.d/abstractions/wayland
/etc/apparmor.d/abstractions/web-data
/etc/apparmor.d/abstractions/winbind
/etc/apparmor.d/abstractions/wutmp
/etc/apparmor.d/abstractions/xad
/etc/apparmor.d/abstractions/xdg-desktop
/etc/apparmor.d/abstractions/xdg-open
/etc/apparmor.d/abstractions/apparmor_api/change_profile
/etc/apparmor.d/abstractions/apparmor_api/examine
/etc/apparmor.d/abstractions/apparmor_api/find_mountpoint
/etc/apparmor.d/abstractions/apparmor_api/introspect
/etc/apparmor.d/abstractions/apparmor_api/is_enabled
/etc/apparmor.d/abstractions/ubuntu-browsers.d/java
/etc/apparmor.d/abstractions/ubuntu-browsers.d/kde
/etc/apparmor.d/abstractions/ubuntu-browsers.d/mailto
/etc/apparmor.d/abstractions/ubuntu-browsers.d/multimedia
/etc/apparmor.d/abstractions/ubuntu-browsers.d/plugins-common
/etc/apparmor.d/abstractions/ubuntu-browsers.d/productivity
/etc/apparmor.d/abstractions/ubuntu-browsers.d/text-editors
/etc/apparmor.d/abstractions/ubuntu-browsers.d/ubuntu-integration
/etc/apparmor.d/abstractions/ubuntu-browsers.d/ubuntu-integration-xul
/etc/apparmor.d/abstractions/ubuntu-browsers.d/user-files
/etc/apparmor.d/local/README
/etc/apparmor.d/local/lsb_release
/etc/apparmor.d/local/nvidia_modprobe
/etc/apparmor.d/local/usr.bin.man
/etc/apparmor.d/tunables/alias
/etc/apparmor.d/tunables/apparmorfs
/etc/apparmor.d/tunables/dovecot
/etc/apparmor.d/tunables/global
/etc/apparmor.d/tunables/home
/etc/apparmor.d/tunables/home.d
/etc/apparmor.d/tunables/kernelvars
/etc/apparmor.d/tunables/multiarch
/etc/apparmor.d/tunables/multiarch.d
/etc/apparmor.d/tunables/proc
/etc/apparmor.d/tunables/run
/etc/apparmor.d/tunables/securityfs
/etc/apparmor.d/tunables/share
/etc/apparmor.d/tunables/sys
/etc/apparmor.d/tunables/xdg-user-dirs
/etc/apparmor.d/tunables/xdg-user-dirs.d
/etc/apparmor.d/tunables/home.d/site.local
/etc/apparmor.d/tunables/home.d/ubuntu
/etc/apparmor.d/tunables/multiarch.d/site.local
/etc/apparmor.d/tunables/xdg-user-dirs.d/site.local
/etc/init.d/apparmor
/etc/rcS.d/K88apparmor
/etc/systemd/system/apparmor.service
/etc/systemd/system/sysinit.target.wants/apparmor.service
/usr/lib/x86_64-linux-gnu/libapparmor.so.1
/usr/lib/x86_64-linux-gnu/libapparmor.so.1.6.3
/usr/share/doc/libapparmor1
/usr/share/doc/libapparmor1/changelog.Debian.gz
/usr/share/doc/libapparmor1/copyright
/usr/src/linux-headers-5.10.0-9-amd64/include/config/default/security/apparmor.h
/usr/src/linux-headers-5.10.0-9-amd64/include/config/security/apparmor
/usr/src/linux-headers-5.10.0-9-amd64/include/config/security/apparmor.h
/usr/src/linux-headers-5.10.0-9-amd64/include/config/security/apparmor/hash
/usr/src/linux-headers-5.10.0-9-amd64/include/config/security/apparmor/hash.h
/usr/src/linux-headers-5.10.0-9-amd64/include/config/security/apparmor/hash/default.h
/var/cache/apparmor
/var/cache/apparmor/c08a2770.0
/var/cache/apparmor/c08a2770.0/.features
/var/cache/apparmor/c08a2770.0/lsb_release
/var/cache/apparmor/c08a2770.0/nvidia_modprobe
/var/cache/apparmor/c08a2770.0/usr.bin.man
/var/lib/dpkg/info/apparmor.list
/var/lib/dpkg/info/apparmor.postrm
/var/lib/dpkg/info/libapparmor1:amd64.list
/var/lib/dpkg/info/libapparmor1:amd64.md5sums
/var/lib/dpkg/info/libapparmor1:amd64.shlibs
/var/lib/dpkg/info/libapparmor1:amd64.symbols
/var/lib/dpkg/info/libapparmor1:amd64.triggers
/var/lib/systemd/deb-systemd-helper-enabled/apparmor.service.dsh-also
/var/lib/systemd/deb-systemd-helper-enabled/sysinit.target.wants/apparmor.service
/var/lib/systemd/deb-systemd-helper-masked/apparmor.service
root@chimaera:~# See what I am referring to?
Then there's what happens when you add apparmor=0 to the kernel command line.
Only the ascii VM reports it as being disabled:
groucho@dev-pihole:~$ sudo dmesg | grep AppArmor
[ 0.286356] AppArmor: AppArmor disabled by boot time parameter
groucho@dev-pihole:~$ The chimaera VM does not:
root@chimaera:~# dmesg | grep AppArmor
root@chimaera:~# Not does the ascii installation with the backported kernel:
groucho@devuan:~$ sudo dmesg | grep AppArmor
groucho@devuan:~$ I fail to see what an apparmor library has to do with dbus.
Or why the chimaera file system has acquired all these apparmor related files if it is not installed or has been purged.
Anyone know or have comments about this?
Thanks in advance.
Best,
A.