You are not logged in.
Hello:
Apparently it works* as expected. 8^)
Much to my chagrin, no.
It does not. 8^|
I am still getting the same error:
2021-06-21 09:04:47 1lrnn0-000275-6X == groucho@devuan R=local_user T=mail_spool defer (-1): Tainted '/var/mail/groucho' (file or directory name for mail_spool transport) not permittedie: mail is being generated, held back and not delivered to my mailbox at /var/mail/groucho because exim4 does not like it anymore.
Unfortunately, editing the exim4/conf/template file as previously described does not solve the problem which apparently needs a deeper editing of the template to get rid of all the offending variables.
https://git.exim.org/exim.git/blob/HEAD … E.UPDATING
Exim version 4.94
-----------------
Some Transports now refuse to use tainted data in constructing their delivery
location; this WILL BREAK configurations which are not updated accordingly.
In particular: any Transport use of $local_part which has been relying upon
check_local_user far away in the Router to make it safe, should be updated to
replace $local_part with $local_part_data.Attempting to remove, in router or transport, a header name that ends with
an asterisk (which is a standards-legal name) will now result in all headers
named starting with the string before the asterisk being removed. We recommend
staying away from such names, if they are private ones (and in case of future
enhancements, also header names that look like REs).
I found this on the web from a chap who explains what's going on and shows (warning against using it) an unsafe solution to the problem.
Here's another chap who explains the different errors, their causes and possible solutions.
All of which is very nice, these chap's efforts are commendable but don't show a workable path for the Linux desktop user.
exim4 is the default MTA for Devuan/Debian.
And it's default configuration ie: non-split configuration scheme which uses the /etc/exim4/exim4.conf.template file is the one probably used by 99% of all Devuan/Debian desktops.
The result of the upgrade to exim4 4.94.2 (without an updated /etc/exim4/exim4.conf.template file) is a broken default MTA in Devuan/Debian.
ie: a MTA that does not transport mail and to that effect is useless.
Is there a solution to this that does not involve a crash course in exim4 configuration?
The configuration file is 2121 lines long which I expect is rather out of reach (at least it is for me) to appropiately edit and fix, something I think exim4 developers should have done.
So I'm at a loss as to what to do now.
And cannot but wonder if I am the only one affected by this problem here at Dev1 as I have not seen any posts about exim error messages.
Maybe it is time to roll back to the previous exim4 version and risk it?
Comments welcome.
Best,
A.
Hello:
Sorry ...
For? 8^)
... talking about crontab ...
... talking about the crontab file that sets up the environment.
... if you execute the command from the crontab file in a standard shell ...
And that's what I understood.
ie: one thing is executing the command listed in crontab from a shell and another is when cron actually executes that command.
... anything that is needed by a command has to be setup by the command itself.
Got it.
That command is set up by the application and I have not touched it.
Hence the warning:
#Back In Time system entry, this will be edited by the gui:... reason why a command that works in a standard shell will fail in a cron call from the crontab file.
Yes, I've seen that some time ago.
In any case, up to now, cron.log has shown no issues with respect to the backintime script.
We'll see if I get some feedback from the GitHub site, it dos not seem to have much activity on behalf of the maintainers.
But it does not seem to be dead.
Thanks so much lot for your input.
Best,
A.
Hello:
... fails in your crontab but is working in a standard shell ...
That's the thing ...
It did not fail in crontab.
The notification was sent by the Cron Daemon on date Mon, 21 Jun 2021 11:00:02 -0300.
The last backintime log entry was for a snapshot taken at Mon Jun 21 07:15:01 2021 local time and does not show any errors.
At least I can't make out a failure in /var/log/cron.log.
groucho@devuan:/var/log$ tail -600 cron.log
--- snip ---
Jun 21 07:04:47 devuan anacron[2132]: Anacron 2.3 started on 2021-06-21
Jun 21 07:04:47 devuan anacron[2132]: Will run job `cron.daily' in 5 min.
Jun 21 07:04:47 devuan anacron[2132]: Jobs will be executed sequentially
Jun 21 07:04:47 devuan cron[2200]: (CRON) INFO (pidfile fd = 3)
Jun 21 07:04:47 devuan cron[2201]: (CRON) STARTUP (fork ok)
Jun 21 07:04:47 devuan cron[2201]: (CRON) INFO (Running @reboot jobs)
Jun 21 07:05:01 devuan CRON[3030]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jun 21 07:09:47 devuan anacron[2132]: Job `cron.daily' started
Jun 21 07:09:47 devuan anacron[3660]: Updated timestamp for job `cron.daily' to 2021-06-21
Jun 21 07:10:42 devuan cracklib: no dictionary update necessary.
Jun 21 07:10:44 devuan anacron[2132]: Job `cron.daily' terminated
Jun 21 07:10:44 devuan anacron[2132]: Normal exit (1 job run)
Jun 21 07:15:01 devuan CRON[4019]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jun 21 07:15:01 devuan CRON[4020]: (groucho) CMD (/usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null)
Jun 21 07:17:01 devuan CRON[4142]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Jun 21 07:25:01 devuan CRON[4479]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jun 21 07:30:01 devuan CRON[4691]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Jun 21 07:30:01 devuan CRON[4692]: (groucho) CMD (/usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null)
Jun 21 07:30:01 devuan anacron[4716]: Anacron 2.3 started on 2021-06-21
Jun 21 07:30:01 devuan anacron[4716]: Normal exit (0 jobs run)
Jun 21 07:35:01 devuan CRON[4986]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jun 21 07:45:01 devuan CRON[5386]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jun 21 07:45:01 devuan CRON[5387]: (groucho) CMD (/usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null)
Jun 21 07:55:01 devuan CRON[5783]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jun 21 08:00:01 devuan CRON[6000]: (root) CMD (timeshift --check --scripted)
Jun 21 08:00:01 devuan CRON[6001]: (groucho) CMD (/usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null)
Jun 21 08:00:02 devuan crontab[6047]: (root) LIST (root)
#
Jun 21 08:00:02 devuan crontab[6048]: (root) LIST (root) # here is where the notification is sent ie: 11:00:02 -0300.
#
Jun 21 08:05:01 devuan CRON[6298]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jun 21 08:15:01 devuan CRON[6663]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jun 21 08:15:01 devuan CRON[6664]: (groucho) CMD (/usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null)
Jun 21 08:17:01 devuan CRON[6758]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Jun 21 08:25:01 devuan CRON[7052]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Jun 21 08:30:01 devuan CRON[7230]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Jun 21 08:30:01 devuan CRON[7231]: (groucho) CMD (/usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null)
Jun 21 08:30:01 devuan anacron[7255]: Anacron 2.3 started on 2021-06-21
Jun 21 08:30:01 devuan anacron[7255]: Normal exit (0 jobs run)
--- snip ---Thanks for your input.
Best,
A.
Hello:
Apparently it works as expected. 8^)
It just dawned on me that the solution I linked to comes from the OP comparing his exim.conf with another file called exim.conf.rpmnew.
Very smart.
This other configuration file is included in a distribution (manjaro?) that detected the problem created by the exim4 update and edited the original file accordingly.
The new (exim.conf.rpmnew) file had the "file" listed as: file = /var/mail/$local_part_data
Maybe the Devuan/Debian (or better yet, the exim4 packagers may want to consider doing the same with the /etc/exim4/exim4.conf.template file.
Q: should a bug report be filed somewhere?
Best,
A.
Hello:
... looks very stange and maybe one of your installed python package is corrupted.
the line
'from time import sleep'
is a core python function to import an external package (in this case the time utils lib)
I see.
At first I thought that maybe the syntax could have been rendered wrong or broken by an update to python?
ie: similar to what happened with the last exim4 update.
But then my python installation is datestamped 10/2019 and this is the first time I have seen this error, so I don't think it is that.
... test if the command from the crontab is working on a standard shell. The cron environment is sometimes very special.
Right
groucho@devuan:~$ /usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null
groucho@devuan:~$
groucho@devuan:~$ mail
No mail for groucho
groucho@devuan:~$ The backintime application produced a backup and the log reported no errors.
========== Take snapshot (profile 1): Tue Jun 22 07:30:02 2021 ==========... try the following:
start python2 on a shell and execute 'from time import sleep'
Here we go:
groucho@devuan:~$ python2
Python 2.7.16 (default, Oct 10 2019, 22:02:15)
[GCC 8.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from time import sleep
>>> exit ()
groucho@devuan:~$If this fails ...
It seems that both tests were successful.
Maybe this is a perfect combination of unknowns?
ie: a glitch which did not disrupt anything and just produced an error message.
I will wait and see if it shows up again.
In the meantime I have filed an issue at the backintime github page -> https://github.com/bit-team/backintime/issues
Thank you very much for taking the time to write this up for me.
Best,
A.
Hello:
Now that my exim4 is (apparently) working as expected, I can reap rewards of a sort.
I now get the news, both good and bad.
I have just received a notification related to the backintime utility that I had not ever seen before:
--- snip ---
Unhandled exception in thread started by <function __log_keyring_warning at 0x7fdf90288488>
Traceback (most recent call last):
File "/usr/share/backintime/common/tools.py", line 1458, in __log_keyring_warning
TypeError: 'NoneType' object is not callableFortunately, in this case the notification is clear and I can go check what is going on.
I open the tools.py file to try and find the offending line which, according to jed has a different number (1457):
1456
1457 def __log_keyring_warning():
1458 from time import sleep
1459 sleep(0.1)
1460 logger.warning('import keyring failed')
1461
1462 if keyring is None and keyring_warn:
1463 #delay warning to give logger some time to import
1464 import _thread
1465 _thread.start_new_thread(__log_keyring_warning, ())
1466 # logger.warning('import keyring failed')
1467 # <-- this is the last line in the scriptI wonder if this is happening now because of some update/upgrade?
In any case, python is just a family of long fat snakes to me.
ie: not a clue
The notification was sent by the Cron Daemon on date Mon, 21 Jun 2021 11:00:02 -0300.
The last backintime log entry was for a snapshot taken at Mon Jun 21 07:15:01 2021 local time and does not show any errors.
The crontab script is a system entry generated by the GUI and the python script comes with the application's installation.
Installed version is Python 2.7.16 (default, Oct 10 2019, 22:02:15).
Q: any idea as to why this has started happening now?
Thanks in advance,
A.
Hello:
... post back in a couple of days reboots with the results.
Apparently it works* as expected. 8^)
Edit:
See the edit in my previous post.
The exim4 needs to be updated, otherwise modifications to the template file are not incorporated to the rest of the configuration files.
The script update-exim4.conf generates the main configuration files /var/lib/exim4/config.autogenerated for Exim v4 by merging the data in the template file
/etc/exim4/exim4.conf.template or the ones in the /etc/exim4/conf.d directory tree respectively and /etc/exim4/update-exim4.conf.conf to the output file /var/lib/exim4/config.autogenerated.
On reboot my mailbox received notice of a number of notifications (crontab and such for logfiles) that had been delayed for as much as 144 hours.
Which means that exim4 no longer has an issue with /var/mail/username.
Clearing the mailbox and rebooting showed no mail in my mailbox.
So that's that.
Best,
A.
Hello:
... how to deal with this #%&@ tainting problem so that exim4 can keep doing what it was doing ...
I think I have found a solution.
I say think because I don't have a clue as to how all this works.
ie: if this is just a workaround or a proper configuration option.
If it is just a workaround the new security schemes in exim4, then it is bound to be temporary and we'll have to be alert.
If it is a proper configuration option, WTF is it not properly documented somewhere?
I found it here:
https://www.linuxquestions.org/question … ost6136422
In this case, the problem seems to be that exim4 now does not like the directory name for my mail folder.
I think it has to do with the backlashes in /var/mail/username.
It would be really nice if whoever came up with this (must be necessary, they know how it all works) just wrote up a small bit or a proper comment inside this file informing that the solution was to edit the file /etc/exim4/exim4.conf.template which is used for the most basic exim4 configuration.
ie: the non-split configuration scheme I expect is used by most of us here at Dev1.
Evidently too much to ask. 8^/
To the point:
The part of this huge 2122 line configuration file that must be edited is the one concerning mail spool configuration.
#####################################################
### transport/30_exim4-config_mail_spool
#####################################################
### transport/30_exim4-config_mail_spool
# This transport is used for local delivery to user mailboxes in traditional
# BSD mailbox format.
#
mail_spool:
debug_print = "T: appendfile for $local_part@$domain"
driver = appendfile
file = /var/mail/$local_part # <----- this is the line that has to be edited
delivery_date_add
envelope_to_add
return_path_add
group = mail
mode = 0660
mode_fail_narrower = false
#####################################################
### end transport/30_exim4-config_mail_spool
#####################################################It seems that the line file = /var/mail/$local_part has to be edited to read file = /var/mail/$local_part_data.
Sort of makes me wonder if there is any reason for the edited line not being there by default.
Caveat emptor:
I have not tested this yet, the post where I got it had a following one saying that it works.
----> EDIT
For this to work properly the exim4 configuration has to be updated.
BTW: did you see anything about it in the comments at the start of the exim4.conf.template file?
No?
I thought as much ...
As root run:
[root@devuan groucho]# update-exim4.conf -v
using non-split configuration scheme from /etc/exim4/exim4.conf.template
[root@devuan groucho]# jed /etc/exim4/exim4.conf.template/EDIT <----
I'll post back in a couple of days reboots with the results.
Best,
A.
Hello:
... never had to roll back a package ...
... dont believe it is straightforward process.
Never done it either.
I have pinned a package which may (?) be more or less the same idea.
An MTA is essential for any Linux installation, the mails I get (when I remember to look ...) have brought me up to date with respect to issues I had with crontab, backups, trim, etc.
Can't do without one.
Exim had some security issues with vulnerabilities discovered early this year and this last version tightened things up a bit.
But, from what I have read, it seems changes were not rolled out in a proper manner and even veteran admins are at odds as to how to get things done with the new version.
I've read at least one post that characterises sendmail as not easy to deal with citing "... complicated configuration steps and demands, and weak security mechanisms ...", something I really don't need.
What I want to know is how to deal with this #%&@ tainting problem so that exim4 can keep doing what it was doing before the same way it was doing it: silently and efficiently.
Seems I'm in a spot: if experienced professional admins* can't understand how to ge that done, what can I expect to achieve?
Thanks for your input.
Best,
A.
* See the links in my OP.
Edit: spelling, etc.
Hello:
I'm getting these mails in my user account:
Subject: exim paniclog on devuan has non-zero size
To: root@devuan
Message-Id: <E1lsebV-000146-0x@devuan>
From: root <root@devuan>
Date: Mon, 14 Jun 2021 01:53:41 -0300
Status: O
exim paniclog /var/log/exim4/paniclog on devuan has non-zero size, mail system might be broken. Up to 10 lines are quoted below.
2021-06-13 21:21:49 1lsAUd-0001xc-6C == groucho@devuan R=local_user T=mail_spool defer (-1): Tainted '/var/mail/groucho' (file or directory name for mail_spool transport) not permitted
--- snip ---
2021-06-14 01:33:33 1lsX5B-00024J-0o == groucho@devuan R=local_user T=mail_spool defer (-1): Tainted '/var/mail/groucho' (file or directory name for mail_spool transport) not permittedThese messages do exist in /var/log/exim4/paniclog but I cannot find out what is going on.
I've had other paniclog entries but these were caused by the IPv6 entries in the hosts file, which I then commented:
groucho@devuan:~$ cat /etc/hosts
127.0.0.1 devuan localhost
#::1 localhost ip6-localhost ip6-loopback
#fe00::0 ip6-localnet
#fe00::0 ip6-mcastprefix
#fe02::1 ip6-allnodes
#fe02::1 ip6-allrouters
groucho@devuan:~$My user is in both the mail and the debian-exim groups:
groucho@devuan:~$ groups
groucho adm lp mail dialout fax cdrom floppy tape sudo audio dip www-data backup video plugdev staff users crontab netdev lpadmin scanner saned fuse powerdev debian-exim
groucho@devuan:~$ /var/mail/groucho belongs to my user and the mail group:
groucho@devuan:~$ ls -l /var/mail/groucho
-rw-rw---- 1 groucho mail 20337 Jun 20 09:01 /var/mail/groucho
groucho@devuan:~$ Exim version is 4.94.2:
groucho@devuan:/var/mail$ sudo exim --version
Exim version 4.94.2 #2 built 26-May-2021 15:52:52
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.28: (September 9, 2013)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DANE DKIM DNSSEC Event I18N OCSP PIPE_CONNECT PRDR SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is /etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /var/lib/exim4/config.autogenerated
groucho@devuan:/var/mail$ I found these links from 2020 that discuss/address the problem:
https://www.mail-archive.com/exim-users … 54868.html
https://www.mail-archive.com/exim-users … 54870.html
https://www.mail-archive.com/exim-users … 54875.html
From the comments it would seem that the developers have not been up to par with the update to 4.94.2 and a lot of admins are not happy.
But it's 06/2021 and things (apparently) remain the same. (?)
I really don't want to break anything in my installation because of the MTA so I'd be quite willing to roll back to the previous exim4 version.
Which would be the safest way to go about doing that?
Or is there another way to avoid all the de-tainting hassle with the chance of breaking something?
Edit:
Looking around for the exim4 configuration files, I finally found /var/lib/exim4/config.autogenerated which starts like this:
groucho@devuan:~$ cat /var/lib/exim4/config.autogenerated
#########
# WARNING WARNING WARNING
# WARNING WARNING WARNING
# WARNING WARNING WARNING
# WARNING WARNING WARNING
# WARNING WARNING WARNING
# This file was generated dynamically from
# non-split config (/etc/exim4/exim4.conf.localmacros
# and /etc/exim4/exim4.conf.template).
# The config files are supplemented with package installation/configuration
# settings managed by debconf. This data is stored in
# /etc/exim4/update-exim4.conf.conf
# Any changes you make here will be lost.
# See /usr/share/doc/exim4-base/README.Debian.gz and update-exim4.conf(8)
# for instructions of customization.
# WARNING WARNING WARNING
# WARNING WARNING WARNING
# WARNING WARNING WARNING
# WARNING WARNING WARNING
# WARNING WARNING WARNING
#########So I went to /etc/exim4/update-exim4.conf.conf, which would be the conf file for exim4:
groucho@devuan:~$ cat /etc/exim4/update-exim4.conf.conf
# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes # is it just me or does
# to this file might happen. The code handling this will honor your local # anyone else read this
# changes, so this is usually fine, but will break local schemes that mess # as devspeak for "screw
# around with multiple versions of the file. # you, you are on your own"?
#
# update-exim4.conf uses this file to determine variable values to generate
# exim configuration macros for the configuration file.
#
# Most settings found in here do have corresponding questions in the # !!!!
# Debconf configuration, but not all of them. # !!!!
#
# This is a Debian specific file
dc_eximconfig_configtype='local'
dc_other_hostnames='groucho'
dc_local_interfaces='127.0.0.1'
dc_readhost=''
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost=''
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname=''
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'
groucho@devuan:~$ [rant]
Who's in charge of exim4, Poettering?
[/rant]
Edit 2:
Interesting and well written post, only understood between 50% and 75% of it. 8^/
But the first two paragraphs are very revealing of what has happened with exim.
See: https://lists.exim.org/lurker/message/2 … 4d.en.html
Thanks in advance,
A.
Hello:
... still need the current kernel headers to recompile the kernel module for NVidia if you are using NVidia's own driver.
Now that you mention it, my memory's been reactivated. 8^/
I recall that having that package installed was neecessary.
HevyDevy figured out how to install the proprietary drivers some time ago when I was having some problems (persistance package IIRC) and part of the sequence was installing the headers if they were not there.
I am on Beowulf but with a backported kernel so I don't know what applies.
In any case, if I ever have to install the Nvidia stuff again, I'll probably find out.
Thanks for the heads up.
Best,
A.
Hello:
I'd try apt-get --simulate autoremove ...
That didn't show anything
Yes ...
... kernel does not have the headers listed as a dependency.
... only needed for building custom kernel modules so most users don't need them.
Good to know.
Thanks for the heads up. 8^)
I can now continue with the housekeeping.
Best,
A.
Hello:
After a good while of using a newer kernel in Beowulf and with no evident issues, I've decided to clean up old stuff.
[root@devuan groucho]# 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
[root@devuan groucho]# So I first had a look at what was there:
groucho@devuan:~$ apt list | grep linux-headers | grep installed
linux-headers-4.19.0-17-amd64/stable,now 4.19.194-1 amd64 [installed,automatic]
linux-headers-4.19.0-17-common/stable,stable,now 4.19.194-1 all [installed,automatic]
linux-headers-5.10.0-0.bpo.3-amd64/stable-backports,now 5.10.13-1~bpo10+1 amd64 [installed]
linux-headers-5.10.0-0.bpo.3-common/stable-backports,stable-backports,now 5.10.13-1~bpo10+1 all [installed,automatic]
linux-headers-amd64/stable,now 4.19+105+deb10u12 amd64 [installed]
groucho@devuan:~$ Seeing that 4.19.0-17 was the target for removal, I opened a terminal:
[root@devuan groucho]# apt purge linux-headers-4.19.0-17-amd64
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
linux-headers-4.19.0-17-common linux-kbuild-4.19
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
linux-headers-4.19.0-17-amd64* linux-headers-amd64*
0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded.
After this operation, 5268 kB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.
[root@devuan groucho]#Is this right?
ie: linux-headers-amd64 -> Linux devuan 5.10.0-0.bpo.3-amd64 does not need it?
Thanks in advance.
A.
Hello:
Thanks ...
You're welcome.
... BIOS issue is never good news.
Quite so.
But check the installed version anyhow.
You may already have the latest one available for that board.
... terror of having to flash a board ...
I don't like it either.
The usual lack of properly written BIOSs aside, gigabyte is a reputed brand and their hardware can be considered trustworthy.
They may also have BIOS recovery tools in case something goes wrong.
Unless the board is very old, it is quite straightforward to flash a BIOS.
... going to live with it on the old board.
You may have seen that I run a Sun MS U24 workstation, very expensive when it hit the market in 2007.
My present full monty configuration would have cost me well over $4.000 at the time.
Obviously, I got my box second hand.
Well ...
The BIOS on this box was a real POS from day one.
As it is not a laptop, does not need to run on solar panels or be up 24/7, I have disabled all the power management settings I could disable.
Processor throttling is taken care of by cpuidle but the rest is off or disabled.
Curiously enough, attempting to disable S states in BIOS put the box in an unusable state, requiring a BIOS wipe and reflash. (!)
In any case, you may want to consider if having any S states enabled (ie: standby/sleep/hibernate) is really necessary for you.
Best,
A.
Hello:
... ascii 2.1 i386 on my other machine an older gigabyte board ...
One of the things I have learnt with Linux is that a properly written BIOS is crucial to getting ACPI things to work properly.
All the 'S''states that relate to power control settings such as suspend, sleep, etc. depend on properly written BIOS/ACPI tables.
ie: a BIOS that is written correctly observing published ACPI guidelines.
Of all the S states, S3 (the sleep/suspend stuff) is the most difficult to get right because it involves different hardware from different OEMs doing the same thing at the same time, not just the motherboard.
Now, one would think that any and all OEMs would follow ACPI guidelines to the letter, but unfortunately that is not the case.
From the very start, OEMs have followed ACPI guidelines in the way Microsoft interprets them (not the same thing) and this is because ...
But I digress.
You may want to (first) try to get the latest BIOS version for your gigabyte board and see if the issue gets worked out.
There may also be a BIOS setting you need to change.
eg: advanced power management settings -> what 'S' state 'Sleep Mode' is set to.
Bear in mind that as kernel development has advanced, at the same time it has also revealed previously undetected BIOS problems in older hardware.
Best,
A.
Hello:
... he would prefer not to ship it in debian was he is not able to debug things as he does not have sysvinit machines around.
This is where it all starts.
It's a sign of Things To Come©. ---> 8^/
A.
Hello:
In a blog post on Thursday, GitHub security researcher Kevin Backhouse recounted how he found the bug (CVE-2021-3560) in a service called polkit that is used in systemd, a common Linux system and service manager component.
Backhouse says the flaw is surprisingly easy to exploit, requiring only a few commands using standard terminal tools like bash, kill, and dbus-send.
See:
Seven-year-old make-me-root bug in Linux kernel patched. https://www.theregister.com/2021/06/11/ … olkit_bug/
So ...
Still want to know if there's a reason to stay with Devuan?
Best,
A.
Hello:
As there is a desktop mode ...
Well ...
The Linux kernel has quite a few things enabled by default which (imho) are not needed, save in a server setup.
eg: apparmor, etc.
... not sure if it should be in the repo or not ...
... not skilled enough ...
Nonsense ...
You were skilled enough to write a script to make it work, the first time around. 8^D
That's certainly not my case.
I would not have been able to use a package installed from the Devuan repository due to its (apparently) missing a vital part.
So ...
Does it make sense that it be in the repository if it is (apparently) incomplete?
... all packages (buster, bullseye, sid) do not have a sysvinit script.
Then it is a very good thing that you discovered this, wrote and shared the necessary script.
Like I said earlier, maybe it is a slip-up on behalf of the packagers.
Best,
A.
Hello:
... "tuned" is directly from redhat they are banning init.d scripts ...
... so "tuned" does not provide any.
... daemon didnt start ...
... the tuned-adm daemon control tool didnt work.
This is (I suppose) mainly for a portable system, so I don't have any use for it it.
But if this is so and there isn't a good reason for this (ie: Devuan package for tuned without the proper scripts) maybe it should not be in the repository.
... wrote the init.d script on my own.
... first init.d script i have written so far.
Good going! 8^D !
You may want to consider reporting this to those taking care of the packaging at Devuan HQ.
Maybe it was just a slip-up on their behalf, they do have a lot o their hands.
Thanks a lot for your effort.
Best,
A.
Hello:
... for me it's monitoring disk space.
I monitor disk space like this:
DISKS
${hr 2}
/ $alignc ${fs_used /} / ${fs_size /} $alignr ${fs_used_perc /}%
${fs_bar /}
/home $alignc ${fs_used /home} / ${fs_size /home} $alignr ${fs_used_perc /home}%
${fs_bar /home}
/media/backups $alignc ${fs_used /media/backups} / ${fs_size /media/backups} $alignr ${fs_used_perc /media/backups}%
${fs_bar /media/backups}
/var/log $alignc ${fs_used /var/log} / ${fs_size /var/log} $alignr ${fs_used_perc /var/log}%
${fs_bar /var/log}Not my doing but cannot recall the source.
Thanks for your input.
Best,
A.
Hello:
... should be able to assign letters to specific UUID's using (e)udev rules.
I think it may be easier to just assign labels instead of saying /dev/sdx.
eg:
SATA1: +${execi 60 hddtemp /dev/disk/by-uuid/d6841f29-e39b-4c87-9c52-3a9c3bafe2d3 | cut -c 81-86} Thanks for your input.
Best,
A.
Hello:
My Devuan box has four SAS drive slots, an on-board USB socket and room to comfortably install an additional two or three 2.5" drives.
I use UUID to keep the installation behaving properly (so to speak) but although this works, drive letters move around between UUIDs if I add a drive.
This affects my conky output by mean of which I monitor drive temperatures.
/dev/sda: +${execi 60 hddtemp /dev/disk/by-uuid/d6841f29-e39b-4c87-9c52-3a9c3bafe2d3 | cut -c 81-84}
/dev/sdb: +${execi 60 hddtemp /dev/disk/by-uuid/49d1369c-ed70-4543-b0ee-ef65327e101b | cut -c 83-86}
/dev/sdc: +${execi 60 hddtemp /dev/disk/by-uuid/bdf33361-5929-433e-ac7f-1a626aa6e844 | cut -c 78-81}
/dev/sdd: +${execi 60 hddtemp /dev/disk/by-uuid/7a33fda5-abda-451b-b6ef-c17553c78810 | cut -c 83-86}
/dev/sde: +${execi 60 hddtemp /dev/disk/by-uuid/ca8dbded-819d-4e2b-b017-0981a75ea718 | cut -c 101-104}
When I added an old SATA drive for testing purposes, drive letters got shuffled down, the new drive became /dev/sda and the one that was /dev/sda became /dev/sdb.
So, while I am still monitoring a specific drive's temperature, I sort of lost as to which drive it is.
It's just a labelling but it is what I use to ID the drives and their temperatures via conky.
Maybe I should skip the /dev/sdx system and just go with something like Drive N?
Comments welcome.
Thanks in advance,
A.
Hello:
Censorship is a slippery slope.
Quite so ...
Very.
Not my intent.
... post may be stupid and irrelevant ...
Not stupid.
In another context/forum it would actually be a fitting subject.
In my opinion, I'd say it is (if anything) irrelevant.
Devuan is better ...
That was my idea.
Thanks.
Best,
A.
Hello:
... installed the proprietary nvidia driver ...
... keep getting this message when I install a new package ...
Did you check out the thread I suggested? -> https://dev1galaxy.org/viewtopic.php?id=3820
See post #23, it has a step by step rendition of how I followed Hevy Devy's instructions and solved my problem.
Don't skip any steps.
Best,
A.
Freedom is a double edged sword so actions should be chosen with care.
Indeed ...
I really fail to grasp how/why What will happen to Windows can actually be a topic, even here at the Off-topic forum.
Ah, yes ...
Forgot my pill. 8^/
A.