Odd. I did all the above. What I don't quite understand is that the "apt upgrade" didn't update or install anything, and the executable I'm trying to run still can't find libcrypt.so.1. Here are some outputs:

dpkg --print-foreign-architectures
i386

apt policy libcrypt1
libcrypt1:
  Installed: 1:4.4.33-2
  Candidate: 1:4.4.33-2
  Version table:
 *** 1:4.4.33-2 500
        500 http://deb.devuan.org/merged daedalus/main amd64 Packages
        100 /var/lib/dpkg/status

dpkg -L libcrypt1
/.
/lib
/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu/libcrypt.so.1.1.0
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libcrypt1
/usr/share/doc/libcrypt1/changelog.Debian.gz
/usr/share/doc/libcrypt1/changelog.gz
/usr/share/doc/libcrypt1/copyright
/lib/x86_64-linux-gnu/libcrypt.so.1

Here's the ldd output of the executable:

	linux-gate.so.1 (0xf7edb000)
	libnsl.so.1 => /lib32/libnsl.so.1 (0xf7eb3000)
	libdl.so.2 => /lib32/libdl.so.2 (0xf7eae000)
	libm.so.6 => /lib32/libm.so.6 (0xf7da9000)
	libcrypt.so.1 => not found
	libutil.so.1 => /lib32/libutil.so.1 (0xf7da4000)
	libpthread.so.0 => /lib32/libpthread.so.0 (0xf7d9f000)
	libc.so.6 => /lib32/libc.so.6 (0xf7a00000)
	/lib/ld-linux.so.2 (0xf7edd000)

As you can see that's still not found. Any ideas? Thanks!

Tom

OK. It turned out that that there was a newer version of that installed (libhcrypto.so.5.0.0). Creating a link to that named libhcrypto.so.4, plus a few other similar ones got the executable running. Seems like a somewhat ugly hack, but did in fact seem to work.

Thanks!
Tom

OMG you're totally correct. That came up in a google search for "libhcrypto4 bookworm" and I didn't notice that difference. Thanks. Just uninstalled that.

Tom

Thanks for the reply! I'll have to figure out how to best handle this one.

What I was hoping to use ld for was to see if there are any other missing libraries in the executable. That's something I'd always done in the past. Is that no longer possible?

Thanks!
Tom

Thanks for that! If I decide to even do this I might try that.

You're correct that this really isn't really an issue. When a customer of ours ends up needing that much space we have them add a new disk and just add it to our LVM logical volume as a raw disk with no partitions at all. We did however have one customer that increased the existing disk to well over 2 TB which we were not able to fully use due to the DOS partitions, and VM doesn't let you get it back.

I was hoping to avoid that but I'm starting to think it's not worth it...especially if it gets into changing stuff to use EFI etc. That could even end up causing worse issues.

Thanks again!
Tom

What also bothers me is that, unless I'm misreading it, the /etc/cron.daily/apt-compat script appears to do that random sleep regardless of whether or not any of this is enabled. That seems odd to me.

Again, this was from a rackspace Buster VM and they apparently had the unattended upgrade stuff installed. I've never installed that on Devuan installs I've done from scratch.

Tom

Thanks! I'm sure you're correct, and given that this was starting with a rackspace server I really have no option to do an install from scratch. Having said that, it's actually a rather simple LAMP server for the most part and I seriously doubt it would ever cause me any problems.

The only reason I noticed was that I set up a user specifically for rsync backups that's restricted to a chroot in it's home. That requires having a few binaries and libraries installed in the home. That failed at first because I had /bin/sh as the users shell and needed to change that to /usr/bin/bash.

Only the systemd and freedesktop.org asshats could manage to make such an asinine decision to screw with shit that's been in place as long as that. I use Gentoo on my own machines which, by default, doesn't do that BS either. Thank God for distros like that, and for the wonderful maintainers of Devuan!

Thanks
Tom

I figured I'd add to this old post to report my recent experience with this. I've been able to convert a Rackspace Debian Buster to Devuan Beowulf successfully, and wanted to outline what I did. For the most part is mostly just involved converting the original VM based on this:

https://www.devuan.org/os/documentation … owulf.html

For the nova-agent I used your init script above and enabled it with update-rc.d...thanks for that! Seems to be fine and, given my understanding of what that does I really doubt that it's lack of any "stop" functionality makes any difference. I also disabled those cloud services.

One additional thing I did was to get the Rackspace driveclient working. We downloaded and installed that, but just as with the nova-agent, they had no traditional init script. I was able to come up with this one which seems to work fine, and it appears that backups are working OK:

#!/bin/sh
### BEGIN INIT INFO
# Provides:          Rackspace Backup Agent
# Required-Start:    networking
# Required-Stop:     networking
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Rackspace Backup Agent
# Description:       Rackspace Backup Agent
### END INIT INFO

# Using the lsb functions to perform the operations.
. /lib/lsb/init-functions

export HOME=/root

PIDFILE=/var/run/driveclient.pid

case "$1" in
    start)
        log_begin_msg "Starting Rackspace Backup Agent..."
        start-stop-daemon --start --quiet --oknodo --pidfile $PIDFILE --exec /usr/local/bin/driveclient -- --daemon
        log_end_msg $?
        ;;
    stop)
        log_begin_msg "Stopping Rackspace Backup Agent..."
        start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE
        log_end_msg $?
        ;;
    restart)
        $0 stop
        sleep 1
        $0 start
        ;;
    status)
        if [ -e $PIDFILE ]; then
            status_of_proc -p $PIDFILE driveclient "Rackspace Backup Agent Service" && exit 0 || exit $?
        else
            log_success_msg "Rackspace Backup Agent Service is stopped"
            exit 3
        fi
        ;;
    *)
        log_success_msg "Usage: /etc/init.d/driveclient {start|stop|restart|status}"
        exit 1
esac

All seems to be working great. Rackspace without systemd lives!

Tom