That's my current key and it has a good signature here. MIT's pgp is frequently down. I just tried to get my key in a web browser, and it failed to find it. Never mind that I uploaded it to pgp.mit.edu when I created it.

Try subkeys.pgp.net and try refreshing your keys. Last year I updated the expiration date on the key but it didn't get updated on the keyserver until later. (mit was down at the time)

Using --refresh-keys will update your local copy.

Do you happen to know what command that executes? If not, we should figure that out. What terminal is it, what desktop environment are you running? Maybe a right-click on that icon will let you see a list of Properties that will show the command.

Does the error message appear inside the terminal that you just opened, or is it in a notification window or other popup?

If you have a terminal that will let you run commands, run the command that the panel icon uses to open a terminal and see if it gives you any more information.

Maintainers Guides
https://git.devuan.org/devuan/documenta … aintainers

The error message is coming from bash - the command providing the error is the first word in the error message. You get 'command not found' if ash is not installed. If you're sure you installed it, then something weird is going on or you didn't notice when it got removed.

If you create an empty /bin/ash, you should then get 'permission denied' because it's not executable. If you make it executable, then the error messages go away, but of course it does nothing.

A few messages above, you said 'ash' gives you a root shell after aliasing 'su'. The prompt that you pasted is a bash prompt. The ash prompt is just # or $ for root or user, respectively.

Note: You can also get 'command not found' with the new default su setup if the command you're trying to run is in an sbin directory and you used 'su' instead of 'su -'. Your alias works around this.

I would not boot that system again. Check it from another system, maybe a live-CD or live-USB.

You might want to run from live media from now on, so that you have a read-only system. That way if someone is able to install software on your system while you are running, you can just reboot to go back to the clean state. And figure out how to keep them from doing that. To save files, you can either set up a persistent volume or plug in another usb stick.

Some of your questions are answered in the release notes. (grub, su)

You can run without any policykit or dbus, but removing /etc/pam.d/ might have been a bad idea. This link is provided for general information. You don't want to use the nodbus isos I made because they are not secure. (ssh is running and the password is public)
https://dev1galaxy.org/viewtopic.php?id=2158

Install libpam-elogind

Another option is to start with devuan and kalify it with this script.
https://github.com/LionSec/katoolin

I tried it in January and it works. I think the script gives you choices of different groups of packages to install, and I think I either chose not to install all of them or could not install some of them. There's a list of missing packages in my work directory, but I don't recall why they are missing.

When I say testing, I mean whichever suite is in testing at the moment. I absolutely DO NOT mean that 'testing' should appear in your sources.

USE CODENAMES!

Whether or not you use chimaera or ceres or both is not my decision. If you're ok with unexpected breakage, then go for it.

Devuan doesn't have a freeze. We bust ass up to the last second to put forked packages into the repo before release. OK, slight exaggeration there. The time between "no new packages go into repo" and actual release is about a week, maybe two. And the time between debian testing freeze and devuan release is long. (slight understatement there)

I don't know if it's still common, but one thing people used to do with debian is run a mixed testing/unstable system. That's basically a testing system with unstable repo enabled but pinned to a lower priority. That way, you can pull selected packages from unstable to get fixes faster while at the same time avoiding pulling packages from unstable that will break stuff.

Such an arrangement will work in devuan only until debian testing goes stable, and then we're behind by one release. If you switch to the next devuan testing at that time, the forked packages won't be ready for that release. So when bullseye goes stable, I guess you would either stick with chimaera or go with pure ceres. I'm not sure which would be the least painful.

I think the newer versions will work on wheezy. If not, there are older versions here: https://sourceforge.net/projects/refracta/files/tools/

I think the installer will work on all releases. Newer versions of refractasnapshot should work on wheezy, but they might not work on jessie. There was a function to edit init to work around a change in util-linux, and that function has been removed. That should not affect wheezy.

Are you sure it's not this issue?
https://dev1galaxy.org/viewtopic.php?id=1688

Here's the SDK page on the new git:
https://git.devuan.org/devuan-sdk

Here's a discussion about using live-sdk. I haven't looked at it in a long time, and there may have been some changes that were not documented. If you clone the live-sdk repo and use one of the existing blends, it should work. This is how the official devuan live isos are made.
https://dev1galaxy.org/viewtopic.php?id=551

The easiest way to make an installable live-iso is to install a system the way you want it. You can do it on hardware or in a VM. Add refractainstaller and refractasnapshot. Run refractasnapshot, and it will make the iso.
https://refracta.org/docs/readme.refractasnapshot.txt

Using the testing suite in a business is probably not a good idea. There may be times when the system is temporarily broken while you wait for new packages to arrive in the repo. If you need a kernel newer than 4.19 you can get 5.x from beowulf-backports.