@sunser Can you please clarify if you still encounter that issue?

syslog is required by multiple targets and logs journald messages, stopping it works at the first commit, but the dependencies will start is automatically after reboot. the vyos config is being removed from rsyslog.d but the default rsyslog.conf will be used, which logs daemon, emerg (to console) and auth failures and would have to be changed in vyos-build if required.

Yeah I figured. vyos is being install into /dev/mdX, I can boot via live cd and mount mount it and it has everything in there, but there seems something wrong with writing the boot sector since I would see at least grub. Instead it is empty.

In T1869#49212, @hagbard wrote:

Looks like an issue with the raid metadata and grub, problem confirmed with virtual box. Tested, latest rolling, 1.2.3 and 1.2.4-epa1.

Looks like an issue with the raid metadata and grub, problem confirmed with virtual box. Tested, latest rolling, 1.2.3 and 1.2.4-epa1.

Thanks; this is necessary when (1) editing at the level of an unset node; (2) reading effective_value(s) in configuration mode. I will extend the original fix.

Just to add to this.

@jestabro problem is not resolved

@dmitry yes, I tried 1.2 rolling as well. I have not been able to try 1.2.3 stable due to a lack of access.

Hello @trae32566 , with 1.2-rolling the same installing result?

Have a screen recording 😄

https://phabricator.vyos.net/T1499
https://phabricator.vyos.net/T1671
https://phabricator.vyos.net/T770
are all related to the same issue.

There is certainly a race condition in interface renaming for VyOS 1.2. This is possibly also an issue for 1.3 but more testing is required before I'm sure of that.

I check it in latest rolling releases and it work fine (ipv4 and ipv6).

@hagbard Confirmed fix. Migration worked perfectly.

@kroy Please let me know if you still experience any issues (setting the port or migration).

tested with today rolling release. (https://downloads.vyos.io/rolling/current/amd64/vyos-1.2-rolling-201912100217-amd64.iso)

disable-connected option on a neighbour would work, too.

@Dmitry Tested it with the latest 1.2 rolling, the issue is still present.

In the VyOS 1.2-rolling-201912090217 and VyOS 1.3-rolling-201912090242 all work fine

That subsystem has now been completely rewritten and certain things are skipped if underlaying hardware is virtio or vmxnet.

@Merijn if you are still willing to test, I can provide build instructions, if you need. I noticed that you had been working with @hagbard recently on your build environment; if you are willing to use docker, I can give you step-by-step instructions to build with these patches.

Over the past 3 months of rolling releases, I haven't seen this problem in KVM with virtio.

@hagbard An inactive route in this case can be resolved using the command "ebgp-multihop 10".

In the latest rolling VyOS 1.3-rolling-201912090242 it work fine.
R1 advertise ipv6 routes with community 65001:666
R2 receives these routes.

Similar task https://phabricator.vyos.net/T1838

/opt/vyatta/sbin/vyatta-firewall.pl contains lines

Hi @systo
Can you describe step by step what you did not succeed?
The example below is just an example.

Confirm the problem on edit level.

Thanks, @trae32566 for the information! I would be happy to change this fix in that way, which does not allow to place unwanted records to resolv.conf at all, but I cannot catch the same situation like yours to collect enough diagnostics data to be sure in the reason of such behavior.

It's probably duplicate of T1863 and T1846, I usually commit configuration under leaf config level

I don't see this bug in the latest versions of the VyOS (VyOS 1.2-rolling-201912090217 and VyOS 1.3-rolling-201912090242).

I can't reproduce this issue on 1.2.3 and 1.2/1.3 rolling. @hagbard can you test again too?

@zsdc It looks like after boot the DHCP DNS and search does indeed disappear, it just appears to take a minute, so I guess this can be closed (though it seems odd it would get added at all, but I guess that's alright).

fixed in http://dev.packages.vyos.net/repositories/current/vyos/pool/main/v/vyos-1x/vyos-1x_1.3.0-16_all.deb

Trying to apply the fix manually:

Built a fresh rolling. It failed with:

FRR will serve RAs in the future.

https://downloads.vyos.io/rolling/current/amd64/vyos-1.2-rolling-201912061907-amd64.iso and later include the fix

SNMP community should stay. If it should be removed it can be handled via dedicates task

Works as expected in VyOS 1.2-rolling and 1.3-rolling.

Hello @primoz , seems you right. left|rightnexthop deprecated in strongswan.

This parameter is usually not needed any more because the NETKEY IPsec stack does not require
explicit routing entries for the traffic to be tunneled. If left|sourceip is used with IKEv1
then left|rightnexthop must still be set in order for the source routes to work properly.

And in CLI rolling l2tp implementation we need replace outside-nexthop to gw-ip-address.