I found the solution.

This file /etc/rc.digitalocean.d/droplet.conf must be edited because it overwrites the hostname=“new.host.name” entry in /etc/rc.conf

Regards

Although this will work, is this really the correct way to do it? Considering that load_rc_config() in rc.subr in fact will try /etc/rc.digitalocean.d/ before trying /etc/rc.conf, I’m under the impression the intended behavior was to override hostname in /etc/rc.conf.

Feel free to correct me; I only took a quick glance at the rc scripts.

The problem appears to be in the /etc/rc.d/hostname script

...
elif [ -n "`/bin/hostname -s`" ]; then
        return
...

if the hostname is already set, then it aborts, so no overriding. Solution maybe to edit the hostname name from all the rc.digitalocean.d/*.conf – so that the default action happens as expected, although I am currently unsure as to whether these configuration files will be overridden at a later date by DO automation?

This problem persists. It seems like it’s coming from cloud-init. If you set cloudinit_enable="NO" in /etc/rc.conf after you change the hostname, it will do the trick.

Also if you:

# grep 'hostname' /var/lib/cloud/seed/config_drive/digitalocean_meta_data.json

You’ll notice the meta-data contains the old hostname. Perhaps cloud-init is picking this up and wiping out rc.conf. This is all speculation at this point, but the above hack is working. Cloud-init only facilitates the early initialization of a droplet. Disabling it won’t hurt anything unless you need it of course.