The debian package system is one of "distributed responsibility" where all software is installed and sprinkled over the system in the way that the package maintainer chooses. There is some structural advice, and in fact control, by the teams that accept packages into the repositories, so that in general an installed system may appear as a designed system whereas in fact that appearance is merely an emergent effect of the package maintainer's implementations of the general policies.

One of the problems with that is that the repository providers don't have a say in any particular system installation. Each system gets installed and setup the way it happens from, indirectly, the system administrator's choices of packages. Thus it's the combined effect ot the package maintainers' sprinkling of software over the filesystem.

Another effect is that composite aggregates, such as "a discrete runit init system", might not exist as an indivisible unit. Rather it emerges, if at all, from the totality of the installed packages. Sometimes people create "aggregation packages" that essentially are empty of their own content but they bring together particular other detail packages by means of utilizing the package dependency system in debian. I.e., those package mantainers try to compound particular composite aggregates.  Given your note, it appears runit is not one of those.

Thus in short, whether the combined effect of your package choices is to your liking or not is unfortunately not under control by the repository service, which is what Devuan is. There are however the issue managers, deb.debian.org for debian packages and deb.devuan.org for the devuan forked packages, that you may explore and use in order to assist the package maintainers with feedback regarding how their packages work (or not) in the particular constallation you are using.

Why not copy the installer ISO, e.g. netinstall onto a device, not as a file but fully onto the device, and then boot with that.

Next, if you come to a similar wifi issue, then use "go back" until you get the menu of tasks (which you also can get directly by choosing the "expert install" option). Then move forward using that. Feel free to come back for specific advice.

Does it work if you make the ISO a partition on the USB?

I.e. not a file... that you create an additional, separate partition on the USB, of the same size as the ISO and dd the ISO onto that partition.

Perhaps you also need to have kernel and initrd available in the other filesystem, for that boot loader to work, but the installer will look for the ISO on partitions, not as a file.

Yes you should remove the stanzas for testing and unstable.
Possibly add one for ceres.

Suite freia is currently in "testing mode" and testing is merely a symbolic link in the remote repository to freia to indicate that. You don't declare testing as a package repository. There's a great big bag of confusion lingering in using it as source point even when it perhaps seems to work fine right now.

Suite ceres, which you don''t have a stanza for, is now and always in "unstable mode" and unstable is merely a symbolic link in the repository repository to ceres. You don't declare unstable as package repository. The lingering confusion bag is somewhat smaller, but still, don't.

Note that "unstable mode" means that there is no dust of promise that the collective of package versions work together. Perhaps often they do, and where it's discovered they don't, it called a bug and it causes a flurry of activities for the package developers attempting to deal with it.

https://pkginfo.devuan.org/cgi-bin/poli … 6&x=submit

As you may see, it's a non-free package.

Please re-read the posts further above. E.g. wall "works with" xfce-terminal quite well.

It really isn't down to a choice of which (virtual) terminal is used but most significantly that the tty/pty must be owned by root. I have not used wall regularly enugh to be certain,  but that particular restriction might be a newish thing (at the timescale of wall).

The other restriction is that the user of wall must have write access to the device being written to. As mentioned above, wall will consider all /dev/ttyN and /dev/pts/N, and then write to those with applicable write access and owner being root.

The interested reader may experiment with, say

$ echo foobar > /dev/pts/3

to see which of their virtual terminal that ends up in. Or to be more targeted, they may first run

$ tty

in a shell to determin which pty device node to use for that shell, and then go crazy writing to it.

Well, wall is a traditional program, see man wall and afaiui the issue is that it behaves differently now from how it has behaved; perhaps most probably because utmp database (another traditional thing, see man utmp) has change format, and in fact might also be one of those things that the kids have deprecated.

Certainly has little or nothing to do with wall papers.

How about waiting for someone that knows something about wall? I realise it can be really tempting to flaunt your ignorance just to have a post made, but it really isn't helpful.

@Altoid, you do what you want at home, but stop immediately to post AI slop instead of knowledge.

If you don't know anything about the subject, then keep away. Noone is helped by AI slop whether it might be related or incidentally correct even. Since you don't know, you can't curate, and you just posted it because it looks convincing.

Stop that!

Hmm. the ventoy handling used to work by setting up a loop device for the ISO and then registering something within the unpacked installer initrd so as too include loop devices in the media search.... maybe @rbit has an idea of possible hands-on.

Note that the installation is in a state where you can use Alt-F2 to enter a shell within the installer's unpacked filesystem, and it may be possible to perform a rescue action there. For example, you could go there and review /sys/class/block to confirm that a loop device has been set up for the media.

Then my memory fades about what the installer needs so as to scan for the media among loop devices... again perhaps @rbit will be around for guidance and ideas.

The error message is an indication that the computer does not run the required server, which is the one registering as an endpoint for the audio service. On a good day I would remember the TLAs involved.

Bluetooth audio invloves firstly a connectiivty daemon, typically bluez, which sits as a broker between the device connection handling (the link level, so to speak) and the audio protocol(s) handler. The latter depends on your choice in audio setup. For a "pure alsa" setup you would need bluealsa daemon, and that afaik has been shit-ified so may require a bit of hands-on in its dbus linking. I'm not aware about a direct point-n-click solution, but mayby there is.

"Devuan" is trademarked, so you will need to discuss with Dyne (jaromil) about that.

Also, github is Microsoft and not acompany to keep.

Antropomorphism for the win.