Unable to change hostname from the one specified during Bionic server installation

[WirelessMoves]

In Bionic Beta 2 I am not able on a host or in a guest VM to change the hostname of a Bionic Beta 2 installation by changing /etc/hostname. The name in the file can be changed but it always reverts to the hostname configured during installation.

In the following thread on the topic it is suggested to remove a number of cloud packages. When doing this in a VM install I could change the hostname again via /etc/hostname.

https://ubuntuforums.org/showthread.php?t=2389098&page=2

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Nathan Stratton Treadway (nathanst)]

When installing Ubuntu Server using Subiquity (i.e. using the ubuntu-18.04-live-server-amd64.iso installer image), the user is prompted to enter a hostname for the new installation (along with username/password info, etc.)

At the very end of the Subquity run, it writes this info into var/lib/cloud/seed/nocloud-net/user-data within the installation target filesystem (e.g.

======
root@bionic:/var/lib/cloud# head -6 seed/nocloud-net/user-data
#cloud-config
growpart: {mode: 'off'}
hostname: bionic
locale: en_US.UTF-8
resize_rootfs: false
users:
======
)

When the newly-installed system is booted for the first time, this file causes cloud-init finish up the configuration of the new instance -- include setting the new system's hostname to the specified value as part of that initial boot.

However, cloud-init on Bionic (e.g. 19.2-36-g059d049c-0ubuntu2~18.04.1) calls the cc_set_hostname module upon every boot (from within the cmd/main.py:main_init() function, thus overriding the normal "per-instance" frequency for the module)...

...and because the "hostname" cloud-config parameter is found to be set, the cc_set_hostname module will always re-write /etc/hostname back to the originally-entered hostname at that point -- unexpectedly undoing the user's manual change to the file.

[Nathan Stratton Treadway (nathanst)]

Presumably the ideal solution would be for Subiquity to hand off to cloud-init in a manner that really only ran on that very first boot of the new system.

However, assuming that a true fix to that situation is too invasive to be included into Bionic at this point, it seems like it might be a good idea to at least mention the issue (and recommended workaround) in the Bionic release notes.

[Nathan Stratton Treadway (nathanst)]

(In addition to the one mentioned by WirelessMoves, I found several other Ubuntu Forum threads as well as blog posts, etc. which recommend working around this problem by editing the /etc/cloud/cloud.cfg file to set the "preserve_hostname:" line's value to "true". However, that approach means there would be a conffile conflict whenever the cloud-init package is upgraded, so a better solution in the long run is probably to create a new file in /etc/cloud/cloud.cfg.d/ with that setting instead.)

[Michael Hudson-Doyle (mwhudson)]

Ah oops, this one fell through the cracks. Should try to do a quick fix.

[Michael Hudson-Doyle (mwhudson)]

This got fixed quite a while ago I think, apologies for the lack of updates.