Ah, so you don't want help. Fair enough.

@zapper: I'm guessing you need to resize the "home" logical volume to use up all the volume group space, and you then need to enlarge the filesystem inside the logical volume to fill all available logical volume space.

Possibly it all can be done in a sinlge command, something like:

# lvresize -l 100%VG -r $LVM

where you replace $LVM with the identity fo the logical volume.

A backup might be handy.

The labels "excalibur", "excalibur-security", "excalibur-updates", etc are known as "codenames" and as such they identify "repositories" (not "distributions"). Each system (yours or mine) is set up with a package system that looks into one or more repositories for packages, which it (i.e. your system or my system) organises by package versions so as to get "the most recent version" of any package across those repositories.

A "distribution" is rather some particular collage of packages from some particular collective of repositories, that is formed and published so as to make a particular end user experience (and typically allowing for a smaller range of variations in experience).

HTH, Ralph.

Right. That's wrong for debootstrapping Devuan. You need to use Devuan's debootstrap for that.
Where did you get that "excalibur" script from?

Which deboostrap version are you using?

EDIT: the reason I'm asking is because "merge_usr" is defined in the "functions" that come with the debootstrap installation, since excalibur.

Perhaps you could show the tail end of the debootstrap.log file, for the failing case.

You install libdvd-pkg. It provides libdvdcss2.

In summary: version 1.6.3-3 has been built and will be available in a couple of days with the sources.list reference:

deb http://deb.devuan.org/devuan experimental main

Note that it is "/devuan" rather than "/merged", since the experimental repository is not merged. Further, I should warn that adding such sources.list lines willy-nilly can bring unplanned hair loss.

At the moment only the plugin package 1.6.3-1 is available.

The experimental building pipeline is for "all" architectures: amd64, arm64, armhf, i386, ppc64el and riscv64.

If you have another architecture, you may download the ".dsc", "tar.gz" and "tar.xz" files to a directory, cd into that and use the "debuild" schemata to build, like the following:

dpkg-source -x fftrate_1.6.3-3.dsc
cd fftrate-1.6.3
debuild -k0x12345678

where  "12345678" is replaced by your GPG key ID. That'll leave the build residue in the parent directory and the work tree fftrate-1.6.3 can be removed. Note that you may have to also install build dependencies; ideally it will tell you which to install. If it doesn't then please tell me (because then I have failed to declare that dependency)

Great. Is that github project yours, or something you could add to? As of principle it's best when "upstream material" is added to upstream; otherwise it ends up as packaging patch(es) which is much less accessible for people.

In this case it would also be possible to make an upstream-based fork within the packaging project to include these things (and maybe some of the other good documentations you have written).

Or even better would be that you create your own project at, say, git.devuan.org (or codeberg.org) as a fork of the github upstream, and then add your documentations and man pages to that. My packaging project can track that instead.

Note that "side documentation", including man pages, may well reside at top level or perhaps a "doc" directory,  without particular format constraints. Often it's plain text files or markup files that get gzipped in the packaging. In the packaging it's typically placed in /usr/share/doc/$package/ (except the man pages of course)

Thanks. Yes it's now packaged and added to Devuan experimental.

It's using quilt packaging with a minor source touch-up patch to resolve  compiler complaints, and a separate "packaging" patch that sets it up for gbp-buildpackage. Presently only the plugin package is built since the binaries lack man pages, and I'm looking into making a man page for the plugin.

I'm thoroughly confused by your explanation. It surely would be simpler to assign two different IP addresses to the two NFS servers (whether or not they are connected on the network concurrently), and then have two alternative mount declarations on a client, which could be onto the same mount point if that's your intention.

In my mind, that would be the simple way. Especially compared to whatever is involved in chasing two or a few modules to fit your kernel.

But that may be of no help to you I suppose.