You are not logged in.
I got nostalgic today and looked up some serious study music:
https://www.youtube.com/watch?v=y9EA90uF7Ek
It's both simple and confusing ![]()
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.
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.
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 -fshould be telling about running the cron.{daily,weekly,monthly} jobs.
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/anacronThat 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_ARGSThe 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.anacronFor 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.
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 -afile /usr/sbin/anacronfile $(readlink -f /lib64/ld-linux-x86-64.so.2)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 -freport 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.
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-*| | |-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 -fand 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.
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 InstalledIs there an anacron running?
pstree -ap | grep -A 3 anacronBtw, re logrotate.conf since 18 and 25 are duplicates you might want to compare with the lines before those.
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.
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=yesjust 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 -dand then even a forced run ignoring date stamping
# start-stop-daemon -v --start --exec /usr/sbin/anacron -- -s -d -n -fI'm running out of ideas
...
I've set up an anacron test myself now and we'll see in a couple of days if I have a similar problem.
Ok that looks like the "normal" installed files. Hmmmm....
Do you use apparmor or selinux? Either one can do ugly things.
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?
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 -- -sSeeing 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-partsreturning nothing, and then use
run-parts --verbose /etc/cron.weeklyto see the new, forced weekly run happening.
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
there is an executable /etc/init.d/anacron (script), and
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 >&2just 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.
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).
Just to be sure: is anacron is installed?
Create a file named /etc/modprobe.d/iwlwifi.conf with content
options enable_ini=NSee man modprobe.d for details.
(That man page belongs to the kmod package, which may and might not be installed)
Some months ago I used rEFInd to rescue an old mac mini; it might work for your troubles too...
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).
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).