The officially official Devuan Forum!

You are not logged in.

#1001 Re: Off-topic » Music » 2021-04-04 12:25:35

I got nostalgic today and looked up some serious study music:
https://www.youtube.com/watch?v=y9EA90uF7Ek

#1002 Re: Other Issues » Can't upgrade my packages from deb.devuan.org's ftp server » 2021-04-04 00:54:13

It's both simple and confusing smile

The FQDN deb.devuan.org is an HTTP mirror collection. The servers in that group are only required to serve HTTP.

If there were several FTP servers it could be useful to craft an ftp.devuan.org mirror collection, and likewise a possible rsync.devuan.org, as well as perhaps even sftp.devuan.org and uucp.devuan.org.

However, only HTTP allows the "HTTP 302 redirect" which tells the client to go elsewhere for package download.

Access for ftp, rsync, etc. requires the server either to house both Devaun and Debian packages themselves, or to have file access proxying. While the latter is not much of a technical challenge it means that any proxied packages would go in and out of the server and thereby doubling the bandwidth loading for them.

The option of housing Debian as well as Devuan is taken up by a couple of servers, typically by them adding Devuan to an already existing Debian mirroring. Then, to provide apt access for Devuan they also have the specially crafted root structure needed to handle the virtual pathnames of the Devuan merged packages.

#1003 Re: Other Issues » Can't upgrade my packages from deb.devuan.org's ftp server » 2021-04-03 07:07:26

Afaik the package repositories are not provided over ftp anywhere; not sure how you got that idea.

The package file access relies on HTTP redirect as means for pulling packages from Devuan the store or the Debian store. The principle is simply that the filename for the package files has a prefix of either pool/DEVUAN or pool/DEBIAN and a server rewrite rule that maps the former into a local access whereas the latter is returned as an HTTP redirect to a deb.debian.org service.

Some release iso mirrors offer different file access protocols such as ftp and rsync for the isos.

#1004 Re: Installation » [SOLVED] Permissions for script in cron » 2021-04-01 13:32:24

Once done, how should I test that everything is working properly?

One confirmation would be that your fstrim logging shows up.

A manual forced test would be like before, i.e. if live-config is uninstalled, then

sudo /usr/sbin/anacron -s -d -n -f

should be telling about running the cron.{daily,weekly,monthly} jobs.

#1005 Re: Installation » [SOLVED] Permissions for script in cron » 2021-04-01 13:01:12

Good. So when the start script runs /usr/sbin/anacron it actuallly runs /bin/true which is doing bugger all...

Possibly @fsmithred (who's doing refracta-base) knows something about that redirect but in any case it's wrong for your purpose.

The fix has two options:

The first option would be to change the link by:

sudo ln -sTf anacron.orig.anacron /usr/sbin/anacron

That will undo the redirect, but this then runs the risk of being undone, and the redirect comming back, if the live-config package is updated.

The second option would be to change /etc/init.d/anacron to use /usr/sbin/anacron.orig.anacron as binary; i.e., change start-stop-daemon --start command line to be

start-stop-daemon --start --exec /usr/sbin/anacron.orig.anacron -- $ANACRON_ARGS

The second option is probably a more sticky fix than changing the link, although it probably breaks if the live-config package is uninstalled.

EDIT: btw you might want to "verify" that anacron.orig.anacron is indeed the program by checking

$ md5sum /usr/sbin/anacron.orig.anacron
a16e182008f9105825af2580ab9e5ced  /usr/sbin/anacron.orig.anacron

#1006 Re: Off-topic » is the subject of that open letter taboo? » 2021-04-01 04:05:02

For sure: everyone should inform themselves, but there are already many places where one can disccuss that, if one is so inclined. No reason to fill up this forum.

#1007 Re: Installation » [SOLVED] Permissions for script in cron » 2021-04-01 02:21:32

The warning can be ignored. But I expected to see the output "Anacron 2.3 started on 2021-04-01" after the "transferring control", and not seeing that is peculiar... which architecture do you have?

uname -a
file /usr/sbin/anacron
file $(readlink -f /lib64/ld-linux-x86-64.so.2)

#1008 Re: Installation » [SOLVED] Permissions for script in cron » 2021-04-01 01:17:25

Right; that's the right one... next check would be first to verify that the problem is with anacron, by seeing

sudo /usr/sbin/anacron -s -d -n -f

report nothing.

Then try the following:

sudo env LD_DEBUG=libs,files /usr/sbin/anacron -s -d -n -f >& /tmp/strace.log

... and paste somewhere

That should be a debug listing of the loading of dynamic libraries including how they are looked up in the file system.

#1009 Re: Installation » [SOLVED] Permissions for script in cron » 2021-04-01 00:52:19

Hmm. obviously your /usr/sbin/anacron dies before it starts, or while it about to start, seemingly at the point where it should allocate memory.

However the "brk(NULL)" which should follow "munmap()" doesn't show up and instead the "exit_group()" showing premature exiting, and that suggests borked linking rather than out of memory; i.e., a technological mismatch with the dynamic libraries rather then a functional error.

Which libc6 do you have?

ls -l /lib*/ld-linux-*

#1010 Re: Installation » [SOLVED] Permissions for script in cron » 2021-04-01 00:11:29

|   |   |-grep,13714 --color=always -A 3 anacron

that was the grepping itself, so no "real" anacron running.

Try again with

sudo start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d -n -f

and verify that that only gives that same one line of output...

Check then at end of /var/log/syslog to see if there's an explanation.

Following that we'll need to go deep diving with

sudo strace -f start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d -n -f >& /tmp/strace.log 

Possibly you'll need to install the strace package first.

That log will be long as it includes all the system calls by the execution, so the best is if you can paste it somewhere rather than include here. It looks like there's something just a little bit off on your system and this will give as a haystack to look in.

#1011 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-31 23:08:07

My test showed nothing ...

But I realized that your forced running only resulted in a "Starting..." message, and not like the expected

$ sudo start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d -n -f
[sudo] password for ralph:
Starting /usr/sbin/anacron...
Anacron 2.3 started on 2021-04-01
Will run job `cron.daily'
Will run job `cron.weekly'
Will run job `cron.monthly'
Jobs will be executed sequentially
Job `cron.daily' started
Job `cron.daily' terminated
Job `cron.weekly' started
Job `cron.weekly' terminated
Job `cron.monthly' started
Job `cron.monthly' terminated
Normal exit (3 jobs run)

Which package version do you have?

apt-cache policy anacron |& grep Installed

Is there an anacron running?

pstree -ap | grep -A 3 anacron

#1012 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-31 22:42:33

Btw, re logrotate.conf since 18 and 25 are duplicates you might want to compare with the lines before those.

#1013 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-31 22:26:53

You seem to mix up non-root and root user; the user's cron jobs ar run as that user and only root's cron jobs are run as root.

The anacron problem is not that problem, since it gets run by root.

#1014 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-30 22:38:59

I keep my apparmor purged. I would purge selinux too had it been possible; it stays disabled.

For testing you might want to try changing /etc/default/anacron to say

ANACRON_RUN_ON_BATTERY_POWER=yes

just for the possibility that anacron misreads something.

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 -d

and then even a forced run ignoring date stamping

# start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d -n -f

I'm running out of ideas sad ...
I've set up an anacron test myself now and we'll see in a couple of days if I have a similar problem.

#1015 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-30 21:01:32

Ok that looks like the "normal" installed files. Hmmmm....

Do you use apparmor or selinux? Either one can do ugly things.

#1016 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-30 10:27:49

Peculiar. Yes, the run-parts .. command if run as root would avoid the permission errors, but your test shows that the dev-fstrim does get invoked, which is enough of detail.

yes, you can use /var/log/WTF for persistent logging.

Peculiar. How do your /etc/anacrontab and /etc/default/anacron look?

#1017 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-30 00:25:16

So apparently the anacron start/stop script gets invoked every hour as it should, but it fails to perform.

Add set -x on a line after your added date ... in /etc/init.d/anacron, and then wait for next invocation which now logs the whole script execution to /tmp/WTF. This in particular should have the line:

+ start-stop-daemon --start --exec /usr/sbin/anacron -- -s

Seeing that to be so you would next try to force run the weekly scripts again. First ensure any previous run has completed, with

pgrep -a run-parts

returning nothing, and then use

run-parts --verbose /etc/cron.weekly

to see the new, forced weekly run happening.

#1018 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-28 23:08:09

Ok. cron.log shows that it finds and loads and processes the /etc/cron.d/anacron scheduling, which would trigger the start/stop script if

  1. there is an executable /etc/init.d/anacron (script), and

  2. the pathname /run/systemd/system is not a directory (eg doesn't exist)

To verify that you would add the following two lines into the script /etc/init.d/anacron:

exec 2>>/tmp/WTF
date -R >&2

just after the PATH=... line.

That should cause an hourly logging to appear in the file /tmp/WTF, and that file will also contain any other stderr output that the script run generates.

In detail: the exec 2>>/tmp/WTF line associates standard error (for this script run) in append mode with the file, and the date -R >&2 line makes the date program issue a time stamp in RFC 5322 format to standard error. Any further error message from the script will be appended subsequently.

#1019 Re: Installation » [SOLVED] Permissions for script in cron » 2021-03-28 21:20:32

Good. As you might know, 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. Since the scripts are not run it is possible that this "chain of control" is broken; that cron fails to run anacron or that anacron fails to run the script(s).

The running of 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. Afaict looking at my such script, it includes the particual misfeature of not running anacron imperatively but rather making this dependent on the absence of something. (A small-brain idea appearing as attempted solution to cater for a range of possible installation sites other than this one, but not bad enough for the effort of forking the package)

So, if that something is present then your set up does not run anacron as it should and 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.

If the preconditions for the regular run/start of anacron are there, the next point of call would be to review and confirm anacron local configuration, at both /etc/anacrontab and /etc/default/anacron. And for debugging purposes also add/change the start/stop script so that it makes some output to, say, /tmp/WTF (eg a date stamp) whenever it's run. Further, to speed up the testing cycle you might set it up for daily trimming rather than weekly since the auto-magic is supposedly the same for that (as configured in the typical installed /etc/anacrontab).

#1021 Re: Hardware & System Configuration » [SOLVED] Changing a parameter in /sys/module » 2021-03-27 12:50:24

Create a file named /etc/modprobe.d/iwlwifi.conf with content

options enable_ini=N

See man modprobe.d for details.
(That man page belongs to the kmod package, which may and might not be installed)

#1022 Re: Installation » Non Booting GRUB on Beowulf » 2021-03-26 20:48:27

Some months ago I used rEFInd to rescue an old mac mini; it might work for your troubles too...

#1024 Re: Other Issues » Runit » 2021-03-23 21:29:42

I don't know how runit works, but for the " in a VM window, so I can't switch tty" part of the problem I would suggest that you start qemu with -serial mon:stdio so that the qemu monitor is available in the start terminal. Then use ^C a to "activate" it, and thereafter use verbatim commands like sendkey ctrl-altl-f2 (literally like that) for keys and key combinations that are not avialabable from the keyboard.

Or, you might want to use -serial mon:unix:/tmp/myvm instead to have the console available on the socket /tmp/myvm which you'd connect to with socat - unix-connect:/tmp/myvm or nc -u /tmp/myvm and then operate the qemu monitor through that (in the same way).

#1025 Re: Hardware & System Configuration » [SOLVED] USB 3.0 card, external drive and unknown algorithms » 2021-03-23 20:52:18

Did you try using the USB "address"? The above example shows bus 2 device 7 funciton 0 (well, the last is not shown but my guess).

Board footer

Forum Software