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

https://github.com/vyos/vyos-1x/pull/4607
https://github.com/vyos/vyos-documentation/pull/1658

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

Resolved by T7424 and https://github.com/vyos/vyos-build/pull/983.

Commands also affected:

https://github.com/vyos/vyos-build/pull/982

Caused by this commit that merges iproute2-next into the main branch of iproute2 and introduced in v6.15.0 which was pushed to debian-backports a couple of days ago.

For anyone else who finds this in their travels, trying to figure out why 1.4.1 broke their DHCPv6 with custom DUID: the workaround steps detailed are not sufficient to restore DHCPv6 functionality. Removing the custom DUID from the VyOS configuration leaves invalid data in /var/lib/dhcpv6/dhcp6c_duid, causing DHCPv6 solicits to be ignored by the server as they don't contain a valid DUID.

Can't be bothered trying to contribute to this project any more.

Also just discovered this at the end of the configure results output before kea starts building:

https://github.com/vyos/vyos-build/pull/864

https://github.com/vyos/vyos-build/pull/865

https://github.com/vyos/vyos-build/pull/828

@aidan-gibson You can build current with the microcode packages included by passing the following to the build script:

This is the result of buster-backports being removed from the main repository server: https://backports.debian.org/news/Removal_of_buster-backports_from_the_debian_archive/

Confirmed this is now fixed.

I've traced the issue back to a USB device that creates an Ethernet interface on the OS. I suspect that the issue was caused by the USB device not being ready by the time ddclient tried to start and bind to configured interfaces, causing the boot time configuration to fail. Given that this is an edge case that would rarely occur, and now that I have replaced the USB device with an actual Ethernet device, I'm happy to close this bug report.

I've done more investigation of this issue today, and I believe I understand the cause.

I haven't had the chance to test this, but the following should be sufficient to replicate the behaviour:

Maybe making the size of the ramdisk configurable via CLI would be wise? I feel that there's enough variation in hardware configurations out there that hard-coding a value would cause problems.

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