Fedora Cloud 43 hostnamectl cloud-init fail

Ask Fedora
1

Hi folks, I’m debugging a really obscure failure in cloud-init that most people won’t even notice. Would this be something that is a candidate to be fixed, or would this case be just too niche to support?

If you use macos and vfkit to boot a Fedora Cloud 43 VM, and you want it to show the hostname in /var/db/dhcpd_leases, the specific path to do so is broken in Fedora 43.

I’ve tested in CentOS 10 Stream, Ubuntu Noble, Debian 13, and they avoid this issue. (They trigger different codepaths or have older cloud-init)

The specific error path triggered is this:

/var/log/cloud-init.log:

2025-12-10 19:24:26,659 - log_util.py[DEBUG]: Failed to set the hostname to fedora43 (fedora43)
Traceback (most recent call last):
File “/usr/lib/python3.14/site-packages/cloudinit/config/cc_set_hostname.py”, line 86, in handle
cloud.distro.set_hostname(hostname, fqdn)
~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
File “/usr/lib/python3.14/site-packages/cloudinit/distros/init.py”, line 392, in set_hostname
self._write_hostname(writeable_hostname, self.hostname_conf_fn)
~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/lib/python3.14/site-packages/cloudinit/distros/rhel.py”, line 119, in _write_hostname
subp.subp([“hostnamectl”, “set-hostname”, str(hostname)])
~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File “/usr/lib/python3.14/site-packages/cloudinit/subp.py”, line 291, in subp
raise ProcessExecutionError(
stdout=out, stderr=err, exit_code=rc, cmd=args
)
cloudinit.subp.ProcessExecutionError: Unexpected error while running command.
Command: [‘hostnamectl’, ‘set-hostname’, ‘fedora43’]
Exit code: 1
Reason: -
Stdout:
Stderr: Failed to connect to system scope bus via local transport: No such file or directory
2025-12-10 19:24:26,660 - main.py[DEBUG]: Failed setting hostname in local stage. Will retry in network stage. Error: Failed to set the hostname to fedora43 (fedora43): Unexpected error while running command.
Command: [‘hostnamectl’, ‘set-hostname’, ‘fedora43’]
Exit code: 1
Reason: -
Stdout:
Stderr: Failed to connect to system scope bus via local transport: No such file or directory.

The causal sequence is:

  1. cloud-init is starting earlier in boot, when dbus is not available
  2. it reads the meta-data config using the config-drive mechanism
  3. on debian based systems it manually edits the hostname
  4. on rpm based systems it tries to use hostnamectl (this fails due to dbus being unavailable)
  5. then it starts configuring the network and dbus, and here it can add the hostname to the dhcp request if configured to do so.
  6. if the hostname wasn’t set in step 4, it will now attempt to set it again

On the plus side, after a reboot everything works well. But it’s annoying that it’s something that’s different for Fedora Cloud in the group I tested.

Having recently delved into the arcana of cloud-init I can attest that this kinda stuff is pretty niche. Would anyone have closer context on this? If there’s a Fedora packager out there who is also a contributor to cloud-init, this would be of interest to you!

I’m planning to push up my reproduction scenario in the next week to so to a public repo. Unfortunately at the moment it’s m4 mac based only.

2

cloud-init seems to at least be aware of the issue: [enhancement]: simplify systemd unit files · Issue #5818 · canonical/cloud-init · GitHub they specifically call out the dbus problem.

3

Oh wow, I found that this has been established behaviour for quite some time!

4

Hi Jan,

In recent months it’s mostly been me dealing with cloud-init in Fedora. Over the summer there were some issues in cloud-init related to systemd unit ordering (which is headache-inducing). At the time I think my plan was to put it in my backlog and hopefully by the time I felt like dealing with it systemd would have varlink APIs for the hostname stuff.

I’ve not checked on the status of those APIs since then, but that might be a good place to start. Depending on dbus being available is one of the reasons the ordering is painful, from what I remember.

I’m certainly open to help getting it sorted out, it’s just not been particularly high on my list of things to fix.

5

Oh man, the reordering hit us pretty hard too at work - on the plus side I understand more about debugging weird things in systemd than I ever thought I would.

I’m wondering if the simplest fix is going to be adding varlink fallback support to hostnamectl in systemd. hostnamed seems to support read access on varlink, but there’s no write access there. I need to read more systemd code to see if it’s feasible without going bananas.

Yeah, I wouldn’t prioritise this as a critical thing to fix - from what I can see I wandered into some really niche behavior that’s pretty ancient.