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

We cannot remove images after this merge

Installed images: 2026.08.14-0025-rolling
2026.08.13-0024-rolling
Cannot prompt "Do you really want to delete the image 2026.08.13-0024-rolling?" ([Y/n] default=False): stdin is not a TTY. Pass an explicit non-interactive option (e.g. no_prompt/-y) instead of relying on ask_yes_no().
Error: Process completed with exit code 1.

Reopened

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

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

We have upgraded the Strongswan to 6.x
Open a new bug report if you have similar/any issues

PR https://github.com/vyos/vyos-build/pull/1267

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

It is already done as part of another change.

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

@hybridops It would be great to provide both variables retaining backward compatibility. Thanks.

Thanks @sageframe for the update and the original report.

Thanks, no-prompt does the job for my case, I'll use that.

Following @rherold analysis of root cause above, cf. https://github.com/vyos/vyatta-cfg/pull/153 --- so you can simply add the no-prompt option to the script in question.

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

Related PRs:
https://github.com/vyos/vyconf/pull/64
https://github.com/vyos/vyos-1x/pull/5395

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

Thx for the Information, but I saw here also the possibility to give this to upstream finding a better solution for this.

We usually don't add docs task for the forge.
You can add PR directly to documentation repo without task number

Use the forum if you want to discuss your issue and find solutions
Phorge is the wrong place for it.

So this mean we can close the bug, because it's looks like that I need to redistrubute KERNEL ones with some filtering or you see some other option?

Root cause confirmed — this is an upstream FRR behavior change, not a VyOS bug.

Data below, but looks like different approach of FRR, could be issue there, but now I thinking how we can workaround it, just to somehow inject route into OSPFv3

Thanks for the full dump — that actually complicates things rather than confirming the kernel-FIB-metric theory. Your new output shows the static route absent from the

kernel FIB on both 1.4.4 and 1.5.1 (only proto kernel metric 256 present in each), which contradicts the earlier 1.4.4 snippet showing proto static metric 20 there. So
either that earlier capture was momentary/stale, or the kernel-installed route is not stable over time (e.g. it disappears/reappears around RA refresh or a DHCPv6 lease
event).

The config in VyOS is stored in /config/config.boot as json-file.

vyos@r0-sto.e-utp.net:~$ ip -6 r s | grep -v tun7
2001:67c:21ec::1 dev lo proto kernel metric 256 pref medium
2001:67c:21ec:9999::8 dev lo proto kernel metric 256 pref medium
2a0f:5707:ba00::1 dev lo proto kernel metric 256 pref medium
2a0f:5707:ba0e:100:14ab:ba50:9291:6963 dev eth0 proto kernel metric 256 pref medium
2a0f:5707:ba0e:100::/64 dev eth0 proto kernel metric 256 pref medium
fe80::/64 dev lo proto kernel metric 256 pref medium
fe80::/64 dev eth0 proto kernel metric 256 pref medium
default via fe80::4f7:44ff:fe8f:a860 dev eth0 proto ra metric 1024 expires 1790sec hoplimit 255 pref medium
vyos@r0-sto.e-utp.net:~$

PR https://github.com/vyos/vyos-documentation/pull/2195

Thanks - that rules out BGP/extended-nexthop entirely then, good to know it's a legitimate RA from your upstream (AWS) gateway, not a self-sent one.

Test results: rebuilt vyos-linux-firmware against the IWLMLD-enabled kernel (rolling @ 6.18.44) with the missing files included, rebuilt the ISO, and the BE200 now works end-to-end on the same hardware from the original report:

There is no BGP on that box.
This box is IPv6 client, RA are send from upstream router, in that case is AWS.

Both the config and the relevant sysctls (accept_ra/accept_ra_pinfo/
forwarding) being identical on 1.4.4 and 1.5.1 rules out an interface-
config or sysctl-default explanation. I initially suspected a kernel
patch-level difference (6.6.117 vs 6.6.144), but I don't think that's
it either: the likely real candidate is T7531 (bgpd's automatic IPv6
RA sending, the bgp ipv6-auto-ra behavior, disabled via
set protocols bgp parameters disable-ipv6-auto-ra).

vyos@r0-sto.e-utp.net:~$ uname -r
6.6.144-vyos

Thanks, that rules out a config difference - the eth0 setup (DHCP/DHCPv6/autoconf) and the resulting address are identical between the two versions.

Doesn't see difference:

---Thanks for the detailed comparison, that confirms the route-selection theory: on 1.5.1 there's now a third competing entry for this prefix that doesn't exist on

1.4.4:

How this looks like on 1.4.4, same config, for clearnes: 51.21.99.1 is this Router ID.

Follow-up: I test-built an ISO from rolling with the merged fix (e14a489) to validate on the same BE200 hardware. The initial PR works... the card is now properly detected:

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

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

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

PR https://github.com/vyos/vyos-build/pull/1265

In T9197#274465, @Viacheslav wrote:

@srnoth Would you like to claim the task and submit a PR?

@srnoth Would you like to claim the task and submit a PR?

PR https://github.com/vyos/vyos-build/pull/1263

PR https://github.com/vyos/vyos-build/pull/1264