It all happens in the partitioning step:

1. first you declare partitions for use in raid setup

2. then you set up the raid device linking it to its partitions

3. and then you partition that into the filesystem partitions you want

"installing the base system" at 6% is where packages are loaded and validated; nothing yet unpacked.
If it breaks there, then it's due to one of 3 things:
  1) that your media is "corrupted"/broken or
  2) that the target partition is too small or broken, or
  3) that the RAM (which holds the installer system itself) is too small.

libsemanage-common_3.1-1_all.deb is a mere 20K, and loaded after maybe at about 30Mb has been used on the partition.

Unless you make a mistake when partitioning, it would suggest that your media is corrupted.

The published ISO image does not come with that corruption (as evidenced by that it's the same image since start and more than a few people have used it successfully)
You need to verify your download of that image using the published SHA256SUM, and you may well need to verify the physical media it is placed on as well.

Ok;
.. so I choose language (english), location (US.. lying), locale (en_US.UTF-8), no additional; just "continue"
.. I skip past access software
.. I skip past speech synthesizer
.. I do configure keyboard (am english)
.. it skips selecting layout automatically
.. I let it detect media
.. I load the default components only (select nothing of the extras, then "continue")

are we same enough so far?

So you have difficulty with the chimaera netinstall iso? Do you want assistance?

@Head_on_a_Stick, when you get your systemd pants on you really get fanboi tedious; taking any odd behaviour from the systemd bug collective and cast it as an advantage over something else with sysvinit. Now you seem to want to claim that overriding a service definition is the same as disabling a service?

Yes, sysvinit does not have overriding, and I can see how you might use that to override the service definition in a way that ends up not starting the daemon. Obviously this would compete with any prior overriding, but presumably overriding is actually quite unusual to use for any other purpose? (Otherwise I'd expect someone would have revised the rc script to include it)

I suppose a sysvinit way to achieve a similar override could be to add a premature exit into the startup script. Doing so would likely have the effect (advantage?) that the package installation system would query about that change upon upgrade, and you would then again automatically reconsider whether or not that "override" remains appropriate.

Clearly neither systemd nor sysvinit have a way to block package installation from installing into the boot sequence. I think this is more a result of the Debian principle to deploy services when installing them.

In any case, I'd agree that apt-get purge apparmor is best here, and that it also seems to need a security=none setting (or similar) on the boot command line to make the kernel bypass apparmor kernel code.

A minimalistic approach might be to review the ArchWiki page on ppp, install pppconfig and configure.

Thanks for noticing. Since it is merging rather than mirroring, there is a short lag before debian packages appear in the devuan repositories.

If you installing without "recommends", you might also need the explicit

apt-get install zfs-modules

to trigger their building.

No, the installer-iso is still version devuan_chimaera_4.0.0_amd64_desktop.iso.

I think @Camtaf is talking about desktop-live, which is a different alternative that many people prefer.

Let me drop two tidbits as a matter of background knowledge:

a) the domain name deb.devuan.org, which is the right one to use, resolves into a collection of alternative IP addresses (ipv4 and ipv6). During any apt operation, every server request will use some IP from that list, and then that server will be the one providing the response to that request.

b) the apt system has meta-information files that tells "where" (in networking sense) the packages are. For Devuan those URLs include some forked packages that are directly served from Devuan package pool mirrors, and a majority of packages that Devuan mirrors handle by means of redirect URLs, to be served by Debian's package pool mirrors.

Your reported case for example shows that chromium  is not forked but retrieved via such a redirect, and apparently that redirect pin-pointed http://debian.bio.lmu.de as redirection target. I.e., the Devuan mirror that was picked offered that redirect, and evidently there was some issue with access to 2001:4ca0:4300::1:22 (aka http://debian.bio.lmu.de)  at that time.

Which iso?

As the key issue was fixed without needing ISO remake, the trial remakes were removed.