It fixed in 1.3 version. With "next-hop-interface "

@jjakob for equuleus too, wait for merge PR. We have also some ideas how we can improve net naming, and fix issues with renameX interfaces after boot.

Is this only for crux or also for equuleus? There is also
https://phabricator.vyos.net/T1499
https://phabricator.vyos.net/T1584
https://phabricator.vyos.net/T291

I guess it has been auto-fixed by https://github.com/vyos/vyos-1x/commit/85349b54ab4de42f81d4c8c4dc84901d1313025f

In the latest VyOS 1.3-rolling-201912261106 all work fine.

Successfully tested on 1.3. PR for current branch https://github.com/vyos/vyatta-cfg-system/pull/113

Note: If we have interfaces with description on device panel, like WAN, DMZ, etc, we can use predefined alias in this case.

vyos@QAT-R1:~$ sudo cat /lib/udev/rules.d/64-vyos-SAF51003I-net.rules 
ATTR{[dmi/id]board_name}!="SAF51003I", GOTO="end_ec_nic"

Same behaviour with compiled uacctd version from pmacct git 1.7.5-git (20191224-00):
packets are arriving correctly to nflog group (tcpdump shows them) but they aren't processed by uacct

Updated the link files.

PR for CRUX branch https://github.com/vyos/vyatta-cfg-system/pull/112

This is confusing. While NTP used to work (listen on all interfaces) without any listen-address set, now it doesn't. This means any old config without listen-address set will now have a non-working NTP without any warning. There was no migration script to migrate the old behavior to the new. ntp should have a mandatory listen-address if this new behavior is kept.

This appears to be a moving target in at least one sense:
The package lists I now see differ from what is listed in the files above; one notable difference is a missing 'systemd-sysv':

tested with minimum aggregate options (no MAC, VLAN, interface, ...):

That seems to be a uacct problem (test inVyOS 1.3-rolling-201912201452 with new flow-accounting python/xml conf).

A reboot seems to have fixed it.

Can confirm. Problem seems to be fixed now.

I'm also experiencing this for the latest rolling versions eg. https://downloads.vyos.io/rolling/current/amd64/vyos-1.3-rolling-201912181733-amd64.iso. This is causing issues when trying to create Packer image builds - total first reboot wait time extended to over 2mins for a successful image build.

Added PR
https://github.com/vyos/vyos-1x/pull/190

@jjakob It's not really relevant if you SIGHUP or SIGKILL as RAs have no status, they are just send. I was looking into rewriting it anyway and port it into frr as frr sends RAs reliably as well. (https://phabricator.vyos.net/T1831) So the above is just a quick fix to get it working again with buster using the original logic.

If this is the issue I would replace the init.d call with systemctl since in 1.3 init.d/radvd is redirected to systemd anyway (maybe the bugs are present in this redirection so it's best to completely avoid it).
1.2 and earlier would still need to call init.d as-is.

@kroy I think I found the issue, the script just called start every time when radvd was already running, please test with either tomorrows iso or: http://dev.packages.vyos.net/repositories/current/pool/main/v/vyatta-ipv6-rtradv/vyatta-ipv6-rtradv_0.38+vyos2+current1_all.deb

It sends it after a while, I was waiting around 5 minutes and captured 1 RA msg.
But it sends only on vlan 22, which is quite unusual since all vlans are setup and readable by radvd, at least when I check /proc/<pid> it has it setup.
After the restart it sends on all interfaces (Just sent a SIGHUP, so no systemd involved). Reboot fixes it then as well.

All right, I can reproduce it now, thanks for the detailed report. I see what I can find out.