Oh, so perhaps the tool is merely using uptime as a way to check if the user has full sudo access. Hm, I guess "sudo -l /actual/command/to/run ; echo $?" is more obtuse...

The logic says this:
If (file $TABFILE does not exist) or ( $TABFILE is older than /proc/1) then,
display the error message
return a non-zero result
end-if.

So the creation date of process number 1 (the init, so most likely sysvinit, but doesn't really matter for merely checking the date) is when that process started. So if the tab file (I'm assuming crypttab, as in encrypted filesystem table, but I could be wrong) is older than the current init, then that is a failure state for your check. So it sounds like, in conjunction with the comment, that we need something else to happen first before cryptroot-unlock will work successfully.

So it's not systemd-related. But I don't know the specifics of cyrptroot or dropbear so that's probably all I can help you with.

If you can stomach having the entirety of the kde stack for one program: kde-config-cron. That looks like it's in Ceres, so it's probably in the others too.

And if you're incredibly desperate, you could adapt the npm instructions and run a web application that hooks in to the crontab: https://www.techrepublic.com/article/ho … emote-use/. I have successfully installed npm (again, just on Ceres) for a different application.

Although it would be worth investigating setting up the correct sources.list contents for the jessie repos (is that oldoldstable?) and seeing what all would happen if you tried to install gnome-schedule from it...

I am concerned that apt has been modified to use systemd. Would anyone well-versed in the subject try to explain it to me? I will also at some point to try to look at the source, but if anybody could summarize, that would help everyone else out!

I am subscribed to this thread and I got an email that golinux had replied to the thread.

Regarding starting and stopping daemons, I've learned that sometimes you have to wait between starting it. A "restart" implementation may not wait long enough for the hardware in question. I've definitely seen services that cannot be restarted, only stopped and then started.

For Ceres, I found gvfs-backends:

$ apt-file list gvfs-backends | grep -iE 'smb|samba'
gvfs-backends: /usr/lib/gvfs/gvfsd-smb
gvfs-backends: /usr/lib/gvfs/gvfsd-smb-browse
gvfs-backends: /usr/libexec/gvfsd-smb
gvfs-backends: /usr/libexec/gvfsd-smb-browse
gvfs-backends: /usr/share/GConf/gsettings/gvfs-smb.convert
gvfs-backends: /usr/share/glib-2.0/schemas/org.gnome.system.smb.gschema.xml
gvfs-backends: /usr/share/gvfs/mounts/smb-browse.mount
gvfs-backends: /usr/share/gvfs/mounts/smb.mount

Based on my quick searching, it appears that gvfs-backends is not required by any of the other gvfs packages, which doesn't make too much sense.

$ apt-cache show gvfs\* | grep -iE 'Package|-backends'
Package: gvfs
Suggests: gvfs-backends
Package: gvfs-backends
Filename: pool/DEBIAN/main/g/gvfs/gvfs-backends_1.44.1-1_amd64.deb
Package: gvfs-fuse
Package: gvfs-bin
Package: gvfs-common
Package: gvfs-daemons
Suggests: gvfs-backends
Package: gvfs-libs

So maybe that's the package in question for Beowulf.

Those aren't a systemd thing necessarily. You can help enforce using the old style names with a kernel boot parameter: "net.ifnames=0" but for some reason it's slipped my mind where that goes on a Devuan system, unless you want to go manually edit /boot/grub/menu.lst. On CentOS 7 it would just go in the variable GRUB_CMDLINE_LINUX in file /etc/sysconfig/grub and you would run grub2-mkconfig -o /boot/grub2/grub.cfg

If you want to go the manual route, for every "kernel" line in menu.lst, you would add the parameter "net.ifnames=0" at the end.

kernel      /vmlinuz-5.4.0-4-amd64 root=/dev/mapper/d2--03a--vg-root ro net.ifnames=0

But I'm sure there's an easier way to get that attribute in Devuan for every kernel entry. Maybe somebody can come rescue me from my half-knowledge.

This sounds like it's related to the group permissions. Is your user a member of group "netdev"?

$ getent group netdev
netdev:x:960600009:bgstack15-local,bgstack15,lastack13,amarkus,...

According to file /etc/dbus-1/system.d/wicd.conf

<!-- /etc/dbus-1/system.d/wicd.conf -->
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>

        <policy user="root">
                <allow own="org.wicd.daemon"/>
                <allow send_destination="org.wicd.daemon"/>
                <allow send_interface="org.wicd.daemon"/>
      <allow send_destination="org.wicd.daemon.wireless"/>
      <allow send_interface="org.wicd.daemon.wireless"/>
      <allow send_destination="org.wicd.daemon.wired"/>
      <allow send_interface="org.wicd.daemon.wired"/>
        </policy>

        <policy context="default">
                <deny own="org.wicd.daemon"/>
        </policy>

   <!-- This Unix group will have permission to use Wicd's gui -->
        <policy group="netdev">
                <allow send_destination="org.wicd.daemon"/>
                <allow send_interface="org.wicd.daemon"/>
                <allow send_interface="org.freedesktop.DBus.Introspectable"/>
                <!-- The Introspectable allow shouldn't be needed here, but
                     it seems that a few distributions aren't yet allowing
                     it in their hal configs, and we need it here, so... -->
        </policy>

       <!-- Comment the block below if you do not want all users logged in
            locally to have permission to use wicd-client.  This ignores the
            group based permission model defined above for the "netdev"
            group. Note that this only applies if you are using ConsoleKit -
            if you do not have ConsoleKit installed and in use, then this
            block makes no difference either way.  -->

        <policy at_console="true">
                <allow send_destination="org.wicd.daemon"/>
                <allow send_interface="org.wicd.daemon"/>
      <allow send_destination="org.wicd.daemon.wireless"/>
      <allow send_interface="org.wicd.daemon.wireless"/>
      <allow send_destination="org.wicd.daemon.wired"/>
      <allow send_interface="org.wicd.daemon.wired"/>
      <allow send_interface="org.freedesktop.DBus.Introspectable"/>
        </policy>

</busconfig>

Which is a little obtuse to me, but the item you're looking for, "org.wicd.daemon.wireless," is allowed to root user and group netdev.

If you need to add your user to netdev, you will need to log out, or possibly restart your display manager (which logs you out), or possibly even reboot.

sudo usermod -aG netdev PengouinPdt

And if your display manager is lightdm:

sudo service lightdm restart

Moving contents from home to work: seems like a security risk to me!
Move home directories from one system to another? You mean like an nfs automount? Especially if you already have to have same uid and gid. But who actually cares about same username and group name? That's not a technical requirement for file permissions. Is that a limitation of systemd?

And so are these systems going to be pre-configured to read external media for these json files? Who is going to pre-load the signing certs into the systems? What's even the point....

That was one of my early issues with Devuan Ceres (which was based on Beowulf at the time) as well! I remember making a .desktop file for my xdg autostart to run "pulseaudio -start" I think it was. Nowadays I've moved to alsa and not Xfce, so I have different types of issues now.

I know people that would actually like this, and that aren't just 10-year-olds.

And ponysay seems way better than cowsay. Just sayin'... ANSI art!