VyOS image build scripts (mirror of https://github.com/vyos/vyos-build.git) https://git.amelek.net/vyos/vyos-build.git/atom?h=rolling 2026-03-26T13:04:58+00:00 2026-03-26T13:04:58+00:00 Viacheslav Hletenko v.gletenko@vyos.io 2026-03-24T14:53:49+00:00 urn:sha1:2933d0f5f5d17551b292cdafb8315cf2876e64a7 Fix typos and mistakes in the comments No functional changes 2026-03-02T14:28:50+00:00 Viacheslav Hletenko v.gletenko@vyos.io 2026-03-02T14:28:50+00:00 urn:sha1:ff2a5df902ca31d51eda6744c94cb257d162fcfc T8120: add support for per CPU architecture serial interface name 2026-02-28T19:19:38+00:00 Christian Breunig christian@breunig.cc 2026-02-28T19:19:38+00:00 urn:sha1:f0dfd279c4f1f4065d893ddf22ca57d4b31cb542 This file is only needed to support upgrades from the legacy image management tools. Example would be an upgrade from VyOS 1.3.8 -> 1.5 (which is officially unsupported, but we always try our best). This is also the reason why we can leave the ttyS0 console in this file - there was no ARM64 image for VyOS 1.3! 2026-02-28T18:30:42+00:00 Christian Breunig christian@breunig.cc 2026-02-28T18:18:50+00:00 urn:sha1:39dc9c98c687049d060b70a6b5d1a99bc7b35c34 Commit f4877564276947 ("T8311: De-hardcode arch for live-build-config 10-vyos-addons") introduced a regression where an unavailable third-party helper script was invoked during initramfs hook execution, breaking the ISO build process. update-initramfs: Generating /boot/initrd.img-6.6.127-vyos live-boot: core filesystems devices utils wget blockdev. /etc/initramfs-tools/hooks/10-vyos-addons: line 3: dpkg-architecture: command not found The dpkg-architecture helper, provided by the dpkg-dev package, is not available during hook execution. The same result can be achieved using GNU coreutils instead: On x86_64 (aka amd64) both yield the same result: $ echo $(uname -m)-linux-gnu x86_64-linux-gnu $ echo $(dpkg-architecture -qDEB_HOST_MULTIARCH) x86_64-linux-gnu On aarch64 (aka arm64) both yield the same result: $ echo $(uname -m)-linux-gnu aarch64-linux-gnu $ echo $(dpkg-architecture -qDEB_HOST_MULTIARCH) aarch64-linux-gnu 2026-02-24T18:54:38+00:00 Viacheslav Hletenko v.gletenko@vyos.io 2026-02-24T18:54:38+00:00 urn:sha1:f4877564276947af06cef44e1d1b41330f66e9dd 2025-05-04T21:51:14+00:00 Christian Breunig christian@breunig.cc 2025-05-04T21:51:14+00:00 urn:sha1:0dd3b4e32937799ff02d2b281de4f7b188f94201 The issue ONLY appears on small terminals where systemd automatically truncates the lines to match the terminal width - so far so good. The BUG is, if truncation happens in the service name which is BOLD you're pretty much screwed, as truncation will not reset the color. We can set StatusUnitFormat=description in /etc/systemd/system.conf which will not print the service long description to avoid truncation making the boot a little less verbose. This actually restores the behavior of VyOS 1.3 2025-04-01T10:01:43+00:00 Daniil Baturin daniil@baturin.org 2025-04-01T10:01:43+00:00 urn:sha1:56497dd47d0ef074af7e504e8a5da2eb1c5c4c6e 2025-03-18T15:19:39+00:00 Christian Breunig christian@breunig.cc 2025-03-16T19:10:09+00:00 urn:sha1:a02b10b2ba4197c4dcd84eef053e4ab94995295b 2024-11-13T21:08:04+00:00 John Estabrook jestabro@vyos.io 2024-11-13T20:27:55+00:00 urn:sha1:2416f963adb4ff8dadbbc734e7ade07ff093cb53 Revert "T1416: remove deprecated default-union-grub-entry" This reverts commit d50707bb295dbd4bc50e3d0301fc8be605448429. The file grub/default-union-grub-entry and its companion install-image/postinst are needed for 'compatibility-mode' upgrades: when upgrading from a system with legacy image-tools, those two files are expected to exist in the mounted image of the target iso. 2024-09-25T18:24:21+00:00 Christian Breunig christian@breunig.cc 2024-09-25T18:24:21+00:00 urn:sha1:d235b31a095f9b8fdb2d5c231935c8b4b4c3da6c The shim review board (which is the secure boot base loader) recommends using ephemeral keys when signing the Linux Kernel. This commit enables the Kernel build system to generate a one-time ephemeral key that is used to: * sign all build-in Kernel modules * sign all other out-of-tree Kernel modules The key lives in /tmp and is destroyed after the build container exits and is named: "VyOS build time autogenerated kernel key". In addition the Kernel now uses CONFIG_MODULE_SIG_FORCE. This now makes it unable to load any Kernel Module to the image that is NOT signed by the ephemeral key.