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

I wanted to add this post from the forums to this thread. It appears to be the same behavior where the failure of a single line deletes the logical section:
https://forum.vyos.io/t/upgrade-from-1-3-6-to-1-4-0-epa1-looses-complete-dhcp-configuration/13935

Duplicated: https://vyos.dev/T6061

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

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

@paigeadelethompson it is another issue, open a separate bug report

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

Do you refer to initially admin-down or oper-down?

Now trying to migrate a second router, with different config. I have corrected the mistakes I could see in the config and have removed policy route config with tcp flags.

Reviewing the logs
When the interface "xfrmi-test-...." appears, opennhrp stops

Using the same router/config I noted previously, I see an "empty" config per T6084.

admin@removed# cat /run/opennhrp/opennhrp.conf
# Created by VyOS - manual changes will be overwritten

I then modified the nhrp vyos config and saved, and the opennhrp.conf was re-populated. Upon reboot, the file reverted to "empty".

Instead of that sysrq stuff, how does it work if you try these 3 tests?

If I comment out this line then everything works.

Thanks - yes - there were in fact 3 "passive-interface" entries for old interfaces, which I should have tidied. Having deleted them, the migration completed.

Check opennhrp.conf file
Could be bug if the ispec in the config T6084