So I guess the key to duplication here is to:

Maybe even just the action of sudo systemctl restart radvd.service is enough to fix it? It seems to maybe be the case

It seems like maybe something doesn't exist, or permissions aren't working right on a freshly upgraded system, until you manually do something to create it?

So the problem went away until I upgraded to the latest rolling. VyOS 1.3-rolling-201912211124

VyOS 1.3 (rolling/equuleus) is now based on Debian Buster so has isc-dhcp-client 4.4.1.
According to the manual dhclient now has a command line option

--prefix-len-hint
When used in conjunction with -P, it directs the client to use the given length to use a prefix hint of, "::/length", when requesting new prefixes.

It was added in 4.3.6:
https://ftp.isc.org/isc/dhcp/4.4.1/dhcp-4.4.1-RELNOTES

Added explanation on how to use quotes inside raw parameters to the docs.
https://github.com/vyos/vyos-documentation/pull/163

Confirmed on 1.3-20191213, tcpdump on the router shows no advertisements until radvd is restarted with sudo systemctl restart radvd.

This is a known fault, and is not easily fixable in the current implementation. This fault is because the vuos cli manually configures the frr process after it's started, and when the process dies/restarts it will read its config from the saved config file. This makes the process restart into an empty config as we have no way to save the config from the prior process.

According to https://live-team.pages.debian.net/live-manual/html/live-manual/customizing-package-installation.en.html#474 some more packages are required.

Weird, afaik there was nothing to migrate yet.

Also tried that:

My output there basically matches yours.

That can't be the issue, what do you see if you do a grep radvd /var/log/messages?

My guess would be missing live-tools in the recommends=false case; live-tools replaces update-initramfs with its version. I'm building to check ...

And I don't know if it's relevant, but the syslog output is definitely different depending on whether I restart it, or it gets restarted on boot

Upgraded to lastest official rolling:

Tried almost all packages via CI, looks very good.

I used your config and just changed to eth1, commit works and after reboot radvd runs and sends RAs as well. radvd has a very low priority, I think 999 or so to ensure all interfaces are up and running plus the fact that radvd runs with a flag which allows the config running on an offline interface. (IgnoreIfMissing on;) Could anything else x-fire?

On current Debian Buster tose are the lsit of installed packages. I have not found the reasion why building with --apt-recommends false makes the ISO unbootable

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

Really thanks for your reply. It's nice to have this fix. But to be honest, crash of vyos-hostsd is not so big deal for me, what really concern me is that restart of vyos-hostsd is followed by restart of vyos-router.

Maybe it's because I have multiples? Or on vlans (not that that should matter)

@fcqpl any chance to test it in your environment?

@kroy can you please share your config? I used a minimal one and everything works without issues.

Hello, @MapleWang!
Thank you for pointing our attention to this issue! It is really bad that such simple action as changing hostname in some cases (well, in fact not only this but it is easy to reproduce) leads to the whole router crash.
The problem consists of several parts:

1. In old systemd versions (which is used in Debian Jessie and VyOS 1.2) exists a problem, when during a restart of systemd-journald all pipes between this daemon and systemd services are disconnecting.
2. In vyos-hostsd, which is responsible for hostname and DNS and controlled by systemd we used print() for logging and debug purposed without enough handling of errors.

So, when arises the situation when there is no PIPE connection between vyos-hostsd and systemd-journald, vyos-hostsd not able to print messages and crashes. :(

I tested this morning and I was able to build the vyos-builder:crux and crux iso.

Please try again

This is fixed/was not present in 1.3-rolling.
1.2 is not possible to fix, the bug is in isc-dhcp which would need to be upgraded to a newer version.

Works correct on 1.3-rolling-201912190503

Awesome! Enjoy Testing!

@c-po, there is also third PR in vyos-buid: https://github.com/vyos/vyos-build/pull/69

Found it. Thx

@zsdc is thwre a second PR removing the old implementation?

After some more testing, after a reboot, a tcpdump -n -i interface icmp6 on a client machine shows nothing until restarting the radvd service on the routers.

I was able to build the container, but sudo make iso failed with:

Wow, you did it!!!
I’ll do some tests
But I don’t know to test on a current vyos build so I’ll have to wait until the PR are accepted.
I hope it will accepted asap.

Thanks, @elbuit !
We have prepared PR with full functionality: https://github.com/vyos/vyos-1x/pull/187
It would be great if you will join us and help to test it, find all bugs and fix them. :)

Hello @zsdc
I didn't tested it.

I did some work porting vyatta-netflow to new vyos model

Solved it by importing libyang binary packages onto http://dev.packages.vyos.net/repositories/crux/debian/pool/main/liby/libyang/ which is even better.

@c-po I can't find any usable from vyatta-ravpn now, seem we can archived it and drop from build process.

What services are provided by vyatta-ravpn?

Fixed in https://github.com/vyos/vyos-build/commit/f2d457a9ed089995783207574699ec98c6956291

Also fixed additional issue with multiple snmp script-extensions entry (jinja2 sort)

Hello, @elbuit!
As I see, NAT events can be recorded only by nfacctd, and therefore this is not possible with the current way to capture traffic (by NFLOG + uacctd). Fix me, if I was missed something, please.

In latest rolling 1.2-rolling-201912180217 permission problem solved, but exist one more problem with script path.
CLI allow us to choice script, which stored on '/config/user-data'

Also mention in https://phabricator.vyos.net/T1058

I found a easy way to reproduce.

I got the following error:

Testing now. Will update

Please pull and try again