THX for the update. done also on current and crux

Also cherry-picked into crux

@MrFunken IPv6 is handled via T366.

CONFIG_FB_VGA16 has been removed from the kernel co fig and thus this should be resolved. Can you please retest with latest rolling?

@SteveP can you please test with latest rolling ISO?

Just hit this at my site, too.

I propose to proceed with a global change. Special case handling is always harder to test and the impact is only 5 seconds max in startup time - who cares on a 24/7 active device which is rarely rebootet?

instead of differentiating between raid and non raid installations - why not always wait 5 seconds for the discs to settle? As this is only done once on startup this is IMHO better then a special case.

I'd like to point out that the "personal appeal from the VyOS Wiki founder Daniil Baturin" at the top of the Wiki pages is fantastically defeated when we make it this difficult to contribute to the documentation. 😞

Can you share your configuration please? I use rc11, too as l2tp/ipsec access concentrator and everything is fine here.

Commit also cherry-picked to crux branch

Changes verified in commit https://github.com/vyos/vyos-kernel/commit/729bd5fafec7d2ad345ab371b04d15d2cf627229 so IMHO this one is resolved

The shared-network-parameters is a real pain and should be used "without warranty" we should rather deprecate it and add proper CLI interface.

Does the problem occur on a virtual environment e.g. ESXi, too?

As the DHCP client sometimes stores its lst IP address and sends a request for it you probably should delete the lease from the DHCP server:

Please retest wirh latest rolling release

• CONFIG_MMC_BLOCK already enabled
• CONFIG_MMC_SDHCI_ACPI has been enabled

+1

Please note:

My changes will make it into rc12 as earliest, sorry

Disabling the complete Framebuffer subsystem works with my UEFI Testboard, too. I will drop it entirely

Not directly but it was added here: https://github.com/librenms/librenms/pull/351

I see OS version in libreNMS.

Netplugd seems to be the thing we want

In vyatta-cfg-firewall please do git checkout current prior to building it, as the submodule pointer is definately not up2date.

According to CI service build works as expected. Can you please retry?

Will set interface vxlan vxlan0 remote-port 12345 be appropriate? Using destination-port would also work but the remote address is called remote and also openvpn utilizes remote-port

Setting destination port per VXLAN interface sound much more reasonable

What about Dockerfile in vyos-build?

I will provide a VyOS testing ISO somewhen next week, would be much appreciated if you can test.

Or drop by our slack channel for help

First you need to specify a new version of your subtree,
https://github.com/vyos/vyatta-cfg-system/commit/f68dda9d619ea74bed266122ac86604284e1a9e4

Correct

@dsteinkopf I think almos every command is good when there is a discussion ongoing and we can agree on somehing. VyOS has so called migration scripts which are executed once we do CLI changes and thus migrate old configuration nodes to new ones. We already make use of this feature alot and it is transparent to the user.

I really like the idea and thank you for the contribution.

@SteveP do you have time booting a Debian Buster (testing) ISO on your device and see if your NICs do appear?

@dmbaturin maybe can, need to verify this behavior together with the EFI stuff when I'm back in germany. If =n works for all szenarios I'm happy with it.

Can you please double-check with latest rolling release: vyos-1.2.0-rolling+201811281529-amd64.iso?

System bootup time is something we should not care, as a router is not rebootet that often. Infact the startup time depends on the amount of configured services or firewall rules. We recently increased the timeout for starting of VyOS to also make it work on slower Intel Atom D525 platforms where a huge firewall config was loaded.

What do you propose as CLI syntax?

I never liked verbatim passed options, this will be a perfect candidate for a first controbution to VyOS as it will be rather easy! You want to give it a try?

There hve recently been changes in regards to EFI. Please check the Dockerfile for all required packages or switch to Completely!

Have you tried specifying /config/config.boot instead?

I always thought 64 cpus should be sufficient for VyOS :)

Another idea (if having no name-server entries is disliked) would be

Eoot hints could be speciefied, if none is specified, buildin one is used.

Could be done by Help text and documentation

Or, if no name-server is set, use the root servers, this is the most easy implementation.

Even better! Thanks for the hint!

BBR was enabled in the latest commit to vyos-kernel

@syncer seems this is the only available SSTP Linux implementation

man strace(1) indicates that it opens several system files until it gets a match for any known distro.

VyOS ships a serial port interface in the default configuration upon installation.