This message was deleted.

I'm just learning the Harvester HCI thing... One thing that I realized at some point is that Harvester uses the Elemental OS distribution which is "immutable". When the OS boots up, you end up with a pristine copy from the install image with a few exceptions. Then, there are tasks reading configuration files and perform some updates. By these docs, you should be able to go through the /oem/90_custom.yaml route described here: https://docs.harvesterhci.io/v1.4/install/update-harvester-configuration With the right question, a chatbot should be able to detail this further.

So when you run the installer there's an option to input the node name. Ultimately that's the shortname that is set on the host.

Hey, thanks a lot for the explanations 🙏 The OEM 90_custom.yaml approach works well — my customizations are applied correctly after installation and reboot. One thing I noticed: Harvester/Elemental does not fully regenerate

/etc/hosts

if I define it myself. Instead, it updates the existing

127.0.0.1

line and automatically appends the

<hostname>

to it, like:

127.0.0.1 localhost <hostname>

This happens even when the file already exists. In my setup this caused issues, because resolving the hostname to

127.0.0.1

breaks some parts of the CSI stack. However, if I add a line like:

<node-ip> <node-fqdn> <hostname>

before the localhost entry, then

hostname -f

resolves correctly and everything works fine — Harvester leaves this line untouched. So the file is not fully overwritten, but Harvester still modifies the localhost entry based on the node name. I may also enforce the correct FQDN with:

hostnamectl set-hostname <fqdn>

in the custom YAML, but the priority of lines in

/etc/hosts

already fixes the issue. Just sharing this behavior in case it helps others with custom networking.

I'm also using static IPs but we still have dhcp PTR records.

yes I was thinking about that also to add in the initramfs

yep, I'm not sure if that's the best stage for it, but it it would probably work.