In this failure case, there are some expected "failed" lines in /var/log/vyatta/cfg-stdout.log. Although they are not detailed log messages, they may help narrow down the source of the failure, if you could share those.

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

Thanks, @Viacheslav. We will need to add a migration script for the previous setting; that is simple in this case, since, as you observed, it was a no-op, and can just be dropped. If you are busy, I can add it.

Tested successfully in Crux.

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

Yes, @jjakob, I run docker as indicated in the vyos-build README, which includes --privileged. I am not that concerned with the docker issue here; rather I want the script to work, and am adding in the necessary ingredients to the script itself. Compare the older prescription:
https://wiki.vyos.net/wiki/Building_images_using_vyos-build_Docker_container#Building_Google_Cloud.2FGCE_image

This should be made consistent with other usage: paths should be lists, not strings. I will make the change, and any other details needed for consistency with model.

https://github.com/vyos/vyos-documentation/pull/220

@Dmitry The simplest workaround for the moment is to add the following to your load steps:

I've tracked this down to a bug in libboost-filesystem, versions < 1.56, that occurs if the locale is not properly set, as is the case within the Docker environment:

Yes, closing.

The 'showConfig' op is not considered ready for 1.2.5, and specifically json configFormat is not yet backported to crux. Regarding the output in the blog, see the line following the screen shot: "In reality that output is not pretty-printed, though we may add a flag for it. "

Checked on vyos-1.2.5-epa1:

All works as expected; thanks.

This is a result of a missing package vyos-intel-ixgbe_5.6.3-0_amd64.deb in http://dev.packages.vyos.net/repositories/crux/ --- when missing, the build will use an outdated package, leading to incorrect dependencies on the kernel version. On the other hand, if the correct intel module is built as a local package, there is only one resident linux-image, and update-initramfs succeeds as usual. The build/upload mechanism for the intel modules will be fixed soon, and the issue resolved.

Firstly, we need to determine why there are two kernel images.

This is dependent on T2029, PR 224, and should only be merged after that PR.

This is dependent on T2029, PR 224, and should only be merged after that PR.