Installing "daedalus preview" without network seems to clock in at 860M.

Note that the SSL credentials system is built upon "domain name control"; i.e., that you are the current renter of the proposed domain name, and in control of the DNS resolution for it.

The "http" validation done by Let's Encrypt via certbot involves them, at an external host, looking up the domain name (realupnow.com) so as to access a file via HTTP that certbot has prepared. This is only possible if you have control of the domain resolution to make that name resolve for that external host to your host and then also run an HTTP service for offering that file.

Firstly, the configuration does not include SSL setup so the service is http and not https.

Next, you will need to convince your browser that the FQDN (fully qualified domain name) realupnow.com resolves to the IP address 127.0.0.1 (or the other one if you prefer, since nginx listens on all interfaces, i.e. both lo and eth0).

Traditionally a browser would end up using the standard libc function gethostbyname to determine the IP adddress to use, and this is technically configured via /etc/nsswitch.conf and /etc/hosts. If all is per traditionally normal, then it is enough to add a line to /etc/hosts:

127.0.0.1 realupnow.com

(with a terminating newline). That would declare the DNS resolution for realupnow.com to be 127.0.0.1.

More recently browser developers have introduced new and interesting ways of resolving domain names, so it's possible that this won't work for you. In that case, you should install surf and trial this via the command line start:

$ surf http://realupnow.com/info.php

Unless of course, you rather enjoy some browser wrestling

Note that it's http without a trailing s.

Look at end of /var/log/nginx/error.log.

Directory /var/www/realupnow.com exists and is readable by www-data ?

php7.4-fpm is started?

btw, code things (like configuration files) are best displayed with code tagging rather than quote tagging since that will avoid word-wrap linebreaks that otherwise might cause confusion.

No.

Rather, please show the content (with ls -l) of /etc/ngiginx/sites-enabled/, and your nginx configuration file.

Does /etc/nginx/sites-enabled have more than the link to your config?

The alphabetically first of any pathnames there will be the virtual server configuration that handles access without proper server name ("127.0.0.1").

For testing, you may temporarily add a line to /etc/hosts to allow direct access via your external server name:

127.0.0.1 example.com

for trialling http://example.com/info.php (or even https://example.com/info.php once the SSL credentials have been set up)

Something for everyone: http://radio.garden

Perhaps you could give more than a trace of a hint of the choices for the whole installation process. That end state of booting up to a command line is fairly unusual. It suggest in particular that you opted to not install any desktop s/w but that's a bit inconsistent with being surprised by ineffectual startx.

A virtualbox VM is basically the same as a qemu VM insofar as Devuan installation is concerned. The range of h/w emulation choices might differ but that would only be an issue if you'd play fancy with that.

@fanderal, there may be some ram used by various tmpfs mounts, which use RAM but are not reported together with process RAM usage. You could check with:

df -h | grep -E 'Filesystem|tmpfs'

Note that all Devuan scripts are links to the ceres script. E.g.

/usr/share/debootstrap/scripts/daedalus -> ceres

You'll need to set that.

That's not how it works.

The s.c. round-robin is merely that the domain name has multiple resolutions that the authorative nameserver serves in different orders upon subsequent requests; apt just picks whichever it receives first.

Afaik there's no easy way to selectively exclude servers from the list.

You may however use /etc/hosts to override the name lookup with your favourite resolution. If, say, you prefer m10k.jp you would add their IP as resolution for deb.devuan.org:

160.16.137.156  deb.devuan.org

For anything more advanced I think you will need a local nameserver.

The handling of efivarfs is different in chimaera and daedalus. I can only refer to sysvinit; other init choices may result in the same or different handling.

On daedalus, the fstab entry that is identified by the mount point /sys/firmware/efi/efivars is used 3 times by the initialisation scripting:

• Firstly as an explicit "mount" by mountkernfs.sh with the name "none" but using the options of the fstab entry for /sys/firmware/efi/efivars if any,

• Secondly as a "remount", also via mountkernfs.sh and in the name "none", but invoked by checkroot.sh, and

• Thirdly as a "mount -a" by mountall.sh which uses all the elements of fstab, esp its name efivarfs.

It's the first use that establishes the mount unless fstab says remount, since that requires a pre-existing mount.

In that third use, "mount" is unhappy auto-mounting over a mount point with content. The actual mount command used is:

mount -t efivarfs -oro efivarfs /sys/firmware/efi/efivars

The previous mount stays unaffected.

However, a later remount command may refer to the mountpoint via the name in fstab even though that's not the name of the mount of that mountpoint. Thus, if you are so inclined, you might add several fstab lines like

writable /sys/firmware/efi/efivars efivarfs remount,rw,noauto 0 0
readonly /sys/firmware/efi/efivars efivarfs remount,ro,noauto 0 0
thursday /sys/firmware/efi/efivars efivarfs remount,rw,noauto 0 0

and with that enjoy your personal command language dealing with the /sys/firmware/efi/efivars mountpoint. E.g.

# mount writable ; grep efivars /proc/mounts
# mount readonly ; grep efivars /proc/mounts

Note that the name of the mount stays the same.

Afaik, chimaera is different in not mounting efivarfs by mountkernfs.sh and therefore some of this entertainment is not immediately available.