Just to confirm, changing the if line does solve the issue, and I am able to log in.

Out of curiosity, shouldn't this just be moved to the end of the startup scripts?

Not sure if this should be re-opened, or, a new ticket should be created. It appears that this function is the only thing that creates etc passwd (etc), and it's only ever called once.

Just confirming this is still an issue, as mentioned in slack, and is really adding a lot of cpu load to pure routers

I'm going to do what I suggested.

You COULD have a peer-group without remote-as, as you could apply that peer group to multiple remotes, and override the remote-as. But that is an edge case. The BETTER way to handle it is to enforce having a remote-as -- especially if you enable route-reflector-client

https://github.com/vyos/vyos-build/pull/162

That was generated by running make defconfig, enabling numa, and saving it back. BUILD_BIN2C is related to kexec.

After upgrading, the entire NAT section is gone

Error when upgrading to 1.3

Confirmed fixed, thanks @c-po!

There's a regression here, I can not 'delete system console' in the current rolling build, I get this:

Reopened, confirmed broken again.

Turns out that 'destination-interface any' works, and I just hadn't read the help.

Confirmed fixed in

vyos@mke-fw1:~$ show version
Version:          VyOS 1.2-rolling-201911051339
Built by:         autobuild@vyos.net
Built on:         Tue 05 Nov 2019 13:39 UTC
Build UUID:       3863567b-039d-4fdd-90cc-eda2e1b11bc6
Build Commit ID:  33c865b2ada281

After adding the missing command set high-availability vrrp sync-group sync member int1, we have a new error when starting conntrackd

Confirmed still present in VyOS 1.3-rolling-201911030242

My hypothesis is that Interface.set_mac is being called AFTER the bond is applied, which sets the mac of the interface back to what it was originally. Probably adding a check to see if it's a bond member may solve it

Basic config that duplicates this problem

To summarise, the MACs of interfaces that are bonded should all be the same (and should also match the mac of the bond interface). This works correctly in the older July build. However, this no longer works *on boot* in the latest builds. The screenshot above shows eth0, eth1, and bond0 all having different MACs which is why it's not working.

On the old image, the macs are set correctly

OH. MY. GLOB. I just figured it out.

This appears to be a bug in that intel driver - there's people reporting the same issues here: https://sourceforge.net/p/e1000/bugs/649/

This is getting more and more crazy the more time I spend on it, as this is a niggly issue that shouldn't be this hard to figure out.

Oh, just to emphasize that it's a startup-config issue, if I disable and re-enable the ethernet port in the switch, it is still broken. The only way to get it working is to delete the member, commit, and re-add the member inside vyos.

While it was booting, it responded to three pings, and then nothing

It looks like the problem occurs when both interfaces are present when the machine boots. I can remove either one, reboot the machine, and it works.

Working 1.2.0-rolling config (with the different bonding syntax)

1.2.0 complete bond0 output

Out of curiosity, I tried 201910170117, and it was fine (at least for booting). The 20191018 image may be broken - should it be pulled?

UEFI is not difficult.

I simply symlinked it to work around the problem.