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.

Great. Welcome on board!
I'm probably doing things wrong yes, and need to retire.
We can rely on you taking over this?

Just in parenthesis: all the installers do still work fine as long as you avoid network mirror backing during installation. It of course means that you'll end up with a rather minimal system, but it's still one where you can use the manual patching (wget + dpkg) before using the network mirroring/access the first time.

I disagree: it's a totally useless question.

Obviously there has been some kind of process failure when everyone in the whole community, including you and Ogis1975 as well as myself, failed to notice that the repository key was about to expire.

You don't have to ask about that. Rather you should ask yourself: "how can I help in the future?" and then act towards that.

The first step would be to determine which, if any, installation use case(s) need attention.