You are not logged in.
Hello:
... run-parts using root rather than your normal user.
Will do.
Root should have the /sbin directories in PATH, unlike your normal user.
Yes.
Here it is:
[root@devuan ~]# run-parts --verbose /etc/cron.daily
run-parts: executing /etc/cron.daily/0anacron
run-parts: executing /etc/cron.daily/apt-compat
run-parts: executing /etc/cron.daily/apt-show-versions
run-parts: executing /etc/cron.daily/aptitude
run-parts: executing /etc/cron.daily/bsdmainutils
run-parts: executing /etc/cron.daily/chkrootkit
run-parts: executing /etc/cron.daily/cracklib-runtime
run-parts: executing /etc/cron.daily/dev-fstrim
run-parts: executing /etc/cron.daily/dpkg
run-parts: executing /etc/cron.daily/exim4-base
run-parts: executing /etc/cron.daily/logrotate
error: /etc/logrotate.conf:18 duplicate log entry for /var/log/wtmp
error: /etc/logrotate.conf:25 duplicate log entry for /var/log/btmp
run-parts: /etc/cron.daily/logrotate exited with return code 1
run-parts: executing /etc/cron.daily/man-db
run-parts: executing /etc/cron.daily/mlocate
run-parts: executing /etc/cron.daily/passwd
run-parts: executing /etc/cron.daily/rkhunter
run-parts: executing /etc/cron.daily/sysstat
[root@devuan ~]# Only errors were with logrotate.
groucho@devuan:~$ cat /etc/logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly
# keep 4 weeks worth of backlogs
rotate 4
# create new (empty) log files after rotating old ones
create
# uncomment this if you want your log files compressed
compress
# packages drop log rotation information into this directory
include /etc/logrotate.d
# no packages own wtmp, or btmp -- we'll rotate them here
/var/log/wtmp {
missingok
monthly
create 0664 root utmp
rotate 1
}
/var/log/btmp {
missingok
monthly
create 0660 root utmp
rotate 1
}
# system-specific logs may be configured here
groucho@devuan:~$ logrotate.conf - lines 17 to 30:
17 # no packages own wtmp, or btmp -- we'll rotate them here
18 /var/log/wtmp { <--- | x |
19 missingok
20 monthly
21 create 0664 root utmp
22 rotate 1
23 }
24
25 /var/log/btmp { <--- | x |
26 missingok
27 monthly
28 create 0660 root utmp
29 rotate 1
30 }No idea what the error is.
But the problem is that /etc/cron.whatever is not running the scripts as expected.
https://dev1galaxy.org/viewtopic.php?pid=28617#p28617
and
https://dev1galaxy.org/viewtopic.php?pid=28624#p28624
Thanks so much for your input.
Best,
A.
Hello:
This morning I woke up too early.
Decided to have another look.
One thing that gnaws at me is that the problem seems (?) to be circumscribed to the scripts run in /etc/cron.whatever.
So I started by looking at those.
/etc/cron.hourly has nothing to run.
/etc/cron.daily has these 16 scripts:
groucho@devuan:~$ ls -1 /etc/cron.daily
0anacron
apt-compat
apt-show-versions
aptitude
bsdmainutils
chkrootkit
cracklib-runtime
dev-fstrim
dpkg
exim4-base
logrotate
man-db
mlocate
passwd
rkhunter
sysstat
groucho@devuan:~$
I ran run-parts --verbose /etc/cron.daily and looked at what was going on:
1. 0anacron
groucho@devuan:~$ /etc/cron.daily/0anacron
/etc/cron.daily/0anacron: 12: /etc/cron.daily/0anacron: anacron: not found
groucho@devuan:~$2. apt-compat
run-parts: executing /etc/cron.daily/apt-compat
/usr/lib/apt/apt.systemd.daily: 320: /usr/lib/apt/apt.systemd.daily: cannot create /var/lib/apt//daily_lock: Permission denied
run-parts: /etc/cron.daily/apt-compat exited with return code 23. apt-show-versions
acetoneiso:amd64/beowulf 2.4-3 uptodate
--- snip ---
zstd:i386 not installed4. /etc/cron.daily/aptitude
cp: cannot create regular file 'aptitude.pkgstates': Permission denied
touch: cannot touch 'aptitude.pkgstates': Permission denied
savelog: could not touch aptitude.pkgstates
run-parts: /etc/cron.daily/aptitude exited with return code 45. bsdmainutils
bsdmainutils6. chkrootkit
chkrootkit7. cracklib-runtime
cracklib-runtime8. dev-fstrim
/etc/cron.daily/dev-fstrim: 7: /etc/cron.daily/dev-fstrim: cannot create /var/log/trim.log: Permission denied
/etc/cron.daily/dev-fstrim: 8: /etc/cron.daily/dev-fstrim: cannot create /var/log/trim.log: Permission denied
run-parts: /etc/cron.daily/dev-fstrim exited with return code 29. dpkg
cp: cannot create regular file 'dpkg.arch': Permission denied
touch: cannot touch 'dpkg.arch': Permission denied
savelog: could not touch dpkg.arch
cp: cannot create regular file 'dpkg.status': Permission denied
touch: cannot touch 'dpkg.status': Permission denied
savelog: could not touch dpkg.status
cp: cannot create regular file 'dpkg.diversions': Permission denied
touch: cannot touch 'dpkg.diversions': Permission denied
savelog: could not touch dpkg.diversions
cp: cannot create regular file 'dpkg.statoverride': Permission denied
touch: cannot touch 'dpkg.statoverride': Permission denied
savelog: could not touch dpkg.statoverride
touch: cannot touch 'alternatives.tar': Permission denied
savelog: could not touch alternatives.tar
run-parts: /etc/cron.daily/dpkg exited with return code 410. exim4-base
/etc/cron.daily/exim4-base: 27: /etc/cron.daily/exim4-base: exim4: not found
/etc/cron.daily/exim4-base: 90: cd: can't cd to /db
run-parts: /etc/cron.daily/exim4-base exited with return code 111. logrotate
error: /etc/logrotate.conf:18 duplicate log entry for /var/log/wtmp
error: /etc/logrotate.conf:25 duplicate log entry for /var/log/btmp
error: error creating output file /var/lib/logrotate/status.tmp: Permission denied
run-parts: /etc/cron.daily/logrotate exited with return code 112. man-db
/etc/cron.daily/man-db: 27: /etc/cron.daily/man-db: start-stop-daemon: not found
run-parts: /etc/cron.daily/man-db exited with return code 12713. mlocate
flock: cannot open lock file /run/mlocate.daily.lock: Permission denied
run-parts: /etc/cron.daily/mlocate exited with return code 6614. passwd
cp: cannot create regular file 'passwd.bak': Permission denied
cp: cannot create regular file 'group.bak': Permission denied
cp: cannot open '/etc/shadow' for reading: Permission denied
cp: cannot open '/etc/gshadow' for reading: Permission denied
run-parts: /etc/cron.daily/passwd exited with return code 115. rkhunter
rkhunter16. sysstat
sysstatStarting with the first script: 0anacron
groucho@devuan:~$ cat /etc/cron.weekly/0anacron
#!/bin/sh
#
# anacron's cron script
#
# This script updates anacron time stamps. It is called through run-parts
# either by anacron itself or by cron.
#
# The script is called "0anacron" to assure that it will be executed
# _before_ all other scripts.
test -x /usr/sbin/anacron || exit 0
anacron -u cron.weekly
groucho@devuan:~$ cron.weekly runs it, no doubt.
Step by step:
groucho@devuan:~$ test -x /usr/sbin/anacron || exit 0
groucho@devuan:~$ groucho@devuan:~$ anacron -u cron.weekly
bash: anacron: command not found
groucho@devuan:~$ But ...
groucho@devuan:~$ /usr/sbin/anacron -u cron.weekly
groucho@devuan:~$ I think the problem may (?) be related to PATH.
I'll experiment a bit and get back.
Edit:
I edited /etc/cron.daily/0anacron thus: anacron -u cron.daily --> /usr/sbin/anacron -u cron.daily
Now, running run-parts --verbose /etc/cron.daily does not give me an error for the 0anacron script:
groucho@devuan:~$ run-parts --verbose /etc/cron.daily
run-parts: executing /etc/cron.daily/0anacron
run-parts: executing /etc/cron.daily/apt-compat
/usr/lib/apt/apt.systemd.daily: 320: /usr/lib/apt/apt.systemd.daily: cannot create /var/lib/apt//daily_lock: Permission denied
run-parts: /etc/cron.daily/apt-compat exited with return cod 2
--- snip ---
groucho@devuan:~$Suggestions?
Thanks in advance,
A.
Hello:
I keep my apparmor purged.
I have disabled it at boot with apparmor=0:
groucho@devuan:~$ sudo dmesg | grep AppArmor
[ 0.327253] AppArmor: AppArmor disabled by boot time parameter
groucho@devuan:~$I got rid of everything and had a particularly hard time with a hidden file in the apparmor cache directory.
rmdir would not remove the directory because it was not empty.
Even running rmdir with --ignore-fail-on-non-empty would not do.
It did not complain but surprisingly enough, did not remove the directory.
I never imagined a cache directory with a hidden file called .features. 8^/
Uninstalling apparmor did not get rid of /etc/apparmor.d/* which I had to do by hand.
Must be profiles added by other applications.
There's also apparmor files in other locations:
groucho@devuan:~$ locate apparmor
/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-4.19.0-14-amd64/include/config/default/security/apparmor.h
/usr/src/linux-headers-4.19.0-14-amd64/include/config/security/apparmor
/usr/src/linux-headers-4.19.0-14-amd64/include/config/security/apparmor.h
/usr/src/linux-headers-4.19.0-14-amd64/include/config/security/apparmor/bootparam
/usr/src/linux-headers-4.19.0-14-amd64/include/config/security/apparmor/hash
/usr/src/linux-headers-4.19.0-14-amd64/include/config/security/apparmor/hash.h
/usr/src/linux-headers-4.19.0-14-amd64/include/config/security/apparmor/bootparam/value.h
/usr/src/linux-headers-4.19.0-14-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:~$ I assume that the one in /usr/src/linux-headers-4.19.0-14-amd64 should stay.
And the rest?
I would purge selinux too had it been possible; it stays disabled.
How to check it is effectively disabled?
... might want to try changing /etc/default/anacron to say
ANACRON_RUN_ON_BATTERY_POWER=yesjust for the possibility that anacron misreads something.
Right.
Then, you might try, as root, a manual run to see if it says something
# start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -dand then even a forced run ignoring date stamping
# start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d -n -f
Will do and report back.
Edit 1:
Done.
This is the result.
groucho@devuan:~$ sudo start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d
[sudo] password for groucho:
Starting /usr/sbin/anacron...
groucho@devuan:~$ groucho@devuan:~$
groucho@devuan:~$ sudo start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d -n -f
Starting /usr/sbin/anacron...
groucho@devuan:~$ ... running out of ideas
...
Imagine me.
I've set up an anacron test myself now and we'll see ....
Edit 2:
I've just noticed something in the forced cron.weekly run:
groucho@devuan:~$ pgrep -a run-parts
groucho@devuan:~$ run-parts --verbose /etc/cron.weekly
run-parts: executing /etc/cron.weekly/0anacron
/etc/cron.weekly/0anacron: 12: /etc/cron.weekly/0anacron: anacron: not found
run-parts: /etc/cron.weekly/0anacron exited with return code 127
run-parts: executing /etc/cron.weekly/dev-fstrim
/etc/cron.weekly/dev-fstrim: 7: /etc/cron.weekly/dev-fstrim: cannot create /var/log/trim.log: Permission denied
/etc/cron.weekly/dev-fstrim: 8: /etc/cron.weekly/dev-fstrim: cannot create /var/log/trim.log: Permission denied
run-parts: /etc/cron.weekly/dev-fstrim exited with return code 2
run-parts: executing /etc/cron.weekly/man-db
/etc/cron.weekly/man-db: 28: /etc/cron.weekly/man-db: start-stop-daemon: not found
run-parts: /etc/cron.weekly/man-db exited with return code 127
run-parts: executing /etc/cron.weekly/rkhunter <----
groucho@devuan:~$ ie: no not found, Permission denied or return code nnn for run-parts: executing /etc/cron.weekly/rkhunter.
I'm also not finding an entry in /var/log/auth.log for the denied instance.
Thank you so much for taking the time to debug this.
Much appreciated.
Best,
A.
Hello:
... looks like the "normal" installed files.
Good thing then.
... use apparmor ...
Not really ...
It came along with my update from ascii to Beowulf and I have been meaning to see if it is useful in any way.
I've read a couple of posts here at Dev1 noting that it is not worth having.
In ascii, dmesg infromed that it was disabled.
There must have been a reason for that.
... or selinux?
No.
But there are three libraries installed.
Two of them 'automatic'.
groucho@devuan:~$ apt list | grep -i selinux | grep -i installed
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
libselinux1-dev/stable,now 2.8-1+b1 amd64 [installed,automatic]
libselinux1/stable,now 2.8-1+b1 amd64 [installed]
libselinux1/stable,now 2.8-1+b1 i386 [installed,automatic]
groucho@devuan:~$ As to why the libselinux libraries are there, I have to dig some with aptitude why and see.
If they are not necessary, I'd rather remove them.
eg: like the absurd 512x512 / 256x256 icons I got rid of.
Just whose bright idea was that?
I should have made a note of how much they weighed.
Either one can do ugly things.
Well, it 's decided then.
I will now remove/purge apparmor.
Hopefully without ill effects.
Please let me know which tests I should run to see if there's any change afetr apparmor is gone.
I have noticed that all the scripts which run from crontab apparently do so without issues.
groucho@devuan:~$ crontab -l
# For details see man 4 crontabs
#
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR
# sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * user-name command to be executed
#
#
# --------------------------------------------------------------------------------------------
# Entries added to keep log files from growing too large
# http://www.daniloaz.com/en/how-to-prevent-the-xsession-errors-file-from-growing-to-huge-size
#
# Set logfiles to 10Mb and 200 lines max. checking for size every 23 hours
# see https://crontab.guru/every-12-hours
#
# File size examples:
#
# 150Mb -> 150000
# 100Mb -> 100000
# 15Mb -> 15000
# 10Mb -> 10000
#
# 1. For /home/groucho/.xsession-errors
# ---
0 */23 * * * [ $(du -k .xsession-errors | awk '{ print $1 }') -gt 10000 ] && tail -200 /home/$(whoami)/.xsession-errors > /home/$(whoami)/.xsession-errors
# ---
#
# 2. For /var/log/boot (bootlogd)
# ---
0 */23 * * * [ $(du -k /var/log/boot | awk '{ print $1 }') -gt 10000 ] && tail -200 /var/log/boot > /var/log/boot
# ---
# 3. For /var/log/cron.log
# ---
0 */23 * * * [ $(du -k /var/log/cron.log | awk '{ print $1 }') -gt 15000 ] && tail -500 /var/log/cron.log > /var/log/cron.log
# ---
# --------------------------------------------------------------------------------------------
# Back In Time system entry, DO NOT EDIT -> will be edited by the gui:
0 */15 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null
#
groucho@devuan:~$ /.xsession-errors > /home/$(whoami)/.xsession-errors)
groucho@devuan:/var/log$ tail -300 cron.log | grep .xsession-errors
Mar 28 23:00:01 devuan CRON[16542]: (groucho) CMD ([ $(du -k .xsession-errors | awk '{ print $1 }') -gt 10000 ] && tail -200 /home/$(whoami)/.xsession-errors > /home/$(whoami)/.xsession-errors)groucho@devuan:/var/log$ tail -300 cron.log | grep /var/log/boot
Mar 28 23:00:01 devuan CRON[16541]: (groucho) CMD ([ $(du -k /var/log/boot | awk '{ print $1 }') -gt 10000 ] && tail -200 /var/log/boot > /var/log/boot)
groucho@devuan:/var/log$ groucho@devuan:/var/log$ tail -300 cron.log | grep /var/log/cron.log
Mar 28 23:00:01 devuan CRON[16543]: (groucho) CMD ([ $(du -k /var/log/cron.log | awk '{ print $1 }') -gt 15000 ] && tail -500 /var/log/cron.log > /var/log/cron.log)
groucho@devuan:/var/log$ groucho@devuan:/var/log$ tail -1000 cron.log | grep backintime
Mar 25 15:00:01 devuan CRON[27902]: (groucho) CMD (/usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null)
Mar 27 00:00:01 devuan CRON[15156]: (groucho) CMD (/usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null)
Mar 28 00:00:01 devuan CRON[21698]: (groucho) CMD (/usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null)
groucho@devuan:/var/log$ Could it be that it is just a cron.whatever problem?
Thanks in advance,
A.
Hello:
Is this correct?
How to install NVIDIA driver ...
I had quite a few issues with the nVidia installation in Beowulf, but then I was installing the legacy340xx version which may or may not had been the cause of my problems.
In any case, have a read here, don't skip anything:
https://dev1galaxy.org/viewtopic.php?id=3820
Dev1 member HevyDevy figured out what was going on and how to do it properly.
By following his instructions I was able to successfully install the 340xx in Beowulf.
Apparently his last post/access was 2020-09-20, if you run into trouble with this maybe he'll chip in.
But the instructions he posted were rock solid.
Cheers,
A.
Hello:
Peculiar.
Any idea as to what could have caused this situation?
As far as 'permissions' go, I did have a kept back files issue that ended up in upgrading from consolkit to elogind.
See http://dev1galaxy.org/viewtopic.php?id=4130
... your test shows that the dev-fstrim does get invoked, which is enough of detail.
Good.
Here's this morning's first entry in /tmp/WTF:
groucho@devuan:~$ cat /tmp/WTF
Tue, 30 Mar 2021 07:15:55 -0300
+ test -x /usr/sbin/anacron
+ test -r /etc/default/anacron
+ . /etc/default/anacron
+ ANACRON_RUN_ON_BATTERY_POWER=no
+ ANACRON_ARGS=-s
+ . /lib/lsb/init-functions
+ run-parts --lsbsysinit --list /lib/lsb/init-functions.d
+ [ -r /lib/lsb/init-functions.d/20-left-info-blocks ]
+ . /lib/lsb/init-functions.d/20-left-info-blocks
+ FANCYTTY=
+ [ -e /etc/lsb-base-logging.sh ]
+ true
+ init_is_upstart
+ log_daemon_msg Starting anac(h)ronistic cron anacron
+ [ -z Starting anac(h)ronistic cron ]
+ log_daemon_msg_pre Starting anac(h)ronistic cron anacron
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ [ xlinux != x ]
+ [ xlinux != xdumb ]
+ [ -x /usr/bin/tput ]
+ [ -x /usr/bin/expr ]
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ [ -z ]
+ FANCYTTY=1
+ true
+ echo -n [....]
+ [ -z anacron ]
+ echo -n Starting anac(h)ronistic cron: anacron
+ log_daemon_msg_post Starting anac(h)ronistic cron anacron
+ :
+ test xno != xyes
+ test -x /usr/bin/on_ac_power
+ /usr/bin/on_ac_power
+ test 255 -eq 1
+ start-stop-daemon --start --exec /usr/sbin/anacron -- -s
+ log_end_msg 0
+ [ -z 0 ]
+ local retval
+ retval=0
+ log_end_msg_pre 0
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ [ xlinux != x ]
+ [ xlinux != xdumb ]
+ [ -x /usr/bin/tput ]
+ [ -x /usr/bin/expr ]
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ [ -z 1 ]
+ true
+ true
+ /usr/bin/tput setaf 1
+ RED=
+ /usr/bin/tput setaf 2
+ GREEN=
+ /usr/bin/tput setaf 3
+ YELLOW=
+ /usr/bin/tput op
+ NORMAL=
+ /usr/bin/tput civis
+ /usr/bin/tput sc
+ /usr/bin/tput hpa 0
+ [ 0 -eq 0 ]
+ /bin/echo -ne [ ok
+ /usr/bin/tput rc
+ /usr/bin/tput cnorm
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ [ xlinux != x ]
+ [ xlinux != xdumb ]
+ [ -x /usr/bin/tput ]
+ [ -x /usr/bin/expr ]
+ /usr/bin/tput hpa 60
+ /usr/bin/tput setaf 1
+ [ -z 1 ]
+ true
+ true
+ /usr/bin/tput setaf 1
+ RED=
+ /usr/bin/tput setaf 3
+ YELLOW=
+ /usr/bin/tput op
+ NORMAL=
+ [ 0 -eq 0 ]
+ echo .
+ log_end_msg_post 0
+ :
+ return 0
+ exit 0
Tue, 30 Mar 2021 07:30:01 -0300
+ test -x /usr/sbin/anacron
+ test -r /etc/default/anacron
+ . /etc/default/anacron
+ ANACRON_RUN_ON_BATTERY_POWER=no
+ ANACRON_ARGS=-s
+ . /lib/lsb/init-functions
+ run-parts --lsbsysinit --list /lib/lsb/init-functions.d
+ [ -r /lib/lsb/init-functions.d/20-left-info-blocks ]
+ . /lib/lsb/init-functions.d/20-left-info-blocks
+ FANCYTTY=
+ [ -e /etc/lsb-base-logging.sh ]
+ true
+ init_is_upstart
+ log_daemon_msg Starting anac(h)ronistic cron anacron
+ [ -z Starting anac(h)ronistic cron ]
+ log_daemon_msg_pre Starting anac(h)ronistic cron anacron
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ FANCYTTY=0
+ false
+ [ -z anacron ]
+ echo -n Starting anac(h)ronistic cron: anacron
+ log_daemon_msg_post Starting anac(h)ronistic cron anacron
+ :
+ test xno != xyes
+ test -x /usr/bin/on_ac_power
+ /usr/bin/on_ac_power
+ test 255 -eq 1
+ start-stop-daemon --start --exec /usr/sbin/anacron -- -s
+ log_end_msg 0
+ [ -z 0 ]
+ local retval
+ retval=0
+ log_end_msg_pre 0
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ FANCYTTY=0
+ false
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ FANCYTTY=0
+ false
+ RED=
+ YELLOW=
+ NORMAL=
+ [ 0 -eq 0 ]
+ echo .
+ log_end_msg_post 0
+ :
+ return 0
+ exit 0
groucho@devuan:~$ ... /var/log/WTF for persistent logging.
Right.
How do your /etc/anacrontab and /etc/default/anacron look?
Here they are:
groucho@devuan:~$ cat /etc/anacrontab
# /etc/anacrontab: configuration file for anacron
# See anacron(8) and anacrontab(5) for details.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
HOME=/root
LOGNAME=root
# These replace cron's entries
1 5 cron.daily run-parts --report /etc/cron.daily
7 10 cron.weekly run-parts --report /etc/cron.weekly
@monthly 15 cron.monthly run-parts --report /etc/cron.monthly
groucho@devuan:~$ groucho@devuan:~$ cat /etc/default/anacron
# Environment File for anacron
# ANACRON_RUN_ON_BATTERY_POWER
#
# NOTE:
# For ANACRON_RUN_ON_BATTERY_POWER, settings here only works
# when you are not using systemd.
# Please read /usr/share/doc/anacron/README.Debian
# to see how to adjust program behaviour on AC power.
#
# If set to "yes", start anacron even when on battery power. By
# default, the /etc/init.d/anacron script tries to avoid running
# anacron unless on AC power, so as to avoid running down the battery.
# (Things like the locate updatedb cause a lot of I/O.)
ANACRON_RUN_ON_BATTERY_POWER=no
# ANACRON_ARGS
#
# Arguments/options to pass to anacron.
# By default, "-s" is used to ensure serialised job arrangements.
# If you want tasks to execute in parallel when the jobs are due to
# start, do not pass "-s" here.
ANACRON_ARGS=-s
groucho@devuan:~$ Thanks in advance.
Best,
A.
Hello:
I'll do that and post back.
Here's /tmp/WTF before shutting down for the day:
groucho@devuan:~$ cat /tmp/WTF
Mon, 29 Mar 2021 16:57:57 -0300
Mon, 29 Mar 2021 17:30:01 -0300
Mon, 29 Mar 2021 18:30:01 -0300
Mon, 29 Mar 2021 19:30:01 -0300
Mon, 29 Mar 2021 20:30:01 -0300
Mon, 29 Mar 2021 21:30:01 -0300
Mon, 29 Mar 2021 22:30:01 -0300
+ test -x /usr/sbin/anacron
+ test -r /etc/default/anacron
+ . /etc/default/anacron
+ ANACRON_RUN_ON_BATTERY_POWER=no
+ ANACRON_ARGS=-s
+ . /lib/lsb/init-functions
+ run-parts --lsbsysinit --list /lib/lsb/init-functions.d
+ [ -r /lib/lsb/init-functions.d/20-left-info-blocks ]
+ . /lib/lsb/init-functions.d/20-left-info-blocks
+ FANCYTTY=
+ [ -e /etc/lsb-base-logging.sh ]
+ true
+ init_is_upstart
+ log_daemon_msg Starting anac(h)ronistic cron anacron
+ [ -z Starting anac(h)ronistic cron ]
+ log_daemon_msg_pre Starting anac(h)ronistic cron anacron
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ FANCYTTY=0
+ false
+ [ -z anacron ]
+ echo -n Starting anac(h)ronistic cron: anacron
+ log_daemon_msg_post Starting anac(h)ronistic cron anacron
+ :
+ test xno != xyes
+ test -x /usr/bin/on_ac_power
+ /usr/bin/on_ac_power
+ test 255 -eq 1
+ start-stop-daemon --start --exec /usr/sbin/anacron -- -s <--- | x |
+ log_end_msg 0
+ [ -z 0 ]
+ local retval
+ retval=0
+ log_end_msg_pre 0
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ FANCYTTY=0
+ false
+ log_use_fancy_output
+ TPUT=/usr/bin/tput
+ EXPR=/usr/bin/expr
+ [ -t 1 ]
+ FANCYTTY=0
+ false
+ RED=
+ YELLOW=
+ NORMAL=
+ [ 0 -eq 0 ]
+ echo .
+ log_end_msg_post 0
+ :
+ return 0
+ exit 0
groucho@devuan:~$ Well, + start-stop-daemon --start --exec /usr/sbin/anacron -- -s is there.
Is something running?
groucho@devuan:~$ pgrep -a run-parts
groucho@devuan:~$ No.
Forcing weekly scripts:
groucho@devuan:~$ run-parts --verbose /etc/cron.weekly
run-parts: executing /etc/cron.weekly/0anacron
/etc/cron.weekly/0anacron: 12: /etc/cron.weekly/0anacron: anacron: not found
run-parts: /etc/cron.weekly/0anacron exited with return code 127
run-parts: executing /etc/cron.weekly/dev-fstrim
/etc/cron.weekly/dev-fstrim: 7: /etc/cron.weekly/dev-fstrim: cannot create /var/log/trim.log: Permission denied
/etc/cron.weekly/dev-fstrim: 8: /etc/cron.weekly/dev-fstrim: cannot create /var/log/trim.log: Permission denied
run-parts: /etc/cron.weekly/dev-fstrim exited with return code 2
run-parts: executing /etc/cron.weekly/man-db
/etc/cron.weekly/man-db: 28: /etc/cron.weekly/man-db: start-stop-daemon: not found
run-parts: /etc/cron.weekly/man-db exited with return code 127
run-parts: executing /etc/cron.weekly/rkhunter
groucho@devuan:~$
groucho@devuan:~$ Yes, there we go!
Many instances of not found and Permission denied
Yes, WTF is right.
What's up with this?
Thanks a lot for your help.
Best,
A.
Hello:
... anacron start/stop script gets invoked every hour as it should, but it fails to perform.
That seems to be the case:
groucho@devuan:~$ cat /tmp/WTF
Mon, 29 Mar 2021 16:57:57 -0300
Mon, 29 Mar 2021 17:30:01 -0300
Mon, 29 Mar 2021 18:30:01 -0300
Mon, 29 Mar 2021 19:30:01 -0300
Mon, 29 Mar 2021 20:30:01 -0300
Mon, 29 Mar 2021 21:30:01 -0300
groucho@devuan:~$ Add set -x on a line after your added date ... in /etc/init.d/anacron ...
Here it is:
groucho@devuan:~$ cat /etc/init.d/anacron
#! /bin/sh
--- snip ---
PATH=/bin:/usr/bin:/sbin:/usr/sbin
exec 2>>/tmp/WTF
date -R >&2
set -x
--- snip ---
groucho@devuan:~$ ... wait for next invocation which now logs the whole script execution to /tmp/WTF.
Right.
... should have the line:
+ start-stop-daemon --start --exec /usr/sbin/anacron -- -s
I'll be watching a series and waiting for it.
Should happen before it ends. 8^7
... you would next try to force run the weekly scripts again.
... ensure any previous run has completed, with
pgrep -a run-partsreturning nothing ...
... then userun-parts --verbose /etc/cron.weeklyto see the new, forced weekly run happening.
I'll do that and post back.
Q: if I change the destination from /tmp/WTF to /var/log/WTF, will it survive a reboot and append the in-between boot results?
Thanks a lot for your help.
Best,
A.
Hello:
I apologize.
... is the opposite ...
... ignore me, as you already ...
No, not ignoring you.
I was checking to find the link to what I had read yesterday about that so you could see it.
Moot point now.
It's the intention that counts.
Thanks for your input. 8^)
Best,
A.
Hello:
I'll check with /tmp/WTF tomorrow and get back with the results.
Here's what happened:
As posted previously, I set up WTF.
exec 2>>/tmp/WTF
date -R >&2I also copied the script that should run in cron.weekly to cron.daily:
groucho@devuan:~$ ls -1 /etc/cron.daily/
--- snip ---
dev-fstrim
--- snip ---
groucho@devuan:~$ I monitored it a couple of times before I shut down the box and all I saw was a set of hourly entries such as this one:
groucho@devuan:~$ cat /tmp/WTF
Mon, 29 Mar 2021 16:57:57 -0300
groucho@devuan:~$ The first one was at boot time.
The following one was at the next HH:30 mark and from then on, once every hour.
No errors logged.
Obviously, /tmp/WTF did not survive a reboot.
This morning I booted the box, did some work and went out to get some stuff.
When I returned, all I saw were a set of hourly entries but with no errors logged.
A look at /var/log/trim.log does not show anyhing new:
groucho@devuan:~$ cat /var/log/trim.log
On Tue, 09 Mar 2021 14:20:41 -0300:
/var/log: 1.4 GiB (1513295872 bytes) trimmed on /dev/sda5
/home: 47.6 GiB (51058135040 bytes) trimmed on /dev/sda6
/: 8.1 GiB (8655081472 bytes) trimmed on /dev/sda1
On Sun, 28 Mar 2021 08:46:19 -0300:
/var/log: 1.4 GiB (1473417216 bytes) trimmed on /dev/sda5
/home: 45.4 GiB (48720437248 bytes) trimmed on /dev/sda6
/: 8.1 GiB (8660197376 bytes) trimmed on /dev/sda1
groucho@devuan:~$ From a previous post we know that the script will run if I do it manually:
Tested it again as USER so it won't really run.
groucho@devuan:~$ /etc/cron.daily/dev-fstrim
/etc/cron.daily/dev-fstrim: 7: /etc/cron.daily/dev-fstrim: cannot create /var/log/trim.log: Permission denied
/etc/cron.daily/dev-fstrim: 8: /etc/cron.daily/dev-fstrim: cannot create /var/log/trim.log: Permission denied
groucho@devuan:~$ groucho@devuan:~$ /etc/cron.weekly/dev-fstrim
/etc/cron.weekly/dev-fstrim: 7: /etc/cron.weekly/dev-fstrim: cannot create /var/log/trim.log: Permission denied
/etc/cron.weekly/dev-fstrim: 8: /etc/cron.weekly/dev-fstrim: cannot create /var/log/trim.log: Permission denied
groucho@devuan:~$ Q: why am I seeing it run twice?
... check if the cron.weekly script is recognised and run:
run-parts --test /etc/cron.weeklyThat will show a list of the scripts to be run.
Here they are:
groucho@devuan:~$ run-parts --test /etc/cron.daily
--- snip ---
/etc/cron.daily/dev-fstrim
--- snip ---
groucho@devuan:~$ groucho@devuan:~$ run-parts --test /etc/cron.weekly
--- snip ---
/etc/cron.weekly/dev-fstrim
--- snip ---
groucho@devuan:~$ It seems that the ownership of the scripts is correct:
groucho@devuan:~$ ls -l /sbin/fstrim
-rwxr-xr-x 1 root root 72808 Nov 27 2019 /sbin/fstrim
groucho@devuan:~$ groucho@devuan:~$ ls -l /etc/cron.daily/dev-fstrim
-rwxr-xr-x 1 root root 236 Mar 29 11:09 /etc/cron.daily/dev-fstrim
groucho@devuan:~$ groucho@devuan:/var/log$ ls -l /etc/cron.weekly/dev-fstrim
-rwxr-xr-x 1 root root 238 Mar 9 14:18 /etc/cron.weekly/dev-fstrim
groucho@devuan:/var/log$ That's all I have.
What else can I do?
Thank you both for your input.
Best,
A.
Hello:
cron.log shows that it finds and loads and processes the /etc/cron.d/anacron scheduling, which would trigger the start/stop script if
there is an executable /etc/init.d/anacron (script) ...
It's there, the one I posted.
... and the pathname /run/systemd/system is not a directory (eg doesn't exist)
It doesn't.
groucho@devuan:~$ ls /run/systemd
cgroups-agent inaccessible machines seats sessions users
groucho@devuan:~$ ... add the following two lines into the script /etc/init.d/anacron:
exec 2>>/tmp/WTF date -R >&2
... just after the PATH=... line.
groucho@devuan:~$ cat /etc/init.d/anacron
#! /bin/sh
--- snip ---
PATH=/bin:/usr/bin:/sbin:/usr/sbin
exec 2>>/tmp/WTF
date -R >&2
--- snip ---
groucho@devuan:~$ Done.
... cause an hourly logging to appear in the file /tmp/WTF, and that file will also contain any other stderr output ...
... the exec 2>>/tmp/WTF line associates standard error (for this script run) in append mode with the file ...
... the date -R >&2 line makes the date program issue a time stamp ...
... error message from the script will be appended ...
Right.
I'll check with /tmp/WTF tomorrow and get back with the results.
Thank you very much for your help.
Best,
A.
Hello:
... anacron is supposed to provide the extended cron function to make sure that the regular scripts are run even if the machine happens to be down at the nominal trigger time.
You give me too much credit, I did not know about that.
Thanks for the heads up. 8^)
... possible that this "chain of control" is broken; that cron fails to run anacron or that anacron fails to run the script(s).
I see ...
Ahh ...
Must be why I got this mail from the system a couple of days ago:
From root@devuan Thu Mar 25 23:30:01 2021
Return-path: <root@devuan>
Envelope-to: root@devuan
Delivery-date: Thu, 25 Mar 2021 23:30:01 -0300
Received: from root by devuan with local (Exim 4.92)
(envelope-from <root@devuan>)
id 1lPcEb-0006Cr-Jd
for root@devuan; Thu, 25 Mar 2021 23:30:01 -0300
From: root@devuan (Cron Daemon)
To: root@devuan
Subject: Cron <root@devuan> [ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 8bit
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <LOGNAME=root>
Message-Id: <E1lPcEb-0006Cr-Jd@devuan>
Date: Thu, 25 Mar 2021 23:30:01 -0300
Status: RO
invoke-rc.d: -----------------------------------------------------
invoke-rc.d: WARNING: 'invoke-rc.d anacron start' called
invoke-rc.d: during shutdown sequence.
invoke-rc.d: enabling safe mode: initscript policy layer disabled
invoke-rc.d: -----------------------------------------------------
groucho@devuan:~$ Is this what you are referring to?
I get a bad shutdown every so often.
It's the crap BIOS in my Ultra24, maybe it kicked in at the right time.
... anacron is typically set up using the sysvinit start/stop script, once initially at boot up, and then regularly by cron with the schedule contol script /etc/cron.d/anacron.
Yes: " ... this script is to run anacron at boot so that it can catch up with missed jobs."
... includes the particual misfeature of not running anacron imperatively but rather making this dependent on the absence of something.
What would that be?
The part of /etc/init.d/anacron where it checks for on_ac_power returning a value of '0'?
What else would my workstation run on?
... if that something is present then your set up does not run anacron as it should ...
Surgery time?
Which lines should I comment?
groucho@devuan:~$ cat /etc/init.d/anacron
#! /bin/sh
### BEGIN INIT INFO
# Provides: anacron
# Required-Start: $remote_fs $syslog $time
# Required-Stop: $remote_fs $syslog $time
# Default-Start: 2 3 4 5
# Default-Stop:
# Short-Description: Run anacron jobs
# Description: The first purpose of this script is to run anacron at
# boot so that it can catch up with missed jobs. Note
# that anacron is not a daemon. It is run here just once
# and is later started by the real cron. The second
# purpose of this script is that said cron job invokes
# this script to start anacron at those subsequent times,
# to keep the logic in one place.
### END INIT INFO
PATH=/bin:/usr/bin:/sbin:/usr/sbin
test -x /usr/sbin/anacron || exit 0
test -r /etc/default/anacron && . /etc/default/anacron
. /lib/lsb/init-functions
case "$1" in
start)
if init_is_upstart 2>/dev/null; then
exit 1
fi
log_daemon_msg "Starting anac(h)ronistic cron" "anacron"
if test x"$ANACRON_RUN_ON_BATTERY_POWER" != x"yes" && test -x /usr/bin/on_ac_power
then
/usr/bin/on_ac_power >/dev/null
if test $? -eq 1
then
log_progress_msg "deferred while on battery power"
log_end_msg 0
exit 0
fi
fi
# on_ac_power doesn't exist, on_ac_power returns 0 (ac power being used)
# or on_ac_power returns 255 (undefined, desktop machine without APM)
start-stop-daemon --start --exec /usr/sbin/anacron -- $ANACRON_ARGS
log_end_msg 0
;;
restart|force-reload|reload)
# nothing to do
:
;;
stop)
if init_is_upstart 2>/dev/null && status anacron 2>/dev/null | grep -q start
then
exit 0
fi
log_daemon_msg "Stopping anac(h)ronistic cron" "anacron"
start-stop-daemon --stop --exec /usr/sbin/anacron --oknodo --quiet --retry=USR1/90/TERM/5/KILL/5
log_end_msg 0
;;
status)
exit 4
;;
*)
echo "Usage: /etc/init.d/anacron {start|stop|restart|force-reload|reload}"
exit 2
;;
esac
exit 0
groucho@devuan:~$ ... consequently your weekly script won't be run "automatically".
Similarly the boot up run of the script only happens at boot up if it's set up so.
This is what I see within the last 50 entries in /var/log/cron.log:
groucho@devuan:/var/log$ tail -50 cron.log | grep -i anacron
Mar 28 16:30:01 devuan CRON[10380]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Mar 28 17:30:01 devuan CRON[20351]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
Mar 28 18:30:01 devuan CRON[5177]: (root) CMD ([ -x /etc/init.d/anacron ] && if [ ! -d /run/systemd/system ]; then /usr/sbin/invoke-rc.d anacron start >/dev/null; fi)
groucho@devuan:/var/log$ If the preconditions for the regular run/start of anacron are there ...
If I understood correctly (?), they are not.
Is there something I have to do with /etc/init.d/anacron?
Thanks a lot for your input.
Best,
A.
BTW: would it be possible to increase the logged-on time out?
Hello:
... output of this command (as root):
# crontab -l
Indeed:
[root@devuan ~]# crontab -l
no crontab for root
[root@devuan ~]# In case you need it, here's my user's crontab -l:
groucho@devuan:~$ crontab -l
# For details see man 4 crontabs
#
# Example of job definition:
# .---------------- minute (0 - 59)
# | .------------- hour (0 - 23)
# | | .---------- day of month (1 - 31)
# | | | .------- month (1 - 12) OR jan,feb,mar,apr ...
# | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR
# sun,mon,tue,wed,thu,fri,sat
# | | | | |
# * * * * * user-name command to be executed
#
# --------------------------------------------------------------------------------------------
# Entries added to keep log files from growing too large
# http://www.daniloaz.com/en/how-to-prevent-the-xsession-errors-file-from-growing-to-huge-size
#
# Set logfiles to 10Mb and 200 lines max. checking for size every 23 hours
# see https://crontab.guru/every-12-hours
#
# File size examples:
# 150Mb -> 150000
# 100Mb -> 100000
# 15Mb -> 15000
# 10Mb -> 10000
#
# 1. For /home/groucho/.xsession-errors
# ---
0 */23 * * * [ $(du -k .xsession-errors | awk '{ print $1 }') -gt 10000 ] && tail -200 /home/$(whoami)/.xsession-errors > /home/$(whoami)/.xsession-errors
# ---
#
# 2. For /var/log/boot (bootlogd)
# ---
0 */23 * * * [ $(du -k /var/log/boot | awk '{ print $1 }') -gt 10000 ] && tail -200 /var/log/boot > /var/log/boot
# ---
# 3. For /var/log/cron.log
# ---
0 */23 * * * [ $(du -k /var/log/cron.log | awk '{ print $1 }') -gt 15000 ] && tail -500 /var/log/cron.log > /var/log/cron.log
# ---
# --------------------------------------------------------------------------------------------
# Back In Time system entry, DO NOT EDIT -> will be edited by the gui:
0 */15 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /usr/bin/backintime backup-job >/dev/null
#
groucho@devuan:~$ I add comments to have a reference and keep track of 'how and why'.
Otherwise I forget. 8^/
Before writing this post I came across this:
https://www.cyberciti.biz/cloud-computi … t-working/
--- snip ---
Also add the path at the beginning of your script
PATH=/path/1:/path/2
PATH=/sbin:/usr/sbin/:/usr/local/sbin:/bin:/usr/local/bin
--- snip ---
But the page it is linked to does not say that the path has to be at the beginning of the script.
In any case, the thing is that /var/log/cron.log does not show the script being run:
groucho@devuan:~$ grep -i /sbin/fstrim /var/log/cron.log
groucho@devuan:~$ Thanks for your input.
Best,
A.
Hello:
... is anacron is installed?
Yes.
groucho@devuan:~$ apt list | grep -i anacron
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
anacron/stable,now 2.3-28 amd64 [installed,automatic]
anacron/stable 2.3-28 i386
groucho@devuan:~$ Thanks for your input.
Bst,
A.
Hello:
... it's a PATH issue.
Either set PATH in the script or call the full path to fstrim in the script.
Right ...
That's what I did.
And that same day (2021-03-09) I ran it manually to check if it worked and it did:
On Tue, 09 Mar 2021 14:20:41 -0300:
/var/log: 1.4 GiB (1513295872 bytes) trimmed on /dev/sda5
/home: 47.6 GiB (51058135040 bytes) trimmed on /dev/sda6
/: 8.1 GiB (8655081472 bytes) trimmed on /dev/sda1
groucho@devuan:/var/log$ But as you can see, nothing has been logged since.
I should have run on the 16th and on the 23rd.
groucho@devuan:~$ cat /etc/cron.weekly/dev-fstrim
#!/bin/sh
# trim all mounted file systems which support it
# PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin
LOG=/var/log/trim.log
echo "On $(date -R):" >> $LOG
/sbin/fstrim -a -v >> "$LOG" 2>&1
groucho@devuan:~$ I checked again this morning:
[root@devuan ~]# /etc/cron.weekly/dev-fstrim
[root@devuan ~]# cat /var/log/trim.log
On Tue, 09 Mar 2021 14:20:41 -0300:
/var/log: 1.4 GiB (1513295872 bytes) trimmed on /dev/sda5
/home: 47.6 GiB (51058135040 bytes) trimmed on /dev/sda6
/: 8.1 GiB (8655081472 bytes) trimmed on /dev/sda1
On Sun, 28 Mar 2021 08:46:19 -0300:
/var/log: 1.4 GiB (1473417216 bytes) trimmed on /dev/sda5
/home: 45.4 GiB (48720437248 bytes) trimmed on /dev/sda6
/: 8.1 GiB (8660197376 bytes) trimmed on /dev/sda1
[root@devuan ~]#As you can see, the script runs and logs as intended.
But cron-weekly is not doing it.
What am I missing here?
Thanks in advance,
A.
Hello:
I can't load pcc_cpufreq unless acpi_cpufreq is also loaded ...
I see.
How did you determine that Slackware system uses pcc instead of acpi?
No.
I didn't figure that one out.
A chap that posted on bugzilla.kernel.org told me.
He has two identical workstations.
One runs a proprietary OS called Unraid which is based on Slackware, the other plain Linux.
One of the workstations had the shutdown issue while the other (identical) runs Unraid and does not get the bad shutdowns.
The first WS BIOS has since been patched but the second one has not.
See https://bugzilla.kernel.org/show_bug.cgi?id=210689#c4.
... don't think they can be used independently but this is just a guess.
... can't really understand ...
Imagine me trying to get anything out of it. 8^7
And btw ...
Yes, I know.
But I forget, being accustomed to using cat and then grep from ages ago.
Eventually, I guess.
Thanks for your input.
Best,
A.
Hello:
... try blocking the acpi_cpufreq module from the GRUB menu ...
This what is going on before blocking it:
groucho@devuan:~$ cpupower frequency-info # supplied by the linux-cpupower package
analyzing CPU 0:
driver: acpi-cpufreq
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 10.0 us
hardware limits: 2.00 GHz - 2.83 GHz
available frequency steps: 2.83 GHz, 2.34 GHz, 2.00 GHz
available cpufreq governors: ondemand performance schedutil
current policy: frequency should be within 2.00 GHz and 2.83 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency: Unable to call hardware
current CPU frequency: 2.03 GHz (asserted by call to kernel)
boost state support:
Supported: no
Active: no
groucho@devuan:~$This is the result:
groucho@devuan:~$ cpupower frequency-info # supplied by the linux-cpupower package
analyzing CPU 0:
no or unknown cpufreq driver is active on this CPU
CPUs which run at the same hardware frequency: Not Available
CPUs which need to have their frequency coordinated by software: Not Available
maximum transition latency: Cannot determine or is not supported.
Not Available
available cpufreq governors: Not Available
Unable to determine current policy
current CPU frequency: Unable to call hardware
current CPU frequency: Unable to call to kernel
boost state support:
Supported: no
Active: no
groucho@devuan:~$But is would seem that if acpi_cpufreq is not loaded, pcc_cpufreq is not loade either:
groucho@devuan:~$ lsmod | grep -i cpu
groucho@devuan:~$ lsmod | grep -i freq
groucho@devuan:~$ lsmod | grep cpu
groucho@devuan:~$ lsmod | grep _cpufreq
groucho@devuan:~$groucho@devuan:~$ cat /proc/modules | grep _cpufreq
groucho@devuan:~$ Thanks for your input.
Best,
A.
Hello:
Running up to date Devuan Beowulf 3.1.0:
groucho@devuan:~$ uname -a
Linux devuan 4.19.0-14-amd64 #1 SMP Debian 4.19.171-2 (2021-01-30) x86_64 GNU/Linux
groucho@devuan:~$ My Sun Ultra 24 box has for the longes time had a persistent bad shutdown issue to which I have not been able to find a soluton, even by injecting a modified DSDT file at boot time.
It has been present across many Linux kernels and distributions.
See https://bugzilla.kernel.org/show_bug.cgi?id=201965
I have recently learned that this issue could be related to the cpu scaling driver.
It seems that a proprietary Slackware based OS which uses pcc_cpufreq instead of acpi_cpufreq does not show the problem when run on a workstation which, running another Linux distribution using acpi_cpufreq, does.
Although the WS is not a Sun U24 such as mine, the problem is exactly the same one, presenting the same symptoms.
See:
https://bugzilla.kernel.org/show_bug.cgi?id=199349#c4
https://lkml.org/lkml/2018/11/13/857.
Both modules are present in my installation, the one in use being acpi_cpufreq:
groucho@devuan:~$ lsmod | grep cpu
pcc_cpufreq 16384 0
acpi_cpufreq 24576 1
groucho@devuan:~$ groucho@devuan:~$ cat /proc/modules | grep _cpufreq
pcc_cpufreq 16384 0 - Live 0x0000000000000000
acpi_cpufreq 24576 1 - Live 0x0000000000000000
groucho@devuan:~$ Is it possible to make the system use pcc_cpufreq instead of acpi_cpufreq?
Testing without a module that seems to have issues could get me a solution.
My CPU is a Core2 Q9550 - Yorkfield.
Thanks in advance,
A.
Hello:
... try using the USB "address" ...
Well ...
I'll be quick so my mood does not get worse yet.
---
I really deserve to be mocked to extintion.
I got these USB drives long ago to do some installations that were eventually cancelled.
Got to keep them but have since had very little use.
They are in pristine condition.
Each drive came with it's own OEM cable in the box.
These cables are, as far as I can see, identical and have the same markings: AWM 2725 80°C 30V VM-1
One says "USB 3.0 HighSpeed Cable Broad" and the other says "Universal Serial Bus 3.0", only difference.
But the drives are both USB3.0 ...
Having no reason to think otherwise, I assumed that they were also electrically identical.
More so coming from the same OEM that sells these drives.
So ...
USB cable A bundled with USB3.0 drive A is the same as USB cable B bundled with USB3.0 drive B, in every sense.
Same OEM, same USB standard, same capacity drive, same markings ...
And as such, obviously interchangeable.
Right?
---
BTW: I was asked about the cable at GitHub.
But as they both worked, there wasn't anything wrong with them.
---
Well ...
Tl,dr: I switched the cables and now both drives are recognised.
groucho@devuan:~ $ sudo uhubctl
[sudo] password for groucho:
Current status for hub 5 [1d6b:0003 Linux 4.19.0-14-amd64 xhci-hcd xHCI Host Controller 0000:04:00.0, USB 3.00, 4 ports, ppps]
Port 1: 0203 power 5gbps U0 enable connect [043e:70f5 LG Electronics Inc. LG External HDD A3110300000A] <--- | x |
Port 2: 0203 power 5gbps U0 enable connect [043e:70f5 LG Electronics Inc. LG External HDD A1204000000004C7] <--- | x |
Port 3: 02a0 power 5gbps Rx.Detect
Port 4: 02a0 power 5gbps Rx.Detect
Current status for hub 3-3 [0424:2514, USB 2.00, 4 ports, ppps]
Port 1: 0100 power
Port 2: 0100 power
Port 3: 0100 power
Port 4: 0100 power
Current status for hub 3 [1d6b:0002 Linux 4.19.0-14-amd64 xhci-hcd xHCI Host Controller 0000:04:00.0, USB 2.00, 4 ports, ppps]
Port 1: 0100 power
Port 2: 0100 power
Port 3: 0507 power highspeed suspend enable connect [0424:2514, USB 2.00, 4 ports, ppps]
Port 4: 0100 power
groucho@devuan:~ $For whatever reason, drive A will only work properly with cable A but drive B will work properly with cable A or cable B.
Seems that "USB 3.0 HighSpeed" is not the same as "Universal Serial Bus 3.0"
[rant]
Is it possible that Toshiba skimped $0.05 on a 30cm USB3.0 cable for their #$%& external USB3.0 drives?
Unbelievable ...
[/rant]
So that's it.
Tomorrow I'll feel better.
Thanks for your input.
A.
Hello:
I (think) I have been able to solve the riddle but not the problem.
Of great help was rtreffer @Github.
On a whim, I connected another 500Gb USB3.0 drive I have, unused in a box.
It worked: same cable, same USB3.0 card, same port.
Both USB3.0 drives are Toshiba but they are different models.
The one that works is model HXD7 USB 3.0.
The one that does not work is model HXE4 USB 3.0.
dmesg
[ 2420.760462] usb 2-1: new SuperSpeed Gen 1 USB device number 4 using xhci_hcd
[ 2420.787113] usb 2-1: New USB device found, idVendor=043e, idProduct=70f5, bcdDevice= 1.00
[ 2420.787117] usb 2-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[ 2420.787120] usb 2-1: Product: LG External HDD
[ 2420.787123] usb 2-1: Manufacturer: LG Electronics Inc.
[ 2420.787125] usb 2-1: SerialNumber: A3110300000A
[ 2420.791771] usb-storage 2-1:1.0: USB Mass Storage device detected
[ 2420.791953] scsi host9: usb-storage 2-1:1.0
[ 2424.446142] scsi 9:0:0:0: Direct-Access LG External HDD AX00 PQ: 0 ANSI: 5
[ 2424.446523] sd 9:0:0:0: Attached scsi generic sg7 type 0
[ 2424.446645] sd 9:0:0:0: [sdg] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[ 2424.447552] sd 9:0:0:0: [sdg] Write Protect is off
[ 2424.447555] sd 9:0:0:0: [sdg] Mode Sense: 23 00 00 00So the USB3.0 card and both USB3.0 drives work properly.
It's just that one of them does not do it at USB3.0 speeds.
Since both drives work with the same cable and the same USB3.0 card, I thought the problem had to be with whatever gets done between the card and the SATA/USB bridge.
Nothing else came to mind.
So I opened up the cases (a real PITA) and saw the difference between them:
Model HXD7 has a ASM1053 SATA/USB controller chip.
[http://j5d2v7d7.stackpathcdn.com/wp-con … SM1051.gif] (url) photo from the web
Model HXD7 has a VIA Labs VL 701-04
[https://www.via-labs.com/archive/images … VL701_.jpg] (url) photo from tthe web
Plugged in the way I knew worked, printout from uhubctl* was clear: both drives are detected
---
*An interesting utility to control USB ports in compatible cards. -> https://github.com/mvp/uhubctl
---
groucho@devuan:~ $ sudo uhubctl
Current status for hub 2 [1d6b:0003 Linux 4.19.0-14-amd64 xhci-hcd xHCI Host Controller 0000:04:00.0, USB 3.00, 4 ports, ppps]
Port 1: 0203 power 5gbps U0 enable connect [043e:70f5 LG Electronics Inc. LG External HDD A3110300000A] <----- | x |
Port 2: 02a0 power 5gbps Rx.Detect
Port 3: 02a0 power 5gbps Rx.Detect
Port 4: 02a0 power 5gbps Rx.Detect
Current status for hub 1-3 [0424:2514, USB 2.00, 4 ports, ppps]
Port 1: 0503 power highspeed enable connect [043e:70f5 LG Electronics Inc. LG External HDD A1204000000004C7] <----- | x |
Port 2: 0100 power
Port 3: 0100 power
Port 4: 0100 power
Current status for hub 1 [1d6b:0002 Linux 4.19.0-14-amd64 xhci-hcd xHCI Host Controller 0000:04:00.0, USB 2.00, 4 ports, ppps]
Port 1: 0100 power
Port 2: 0100 power
Port 3: 0503 power highspeed enable connect [0424:2514, USB 2.00, 4 ports, ppps]
Port 4: 0100 power
groucho@devuan:~ $But when I switch them around, the one with the VIA SATA/USB bridge is no longer detected:
groucho@devuan:~ $ sudo uhubctl
Current status for hub 2 [1d6b:0003 Linux 4.19.0-14-amd64 xhci-hcd xHCI Host Controller 0000:04:00.0, USB 3.00, 4 ports, ppps]
Port 1: 02a0 power 5gbps Rx.Detect <----- | o |
Port 2: 02a0 power 5gbps Rx.Detect
Port 3: 02a0 power 5gbps Rx.Detect
Port 4: 02a0 power 5gbps Rx.Detect
Current status for hub 1-3 [0424:2514, USB 2.00, 4 ports, ppps]
Port 1: 0503 power highspeed enable connect [043e:70f5 LG Electronics Inc. LG External HDD A3110300000A] <----- | x |
Port 2: 0100 power
Port 3: 0100 power
Port 4: 0100 power
Current status for hub 1 [1d6b:0002 Linux 4.19.0-14-amd64 xhci-hcd xHCI Host Controller 0000:04:00.0, USB 2.00, 4 ports, ppps]
Port 1: 0100 power
Port 2: 0100 power
Port 3: 0503 power highspeed enable connect [0424:2514, USB 2.00, 4 ports, ppps]
Port 4: 0100 power
groucho@devuan:~ $That seems to be what it is all about.
lsusb -vv can reveal interesting things:
groucho@devuan:~$ sudo lsusb -vv
--- snip ---
Bus 002 Device 007: ID 043e:70f5 LG Electronics USA, Inc. External HDD
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 3.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 9
idVendor 0x043e LG Electronics USA, Inc.
idProduct 0x70f5 External HDD
bcdDevice 1.00
iManufacturer 2 LG Electronics Inc.
iProduct 3 LG External HDD
iSerial 1 A3110300000A
--- snip ---
wSpeedsSupported 0x000e
Device can operate at Full Speed (12Mbps) <---
Device can operate at High Speed (480Mbps) <---
Device can operate at SuperSpeed (5Gbps) <---
--- snip ---
Bus 001 Device 006: ID 043e:70f5 LG Electronics USA, Inc. External HDD
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.10
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x043e LG Electronics USA, Inc.
idProduct 0x70f5 External HDD
bcdDevice 6.00
iManufacturer 1 LG Electronics Inc.
iProduct 2 LG External HDD
iSerial 3 A1204000000004C7
--- snip ---
wSpeedsSupported 0x000c
Device can operate at High Speed (480Mbps) <---
Device can operate at SuperSpeed (5Gbps) <---
--- snip ---lsusb reveals that both external USB3.0 drives support USB3.0 speeds.
I'd think that data that comes from somewhere in the drive's SATA/USB3.0 bridge, not the HDD.
If I had to make an (un)educated guess, I'd say that one SATA/USB bridge has a problem with the USB3.0 ports' Rx.Detect.
And if this were true, could it be a xHCI_PCI module problem/setting causing this?
But it is all over my head.
Any comments of suggestions will be welcome.
Thanks in advance,
Best,
A.
Hello:
Also got a PCIe card with a Renesas 720201 installed. Used the same tools and failed:
05:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03)
It seems to be a problematic card, to say the least.
It seems that application has a bug.
See here: https://github.com/markusj/upd72020x-load/issues/16 <- fourth post
So if you compiled the project in the past edit that line to read `is_x1 = true, is_x2 = true;`,
then compile as usual (`make` is enough - the task of make is to figure out what changed an needs to be recompiled)
Then use the new binary to upload.
Now the application apparently works.
But I am doing something wrong.
ie: -w is a no-no and I'm downgrading which apparently won'r work.
See the rest of the thread there, that chap seems to know about it.
Could you send me a link to the firmware you have?
Thanks in advance.
Best,
A.
Hello:
I would place the script under /usr/local/bin/ and place the firmware under /usr/local/lib/firmware/ then change the script like this:
# set paths to loader and firmware, if not provided by environment readonly UPD72020X_CMD="${UPD72020X_CMD:-/usr/local/bin/upd72020x-load}" readonly UPD72020X_FW="${UPD72020X_FW:-/usr/local/lib/firmware/K2026.mem}"^ That replaces lines 7-13 (inclusive) in the original script. It does the same thing without having to run two if...fi loops.
Right, will do.
But it's still not working, some problem with the application and the card's ID and some missing data somewhere.
Hopefully I won't brick the damn thing.
Not as easy as it seemed at first.
But I got to use "make" for the first time.
Altoid wrote:Just who do you take me for?
Sorry, that was a comment about ...
Sorry?
Hmm ...
Have you had your tea yet?
I was just taking the piss ... 8^D!
Can't take me that seriously.
Right.
Once I get this working manually, I'll fix that.
Thanks a lot for your input.
Best,
A.
... so I would guess on
-b 0x04 -d 0x00 -f 0x00
Right ...
But I am getting errors and cannot save the original or upload a new/different firmware.
According to the application, usage is like this:
[root@devuan work]# ./upd72020x-load
upd72020x-load: version 0.1
usage: upd72020 -r -b bus -d dev -f fct -s -o outfile : read eeprom to file (size default is 0x10000 or 64KB)
usage: upd72020 -w -b bus -d dev -f fct -i infile : write file to eeprom
usage: upd72020 -u -b bus -d dev -f fct -i infile : upload file to firmware memory
[root@devuan work]# Reading:
[root@devuan work]# ./upd72020x-load -r -b 0x04 -d 0x00 -f 0x00 -s -o original.mem
Doing the reading <---- must be right because it says it is reading.
bus = 4
dev = 0
fct = 0
fname = (null)
ERROR: wrong vendorid/devid. Expected an UPD720201 or UPD720202 chip and this is not one!
reported vendorid/devid: 1912:0014
======> FAILEDWriting:
[root@devuan work]# ./upd72020x-load -u -b 0x04 -d 0x00 -f 0x00 -i K2013080.mem
Doing the upload <---- must be right because it says it is uploading.
bus = 4
dev = 0
fct = 0
fname = K2013080.mem
ERROR: wrong vendorid/devid. Expected an UPD720201 or UPD720202 chip and this is not one!
reported vendorid/devid: 1912:0014
======> FAILED
[root@devuan work]# or
[root@devuan work]# ./upd72020x-load -w -b 0x04 -d 0x00 -f 0x00 -i K2013080.mem
Doing the writing
bus = 4
dev = 0
fct = 0
fname = K2013080.mem
ERROR: wrong vendorid/devid. Expected an UPD720201 or UPD720202 chip and this is not one!
reported vendorid/devid: 1912:0014
======> FAILED
[root@devuan work]# I've posted at GitHub to see if I can get a solution.
Thanks for your input.
A.
Hello:
... supplies a systemd[0] unit file to load the firmware at boot but that won't work for Devuan.
The readme says:
For using SystemD, please adjust the paths/environment variables in the unit file according to your install locations of script, loader and firmware image.
If no environment variables are set, the script presumes that loader and firmware image are co-located with itself in the same directory.
For testing, I have everything in the same directory:
groucho@devuan:~/Downloads/renesas/work$ ls
K2013080.mem
README.md
upd72020x-check-and-init
upd72020x-load
upd72020x-load.c
Makefile
check-and-init
upd72020x-fwload.service
groucho@devuan:~/Downloads/renesas/work$ Change ...
... and change
Like this?
For the firmware file ---> UPD72020X_FW=[path-to-file] K2026.mem
For the executable ---> UPD72020X_CMD=[path-to-file]./upd72020x-load
Q: where in the system should these two (firmware and executable) files be saved?
You could call the script using /etc/rc.local instead.
Yes.
If it works.
Then I'll have to run it at every boot.
At least until the patch makes it into the kernel but I don't see that happening too soon. 8^/
This issue with Renesas USB .0 cards comes from way back.
I did a dry run to see if everything was in place:
[root@devuan work]#
[root@devuan work]# ./upd72020x-load
upd72020x-load: version 0.1
usage: upd72020 -r -b bus -d dev -f fct -s -o outfile : read eeprom to file (size default is 0x10000 or 64KB)
usage: upd72020 -w -b bus -d dev -f fct -i infile : write file to eeprom
usage: upd72020 -u -b bus -d dev -f fct -i infile : upload file to firmware memory
[root@devuan work]# Usage is specified at GitHub as being this:
./upd72020x-load -u -b 0x02 -d 0x00 -f 0x0 -i Kxxxxxx.memBut I still need to find the values for -u, -b and -f.
lspci says:
groucho@devuan:~/Downloads/renesas/work$ lspci
04:00.0 USB controller: Renesas Technology Corp. uPD720201 USB 3.0 Host Controller (rev 03)
groucho@devuan:~/Downloads/renesas/work$ So it would be PCI bus 04:00.0
Yes?
lsusb says:
groucho@devuan:~/Downloads/renesas/work$ lsusb
Bus 005 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
groucho@devuan:~/Downloads/renesas/work$ So it would be Device 001
Yes?
Is the function address 1d6b:0003?
I'm at a loss as to how to put together the line.
I'd appreciate some pointers as to how to do it.
---
[0] Not "SystemD"!
Quite obvious ...
Just who do you take me for?
---
Thanks in advance.
Best,
A.
Hello:
I think I found the necessary bits/data for a solution to this but to be honest, have no idea as to how to go about it.
ie: properly and without bricking something.
Here's the link that has what seems to be a solution:
https://github.com/markusj/upd72020x-load
Here's a blog with the hows and whys:
https://mjott.de/blog/881-renesas-usb-3 … -vs-linux/
The uPD720202 chipset requires additional firmware to operate.
It must be either uploaded by the driver during initialization, or can be stored on an external EEPROM.
--- snip ---
For the first case, there exists a patch for the Linux kernel driver for this chipset to support uploading the firmware image at boot time.
But apparently, this patch never made it into the kernel and I have not found the firmware image in the linux-firmware repository.
Here's the link to the firmware file:
https://raw.githubusercontent.com/chunk … 120615.zip
Firmware file Release Note:
****************************************************************************
******* D720201 & D720202 Design Resources Release *******
****************************************************************************
Release Note June 15.2012Renesas Electronics D720201 & uPD720202
USB3.0 Host Controller FirmwareVersion : 2.0.1.3 :June 15th, 2012
Copyright (C) 2011-2012 Renesas Electronics Corporation All Rights Reserved
***************************************************************************************************Note : This firmware is for the following devices.
- uPD720201 ES 2.0 sample whose revision ID (in the PCI Configuration
Register) is 2h.
- uPD720201 ES 2.1 sample & CS sample & Mass product whose revision
ID (in the PCI Configuration Register) is 3h.
- uPD720202 ES 2.0 sample & CS sample & Mass product whose revision
ID (in the PCI Configuration Register) is 2h.
This is all I could find.
Anyone care to have alook/comment?
Thanks in advance,
A.