Hi @MrXermon
Can you describe how we can reproduce this bug?
Can you show share your configuration?

current hop limit is per default set to 64, but can't be set in frr while is was/is possible for radvd. I'd propose to use the the frr options only and not using the current existing ones, that way migration will become easier since the option 'current hop limit' could be just skipped and removed during migration.
Any ideas? Or should we stay with radvd for that purpose?
I would only do it for 1.3 and not backport into 1.2-rolling.

Protocol rewrite is more then overdue now ... :)

@c-po
I get other result.
After set from your example I see correct area
FRR

tagNode has been renamed to dnssl

Yepp, the issue is the quotes in dhcp server config (like the sample line i wrote).
i think, duplicates functionality doesnt matter, there are already such duplications: global-parameters, subnet-parameters, etc. That are for raw settings, if someone want a magic things in dhcp. But adding normal options to static-mapping-parameters are just a workaround.

Resolved since parent task closed

[edit system static-host-mapping]
vyos@vultr# set host-name test.lan inet 127.0.0.1
[edit system static-host-mapping]
vyos@vultr# commit
[edit system static-host-mapping]
vyos@vultr# save
Saving configuration to '/config/config.boot'...
Done
[edit]
vyos@vultr# show system static-host-mapping
host-name test.lan {

inet 127.0.0.1

}
[edit]
vyos@vultr#

Sorry, I misunderstood your issue, indeed adding quotes inside the parameters is not possible now. A reimplementation would be needed.

https://github.com/vyos/vyos-1x/pull/182
We have to ship our own /etc/{init.d,default}/isc-dhcp{v4,v6}-server files since we can't overwrite the ones supplied by the debian package.

The current static-mapping-parameters can be used to add a quoted value, e.g.

static-mapping test {
                    ip-address x.x.x.x
                    mac-address yy:yy:yy:yy:yy:yy
                    static-mapping-parameters "option domain-name-servers 1.1.1.1, 9.9.9.9;"
                }

command

set service dhcp-server shared-network-name dhcpexample subnet 192.0.2.0/24 static-mapping example static-mapping-parameters "option domain-name-servers 192.0.2.11, 192.0.2.12;"

I'm experiencing the same issue of the service failing to start on 1.3.
The installation was first started with the default config in a VM that had a serial port. Then the installation was transferred to a physical machine without a serial port, and the whole /config directory was manually copied from the old installation on that machine. The machine was then rebooted. The result were the same errors in syslog/journal.
I believe the issue is that if the config.boot is manually replaced or edited on disk, the script that would normally be triggered on commit when deleting system console is never triggered, thus the service remains enabled, but there is no system console in the config to delete any more.

@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.

Do you know what the outcome of this old task was?

Problem was in the wrong IKEv2 definition, set vpn ipsec ike-group IKE-AZURE ikev2-reauth must be yes

Yes, now the driver is there. But, as I am not using that driver, I have asked for confirmation, just in case.

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.

This requirement needs to be applied to 'running_config' as well, in case of (1) editing at the level of an unset node (parse error); (2) reading effective_value(s) in configuration mode (lacking full paths).

Resolved in commit fa85664ba050dab99d18d5d05018eea6a0fb0879

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 😄

T1846 fixes this

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).

Looks like the vyos-1x images was not rebuilt from the crux branch before the new image was built. I manually checked out the crux branch and the commit ins backported in there, rebuilt the packages manually and everything needed is in there and working.

@hagbard Confirmed fix. Migration worked perfectly.

Link to the changelog https://phabricator.vyos.net/maniphest/query/Vx2T4niywHe4/#R

@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)

Good point! PR merged.

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

@kroy please test with the latest rolling if https://phabricator.vyos.net/T1846 solves your issue.

@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.