Updated aws-gwlbtun requires boost too new for Debian bookworm,
but requires only one header-only library.
* Add download/installation of thist boost header library.
* Set path to this boost installation via cmake options.
```
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.
The build package binaries script should exit if the repo is absent
or cannot be cloned
If a build package `repo-a` depends on the `repo-b` and the `repo-b`
cannot be cloned, then we shoud exit from the script to avoid
partly build dependencies
For example:
```
[[packages]]
name = "fake-repo"
commit_id = "v0.0.1"
scm_url = "https://github.com/vyos/fake-repo"
[[packages]]
name = "ethtool"
commit_id = "debian/1%6.10-1"
scm_url = "https://salsa.debian.org/kernel-team/ethtool"
```
If ethtool depends on some fake-package and this package cannot be
downloaded from the repo, then we shouldn't build the ethtool package
at all.
Enhanced the raw image creation logic to dynamically detect and assign
EFI and root partitions based on the number of partitions created by kpartx.
- Supports both 2-partition and 3-partition layouts
- Adds debug output for mapped partitions
- Avoids hardcoded assumptions about partition order
- Improves resilience in cloud-init and containerized build contexts
Fixes build failure when /dev/loopXp3 is missing or not mapped properly.
Signed-off-by: Gabin-CC <gabin.laurent@rte-international.com>
Description
This pull request introduces improvements to the raw_image.py script responsible for building raw disk images in the VyOS build process.
Main Changes
Added use of kpartx to reliably map EFI and root partitions from the loop device.
Introduced disk_details as an attribute on the BuildContext object to pass partition metadata through the image build steps.
Improved the __exit__ method for BuildContext to unmount all mount points and clean up kpartx mappings and loop devices, even in failure cases.
Fixed a crash in mount_image() when con.disk_details was not set.
Added useful debug logs for loop device usage and partition mapping.
Motivation
The previous implementation assumed partitions like /dev/loopXp3 would appear automatically, which is unreliable across some environments (especially containers or newer systems).
This PR makes the process more reliable by explicitly mapping partitions with kpartx, a tool designed for this purpose.
It also ensures proper resource cleanup by unmounting and detaching everything cleanly, preventing leaked loop devices or stale mount points.
Test Instructions
Flavor : cloud-init.toml
packages = [
"cloud-init",
"qemu-guest-agent"
]
image_format = ["qcow2"]
disk_size = 10
[boot_settings]
console_type = "ttyS0"
Run:
sudo ./build-vyos-image --architecture amd64 \
--build-by "you@example.com" \
--reuse-iso vyos-1.5-rolling-*.iso \
cloud-init
Expected behavior:
The build completes without errors.
The .qcow2 image file is generated and bootable (e.g., in KVM or Proxmox).
Partitions are mounted correctly via /dev/mapper/loopXp*.
Signed-off-by: Gabin-CC <gabin.laurent@rte-international.com>
Kernel compile time option for our custom patch to enable inotify
on stackable filesystems accidently got removed in commit cfdd4451ca3aa
("Kernel: T7428: remove io_uring support").
Option was re-enabled.
Previous patch was removed during VyOS 1.3 -> 1.4 development cycle as the
internal handling for Kernel package generation changed.
This brings back the perf binary in a new linux-perf-$KERNELVERSION
Debian package.
Given the recent chatter about io_uring and it flaws - e.g. [1] - and we have
to my knowledge no use for it we should remove it from the Kernel configuration.
Every feature not used and removed from the Kernel is a good one.
1: https://www.armosec.io/blog/io_uring-rootkit-bypasses-linux-security/
