The fix is now a part of https://github.com/vyos/vyos.vyos/pull/367

https://github.com/vyos/vyos-utils/pull/28

the PR to fix this is https://github.com/vyos/vyos.vyos/pull/367

The PR tp fix this https://github.com/vyos/vyos.vyos/pull/367

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

This works!:

trae@cr01b-vyos# set pki ca IPA.TRAE32566.ORG system-install 
[edit]
trae@cr01b-vyos# commit
Archiving config...
  sftp://stor01a-rh9.int.trae32566.org/int/cr01b-vyos [edit]
trae@cr01b-vyos# run restart ntp
[edit]
trae@cr01b-vyos# run show ntp sources
.-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^* ns02.ac.trae32566.org         2   6     7     0     +2ns[ -188ms] +/- 5513us
^- ns01.ac.trae32566.org         2   6     7     0   +120us[ -188ms] +/- 5598us

I prepared a service to log some network events including changing link status.
to configure service:

conf
set service monitoring network-event event addr
set service monitoring network-event event link
set service monitoring network-event event neigh
set service monitoring network-event event route
set service monitoring network-event event rule
commit

to check change status:

vyos@vyos:~$ sudo ip link set down dev eth1
vyos@vyos:~$ sudo ip link set up dev eth1
vyos@vyos:~$ show interfaces ethernet eth1 event-log link 
Dec 03 09:30:09 vyos-network-event-logger[21158]: [LINK]   3: eth1:  <BROADCAST,MULTICAST>  mtu 1500  qdisc fq_codel  state DOWN  group 0  link/ether 0c:89:0a:2e:00:01  brd ff:ff:ff:ff:ff:ff  [altname enp0s4] [altname ens4]
Dec 03 09:30:14 vyos-network-event-logger[21158]: [LINK]   3: eth1:  <BROADCAST,MULTICAST,UP,LOWER_UP>  mtu 1500  qdisc fq_codel  state UP  group 0  link/ether 0c:89:0a:2e:00:01  brd ff:ff:ff:ff:ff:ff  [altname enp0s4] [altname ens4]

Implemented in T6045

The PR# is re-submitted for review and testing

Path issues and unit tests resolved

Sounds reasonable! I'm not going to worry about it any more, unless I see any further symptoms. Thanks a lot for the fix and taking the time to respond here!

@gadams it may well have been the case that the fragile synchronization before the fix was in fact a cause of the problem, at least in some (all ?) cases. I expected however, that any other config error on boot could also trigger the complaint in vyos-configd, which would consequently drop any useful output. With the original change in T6326 and the fix in T6899, any output (error or otherwise) should now be robust and generally available (notably, through the http-api, which was the motivation to finally fix the output workaround for T6326).

To be clear, the clean-config boot hangs I was seeing were prior to this fix. Since the fix, I have yet to see the hang.

@gadams I agree with 2, as becomes apparent in the current situation: it is misleading and should be changed so as to avoid confusion. If you want to take it up, that would be great; thanks. Regarding 1, if you are seeing boot hangs on a system with the above fix, we will need to investigate: I have not encountered it, so I can try to reproduce with the following information: rolling version; sanitized config; platform (vm or hardware). I suggest opening as a separate task, as the forum reports so far (unless I'm mistaken) have pointed to this one. Thanks again for the info.

For the record, I am seeing the same thing with the same build (but different config commands, since this is a fresh installation, and there's not much in config.boot).

@opswill I suggest closing this task and opening a separate task focused on the specific continuing issue.

@opswill Yes, those debug messages report that vyos-configd is operating correctly: error_code 1 is 'success' in the enum list. Consequently, the obscuring error in vyos-configd has been resolved, and the root cause of your issue can now be investigated ...

Thank you for your work. I tried upgrading to the latest version 1.5-rolling-202411220007. After the upgrade, I still lost access to the LAN. However, after checking the logs, it seems that the previous exception has been fixed. There are just a few logs: Sending reply: error_code 1 with output. I'm not sure if this is a bug; could you please take a look?

As mentioned above, I'm not sure the Intel drivers actually support hardware flow table offload. I came across a thread on the netfilter development mailing list where the maintainer mentions that the driver needs to implement TC_SETUP_FT and that hw-tc-offload is not sufficient. The thread was discussing the igb driver for the Intel i350, but a cursory search of driver sources I only saw reference to TC_SETUP_FT in Mellanox and Mediatek drivers. It is entirely possible I'm missing something though.

Raised https://github.com/vyos/vyos.vyos/pull/365

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

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

In T6691#207172, @MPStudyly wrote:

I've just encountered the same issue upgrading from a 1.5 build from May 2024 to the most recent a few days ago. Had very little time to investigate. Next week I'll take some more time and will report back if I find anything interesting.

@sarthurdev and need to be in 1.4?

@syncer The fix is present in rolling and circinus branches

@sarthurdev, does this require backporting?

Can be closed as resolved by above PR.

T6899 merged; when rolling available, kindly retest. Thanks !

This will need the fix in https://vyos.dev/T6899 for backport to Circinus.

Issue present in 1.4.0 tested with Supermicro SOL on ttyS1.

It appears that path-limit GBP network options is deprecated

Thanks @gadams , and yes that was also mentioned in the forum discussion here:
https://forum.vyos.io/t/vyos-sometimes-does-not-start-properly/15486
I believe the correction made in the PR for the parent task T6899 should help reveal/resolve the issue.

It's not just on upgrade; I'm seeing the same problem in a fresh installation of VyOS 1.5-rolling-202411190007:

The PR for the parent task:
https://vyos.dev/T6899
will avoid obscuring underlying errors. Revisit after merge of above.

I did some investigation - apparently the plugin cannot match the full command pattern (including optional attributes) and silently refuses to generate a resultant set of commands - I will be looking into this - most likely the issue is related to rm_templates regex patterns for getval

Per slack conversation.

This should be fixed by

@sdwilsh Are you good to close this out? The change in ipv6 should be handled by the updated version now in main

As covered in last comment, all matters have been addressed, but for (then) open question re firewall migration. If that recurs, or still present, we will open a specific task.

As discussed a workaround is available, and preferable to the danger over usefulness of backporting to 1.3.x.

Adding that the long standing issue in T6543 is being addressed in the work of T6718, which provides a replacement to legacy loadConfig; the legacy code will not be corrected.

The only piece remaining here is a backport for Equuleus.

The specific high priority issue here was addressed in T6131; the general question of support for ZeroTier is in T6455. Closing this task as stated.

Fixed in https://github.com/vyos/ipaddrcheck/pull/10

fixed as part of https://vyos.dev/T6802
https://github.com/vyos/vyos-1x/pull/4177