You are not logged in.
Hello:
I run Devuan ASCII 2.0 and my email client is Pegasus Mail 4.73 under Wine Debian 1.8.7-2.
~$ uname -a
Linux devuan 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05) x86_64 GNU/Linux
~$ I keep tabs on my LAN with Conky using this configuration:
--- snip ---
NETWORK LAN
${hr 2}
IP address: $alignr ${addr eth0}
${downspeedgraph eth0}
Incoming: ${downspeed eth0} /s $alignr total: ${totaldown eth0}
${upspeedgraph eth0}
Outgoing: ${upspeed eth0} /s $alignr total: ${totalup eth0}
--- snip ---The thing is that (had not noticed this before) I just sent an email with a 15.5MiB *.pdf document but Conky informs me there were a total of 30.5MiB transmitted. ie: outgoing.
That's almost 2X the original file size.
There was practically no incoming activity while the file was being uploaded so I don't think (?) it was retransmission of dropped/failed packets.
At the risk of revealing my ignorance, could anyone explain to me what is going on?
Thanks in advance.
A.
Hello:
... trying to install plexmediaserver, I added some debian sources ...
These are the debian sources that I had:# deb [url]http://deb.debian.org/debian[/url] buster main contrib non-free <-- Error: it's either ascii or buster. Can't be both. # deb [url]https://downloads.plex.tv/repo/deb[/url] ./public main
fsmithred can surely expand on this more than I could, ie: how to fix it.
But what I'm sure of is that # deb http://deb.debian.org/debian buster main contrib non-free should not be/have been there.
BTW: please use code to insert code and quote to insert a quote.
Cheers,
A.
Hello:
Dependency hell.
Could you post your surces list?
~$ cat /etc/apt/sources.listI run on an updated Devuan ascii 2.0
~$ uname -a
Linux devuan 4.9.0-13-amd64 #1 SMP Debian 4.9.228-1 (2020-07-05) x86_64 GNU/Linux
~$ # apt-get update && apt-get upgrade && apt-get install -f
Hit:1 http://deb.devuan.org/merged ascii InRelease
Hit:2 http://deb.devuan.org/merged ascii-security InRelease
Hit:3 http://deb.devuan.org/merged ascii-updates InRelease
Hit:4 http://deb.devuan.org/devuan ascii-proposed InRelease
Hit:5 http://deb.devuan.org/merged ascii-backports InRelease
Reading package lists... Done
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
# Here's my sources.list, please disregard the comments:
~$ cat /etc/apt/sources.list
deb http://deb.devuan.org/merged/ ascii main
deb http://deb.devuan.org/merged/ ascii-security main
deb http://deb.devuan.org/merged/ ascii-updates main
# needed x virtualbox backport - enable to update package
deb http://deb.devuan.org/devuan/ ascii-proposed main contrib non-free
deb http://deb.devuan.org/merged/ ascii-backports non-free contrib main
# needed x nvidia non-free drivers installation
deb http://deb.devuan.org/merged/ ascii contrib
deb http://deb.devuan.org/merged/ ascii non-free
# virtual box repository
# deb http://download.virtualbox.org/virtualbox/debian/ stretch non-free contrib With those sources, if I try to install vlc, I get this:
# apt-get install vlc
Reading package lists... Done
Building dependency tree
Reading state information... Done
vlc is already the newest version (3.0.11-0+deb9u1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
# Same with the plugin:
# apt-get install vlc-plugin-video-output
Reading package lists... Done
Building dependency tree
Reading state information... Done
vlc-plugin-video-output is already the newest version (3.0.11-0+deb9u1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
# Check your sources.list, maybe there's something there that should not be or maybe there's something missing.
Cheers,
A.
Hello:
... just a python script so you can fudge an "installation" ...
Right, I'll get to it.
Thanks a lot ! 8^ )
Cheers,
A.
Hello:
... tried Guix, Gentoo, Artix and a few others, but it always ended up with the same set of bullshit spyware.
Hmm ...
Just what is it that you do with your rig?
Did you sanitize your drive before each installation?
ie: with a bootable Linux install CD/DVD run gparted and clear the drive.
Then reboot, format it to FAT32, then reboot and clear it again.
Repeat till you have gone through ext3, ext4 and cleared one last time.
Only then install the OS again, from scratch.
... a copy of my entire root directory from several different installs.
From what you say, I have the idea that whatever is dumping that crap into your installation is probably in your backups.
Have you gone through them and checked what was there?
Cheers,
A.
Hello:
The kernel & headers metapackages need to install new versions of their dependencies ...
Right ...
But why has this happened with my VM Devuan ascii ...
groucho@devuan:~$ uname -a
Linux devuan 4.9.0-12-amd64 #1 SMP Debian 4.9.210-1+deb9u1 (2020-06-07) x86_64 GNU/Linux
groucho@devuan:~$ ... and not with my everyday rig:
groucho@devuan:~$ uname -a
Linux devuan 4.9.0-12-amd64 #1 SMP Debian 4.9.210-1+deb9u1 (2020-06-07) x86_64 GNU/Linux
groucho@devuan:~$ ie: what difference is there between them that causes those packages to be kept back? <- which was the reason for my OP.
There's more ...
EDIT:
It seems that between running apt-get update and apt-get upgrade on my rig and then doing the same on the VM used for the USB plug, the repos were updated.
So it looked like two different update/upgrade processes were taking place.
ie: one machine did it on the repos just before they were updated and the other just after they were updated.
Just what are the chances? 8^D
Thanks a lot for your input.
Cheers,
A.
Hello:
I was in the process of updating/upgrading a Devuan image I burn to a USB plug as an emergency recovery tool.
groucho@devuan:~$ uname -a
Linux devuan 4.9.0-12-amd64 #1 SMP Debian 4.9.210-1+deb9u1 (2020-06-07) x86_64 GNU/Linux
groucho@devuan:~$ The image was built with refracta snapshot 10.2.4 (20190713).
It is supposed to live inside the box, plugged into a USB socket on the MB but I've been sloppy lately so it is outside and not updated.
But I digress ...
On starting the process I came across this:
---
groucho@devuan:~$ sudo apt-get update
[sudo] password for groucho:
Get:1 http://deb.devuan.org/merged ascii InRelease [25.6 kB]
Get:2 http://deb.devuan.org/merged ascii-security InRelease [25.6 kB]
Get:3 http://deb.devuan.org/merged ascii-updates InRelease [25.6 kB]
Get:4 http://deb.devuan.org/devuan ascii-proposed InRelease [54.5 kB]
Get:5 http://deb.devuan.org/merged ascii-backports InRelease [25.6 kB]
Get:6 http://deb.devuan.org/merged ascii/main amd64 Packages [7198 kB]
Get:7 http://deb.devuan.org/merged ascii/contrib amd64 Packages [50.8 kB]
Get:8 http://deb.devuan.org/merged ascii/non-free amd64 Packages [78.8 kB]
Get:9 http://deb.devuan.org/merged ascii-updates/main amd64 Packages [3504 B]
Fetched 7488 kB in 9s (767 kB/s)
Reading package lists... Done
groucho@devuan:~$ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
linux-headers-amd64 linux-image-amd64 <------------ this
The following packages will be upgraded:
glib-networking glib-networking-common glib-networking-services libcups2 libgnutls30 libneon27-gnutls libopenjp2-7 libperl5.24
linux-compiler-gcc-6-x86 linux-kbuild-4.9 nfs-common perl perl-base perl-modules-5.24 tzdata wpasupplicant xdg-utils
17 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
Need to get 12.6 MB of archives.
After this operation, 63.5 kB of additional disk space will be used.
Do you want to continue? [Y/n] Makes me wonder because I have linux-headers-amd64 and linux-image-amd64 as essential.
¿Why are these packages being kept back?
¿Is there some application that would break if forced the upgrade?
If so, ¿how can I find out which one?
Thanks in advance,
A.
Hello:
Another option is using CUPS.
+1
When (in a hurry) I purchased a M2020W, the only thing that worked almost right away (Devuan 2.0 ascii) was CUPS.
No issues since.
Cheers,
A.
There is another distro?
No ...
Not really. 8^7
Don't know all I can do with just one, what would I want two for?
A.
Hello:
... couldn't log into 'X' after rebooting ...
... been running 'xfce' for a week ...
So the rig was working perfectly well until "adding printer driver for a Brother laser printer"?
If so, maybe it is just the old and well known cause -> effect mechanism doing it's thing here.
Q: Just where did the driver come from?
any advice?
1.
Scan through dmesg for errors and see what /var/log/Xorg.0.log has to say about X not starting.
2.
Try seeing if there's something missing, as root do:
# apt-get install -fPlease post back results.
Cheers,
A.
Hello:
... please note that Devuan ships with an unmodified Debian kernel.
... a mainline LTS kernel with very few patches ...
... *does not* support any of the RPI boards.
Ahh ...
Petit dètail.
... don't see any sound way for providing any sound RPI support in Devuan.
I understand.
... build some kind of "Respuan" ...
... all the RPI-specific stuff but uses Devuan ...
I've not seen anything like that.
Where does the Raspbian kernel come from?
How do the Ubuntu people do it?
Surely they are both Debian based.
... package a kernel for the RPI boards and then build installation images ...
Indeed ...
But like you say, no generic kernel. 8^7
... images with a kernel that is not packaged and receives no security updates ...
Of course, I agree 100%, it is a false sense of security.
I was trying to make a point.
Thanks for your input.
A.
Hello:
... as the packaged Devuan kernel is not working for the RPI, I don't see much value ...
... images with a "hardcoded" kernels are definitely not what you want ...
... false sense about security of such systems ...
... with no kernel updates forever.
From where I stand ie: not a coder or developer, just a 65+ advanced (?) user, what you say makes a lot of sense.
But I also believe that it makes sense to take into account that for Devuan, which has a hard time as things stand, things won't get easier if it has no access to or ignores SBC hardware such as RPis of which over 35 million have been sold.
These inexpensive SBP are the entry point to IT for a great many people who maybe cannot afford something else, just want to play and see what it is like or just need an inexpensive solution to a small and simple problem.
And if you leave it all to Raspbian, you will have lost a lot of potential users many of which may eventually become IT staff or pros ie: just the people Devuan needs to survive in the future.
I'm afraid that spawning dozens of derivatives will not be enough.
The Devuan project is not just a distribution, it also represents a core philosophy (Unix) or an ideology if you will.
Exactly the opposite of what mainstream MS software represents today.
It urgently needs to develop a strategy to occupy the RPi field or get permanently pushed out of it.
Just another point of view and as always, YMMV.
Cheers,
A.
Hello:
... for rpi 3B+ its the only arm64 image ...
I thought so.
... but you can dist-upgrade it to beowulf.
I tried (just to test it) but it did not do anything because of the system lacking the proper entries in /etc/apt/sources.list.
Maybe when Beowulf reaches old-stable.
... they are not mainlined.
... are always behind.
I understand.
But I don't want the mainline version, just the last stable one.
Thanks a lot for taking the time to explain this.
Best,
A.
Hello:
Search the kernel image in the list of installed packages.
While my WS ascii installaton gets me this ...
groucho@devuan:~$ apt list --installed | grep -i linux-image
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
linux-image-4.9.0-12-amd64/oldstable-security,now 4.9.210-1+deb9u1 amd64 [installed,automatic]
linux-image-amd64/oldstable,now 4.9+80+deb9u10 amd64 [installed]
groucho@devuan:~$ ... my RPi installation (image) gets me this:
pi@rpidevuan:~$ apt list --installed | grep -i linux-image
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
pi@rpidevuan:~$ Please explain as I'm not getting the point.
Thnaks,
A.
Hello:
... official RPi images never got kernel updates.
No idea ...
Is there/would there be a reason for that?
Did that change now?
As I noted previously, there's only one image for the RPi3 and it is 12 major revisions behind.
A.
Hello:
... and several for ascii for rpi's..
There's only one (have I missed something?) image for RPi3 and it is from 2 years ago.
Would it be the same as an image of the last/latest Devuan ascii 2.1 old-stable?
This is what I have installed on my RPi +B+ now:
pi@rpidevuan:~$ uname -a
Linux rpidevuan 4.16.14-v8+ #1 SMP PREEMPT Tue Jun 5 18:50:10 CEST 2018 aarch64 GNU/Linux
pi@rpidevuan:~$ This is what I have on my up-to-date Devuan ascii rig:
groucho@devuan:~$ uname -a
Linux devuan 4.9.0-12-amd64 #1 SMP Debian 4.9.210-1+deb9u1 (2020-06-07) x86_64 GNU/Linux
groucho@devuan:~$ If I counted (toes/fingers) correctly, it (4.16) is 12 major revisions behind.
A.
Hello:
... probably a million or two RPi users ...
Apparently, there's been more than 30 million RPis sold (of various models) but the Raspberry people do not support anything that's not Raspbian or Ubuntu:
It's not supported on here. The OS on here is Raspbian complete with the full-fat systemd wonderfulness. I'd guess that 99.999% of folks on the forum a) won't know what Devuan is, b) won't know why they'd swap from Raspbian and c) have no problems with systemd (and any quirks it may possess).
... without an image to just dd to an SDHC card, I doubt that you will get much interest from them.
At least for them to try and see what it is about.
Devuan won't get very far RPi wise without at least that.
Like I mentioned earlier, the only available version is ascii from two years ago and Beowulf is still too new and from what I am seeing, not without a few teething issues.
An old-stable Devuan ascii image would be a good thing to have.
A.
Hello:
... want net install images, but the RPi brigade ...
Brigade?
Not that I know much about this, but from what I have read, a brigade is composed of ~3 batallions and this could be from 2000 to 8000 troops.
From the amount of RPi traffic I've seen there at Dev1G, I doubt we have a squad, ie: 7 to 14 troops.
That said, if not a netinstall, now that it is old-stable, at least the latest ARM Build Devuan ascii 2.1 image would be very nice to have at hand.
The one available for download is over two years old (06-Jun-2018).
A.
Hello:
... both apparmor-utils and dh-apparmor.
Right.
... install NSCD and what do you know:
apparmor started to work.
43 profiles are loaded. 43 profiles are in enforce mode. ... 0 profiles are in complain mode. 1 processes have profiles defined. 1 processes are in enforce mode. /usr/sbin/nscd (3725) 0 processes are in complain mode. 0 processes are unconfined but have a profile defined.
The "0 processes are unconfined ...
... suggests that everything other than nscd does not have a profile at all.
So the problem was not in apparmor but in how you have to configure it.
Right?
Glad you managed to get it to work.
See?
Wasn't that hard.
Lack of designed maintainer and all.
Cheers,
A.
Hello:
Looks like the topic title is on point ...
I beg to differ.
Not having a designated maintainer is not the same as support being a joke.
There could be/are many reasons for not having a maintainer.
Everything seems to be enabled, just not working:
Jun 7 22:54:14 devuan kernel: [ 0.000000] Kernel command line: BOOT_IMAGE=/devuan/root.subvol/boot/vmlinuz-4.9.0-6-amd64 root=UUID=d7e92d18-e57a-4d4a-9f7e-e9301fa4c16e ro rootflags=subvol=devuan/root.subvol quiet apparmor=1 security=apparmor Jun 7 22:54:14 devuan kernel: [ 0.008000] AppArmor: AppArmor initialized Jun 7 22:54:14 devuan kernel: [ 0.213838] AppArmor: AppArmor Filesystem Enabled Jun 7 22:54:14 devuan kernel: [ 0.404639] AppArmor: AppArmor sha1 policy hashing enabled Jun 7 22:54:14 devuan kernel: [ 11.708360] audit: type=1400 audit(1591563247.192:2): apparmor="STATUS" operation="profile_load" name="ping" pid=1544 comm="apparmor_parser"
Right.
Everything seems fine:
apt-get install -f --dry-run Reading package lists... Done Building dependency tree Reading state information... Done
... how to associate programs with AppArmor profiles.
... apparmor-profiles and apparmor-profiles-extra ...
I have seen more than one application with no apparent dependency issues eg: apt-get install -f not installing anything but they would still not work because an unlisted dependency was (obviously) not installed.
These are the apparmor related (by name) packages that show up in synaptic:
apparmor-easyprof
apparmor-notify
apparmor-utils
dh-apparmorSee if installing these changes anything, especially apparmor-utils and dh-apparmor.
Then check these sites:
https://apparmor.net/
https://medium.com/information-and-tech … 4d7ae211ed
Cheers,
A.
Hello:
There is, and:
cat /proc/cmdline BOOT_IMAGE=/devuan/root.subvol/boot/vmlinuz-4.9.0-6-amd64 root=UUID=d7e92d18-e57a-4d4a-9f7e-e9301fa4c16e ro rootflags=subvol=devuan/root.subvol quiet apparmor=1 security=apparmor
I see.
Looking for apparmor bug reports I found this:
Devuan bug report logs: bugs in source package apparmor
There is no maintainer for apparmor. This means that this package no longer exists (or never existed). Please do not report new bugs against this package.
Notwithstanding, apparmor would seem to be available as a package for Devuan ascii.
Much to my chagrin, this is as far as I can go with this as it is rather above my pay grade, so to speak and like I mentioned in my first post, I only once had an issue with apparmor showing up on my dmesg, which took me to learn that apparmor was disabled in Devuan ascii and that was it as I was not interested in enabling it.
There has to be a trace of this somewhere in your system logs.
eg: in my case, I get this output in /var/log/syslog: (same in /var/log kern.log and /var/log/messages)
~$ cat /var/log/syslog | grep -i apparmor
--- snip ---
[ 0.010665] AppArmor: AppArmor disabled by boot time parameter
~$There is also the remote possibility of a missing dependency.
~# apt-get install -f --dry-runCheck to see what it says and post back.
I'm sure someone knows much more than me about this.
Cheers,
A.
Hello:
I've downed an entire barrel of it already!
Right ...
Seems to have worked.
Good sport! ;^ )
... read through both of that ...
... skipping the Ubuntu ...
Good.
... what the first reboot was for in my original post.
I see.
Please have a look at /etc/default/grub.d/apparmor.cfg:
~$ cat /etc/default/grub.d/apparmor.cfgThere should be a line like this one:
GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=1 security=apparmor"Cheers,
A.
Hello:
... furious ...
Hmmm ...
How about taking two or three cups of chamomile tea? 8^7
---
... unable to setup Apparmor in Devuan Ascii:
... had to(!) reboot ...
... had to(!) reboot for a second time ...
... still reports that everything is unconfined.
Hmm ...
Tsk, tsk.
Seems you are having a hard time.
How does one setup Apparmor ...
Try this:
$~ man apparmorOr this.
Particularly the part that says this: (because ASCII = Stretch < Buster)
Enable AppArmor
If you are using Debian 10 "Buster" or newer, AppArmor is enabled by default so you can skip this step. <- if you are running Devuan ASCII, you don't get to skip it.The AppArmor Linux Security Modules (LSM) must be enabled from the linux kernel command line in the bootloader:
$ sudo mkdir -p /etc/default/grub.d $ echo 'GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT apparmor=1 security=apparmor"' \ | sudo tee /etc/default/grub.d/apparmor.cfg $ sudo update-grub $ sudo reboot
Now ...
Take a couple of deep breaths and once you are your usual calm self, carry on and try again.
There's far too much BS going on in the world now to get so furious over a nothing. ie: don't be a dick.
Especially on a Sunday night.
Cheers,
A.
Hello:
... Devuan image doesn't have the USB drivers built in ....
Does this have a way around it?
No one?
Thanks in advance,
A.