| Age | Commit message (Collapse) | Author |
|---|
|
|
|
lb (live-build) binary runs binary_rootfs first, then binary_grub-efi.
binary_grub-efi temporarily installs EFI tooling and then runs:
"apt remove --auto-remove --purge --allow-remove-essential"
That cleanup is safe for the already-generated squashfs, but it mutates
build/chroot and can remove vyos-1x, breaking subsequent work that expects
chroot to remain intact for SBOM generation.
But why unpacking the squashfs?
In an ideal world we could call syft on the compressed squashfs file which is
supported. In our world, we do use a BCJ pre-filter chained with LZMA2 for
compressing the squashfs, which will increase the compression ratio without a
decompression penalty.
Difference: ~14.3 MB, ~2.7% smaller
This is unsupported by fyft which means we do need to unpack the squashfs first
before checking the files and generating the SBOM file.
|
|
Commit 75a495b237 ("sbom: T8542: create during ISO assembly") will shadow any
subsequent calls to vyos.utils.process.cmd() as cmd has be redefined as
variable to hold the CLI command strings for SBOM generation using the syft
binary.
This has been fixed by replacing the cmd variable with another name syft_cmd.
|
|
|
|
|
|
T8445: add support for extension of activation system
|
|
|
|
When building raw images, leave hint to indicate activiation init on
boot.
|
|
VyOS flavors might come with boot_settings which already provided additional
serial interface settings if required. Instead of using our own definitions,
re-use what's already existing.
scripts/image-build/build-vyos-image comes with an implicit default for
boot_settings like console number and speed, thus we do not need to redefine
the existing default - again.
|
|
In order for amd64 or arm64 images to know their serial console settings, we
embed a new file named "flavor.json" under "/usr/share/vyos" into the resulting
image. The file holds configuration parameters unique to the build flavor.
Corresponding library functions are available via a Python vyos.flavor module.
|
|
Fix typos and mistakes in the comments
No functional changes
|
|
T8311: move to GNU coreutils when building GLIBC multiarch variable
|
|
This reverts commit 673a2de05776656b70dc4803aa3579138e9fffca.
|
|
x86_64 and arm64 both use a different serial interface during Linux Kernel
boot. Define either ttyS0 or ttyAMA0 per CPU architecture. This could be
further overwritten by individual flavors.
|
|
Commit 88f11dc01bb6 ("T8311: De-hardcode arch for live-build-config
92-strip-symbols") added use on dpkg-architecture which is not present in the
normal chroot build environment.
To be able to use it we need the dpkg-dev in our build chroot environment.
|
|
|
|
|
|
do not exist
|
|
|
|
|
|
|
|
```
vyos@r15:~$ show version | match dir
Build commit ID: d8038ded37fadb-dirty
```
Having uncommited files in vyos-build is completely normal:
custom configs, EULA files in official release builds,
anything else that flavor files may include.
However, many people are not familiar with the specific
meaning of "dirty" in git or with the build process and assume
that "dirty" means something went wrong with the image build.
|
|
build: T7409: do not include MD5 checksums in the ISO image
|
|
|
|
It doesn't appear necessary anymore, if it ever was
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
build: T6923: use the Debian mirror for security updates if it's specified explicitly
|
|
|
|
explicitly
but the security mirror is not
|
|
build: T6904: allow development builds to have version strings
|
|
|
|
|
|
|
|
|
|
build: T6738: add build_type field to version data instead of the very limited and unused lts_build
|
|
instead of the very limited and unused lts_build
|
|
|
|
so that the manifest only contains files considered build artifacts,
and those artifacts can be automatically picked up by CI jobs and the like
|
|
|
|
|
|
This adds support for UEFI Secure Boot. It adds the missing pieces to the Linux
Kernel and enforces module signing. This results in an additional security
layer where untrusted (unsigned) Kernel modules can no longer be loaded into
the live system.
NOTE: This commit will not work unless signing keys are present. Arbitrary
keys can be generated using instructions found in:
data/live-build-config/includes.chroot/var/lib/shim-signed/mok/README.md
|
|
|
|
|
|
|
|
Moved defaults away from argparser to `defaults.py`. This unlocks the ability to
pass values that can be defined as command line arguments via a config file.
With this change logic looks like this (in order of overrides).
Pre-build config:
`data/defaults.toml` -> `build-flavors/<flavor>.toml` ->
`--<command line argument>`
Build config:
`defaults.py` -> `data/defaults.toml` -> `build-types/<type>.toml` ->
`architectures/<architecture>.toml` -> `build-flavors/<flavor>.toml` ->
`--<command line argument>`
|
