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

Bug #1764172 reported by WirelessMoves on 2018-04-15
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Release Notes for Ubuntu
Undecided
Unassigned
subiquity
High
Unassigned
hostname (Ubuntu)
Undecided
Unassigned

Bug Description

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

WirelessMoves (gsmumts) on 2018-04-15
affects: update-notifier (Ubuntu) → hostname (Ubuntu)
Paul White (paulw2u) on 2018-04-15
tags: added: bionic
Launchpad Janitor (janitor) wrote :

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

Changed in hostname (Ubuntu):
status: New → Confirmed
summary: - Unable to change hostname
+ Unable to change hostname specified during Bionic server installation
summary: - Unable to change hostname specified during Bionic server installation
+ Unable to change hostname from the one specified during Bionic server
+ installation

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.

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.

(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) wrote :

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

affects: subiquity (Ubuntu) → subiquity
Changed in subiquity:
status: New → Triaged
importance: Undecided → High
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers