Thank you. I see my mistake now. When I read under step 3, "Optionally, the user can attach a CDROM with an ISO as a cloud-init data source", it left me with the impression this was *optional*—that skipping this would not cause problems. I didn't realize that it would mean no default username/password would be set.

What is the intended way to apply configuration to a newly created proxmox flavor instance? At the page I referenced, it doesn't give any indication how to login or add a configuration under the "deploy from qcow2" section. Under the deploy from rolling release, it does mention the normal default vyos/vyos credentials.

As an update, I didn't realize originally but it seems I need to both the new VM once before the password reset option will work. If I go directly to it on first boot I get a message about no config.boot file and this not being a restore tool. Booting normally once seems to create the default config, then the password recovery option works from the serial interface.

Just an update on this... I _had_ two systems with this problem, but have found a possible workaround?

Hypervisor is VMware ESXi. I believe these were installed from OVA several
months ago, but haven't reproduced recently.

Yes, this _was_ still a problem but the workaround solves the issue for
me. I've been able to upgrade the 1.1.8 instances to 1.2.3 after adding
this extra interface route.

Unfortunately I still see the problem when the blackhole routes are set with a distance of 240 and the 0.0.0.0 route is distance 1.

The problem discussed here sounds remarkably similar to what I'm seeing: https://github.com/FRRouting/frr/issues/2230

I've tried several variations on the VRRP configuration, and it doesn't seem to make any difference. As far as I can tell, nothing is wrong with VRRP. It is only relevant as a source for change in the routing table. I can demonstrate the problem on a single instance with no VRRP.

The abnormal part of our setup might be that we have blackhole routes in
place to prevent any accidental leakage of private IP addresses through a
public class C network. The configurations posted above are contrived -
purely to demonstrate the problem, but it does reliably demonstrate the
regression from 1.1.8 to 1.2.0.

From the 1.2.0 instance (10.240.4.31) I'm able to ping the 1.1.8 (10.240.4.32) instance immediately after adding the address, but cannot ping out to the internet until after a reboot.

This won't help in production case, as that uses a /30 network with only 2 possible addresses. One is the floating VRRP address and the other is the destination for the static route.

One fairly simple workaround is to add a couple lines to /config/scripts/vyatta-postconfig-bootup.script

Unfortunately this is still not enabled in 1.2.0-rc8.