From: Luis Chamberlain <mcgrof@kernel.org>
To: Chuck Lever <cel@kernel.org>, Daniel Gomez <da.gomez@kruces.com>,
kdevops@lists.linux.dev
Cc: Luis Chamberlain <mcgrof@kernel.org>
Subject: [PATCH 7/8] guestfs: Fix base_image_pathname for custom images
Date: Fri, 17 Oct 2025 19:31:52 -0700 [thread overview]
Message-ID: <20251018023154.2239688-8-mcgrof@kernel.org> (raw)
In-Reply-To: <20251018023154.2239688-1-mcgrof@kernel.org>
Fix a bug in the guestfs role where base_image_pathname was set to
point to the custom_images directory instead of the base_images
directory when using custom raw images.
The Bug:
--------
When guestfs_has_custom_raw_image is true, the guestfs role was setting:
base_image = "{{ storagedir }}/custom_images/{{ virtbuilder_os_version }}/..."
This path was then passed as base_image_pathname to the base_image role.
The base_image role's custom-image.yml has a task that copies the
custom image from custom_images/ to base_images/:
- name: Copy custom image to base image location
command: cp --reflink=auto '{{ custom_image }}' '{{ base_image_pathname }}'
when:
- custom_image_stat.stat.exists or custom_image_download is changed
- custom_image != base_image_pathname
However, both custom_image and base_image_pathname were set to the
SAME PATH (in custom_images/), so the condition "custom_image !=
base_image_pathname" was always false, causing the copy task to be
skipped.
This meant base images were never created in the base_images directory,
breaking workflows that expect base images there (like rcloud).
The Fix:
--------
Changed guestfs role to always set base_image to the base_images
directory location, regardless of whether custom images are used:
base_image = "{{ storagedir }}/base_images/{{ virtbuilder_os_version }}.raw"
Now for custom images:
- custom_image = /path/to/custom_images/image/image.raw (source)
- base_image_pathname = /path/to/base_images/image.raw (destination)
- These are different paths, so the copy runs correctly
For non-custom images:
- virt-builder creates directly at base_images/image.raw
- No copy needed (same behavior as before)
Impact:
-------
This fix ensures that when using custom raw images:
1. Images are properly customized in custom_images/ directory
2. Customized images are copied to base_images/ directory
3. Other roles and workflows can find base images in the expected location
4. Permissions are set correctly (root:libvirt-qemu 0640)
Fixes: 7af0e602e8c8 ("guestfs: bringup: fix ssh key injection")
Generated-by: Claude AI
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
---
playbooks/roles/guestfs/tasks/main.yml | 14 +-------------
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/playbooks/roles/guestfs/tasks/main.yml b/playbooks/roles/guestfs/tasks/main.yml
index 6618687e..e5960946 100644
--- a/playbooks/roles/guestfs/tasks/main.yml
+++ b/playbooks/roles/guestfs/tasks/main.yml
@@ -25,24 +25,12 @@
storagedir: "{{ kdevops_storage_pool_path }}/guestfs"
delegate_to: localhost
-- name: Set the pathname of the OS base image
+- name: Set the pathname of the base image in base_images directory
tags:
- base_image
- bringup
ansible.builtin.set_fact:
base_image: "{{ storagedir }}/base_images/{{ virtbuilder_os_version }}.raw"
- when:
- - not guestfs_has_custom_raw_image|bool
- delegate_to: localhost
-
-- name: Set the pathname of the custom OS base image
- tags:
- - base_image
- - bringup
- ansible.builtin.set_fact:
- base_image: "{{ storagedir }}/custom_images/{{ virtbuilder_os_version }}/{{ virtbuilder_os_version }}.raw"
- when:
- - guestfs_has_custom_raw_image|bool
delegate_to: localhost
- name: Ensure the required base OS image exists
--
2.51.0
next prev parent reply other threads:[~2025-10-18 2:31 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-18 2:31 [PATCH 0/8] guestfs / base_images: fixes Luis Chamberlain
2025-10-18 2:31 ` [PATCH 1/8] guestfs: Fix Debian 13 (Trixie) APT sources file path Luis Chamberlain
2025-10-18 2:31 ` [PATCH 2/8] guestfs: Don't delete APT sources copied from host Luis Chamberlain
2025-10-18 2:31 ` [PATCH 3/8] guestfs: Fix dracut-config-rescue removal for Debian systems Luis Chamberlain
2025-10-18 18:16 ` Chuck Lever
2025-10-21 16:56 ` Luis Chamberlain
2025-10-18 2:31 ` [PATCH 4/8] base_image: put a guard check before adding kdevops user Luis Chamberlain
2025-10-18 2:31 ` [PATCH 5/8] base_image: relax base image permissions Luis Chamberlain
2025-10-18 2:31 ` [PATCH 6/8] guestfs: Use sudo for base image copy with system libvirt Luis Chamberlain
2025-10-18 2:31 ` Luis Chamberlain [this message]
2025-10-18 2:31 ` [PATCH 8/8] playbooks: Fix host pattern for single-node setups Luis Chamberlain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251018023154.2239688-8-mcgrof@kernel.org \
--to=mcgrof@kernel.org \
--cc=cel@kernel.org \
--cc=da.gomez@kruces.com \
--cc=kdevops@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox