Mmm; it's rc-update that complains.... That's a different place with kindof the same structure.

I'm guessing you have two files in /etc/init.d where one says it provides "udev" and the other that it provides "$udev" (where the latter is a virtual service name). Probably you don't need both, perhaps it's a matter of keeping "eudev" and moving away "udev" from there.

How does the installer say that? I.e. in what way?

If you are at all interested in getting some help you do need to start reporting actual error messages.

33.3 MB for "/" does seem a bit tight, but I'd suspect rather that /dev/sda is write protected.

Use C-A-F2 to get a shell prompt and inspect /var/log/syslog, and also, run "fdisk /dev/sda" to check out the ablility to write.  Note that the partition table to be written will reside on the first 1 Mb of the device.

@devuan_dk_fan: With "/opt" in $PATH one would expect to find some binaries in "/opt" such as for instance "/opt/binary1" and "/opt/binary2" ... but you seem to expect something else?

Did you ever look into what $PATH is, and how it isused? You find $PATH in many operating systems (although some will name it %PATH% instead). All in all it's part of the magic of running programs without naming them by absolute pathname, but merely naming them with relative path.

Like, with your "/opt" setting, you could type "waterfox/waterfox-bin" as a command to run the binary linked as "waterfox-bin" in the directory "waterfox/" relative to some direcotry in $PATH (namely "/opt").

Have you tried all different ttyN ? Traditionally graphical session is at tty7, but I have an inclination that sddm deviates from that and uses tty2. I would guess you have keyboard shortcuts for at least tty1-tty10 so you can check those easily. checking further is a little more complex (though afaik debian kernel sets up 64 VTs to play with).

I think it does depend on whether or not the Ventoy partition is an exfat with label "Ventoy".

That which is wrong is that you are using a git clone URL as if you have set up your ssh authorising access for that project, which apperently you haven't.

The public cloning URL is https://git.devuan.org/devuan-editors/devuan-art.git
Try using that instead.

I think we should thank @lafat for offereing tactical level feedback, which is perfectly good to get for a tactical management suborganisation.

Of course such a thing does not exist in the name of Devuan. Instead there are only a number of Devuan fork maintainers who each focus on their packages, a small group of people keeping up the build and repository system and the much larger group of "normal" people that in their minds identify as Devuanites to varying degrees from the perspective of using the Devuan repositories.

All thoughts on coherence and "quality" of desktop environments and "distributions" will fall on those who take an interest in that. It's not something seen as "a Devuan concern".

Rather, Devuan's (qua organisation) strategic objective is merely to counteract the technological lock-in peddled by and with the systemd crowd, by taking positive action that includes both technical work (to bring about and maintain working alternatives) and community oriented activities that largely are aimed at maintaining an active and engaged community.

I'm sure we all also recognise that at a forum like this, anyone at times will capture their thoughts and feelings in words quicly and strongly, and submit without much post-editorial attention to how the words will land in the readership. Evenso, I want to think of every post as intended towards improvement.

I guess you won't be interested but as you may know, the action path for Devuan would be for a maintainer to set up a fork project (at git.devuan.org) to sort out its utility in Devuan. I anyhow invite you to take on that role for this package (as well as fftrate packages if you like).

I think bluealsa gets started via dbus, But I haven't explored it.

Note also that In excalibur bluez-alsa-utils provides bluealsa (without systemd dependency).

I prefer asciidoctor