public inbox for kdevops@lists.linux.dev
 help / color / mirror / Atom feed
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


  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