One note: I'm removing the "firewall" option. First, it's only relevant for RFC-compliant VRRP, and there's no checking for it. Second, it has no advantages over assigning the firewall directly to the parent interface in any case.
Third, it was implemented inconsistently: ethernet VIFs and non-ethernet interfaces (e.g. bond) lack it.

For the reference: https://github.com/acassen/keepalived/blob/master/doc/NOTE_vrrp_vmac.txt

Does the problem also exist with the other kind of VRRP?

I'd need to check.

There was one or two 1.2.0 images that did have a hostname problem due to a problem in the new implementation of the system host-name command, but I fixed it. I wonder if your problem might be carried over from one of those images.

Could you try updating some test machine from 1.1.8?

You get this when you upgrade from a previous rolling release, or from 1.1.8? If the former, which one?

Should we delete user home dirs when deleting a user then?

I think new version should still be able to sync with the old versions, since people will be upgrading routers in their HA pairs one by one, and loss of functionality during upgrades isn't a very nice situation.

@hagbard Migration scripts are no longer that much of a problem (though they still need to be carefully written). See http://blog.vyos.net/writing-migration-scripts-and-manipulating-vyos-config-files-outside-vyos-just-got-easier

https://github.com/vyos/vyos-1x/blob/new-vrrp/interface-definitions/vrrp.xml The new syntax draft.

That's my punishment for the sin of only testing op mode commands from conf mode.

The pull request was merged.

@runar Found an issue: show-raid.xml refers to ${vyos_op_scripts_dir}/show_raid.sh file, but that file does not exist.

Yes, it's been fixed a while ago.

@c-po I've rebuilt those newer packages from source (typically by using apt-get source). Due to different libc and all they indeed cannot be installed directly.

Appears to work fine now.

@hagbard If rewrite can be done in a reasonable time (days to a couple of weeks), I think trying to clean up old code is more trouble than it's worth.
With big stuff that cannot be easily rewritten, it may be worthwhile.

@hagbard If you are working on it, by all means, assign it to yourself. We do not have a formal assignment policy, it's more like "I'm working on it" flag for coordination.