VyOS image build scripts (mirror of https://github.com/vyos/vyos-build.git) https://git.amelek.net/vyos/vyos-build.git/atom?h=T7032 2025-01-05T19:00:49+00:00 2025-01-05T19:00:49+00:00 Christian Breunig christian@breunig.cc 2025-01-05T19:00:49+00:00 urn:sha1:f8b88e54bc5a0b9f3466699c94b63decd2502d57 VyOS is based on Debian * VyOS 1.3 -> Debian Buster (VyOS equuleus) * VyOS 1.4 -> Debian Bookworm (VyOS sagitta) * VyOS 1.5 -> Debian Bookworm (and then trixie) (VyOS circinus) * VyOS rolling -> Debian Bookworm (and then trixie) (VyOS t.b.d.) When running vyos@vyos:~$ lsb_release -a Distributor ID: VyOS Description: VyOS 1.5-rolling-202501031241 (current) Release: 1.5-rolling-202501031241 Codename: bookworm The codename in use is the Debian base distribution. This should be changed to the VyOS release name. 2025-01-03T16:00:52+00:00 Christian Breunig christian@breunig.cc 2025-01-03T14:00:49+00:00 urn:sha1:dabd5b2a6a6b9550439f9258a0a01dac2d0c0e60 The file /etc/os-release is written during image build, but it's content is not validated that it can be used by e.g. "lsb_release -a" command. 2025-01-01T19:10:52+00:00 Christian Breunig christian@breunig.cc 2025-01-01T19:06:42+00:00 urn:sha1:bf01c00d0446564ce8433ad1e916c366d7f8f32d Commit 085df7615a ("Testsuite: T861: always use 2 VCPUs") also altered the base MAC address used by QEMU to a locally administered one. Something that looked "right" in the beginning turned out to break the smoketest platform. The reason is the locally administered bit is evaluated in [1] and if set and not on the exclusion list (as it was a Realtek base MAC address before), the interface in question is not considered persistent and thus not added to the configuration file upon system startup. 1: https://github.com/vyos/vyos-1x/blob/825743b6bcdf8fa2c263dabaa3fee40ba7a98525/src/helpers/vyos-interface-rescan.py#L73-L74 2024-12-31T13:20:49+00:00 Christian Breunig christian@breunig.cc 2024-12-31T13:13:58+00:00 urn:sha1:81ae7efbac6cce251092ae91719611007a07a5f7 2024-12-31T13:20:32+00:00 Christian Breunig christian@breunig.cc 2024-12-31T13:13:29+00:00 urn:sha1:20b20efcca3a7c1d5e7acc375e31afbc212784cf 2024-12-31T13:13:04+00:00 Christian Breunig christian@breunig.cc 2024-12-31T13:13:04+00:00 urn:sha1:085df7615aaded2a24f3668f51505dfe7d446660 2024-11-12T07:48:28+00:00 Nataliia Solomko natalirs1985@gmail.com 2024-11-12T07:48:28+00:00 urn:sha1:a975e075fda18213bebffd63a10fa9ba21aa4be4 2024-10-06T14:16:02+00:00 Christian Breunig christian@breunig.cc 2024-10-06T14:10:04+00:00 urn:sha1:57d5afe0ff6623d63f014d277246b14a1f12f62c We can not run the interface related tests, and non interface related testcases in parallel to speedup the entire build process. 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. 2024-09-17T09:30:36+00:00 sarthurdev 965089+sarthurdev@users.noreply.github.com 2024-09-17T09:20:09+00:00 urn:sha1:d60f5222c264cdc426c5ea4ebba5107566900d22