@j.vela please check if this option resolves the issue:
- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
May 18 2026
May 17 2026
Quite possibly this issue is caused by CONFIG_HYPERV_STORAGE=m removal in this PR - https://github.com/vyos/vyos-build/pull/1177
Narrowed it down to changes between 2026.05.05-0039-rolling (sig) and 2026.05.07-0040-rolling.
Also, I'm getting error
May 16 2026
ok thanks for the info. Stream 2026.02 and 2026.03 were released very close to each other, so do you have a guesstimate on when a new version of Stream will be released? I might jump to a nightly build from early May until the next Stream is out to pick up the fix for this issue. thanks for everything!
May 15 2026
PR, for the record: https://github.com/vyos/vyos-build/pull/1190
Required changes:
We do already have a Kernel build with a custom patch.
This removes the patch and bumps to the appropriate version number: https://github.com/vyos/vyos-build/pull/1192
@taylorcb updating the Kernel manually is not supported by us. The next stream build will have an updated Kernel with these vulnerabilities mitigated.
Hi. Kind of a newbie here tracking Kernel updates with VyOS, and I'm not sure if it's appropriate to ask here? I'm running Stream 2026.03, and would like to stay on the Stream builds, so will the 6.6.137 Kernel be added to the next Stream build, or is there a way I can pull it into my current router? The nightly rolling are running are running a 6.18 Kernel, and again I really would like to stay on a Stream build to get the fix for the copy.fail vulnerability. thanks!
Already fixed by https://github.com/vyos/vyos-1x/pull/5122
Consider to backport it, reopened
May 14 2026
After the patch:
commit lock optimisation is in https://github.com/vyos/vyos-1x/pull/5200 which we might backport to 1.5.1 earlier then vyos-netlinkd
@fabrizziop https://github.com/vyos/vyos-1x/pull/5199 please sign the CLA by replying: I have read the CLA Document and I hereby sign the CLA as I put you in as author of the commit
In T8781#264420, @c-po wrote:@fabrizziop thank you for the patch. I would like to partly reuse it and add you as author. Your commit is authored by Fabrizio <fabrizzio@example.com> - is this what you wan't or what Name/Familyname/mail should I include.
@fabrizziop thank you for the patch. I would like to partly reuse it and add you as author. Your commit is authored by Fabrizio <fabrizzio@example.com> - is this what you wan't or what Name/Familyname/mail should I include.
@c-po or @dmbaturin guys, would you be open to adding ldap with sssd support without kerberos?
Copy from GH PR
[*never mind] DUID behavior. Out of the box, dhcpcd generates a per-interface DUID-LL (type 0003, derived from the interface MAC) rather than the single global DUID-LLT (type 0001) that wide-dhcpv6-client stored in /var/lib/dhcpv6/dhcp6c_duid. I think it's probably possible to come up with a migration here to keep operators' DUIDs stable, but I wasn't sure if it was worth it -- or if documenting the fact that auto DUIDs will churn is sufficient.