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>
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.
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>`
Added two new options:
- `image_ext`. Can be used if the file extension needs to be different than
the image format
- `image_opts`. Required if a target format needs extra options.
