Yes, boot\x86\wdsnbp.com is a proper filename, and this further correctly translates to double backslash in the dhcp.conf file at /run/dhcp-server/dhcpd.conf, as I noted. Why it is so, explained for example here: https://www.linkedin.com/pulse/quit-thinking-look-matthew-topper
And with such a setting network boot works just fine.
The problem is that after each reboot the vyos configuration scripts, I guess, double the number of backslashes in the config, that further leads to doubling them in the dhcp.conf. And on, and on. This actually breaks the network boot, and manual intervention is required after each router reboot.

Is "\" really a valid path for bootfile?

The 1.3.x behaviour,

1. VTI interfaces without IPsec is not created

# 1.3
set interfaces vti vti10 address '10.0.0.1/30'
commit

Create the PR without smoketest. This case is not tested.

@c-po, while I don't wish to put words in the mouths of others, I believe the belief is that the interface should stay oper-down.

https://github.com/vyos/vyos-1x/pull/3093

https://github.com/vyos/vyos-1x/pull/3090

Revised PR:
https://github.com/vyos/vyos-1x/pull/3089

kea_parse_leases was deleted in https://github.com/vyos/vyos-1x/commit/c44d24eae276f77c700e961a22c0cd5582416dff
Probably the correct function is kea_get_leases

Note that the PR https://github.com/vyos/vyos-1x/pull/3035 is only for 1.5 at this point: the critical question for this task is whether or not to restore the simple support for unicode.

Simple unicode support was allowed in
https://vyos.dev/T3785
however, the constraint on description, above, restricts to ascii.

Perfect, that's what I was trying to better understand. Thanks for the clarification!

The regex should be [-_a-zA-Z0-9.\s]+ instead of [-_a-zA-Z0-9\s]+

The short answer is that it will change going forward, and the work within this task, and the ongoing work mentioned above will avoid failing viable configs that have the symptom of 'full section of the config not applied'; that's what we are addressing here. The longer answer above attempted to distinguish several unrelated situations that have that same symptom, and in the extreme case of a user providing a corrupted, partial, or nonsensical config, there is not much that can be divined without some user feedback and suggested debugging: if critical dependencies are missing, that means that the system would be non-operational. What interests me here is some immediate improvements that may be made, and in proceeding with that, it is necessary to make these distinctions.

PR: https://github.com/vyos/vyos-1x/pull/3088

PR: https://github.com/vyos/vyos-1x/pull/3087

PR: https://github.com/vyos/vyos-1x/pull/3087

For 1.5 fix works as expected

vyos@r4:~$ cat /run/opennhrp/opennhrp.conf
# Created by VyOS - manual changes will be overwritten

works with version 1.5-rolling-202403050022

Gotcha! The thing I keep struggling to understand is why is the full section of the config removed? This will 100% cause outages. If there's part of the config that is invalid, only that part should not be applied. You shouldn't remove 19 valid lines of config due to a single invalid line. Particularly with almost all of the instances I've seen of this, the invalid line is just cosmetically invalid, and doesn't cause any issues with the operation of the system.

Should be fixed in the next rolling release.
Can you recheck it after 20240304 ?

Well, nothing is deleted, rather the config section is not applied if the verification steps do not pass: if the user ignores the error and warnings and saves the subsequent working configuration, the resident config.boot file will be overwritten. So I agree that it an issue for consideration, if we distinguish those cases in which this may occur, as above. Considering those cases, we can not or would not want to (1) automatically fix migration errors, in some sense or other, to avoid non-application of config sections on migration failure; bugs in the migration system should be fixed, and improvements to the migration system itself are part of the current development plans (2) support non-verified/non-existent interfaces without clarification of when if ever that is appropriate, such as the current investigation. There is current development of the design to refine the verification stage, unrelated to this specific task. Given the preceding, I would not say either that it is a case of 'everything's fine' or of 'design flaw'; design evolution is appropriate perhaps.

@jestabro, do you guys consider the process of deleting the entire config section for a single offending line working as intended? Or do you consider it a design flaw/bug that will get fixed? I'm trying to understand if that is an intentional design choice and will permanently be part of VyOS going forward, or if it's just part of growing pains as VyOS moves from 1.3 to 1.4.

PR created: https://github.com/vyos/vyos-1x/pull/3085

Config sections not applied after failed verification is not a surprise, as discussed above, though it is understandably frustrating: warnings are provided on failure and upon entering config-mode subsequent to failure, to help avoid overwriting the saved config before investigation. As we continue this discussion we should distinguish the various issues (and I will open subtasks as appropriate):
(1) missing config sections on migration need to be debugged, as with T6076, ongoing ...
(2) verification of 'late' arriving interfaces (general); configuring ZeroTier (specific): I'm looking into what may be considered for the general issue, as mentioned, and I have some initial ideas; thanks to the details provided by @L0crian I'll reproduce the specific configuration for experiment
(3) support for hotplugging interfaces: not planned at the moment, but may be discussed again for 1.5

https://vyos.dev/T6076 is also similar...

PR https://github.com/vyos/vyatta-cfg/pull/75