One explanation could be that during the lstvdeployment ae of ixgbe something crashed leading to the missing module. I just started a rebuild of the crux kernel, lets see - module should reappear

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

The changes are also part of the patch for T2057 which was merged.

All my apologies for this stupid bug.

This is a result of a missing package vyos-intel-ixgbe_5.6.3-0_amd64.deb in http://dev.packages.vyos.net/repositories/crux/ --- when missing, the build will use an outdated package, leading to incorrect dependencies on the kernel version. On the other hand, if the correct intel module is built as a local package, there is only one resident linux-image, and update-initramfs succeeds as usual. The build/upload mechanism for the intel modules will be fixed soon, and the issue resolved.

@cpo I think you need to add it to CI in addition to vyos-build

That's bad, because debian stable (=buster) is fixing security bugs only. They will not fix/add this patches to conntrack package, they leave conntrack buggy. So you sould build an own conntrack-tools package for 1.3 too :( If not, vyos will be less good software.

Upstream still hasn't made a release with this patch: https://git.netfilter.org/conntrack-tools/commit/?id=c12fa8df76752b0a011430f069677b52e4dad164
So we could wait on upstream to release it and debian to package it, or build our own as we used to in 1.2.
It would be better to ask upstream to make a release as there's less work for us.

We don't build conntrack-tools in 1.3 (current/equuleus) any more, upstream Debian Buster conntrack and conntrackd packages are used. So as upstream gets patched, we'll pull in those patches automatically.
If I see things correctly, there are references to conntrack-tools in the build scripts that still need to be removed.

Sorry, I titled the task wrong. The error is in building conntrack-tools.

I think you're right, I couldn't find any package depending on it, vyatta-conntrack-sync only depends on conntrack.
I also found this https://phabricator.vyos.net/T1538 in which the conclusion is we should upgrade conntrack-tools.

I guess that one is deprecated as we also don‘t have it in our CI at https://ci.vyos.net/

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

looks for my like an frr bug. Has someone contacted upstream?

As PPPoE is now denested the logic in Vyatta::Interfaces needs to be adjusted

I think this needs to be fixed from VyOS crux package repos, Because after applying this patch, ISO was created with two kernel images, And after ISO installation VyOS was showing boot entries for kernel versions 4.19.4 and 4.19.84.

I can confirm this bug also with VyOS 1.2.4

It seems that in the process of ISO creation, kernel deb packages are installed in the chroot directory.

Firstly, we need to determine why there are two kernel images.

In debugging, It's found that chroot for ISO build had two kernel images in the boot directory

Ah, that is just legacy. Ironically, when I updated the code manually to mitigate this problem, I deleted the root user. Lol. Still, there may still be users out there from the Vyatta days that still have it there. Off topic here but I am also a PPPoE user and am now running the latest version with all the recent PPPoE re-write and all is working fine.

For TLS crypt please see T2075

looking at your config I see the issue, it is b/c you define a root user which triggered an exception. I will fix the code to mitigate this bug.
Thanks for testing and reporting.

i think, you sould use crux branch for 1.2 build, current branch is 1.3

This should actually be possible after the PPPoE interface rewrite in the latest rolling image.

No answer from user.

Yes there are definately other places like DHCP.

I personally don't mind the raw options, and there are other people using them too (T127, T1246, T1383, T1421, T1430).
There is no option for tls-crypt, just tls-auth. Also I'm experimenting with the various mtu options (tun-mtu, link-mtu, mssfix, fragment) and keepalive options (ping-restart, ping) that can't be set through the existing keepalive options (keepalive doesn't take 0 as a value if I want ping-restart 0 for example, and there's no way to not have keepalive be set with default vaules). So yeah, if all of these options were integrated, I personally wouldn't need the openvpn-options. But I think there are other places that use raw values with quotes that are affected by the autocompletion bug too, dhcp-server for example.

Thats the downside of those nodes which allow passing raw values down the config. I never liked them and they should be removed. The CLI should be extended to support the raw options instead.

There you go

Could you provide me with your full 1:1 configuration (paswords can be omitted)? Then I check again