@hagbard I don't have a running vyos instance where I could verify immediately. But if it's not reproduceable anymore by following the steps I described then I'd assume it's fixed?

On a side note:

In T750#17132, @hagbard wrote:

additionally in /etc/hosts each change adds the localhost line instead of replacing it.

127.0.1.1 vyos-hostnametest.localdomain # VyOS entry
127.0.1.1 vyos-hostnametest.localdomain # VyOS entry
127.0.1.1 vyos-hostnametest.localdomain # VyOS entry

This is reproducible:

I started with vyos-1.2.0-rolling+201807050337-amd64.iso and it only occurs after the first reboot after a new image installation. The next reboot fixes it.

Hmm weird. Then I rather nuke the 1.2.0 installation and redo it completely.

Don't remember how it was from 1.1.8 to 1.2.0 but within 1.2.0 always.

Thank you @hagbard. This copies unfortunately only the ssh host keys. Interstingly this also happens in install-image-existing and is likely duplicate code ?

The below code does work if inserted at line 254. It does however mess with the ownership of the home dir it's all owned by vyos afterwards even though cp -p i used, resulting ssh key based authn not working anymore until fixing ownership.

Thanks @c-po. I'm not sure though - how does "user creation" matter in that context? I had the impression that preserving home/user will be mostly a matter of adding a few lines of code to https://github.com/vyos/vyatta-cfg-system/blob/current/scripts/install/install-image-existing similar to the /etc/ssh block starting at line 240. Am I wrong?

is it. I can surely extend it quick and dirty to have something working which can then be improved and beautified as needed.

If someone could point me to the relevant code files / documentation, I can give it a look.
If it is a simple thing to do I may even be able to create a PR.

Thanks ??

I just observed that I had these famous "kernel:[ ] Uhhuh. NMI received for unknown reason xx on CPU y." messages on the VM. Seems to be a common problem with the Q35 chipset in KVM. I suspect that this may have also caused the erratic behavior in VyOS. I'm now back on i440 and will close the bug until it occurs again.

The host is Debian9 with KVM. I have a few VMs running there, never had a comparable issue.

May these entries in /var/log/vyatta/vyatta-commit.log be related?

Just had it here

Couldn't reproduce on a fresh VM so this must have been a singular anomaly ;)

Update: I was now able to set a new host-name. When I logged in from a different machine it miraculously worked and the error message disappeared. Still assuming there is something wrong here, somewhere?