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

I raised a draft PR (https://github.com/vyos/vyos.vyos/pull/357) to tackle some of the compatibility issues. I will try and finalise it in coming days

forum post with the same problem: https://forum.vyos.io/t/vyos-1-2-traffic-policy-shaper-match-interface-not-working/8389

exmaple test with shaper policy:

Implemented handling for the CLI command to set a filter by interface(rt_iif).
Implemented a command such as set qos policy limiter test class 10 match test_match interface 'eth1' to generate filters similar to those used in VyOS 1.3.

This is not valid for 1.4 and 1.5
Only valid for 1.3 and older images.

Thanks for bringing this to our attention @paulywog

I was able to update my router to VyOS 1.5-rolling-202411070006 and my xen vif interface is working once again. Thanks everyone!

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.

Hi marekm

Needs testing, will be fixed in the next rolling release

@syncer not it doesn’t
JSON parser wasn’t back ported so other branches are not affected

@Viacheslav, does this require a backport?

Is the binary file data/live-build-config/archives/zabbix-official-repo.key.chroot correct? Other key files there are text files.

BTW @SteveP these iperf speeds look quite impressive, I thought USB overhead would make it difficult to see much more than 1 Gbps in practice. Realtek was traditionally a "low cost, low performance" brand, it seems they have made a lot of progress...

Please make it possible to load the microde separately (file downloaded directly from CPU vendor, independent of VyOS update) to address the last edge case. Especially important for some Intel CPUs that self-destruct with too high voltage, as update applied too late will not reverse any permanent damage already done.

I created a separated bug report https://vyos.dev/T6856