@LarsH
In my working installation I added a line to load pulseaudio in the system-mode to /etc/rc.local (we work with init, so this is possible).

Because we don't use systemd there is of course the need to write "#autospawn=no". This ist done.

I wrote about my other devuan-installation that exists to test changes of my configuration. There I deleted pulseaudio.

The gui for alsamixer, using gtk, shows two levels, that are not to movable In my last post I described a program for alsa, where it seems that the different channels are ruled, but nothing happens. Maybe a problem of the hardware.

Thank you for your answer
hmj

@fsmithred

policykit-gnome is installed, version 0.105-7
policykit-1 has version 0.105-25+devuan8

@larsH
Invoking amixer I get:

After the test I installed volumeicon-alsa. I suppose that it is necessary to delete pulseaudio to make it work?

Thank you

hmj

Meanwhile I have another computer with the same mainboard and the AMD CPU Ryzen 3 3200G. I changed the computer by other reasons than mainboard and CPU. The system is running fine. Very seldom it occurred that my usb-keyboard and mouse were lost. 
In the thread i got a lot of advices. Most of them didn't concern the reasons of my problem.  So I will give some information, what is needed to use the CPU.


1. No problem using lilo with UUID. Indeed: Using /dev/sdaX as root devices instead of UUID makes no problems.


2. The package firmware-linux-free is installed, it is not necessary to select firmware-nonfree.


3. Before putting the harddisk in the new computer, I changed my selection in /etc/initramfs-tools/conf.d.d/driver-policy from MODULES=dep to #MODULES=dep, then I updated the
initrd.img for one kernel - it grew from about 7 MB to 21 MB. I installed the packages firmware-amd-graphics and amd-microcode.


4. So I could boot using the big initrd. I have a system with 3 installations, that I can boot from the same menu. That means: the boot directory contains more initrd.imgs. Using the
small (MODULES=dep) the root device was not found. Using the big one I had nearly succeeded, because with a kernel version 4.19 the framebuffer-font (terminus 11x22) did not appear, my screen was not detected, I suppose a default mode of the X-server. Installing a kernel of version 5.4 made everything run.

5. After these steps there is no need to keep the big initrd.img Set /etc/initramfs-tools/conf.d.d/driver-policy to MODULES=dep, and rebuild the initrd.img.

@rolfie
Thank you - a lot of questions

It may be useful to give some informations about my experiences with linux-systems.

I started my linux life in the late nineties with a SuSE 5.3. Some years later I changed to debian, about since one year I'm working with devuan. I'm using lilo from the very beginning. Before starting with linux I used OS/2 and MSDOS. With lilo it was possible to start MSDOS on a second harddisk. I installed linux on a lot of computers including computers of friends. As a result I have a great experience with multiboot-systems.

- the HDD has a MSDOS partition-table. An early  copy of the first 512 bytes is written in /boot under the filename boot.0800.

- I only used devuan-kernels 4,19 for devuan, debian kernel 5.4 for buster. As I've found, AMD ryzen 3 is supported since the version 4.17. Devuan stable has on the install-dvd 4.09. That's why the devuan live dvd is booting, but the amdgpu is not supported. But: it doesn't stop, the screen is not readable, that's all.

- only one hdd and one /dev/sr0 (read and write dvds). No encryption, no LVM, nothing special. Mouse and keyboard ar connected with USB 2..

- I put the devices back in the old PC, no problem at all. I write this on my old computer.

- Firmware: Searching in synaptic, i found an amd-microcode, made non-free by amd, and a firmware-amd-graphics. Software from the backports is chosen in sources-list, but, very funny, the stable-versions for these two packages are shown, I had to force the new backport-version to activate in in the list.
Concerning graphics: amdgpu.ko exists für 4.19 and 5.4. And I've found a posting, that the microcode could bring problems when booting.

ASUS-boards have extended possibilities to configure the bios. Choosing them you can exclude the UEFI and secure-boot possibilities. Some time ago I installed another computer with an ASUS-board and an AMD-cpu, where the same procedures in the bios made the system boot without any problem - but it was no ryzen-cpu.

memtest86+.bin is booting without problem, the kernels for linux are booting, but stopping.

- The program liloconfig will write a file lilo.conf. There you find the boot device by id and the partitions by uuid -> values: blkid and etc/fstab. I've found, some years ago, the modern systems using libata would need such a unique ID. There is another possibility to give a value to a partition by using PARTUUID= ... Should I try it? Until now I just use it for the swap-partition, file: /etc/initramfs-tools/conf.d/resume. And I could try to use /dev/sda1 and so on, because, when watching the informations given bei dmesg, I find sda1, sda2 etc., not the UUIDs.

My plan: I will boot the debian-live dvd, mount the partitions needed, using update-initramfs to renew the initrd.img.

By reasons that not concern the starting problems I actually change the computer against another with the same mainboard and the same cpu. So it will last some days before I can retry the installation. I'm sure: I'll find the right way ...