[PATCH v2 00/15] Fedora on Debian

[PATCH v2 00/15] Fedora on Debian

[Daniel Gomez]

This series enables testing Fedora guest VMs on Debian host systems,
addressing cross-distribution compatibility issues in guestfs workflow
and adding manual CI workflow support for multi-distro testing.

The key technical challenge solved is SELinux context handling
when building Fedora images on non-SELinux hosts like Debian, where
libguestfs cannot persist security.selinux extended attributes. The
series also fixes Ansible variable scope issues in 9P builds and adds
configuration infrastructure to support distribution-specific guest
selection.

The GitHub Actions workflow gains manual guest OS selection to validate
distro-specific fixes across both Debian and Fedora environments.

kdevops-ci blktests_nvme validation test using Fedora on Debian:
https://github.com/linux-kdevops/kdevops/actions/runs/18883031353

Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
Changes in v2:
- Update patch 9p os detection and leverage Kconfig distro variables as
Chuck's suggestion
- Drop include/import grub changes as unnecessary
- Fix same issue in selftests install-deps step
- CI tests :
1. Fedora on Debian
https://github.com/linux-kdevops/kdevops/actions/runs/18903303694
2. Debian on Debian
https://github.com/linux-kdevops/kdevops/actions/runs/18903311654
- Link to v1: https://lore.kernel.org/r/20251028-fedora-on-debian-v1-0-1802ab2f993a@samsung.com

---
Daniel Gomez (15):
      base_image: restore locales-all installation for Debian Trixie
      guestfs: fix Kconfig indentation style
      guestfs: remove unused bringup debug Kconfig options
      guestfs: fix spelling errors and Debian capitalization
      base_image: set selinux to permissive for fedora on debian hosts
      ansible_provisioning: fix help text indentation style
      devconfig: fix undefined custom repos/packages variables
      devconfig: fix Ansible boolean conditional for custom repos
      bootlinux: fix os detection for 9p build dependency installation
      selftests: fix os detection for 9p build dependency installation
      guestfs: generate fedora distribution-specific hostname prefixes
      defconfigs: add fedora-41 fragment for guestfs
      defconfigs: add debian-13 fragment for guestfs
      github: add guest OS selection for CI testing
      guestfs: increase SSH config timeout for Fedora on Debian hosts

 .github/actions/configure/action.yml               | 22 ++++++-
 .github/workflows/kdevops.yml                      | 10 ++++
 Makefile                                           |  7 ---
 defconfigs/configs/guestfs-debian-13.config        |  2 +
 defconfigs/configs/guestfs-fedora-41.config        |  2 +
 kconfigs/Kconfig.ansible_provisioning              | 58 +++++++++---------
 kconfigs/Kconfig.guestfs                           | 68 +++++++++-------------
 kconfigs/Kconfig.kdevops                           |  1 +
 playbooks/roles/base_image/tasks/base-image.yml    | 34 +++++++++++
 .../roles/base_image/templates/virt-builder.j2     |  1 +
 playbooks/roles/bootlinux/defaults/main.yml        |  6 ++
 playbooks/roles/bootlinux/tasks/build/9p.yml       |  2 +-
 .../roles/bootlinux/tasks/install-deps/main.yml    |  6 +-
 .../bootlinux/tasks/install-deps/redhat/main.yml   |  4 +-
 playbooks/roles/devconfig/defaults/main.yml        |  4 ++
 .../redhat/main.yml                                |  2 -
 playbooks/roles/guestfs/tasks/bringup/main.yml     |  4 ++
 playbooks/roles/selftests/defaults/main.yml        |  6 ++
 .../tasks/install-deps/main-localhost.yml          | 10 ++++
 playbooks/roles/selftests/tasks/main.yml           |  2 +-
 scripts/update_ssh_config_guestfs.py               |  8 ++-
 21 files changed, 172 insertions(+), 87 deletions(-)
---
base-commit: 8d223755643d5017562a632ea7f0aaa79f2f5563
change-id: 20251028-fedora-on-debian-73ed90d0fbd8

Best regards,
--  
Daniel Gomez <da.gomez@samsung.com>

[PATCH v2 01/15] base_image: restore locales-all installation for Debian Trixie

[Daniel Gomez]

From: Daniel Gomez <da.gomez@samsung.com>

The virt-customize phase was failing with "update-locale: Error: invalid
locale settings" because commit 6bb3bfb2c257 removed the locales-all
package installation but left the locale configuration commands that
depend on it.

The update-locale command validates all settings in /etc/default/locale,
and without locales-all providing the necessary locale infrastructure, it
rejects the LANGUAGE=en_US:en setting as invalid during image build.

Restore the locales-all installation within the Debian Trixie conditional
block, placing it immediately before the locale configuration sequence so
the image has proper locale support from the start. This prevents SSH
locale warnings on first boot while keeping the package Debian-specific.

Generated-by: Claude AI
Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 playbooks/roles/base_image/templates/virt-builder.j2 | 1 +
 1 file changed, 1 insertion(+)

diff --git a/playbooks/roles/base_image/templates/virt-builder.j2 b/playbooks/roles/base_image/templates/virt-builder.j2
index 3069e95f..289ee9e5 100644
--- a/playbooks/roles/base_image/templates/virt-builder.j2
+++ b/playbooks/roles/base_image/templates/virt-builder.j2
@@ -73,6 +73,7 @@ append-line /etc/nsswitch.conf:ethers:         db files
 append-line /etc/nsswitch.conf:rpc:            db files
 append-line /etc/nsswitch.conf:netgroup:       nis
 uninstall cloud-init
+install locales-all
 write /etc/default/locale:LANG=en_US.UTF-8
 append-line /etc/default/locale:LANGUAGE=en_US:en
 write /etc/locale.gen:en_US.UTF-8 UTF-8

-- 
2.51.0

[PATCH v2 02/15] guestfs: fix Kconfig indentation style

[Daniel Gomez]

From: Daniel Gomez <da.gomez@samsung.com>

Fix help text indentation in Kconfig.guestfs to use tabs consistently
instead of mixed tabs and spaces. Kconfig style requires tabs for
indentation with tab+2spaces acceptable for help text continuation.

Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 kconfigs/Kconfig.guestfs | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/kconfigs/Kconfig.guestfs b/kconfigs/Kconfig.guestfs
index d0ac66fc..451c3d38 100644
--- a/kconfigs/Kconfig.guestfs
+++ b/kconfigs/Kconfig.guestfs
@@ -194,9 +194,9 @@ config GUESTFS_DEBIAN_IMAGE_NAME
 	default "debian-12" if GUESTFS_DEBIAN_BUSTER
 
 config GUESTFS_DEBIAN_BOX_SHORT
-        string
-        default "debian13" if GUESTFS_DEBIAN_TRIXIE
-        default "debian12" if GUESTFS_DEBIAN_BUSTER
+	string
+	default "debian13" if GUESTFS_DEBIAN_TRIXIE
+	default "debian12" if GUESTFS_DEBIAN_BUSTER
 
 config GUESTFS_DEBIAN_COPY_HOST_SOURCES
 	bool
@@ -223,14 +223,14 @@ config GUESTFS_DEBIAN_COPY_HOST_SOURCES
 endif # GUESTFS_DEBIAN
 
 config VIRT_BUILDER_OS_VERSION
-       string "virt-builder os-version"
-       default "fedora-39" if GUESTFS_FEDORA
-       default GUESTFS_DEBIAN_IMAGE_NAME if GUESTFS_DEBIAN
-       help
-         Have virt-builder use this os-version string to
-         build a root image for the guest. Run "virt-builder -l"
-         to get a list of operating systems and versions supported
-         by guestfs.
+	string "virt-builder os-version"
+	default "fedora-39" if GUESTFS_FEDORA
+	default GUESTFS_DEBIAN_IMAGE_NAME if GUESTFS_DEBIAN
+	help
+	  Have virt-builder use this os-version string to
+	  build a root image for the guest. Run "virt-builder -l"
+	  to get a list of operating systems and versions supported
+	  by guestfs.
 
 choice
 	prompt "Guestfs bringup debug mode"

-- 
2.51.0

[PATCH v2 03/15] guestfs: remove unused bringup debug Kconfig options

[Daniel Gomez]

From: Daniel Gomez <da.gomez@samsung.com>

Remove GUESTFS_BRINGUP_DEBUG_* configuration options as they reference
scripts/guestfs_bringup.sh which no longer exists after the migration to
Ansible-based bringup in the guestfs role.

Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 kconfigs/Kconfig.guestfs | 21 ---------------------
 1 file changed, 21 deletions(-)

diff --git a/kconfigs/Kconfig.guestfs b/kconfigs/Kconfig.guestfs
index 451c3d38..63262a8c 100644
--- a/kconfigs/Kconfig.guestfs
+++ b/kconfigs/Kconfig.guestfs
@@ -232,25 +232,4 @@ config VIRT_BUILDER_OS_VERSION
 	  to get a list of operating systems and versions supported
 	  by guestfs.
 
-choice
-	prompt "Guestfs bringup debug mode"
-	default GUESTFS_BRINGUP_DEBUG_DISABLED
-
-config GUESTFS_BRINGUP_DEBUG_DISABLED
-	bool "Disabled"
-	help
-	  Disables bringup debug.
-
-config GUESTFS_BRINGUP_DEBUG_0
-	bool "set -x"
-	help
-	  Enables 'set -x' when running scripts/guestfs_bringup.sh.
-
-config GUESTFS_BRINGUP_DEBUG_1
-	bool "set -euxo pipefile"
-	help
-	  Enables 'set -euxo pipefile' when running scripts/guestfs_bringup.sh.
-
-endchoice
-
 endif # GUESTFS

-- 
2.51.0

[PATCH v2 04/15] guestfs: fix spelling errors and Debian capitalization

[Daniel Gomez]

From: Daniel Gomez <da.gomez@samsung.com>

Fix multiple minor spelling errors in Kconfig help text.

Capitalize "Debian" when referring to the distribution name per proper
noun conventions, while keeping lowercase in technical contexts like
"debian-testing" repository names.

Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 kconfigs/Kconfig.guestfs | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/kconfigs/Kconfig.guestfs b/kconfigs/Kconfig.guestfs
index 63262a8c..f7601bc9 100644
--- a/kconfigs/Kconfig.guestfs
+++ b/kconfigs/Kconfig.guestfs
@@ -118,12 +118,12 @@ config GUESTFS_DEBIAN_TRIXIE
 	select GUESTFS_HAS_CUSTOM_RAW_IMAGE_SHA512SUMS
 	select GUESTFS_HAS_CUSTOM_RAW_IMAGE_ROLLING
 	help
-	  Select this for debian trixie, debian 13. Since debian does not yet
-	  provie a virt-builder repo, we must download mock up our own URL
-	  for trixie release, as the default guestfs repo only has debian buster.
+	  Select this for Debian Trixie, Debian 13. Since Debian does not yet
+	  provide a virt-builder repo, we must download mock up our own URL
+	  for trixie release, as the default guestfs repo only has Debian Buster.
 	  We download the image for you once, and once its there we don't refresh
 	  it. We can later add support to force a refresh using the latest URL,
-	  as trixie is debian-testing and debian testing always has an new
+	  as trixie is debian-testing and Debian Testing always has a new
 	  up to date image release, that is, its a rolling distribution release.
 
 	  This doesn't work yet.. it gets stuck on the grub prompt.
@@ -132,7 +132,7 @@ config GUESTFS_DEBIAN_BUSTER
 	bool "Debian 12 - Buster"
 	output yaml
 	help
-	  Select this for debian buster, debian 12.
+	  Select this for Debian Buster, Debian 12.
 
 endchoice
 
@@ -204,16 +204,16 @@ config GUESTFS_DEBIAN_COPY_HOST_SOURCES
 	default DISTRO_DEBIAN_HAS_HOP1_SOURCES
 	select GUESTFS_COPY_SOURCES_FROM_HOST_TO_GUEST
 	help
-	  We have detected that you are running debian on the host, this option
+	  We have detected that you are running Debian on the host, this option
 	  will be enabled by default if we detect that your /etc/apt/sources.list
 	  is using a source we determine has only one hop via traceroute to it,
 	  for details of that heuristic see the script:
 
 	    ./scripts/get-distro-has-hop-count-sources.sh
 
-	  If your hop distance to your mirror is just 1, you are using debian on
-	  the host, want to use debian guests, both host and guest match the
-	  target release, then its a good assumtion you'd likely want to take
+	  If your hop distance to your mirror is just 1, you are using Debian on
+	  the host, want to use Debian guests, both host and guest match the
+	  target release, then its a good assumption you'd likely want to take
 	  advantage of that same mirror for your guests. So disable this if you
 	  really don't want to take advantage of your sources.list.
 

-- 
2.51.0

[PATCH v2 05/15] base_image: set selinux to permissive for fedora on debian hosts

[Daniel Gomez]

From: Daniel Gomez <da.gomez@samsung.com>

When building Fedora guest images on Debian hosts, SELinux contexts
cannot be properly set because Debian lacks SELinux kernel support.
Libguestfs cannot persist security.selinux extended attributes to
filesystems when mounting from non-SELinux hosts, causing all files to
have unlabeled_t context.

This creates a boot failure where SELinux blocks all binary execution
(195 AVC denials, 211 exit 127 errors), including the autorelabel
service itself.

Configure Fedora images to use SELinux permissive mode instead of
enforcing when built on Debian/Ubuntu hosts. This allows guests to boot
successfully while still loading SELinux policy for development and
testing.

Add --no-selinux-relabel to virt-sysprep to prevent it from creating
.autorelabel files that would trigger failed relabeling attempts on
first boot.

Generated-by: Claude AI
Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 playbooks/roles/base_image/tasks/base-image.yml | 34 +++++++++++++++++++++++++
 playbooks/roles/guestfs/tasks/bringup/main.yml  |  4 +++
 2 files changed, 38 insertions(+)

diff --git a/playbooks/roles/base_image/tasks/base-image.yml b/playbooks/roles/base_image/tasks/base-image.yml
index fc022649..a7f2da2d 100644
--- a/playbooks/roles/base_image/tasks/base-image.yml
+++ b/playbooks/roles/base_image/tasks/base-image.yml
@@ -52,6 +52,7 @@
     creates: "{{ base_image_pathname }}"
   when:
     - libvirt_uri_system|bool
+  register: virt_builder_result_system
 
 - name: Generate a new base image for {{ base_image_os_version }}
   ansible.builtin.command:
@@ -71,6 +72,39 @@
     creates: "{{ base_image_pathname }}"
   when:
     - not libvirt_uri_system|bool
+  register: virt_builder_result_user
+
+- name: Set SELinux to permissive mode for Fedora images on non-SELinux hosts (system libvirt)
+  become: true
+  become_method: ansible.builtin.sudo
+  ansible.builtin.command:
+    argv:
+      - "virt-customize"
+      - "-a"
+      - "{{ base_image_pathname }}"
+      - "--run-command"
+      - "sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config"
+  when:
+    - libvirt_uri_system|bool
+    - guestfs_fedora is defined
+    - guestfs_fedora|bool
+    - ansible_distribution|lower in ['debian', 'ubuntu']
+    - virt_builder_result_system is changed
+
+- name: Set SELinux to permissive mode for Fedora images on non-SELinux hosts (user libvirt)
+  ansible.builtin.command:
+    argv:
+      - "virt-customize"
+      - "-a"
+      - "{{ base_image_pathname }}"
+      - "--run-command"
+      - "sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config"
+  when:
+    - not libvirt_uri_system|bool
+    - guestfs_fedora is defined
+    - guestfs_fedora|bool
+    - ansible_distribution|lower in ['debian', 'ubuntu']
+    - virt_builder_result_user is changed
 
 - name: Set proper ownership on base image for rcloud access (system libvirt)
   become: true
diff --git a/playbooks/roles/guestfs/tasks/bringup/main.yml b/playbooks/roles/guestfs/tasks/bringup/main.yml
index 510e1a7d..f3645b90 100644
--- a/playbooks/roles/guestfs/tasks/bringup/main.yml
+++ b/playbooks/roles/guestfs/tasks/bringup/main.yml
@@ -91,6 +91,10 @@
                 "--firstboot-command", "if command -v ufw >/dev/null 2>&1 && systemctl is-active ufw >/dev/null 2>&1; then ufw allow " + (ansible_cfg_ssh_port | string) + "/tcp; fi"
               ]
               if ansible_cfg_ssh_port | int != 22 else []
+            ) + (
+              ["--no-selinux-relabel"]
+              if (guestfs_fedora is defined and guestfs_fedora|bool and ansible_distribution|lower in ['debian', 'ubuntu'])
+              else []
             )
           }}
 

-- 
2.51.0

[PATCH v2 06/15] ansible_provisioning: fix help text indentation style

[Daniel Gomez]

From: Daniel Gomez <da.gomez@samsung.com>

Fix Kconfig help text indentation to consistently use tabs. Several help
entries were using spaces instead of tabs for indentation, and one had
incorrect placement of the "help" keyword.

Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 kconfigs/Kconfig.ansible_provisioning | 56 +++++++++++++++++------------------
 1 file changed, 28 insertions(+), 28 deletions(-)

diff --git a/kconfigs/Kconfig.ansible_provisioning b/kconfigs/Kconfig.ansible_provisioning
index 52b64854..590a1148 100644
--- a/kconfigs/Kconfig.ansible_provisioning
+++ b/kconfigs/Kconfig.ansible_provisioning
@@ -37,7 +37,7 @@ config KDEVOPS_DEVCONFIG_ENABLE_CONSOLE
 	depends on KDEVOPS_DEVCONFIG_ENABLE
 	help
 	  Enable this so that we configure and enable console serial settings
-          for you on /etc/default/grub.
+	  for you on /etc/default/grub.
 
 if KDEVOPS_DEVCONFIG_ENABLE_CONSOLE
 
@@ -45,26 +45,26 @@ config KDEVOPS_DEVCONFIG_KERNEL_CONSOLE_SETTINGS
 	string "Kernel command line console kernel parameters to use"
 	default "console=tty0 console=tty1 console=ttyS0,115200n8"
 	help
-          Linux kernel console kernel parameters to use. This will be appended
+	  Linux kernel console kernel parameters to use. This will be appended
 	  to the GRUB configuration file /etc/default/grub on the variable
-          GRUB_CMDLINE_LINUX_DEFAULT, if and only if you did not have any
-          console settings already set.
+	  GRUB_CMDLINE_LINUX_DEFAULT, if and only if you did not have any
+	  console settings already set.
 
 config KDEVOPS_DEVCONFIG_GRUB_SERIAL_COMMAND
 	string "GRUB specific serial settings"
 	default "serial --speed=115200 --unit=0 --parity=no --stop=1"
 	help
-          GRUB console settings to use. This will be appended to the GRUB
-          configuration file /etc/default/grub on the variable
-          GRUB_SERIAL_COMMAND, if and only if we did change the your console
-          settings as per the above configured kernel parameters passed.
+	  GRUB console settings to use. This will be appended to the GRUB
+	  configuration file /etc/default/grub on the variable
+	  GRUB_SERIAL_COMMAND, if and only if we did change the your console
+	  settings as per the above configured kernel parameters passed.
 
 config KDEVOPS_GRUB_TIMEOUT
 	int "GRUB timeout"
 	default 2
 	help
-          GRUB timeout to wait for user interaction to let you pick another
-          kernel or boot options.
+	  GRUB timeout to wait for user interaction to let you pick another
+	  kernel or boot options.
 
 endif # KDEVOPS_DEVCONFIG_ENABLE_CONSOLE
 
@@ -72,7 +72,7 @@ config KDEVOPS_DEVCONFIG_ENABLE_SYSTEMD_WATCHDOG
 	bool "Enable systemd watchdog setup"
 	default y
 	depends on KDEVOPS_DEVCONFIG_ENABLE
-	  help
+	help
 	  Enable this to allow you to configure your systemd watchdog configuration.
 	  For details refer to: https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html
 
@@ -81,20 +81,20 @@ if KDEVOPS_DEVCONFIG_ENABLE_SYSTEMD_WATCHDOG
 config KDEVOPS_DEVCONFIG_SYSTEMD_WATCHDOG_TIMEOUT_RUNTIME
 	string "Configures the RuntimeWatchdogSec settting"
 	default "5min"
-	  help
-          Configures the systemd watchdog RuntimeWatchdogSec setting.
+	help
+	  Configures the systemd watchdog RuntimeWatchdogSec setting.
 
 config KDEVOPS_DEVCONFIG_SYSTEMD_WATCHDOG_TIMEOUT_REBOOT
 	string "Configures the RebootWatchdogSec settting"
 	default "10min"
-	  help
-          Configures the systemd watchdog RebootWatchdogSec setting.
+	help
+	  Configures the systemd watchdog RebootWatchdogSec setting.
 
 config KDEVOPS_DEVCONFIG_SYSTEMD_WATCHDOG_TIMEOUT_KEXEC
 	string "Configures the KexecWatchdogSec settting"
 	default "5min"
-	  help
-          Configures the systemd watchdog KexecWatchdogSec setting.
+	help
+	  Configures the systemd watchdog KexecWatchdogSec setting.
 
 endif # KDEVOPS_DEVCONFIG_ENABLE_SYSTEMD_WATCHDOG
 
@@ -131,8 +131,8 @@ config DEVCONFIG_ENABLE_SYSTEMD_JOURNAL_REMOTE
 	select DEVCONFIG_ENABLE_SYSTEMD_TIMESYNCD
 	select DEVCONFIG_ENABLE_SYSTEMD_TIMESYNCD_NTP
 	help
-          It is a pain to have to ssh to target nodes one is testing to check
-          for kernel logs. Enable this to allow us to set up the host with
+	  It is a pain to have to ssh to target nodes one is testing to check
+	  for kernel logs. Enable this to allow us to set up the host with
 	  systemd-journal-remote.service on then we will also congigure all
 	  test nodes with systemd-journal-upload.service so to upload their
 	  systemd journal to the host. By default we rely on insecure http
@@ -168,8 +168,8 @@ config DEVCONFIG_SYSTEMD_JOURNAL_USE_HTTP
 	bool "Use simple insecure http"
 	default y
 	help
-          For a simple setup you don't want to set up SSL cert files.
-          If you disable this you are on your own for now on setting up the
+	  For a simple setup you don't want to set up SSL cert files.
+	  If you disable this you are on your own for now on setting up the
 	  SSL cert files. For cloud environments you may want to have a
 	  command and control server within the network on the nodes, and assign
 	  that node as the systemd service.
@@ -178,8 +178,8 @@ config DEVCONFIG_SYSTEMD_JOURNAL_REMOTE_URL
 	string "systemd-remote URL"
 	default $(shell, scripts/append-makefile-vars.sh http:// $(KDEVOPS_DEFAULT_BRIDGE_IP_GUESTFS)) if GUESTFS
 	help
-          This is used for the client /etc/systemd/journal-upload.conf URL line.
-          By default we won't use SSL for now. If you should make sure the
+	  This is used for the client /etc/systemd/journal-upload.conf URL line.
+	  By default we won't use SSL for now. If you should make sure the
 	  IP address used here matches what the node should use. If using
 	  libvirt then ensure it is the same for your virtualization setup.
 	  If you are using libvirt on debian on the host it would seem the
@@ -191,7 +191,7 @@ config DEVCONFIG_ENABLE_SYSTEMD_TIMESYNCD
 	bool "Set up systemd-timesyncd"
 	default n
 	help
-          It if often useful to have the host and target nodes on the same
+	  It if often useful to have the host and target nodes on the same
 	  time. This is usefult to optimize watchdogs so that we can use on
 	  local time instead of remote time for a sense of how much time has
 	  lapsed. Enable this if you want to benefit from this.
@@ -202,7 +202,7 @@ config DEVCONFIG_ENABLE_SYSTEMD_TIMESYNCD_NTP
 	bool "Enable systemd-timesyncd NTP"
 	default y
 	help
-          Enable NTP service using systemd-timesyncd.
+	  Enable NTP service using systemd-timesyncd.
 
 if DEVCONFIG_ENABLE_SYSTEMD_TIMESYNCD_NTP
 
@@ -238,9 +238,9 @@ config KDEVOPS_DEVCONFIG_ENABLE_CUSTOM_REPOS
 	bool "Allow user to add custom repositories and install packages from them"
 	default n
 	help
-          Enable Kconfig options to allow user to add custom package
-          repositories and to also specify packages to be installed
-          from them.
+	  Enable Kconfig options to allow user to add custom package
+	  repositories and to also specify packages to be installed
+	  from them.
 
 config KDEVOPS_DEVCONFIG_CUSTOM_REPOS
 	string "Comma separated list of custom repositories to be enabled"

-- 
2.51.0

[PATCH v2 07/15] devconfig: fix undefined custom repos/packages variables

[Daniel Gomez]

From: Daniel Gomez <da.gomez@samsung.com>

Ansible fails with "'kdevops_devconfig_custom_repos' is undefined" when
KDEVOPS_DEVCONFIG_ENABLE_CUSTOM_REPOS is disabled (the default).

Kconfig has a limitation where "output yaml" will not export variables that
have unmet "depends on" conditions, leaving them completely undefined in
extra_vars.yaml. This causes Ansible to fail when checking these variables
even though they have default values in Kconfig.

The fix migrates both variables to proper output yaml in Kconfig while removing
the redundant legacy Makefile ANSIBLE_EXTRA_ARGS exports. To ensure the
variables always exist regardless of kconfig conditions, the devconfig role's
defaults/main.yml now provides empty string fallbacks. This follows standard
Ansible patterns and makes the playbook portable for standalone use outside
kdevops.

Generated-by: Claude AI
Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 Makefile                                    | 7 -------
 kconfigs/Kconfig.ansible_provisioning       | 2 ++
 playbooks/roles/devconfig/defaults/main.yml | 4 ++++
 3 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/Makefile b/Makefile
index bf72eee9..f8d36572 100644
--- a/Makefile
+++ b/Makefile
@@ -213,13 +213,6 @@ endif
 KDEVOPS_ANSIBLE_PROVISION_PLAYBOOK:=$(subst ",,$(CONFIG_KDEVOPS_ANSIBLE_PROVISION_PLAYBOOK))
 ifeq (y,$(CONFIG_KDEVOPS_ANSIBLE_PROVISION_ENABLE))
 ANSIBLE_EXTRA_ARGS += kdevops_ansible_provision_playbook='$(KDEVOPS_ANSIBLE_PROVISION_PLAYBOOK)'
-
-KDEVOPS_DEVCONFIG_CUSTOM_REPOS:=$(subst ",,$(CONFIG_KDEVOPS_DEVCONFIG_CUSTOM_REPOS))
-ANSIBLE_EXTRA_ARGS += kdevops_devconfig_custom_repos='$(KDEVOPS_DEVCONFIG_CUSTOM_REPOS)'
-
-KDEVOPS_DEVCONFIG_CUSTOM_PACKAGES:=$(subst ",,$(CONFIG_KDEVOPS_DEVCONFIG_CUSTOM_PACKAGES))
-ANSIBLE_EXTRA_ARGS += kdevops_devconfig_custom_packages='$(KDEVOPS_DEVCONFIG_CUSTOM_PACKAGES)'
-
 endif
 
 include scripts/gen-hosts.Makefile
diff --git a/kconfigs/Kconfig.ansible_provisioning b/kconfigs/Kconfig.ansible_provisioning
index 590a1148..93cc395f 100644
--- a/kconfigs/Kconfig.ansible_provisioning
+++ b/kconfigs/Kconfig.ansible_provisioning
@@ -245,6 +245,7 @@ config KDEVOPS_DEVCONFIG_ENABLE_CUSTOM_REPOS
 config KDEVOPS_DEVCONFIG_CUSTOM_REPOS
 	string "Comma separated list of custom repositories to be enabled"
 	default ""
+	output yaml
 	depends on KDEVOPS_DEVCONFIG_ENABLE_CUSTOM_REPOS=y
 	help
 	  Comma separated list of custom repositories to be enabled
@@ -252,6 +253,7 @@ config KDEVOPS_DEVCONFIG_CUSTOM_REPOS
 config KDEVOPS_DEVCONFIG_CUSTOM_PACKAGES
 	string "Comma separated list of custom packages to be installed"
 	default ""
+	output yaml
 	depends on KDEVOPS_DEVCONFIG_ENABLE_CUSTOM_REPOS=y
 	help
 	  Comma separated list of custom packages to be installed
diff --git a/playbooks/roles/devconfig/defaults/main.yml b/playbooks/roles/devconfig/defaults/main.yml
index b5d4724d..122cb898 100644
--- a/playbooks/roles/devconfig/defaults/main.yml
+++ b/playbooks/roles/devconfig/defaults/main.yml
@@ -60,3 +60,7 @@ unattended_upgrades_installed: false
 workflow_infer_user_and_group: false
 kdevops_use_declared_hosts: false
 kdevops_enable_terraform: false
+
+# Custom repository and package installation defaults
+kdevops_devconfig_custom_repos: ""
+kdevops_devconfig_custom_packages: ""

-- 
2.51.0

[PATCH v2 08/15] devconfig: fix Ansible boolean conditional for custom repos

[Daniel Gomez]

From: Daniel Gomez <da.gomez@samsung.com>

Newer Ansible versions reject string variables in conditionals without
explicit boolean expressions, producing "Conditional result was derived
from type 'str'" errors.

Remove the redundant string variable check. The length test already
evaluates to boolean (length > 1), properly handling empty strings by
skipping the task.

Generated-by: Claude AI
Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 .../devconfig/tasks/config-custom-repos-and-packages/redhat/main.yml    | 2 --
 1 file changed, 2 deletions(-)

diff --git a/playbooks/roles/devconfig/tasks/config-custom-repos-and-packages/redhat/main.yml b/playbooks/roles/devconfig/tasks/config-custom-repos-and-packages/redhat/main.yml
index 0a772dd7..76d1ce3c 100644
--- a/playbooks/roles/devconfig/tasks/config-custom-repos-and-packages/redhat/main.yml
+++ b/playbooks/roles/devconfig/tasks/config-custom-repos-and-packages/redhat/main.yml
@@ -10,7 +10,6 @@
     mode: "0644"
   with_items: "{{ kdevops_devconfig_custom_repos | trim | split(',') }}"
   when:
-    - kdevops_devconfig_custom_repos
     - kdevops_devconfig_custom_repos | trim | length > 1
 
 - name: Install custom packages
@@ -24,5 +23,4 @@
   until: result.rc == 0
   with_items: "{{ kdevops_devconfig_custom_packages | trim | split(',') }}"
   when:
-    - kdevops_devconfig_custom_packages
     - kdevops_devconfig_custom_packages | trim | length > 1

-- 
2.51.0

[PATCH v2 09/15] bootlinux: fix os detection for 9p build dependency installation

[Daniel Gomez]

From: Daniel Gomez <da.gomez@samsung.com>

Dependency installation for 9P builds was checking ansible_os_family,
which references the target guest's OS instead of the control host where
packages are actually installed. This caused incorrect packages to be
installed when building Fedora guests on Debian hosts.

Replace ansible_os_family checks with Kconfig distro variables
(distro_debian_based, distro_fedora, etc.) which correctly detect
the control host's distribution. Add fallback defaults to ensure the
variables are always defined for standalone role usage.

Generated-by: Claude AI
Suggested-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 playbooks/roles/bootlinux/defaults/main.yml                  | 6 ++++++
 playbooks/roles/bootlinux/tasks/build/9p.yml                 | 2 +-
 playbooks/roles/bootlinux/tasks/install-deps/main.yml        | 6 +++---
 playbooks/roles/bootlinux/tasks/install-deps/redhat/main.yml | 4 ++--
 4 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/playbooks/roles/bootlinux/defaults/main.yml b/playbooks/roles/bootlinux/defaults/main.yml
index 1ae70b2c..78e4e28f 100644
--- a/playbooks/roles/bootlinux/defaults/main.yml
+++ b/playbooks/roles/bootlinux/defaults/main.yml
@@ -141,3 +141,9 @@ bootlinux_fragment_x86: false
 bootlinux_fragment_xarray: false
 bootlinux_fragment_xarray_no_multi: false
 
+
+# Distro controls
+distro_debian_based: false
+distro_fedora: false
+distro_redhat_based: false
+distro_suse_based: false
diff --git a/playbooks/roles/bootlinux/tasks/build/9p.yml b/playbooks/roles/bootlinux/tasks/build/9p.yml
index f390f028..809d342a 100644
--- a/playbooks/roles/bootlinux/tasks/build/9p.yml
+++ b/playbooks/roles/bootlinux/tasks/build/9p.yml
@@ -14,7 +14,7 @@
   when:
     - target_linux_install_b4 is defined
     - target_linux_install_b4
-    - ansible_facts['os_family']|lower != 'debian'
+    - not distro_debian_based|bool
   run_once: true
   delegate_to: localhost
 
diff --git a/playbooks/roles/bootlinux/tasks/install-deps/main.yml b/playbooks/roles/bootlinux/tasks/install-deps/main.yml
index 51a20741..058f3926 100644
--- a/playbooks/roles/bootlinux/tasks/install-deps/main.yml
+++ b/playbooks/roles/bootlinux/tasks/install-deps/main.yml
@@ -2,14 +2,14 @@
 - name: Debian-specific setup
   ansible.builtin.import_tasks: debian/main.yml
   when:
-    - ansible_os_family == "Debian"
+    - distro_debian_based|bool
 
 - name: SuSE-specific setup
   ansible.builtin.import_tasks: suse/main.yml
   when:
-    - ansible_os_family == "Suse"
+    - distro_suse_based|bool
 
 - name: Red Hat-specific setup
   ansible.builtin.import_tasks: redhat/main.yml
   when:
-    - ansible_os_family == "RedHat"
+    - distro_redhat_based|bool
diff --git a/playbooks/roles/bootlinux/tasks/install-deps/redhat/main.yml b/playbooks/roles/bootlinux/tasks/install-deps/redhat/main.yml
index 7f1955bf..e9a0c6e2 100644
--- a/playbooks/roles/bootlinux/tasks/install-deps/redhat/main.yml
+++ b/playbooks/roles/bootlinux/tasks/install-deps/redhat/main.yml
@@ -3,7 +3,7 @@
   ansible.builtin.include_role:
     name: epel-release
   when:
-    - ansible_distribution != "Fedora"
+    - not distro_fedora|bool
 
 - name: Install packages we care about
   become: true
@@ -67,7 +67,7 @@
   vars:
     packages:
       - btrfs-progs
-  when: ansible_distribution == 'Fedora'
+  when: distro_fedora|bool
 
 - name: Install clang
   become: true

-- 
2.51.0

[PATCH v2 10/15] selftests: fix os detection for 9p build dependency installation

[Daniel Gomez]

From: Daniel Gomez <da.gomez@samsung.com>

The selftests role calls install-deps twice: once on the target guest and
once on localhost for 9P builds. When delegated to localhost, ansible_facts
still references the target guest's OS rather than the control host's OS,
causing the wrong package manager to be invoked (e.g., dnf on Debian hosts
when building Fedora guests).

Split install-deps into two separate files: main.yml uses ansible_facts
for detecting the guest OS in normal execution, while main-localhost.yml
uses Kconfig distro variables for detecting the control host OS when
delegated to localhost.

Add distro variable fallbacks to defaults/main.yml to ensure the Kconfig
variables are always defined when the role runs.

This prevents "Could not detect which major revision of dnf is in use"
errors when building Fedora guests on Debian control hosts with 9P.

Generated-by: Claude AI
Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 playbooks/roles/selftests/defaults/main.yml                    |  6 ++++++
 .../roles/selftests/tasks/install-deps/main-localhost.yml      | 10 ++++++++++
 playbooks/roles/selftests/tasks/main.yml                       |  2 +-
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/playbooks/roles/selftests/defaults/main.yml b/playbooks/roles/selftests/defaults/main.yml
index 45cb5022..21623690 100644
--- a/playbooks/roles/selftests/defaults/main.yml
+++ b/playbooks/roles/selftests/defaults/main.yml
@@ -37,3 +37,9 @@ selftest_kernelspace: false
 selftest_xarray: false
 selftest_maple: false
 selftest_vma: false
+
+# Distro controls
+distro_debian_based: false
+distro_fedora: false
+distro_redhat_based: false
+distro_suse_based: false
diff --git a/playbooks/roles/selftests/tasks/install-deps/main-localhost.yml b/playbooks/roles/selftests/tasks/install-deps/main-localhost.yml
new file mode 100644
index 00000000..4817f530
--- /dev/null
+++ b/playbooks/roles/selftests/tasks/install-deps/main-localhost.yml
@@ -0,0 +1,10 @@
+---
+# tasks to install dependencies for selftests on localhost (for 9P builds)
+# Uses Kconfig distro variables instead of ansible_facts to detect control host OS
+- name: Debian-specific setup for localhost
+  ansible.builtin.import_tasks: tasks/install-deps/debian/main.yml
+  when: distro_debian_based|bool
+- ansible.builtin.import_tasks: tasks/install-deps/suse/main.yml
+  when: distro_suse_based|bool
+- ansible.builtin.import_tasks: tasks/install-deps/redhat/main.yml
+  when: distro_redhat_based|bool
diff --git a/playbooks/roles/selftests/tasks/main.yml b/playbooks/roles/selftests/tasks/main.yml
index f8af3080..3f5e0319 100644
--- a/playbooks/roles/selftests/tasks/main.yml
+++ b/playbooks/roles/selftests/tasks/main.yml
@@ -19,7 +19,7 @@
 - name: Install dependencies to build Linux selftests on host
   tags: ["deps"]
   run_once: true
-  ansible.builtin.import_tasks: install-deps/main.yml
+  ansible.builtin.import_tasks: install-deps/main-localhost.yml
   delegate_to: localhost
   when:
     - bootlinux_9p|bool

-- 
2.51.0

[PATCH v2 11/15] guestfs: generate fedora distribution-specific hostname prefixes

[Daniel Gomez]

From: Daniel Gomez <da.gomez@samsung.com>

Add GUESTFS_FEDORA_BOX_SHORT configuration to generate version-specific
short prefixes (fedora41, fedora40, fedora39) for Fedora guests,
matching the existing Debian implementation.

Enable HAVE_CUSTOM_DISTRO_HOST_PREFIX and
HAVE_DISTRO_PREFERS_CUSTOM_HOST_PREFIX for Fedora to allow automatic
hostname prefix generation based on the selected Fedora version,
helping distinguish different distribution releases in multi-VM test
environments.

Generated-by: Claude AI
Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 kconfigs/Kconfig.guestfs | 9 +++++++++
 kconfigs/Kconfig.kdevops | 1 +
 2 files changed, 10 insertions(+)

diff --git a/kconfigs/Kconfig.guestfs b/kconfigs/Kconfig.guestfs
index f7601bc9..3bc4b060 100644
--- a/kconfigs/Kconfig.guestfs
+++ b/kconfigs/Kconfig.guestfs
@@ -78,6 +78,8 @@ choice
 config GUESTFS_FEDORA
 	bool "Fedora (or derived distro)"
 	output yaml
+	select HAVE_CUSTOM_DISTRO_HOST_PREFIX
+	select HAVE_DISTRO_PREFERS_CUSTOM_HOST_PREFIX
 	select HAVE_DISTRO_XFS_PREFERS_MANUAL if FSTESTS_XFS
 	select HAVE_DISTRO_BTRFS_PREFERS_MANUAL if FSTESTS_BTRFS
 	select HAVE_DISTRO_EXT4_PREFERS_MANUAL if FSTESTS_EXT4
@@ -222,6 +224,13 @@ config GUESTFS_DEBIAN_COPY_HOST_SOURCES
 
 endif # GUESTFS_DEBIAN
 
+config GUESTFS_FEDORA_BOX_SHORT
+	string
+	default "fedora41" if VIRT_BUILDER_OS_VERSION = "fedora-41"
+	default "fedora40" if VIRT_BUILDER_OS_VERSION = "fedora-40"
+	default "fedora39" if VIRT_BUILDER_OS_VERSION = "fedora-39"
+	default "fedora"
+
 config VIRT_BUILDER_OS_VERSION
 	string "virt-builder os-version"
 	default "fedora-39" if GUESTFS_FEDORA
diff --git a/kconfigs/Kconfig.kdevops b/kconfigs/Kconfig.kdevops
index 1b40db5b..68e91193 100644
--- a/kconfigs/Kconfig.kdevops
+++ b/kconfigs/Kconfig.kdevops
@@ -25,6 +25,7 @@ config HAVE_DISTRO_REQUIRES_CUSTOM_SSH_KEXALGORITHMS
 config CUSTOM_DISTRO_HOST_PREFIX
 	string
 	depends on HAVE_CUSTOM_DISTRO_HOST_PREFIX
+	default GUESTFS_FEDORA_BOX_SHORT if GUESTFS_FEDORA
 	default GUESTFS_DEBIAN_BOX_SHORT if GUESTFS_DEBIAN
 
 config CUSTOM_SSH_KEXALGORITHMS

-- 
2.51.0

[PATCH v2 12/15] defconfigs: add fedora-41 fragment for guestfs

[Daniel Gomez]

From: Daniel Gomez <da.gomez@samsung.com>

Add configuration fragment for selecting Fedora 41 as the guest OS. This
allows overriding defconfig guest OS choices via merge_config.sh and
enables CI workflows to test Fedora-specific configurations.

Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 defconfigs/configs/guestfs-fedora-41.config | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/defconfigs/configs/guestfs-fedora-41.config b/defconfigs/configs/guestfs-fedora-41.config
new file mode 100644
index 00000000..bfbd4cf8
--- /dev/null
+++ b/defconfigs/configs/guestfs-fedora-41.config
@@ -0,0 +1,2 @@
+CONFIG_GUESTFS_FEDORA=y
+CONFIG_VIRT_BUILDER_OS_VERSION="fedora-41"

-- 
2.51.0

[PATCH v2 13/15] defconfigs: add debian-13 fragment for guestfs

[Daniel Gomez]

From: Daniel Gomez <da.gomez@samsung.com>

Add configuration fragment for selecting Debian 13 (Trixie) as the
guest OS. This allows overriding defconfig guest OS choices via
merge_config.sh and enables CI workflows to test Debian-specific
configurations.

Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 defconfigs/configs/guestfs-debian-13.config | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/defconfigs/configs/guestfs-debian-13.config b/defconfigs/configs/guestfs-debian-13.config
new file mode 100644
index 00000000..b638304a
--- /dev/null
+++ b/defconfigs/configs/guestfs-debian-13.config
@@ -0,0 +1,2 @@
+CONFIG_GUESTFS_DEBIAN=y
+CONFIG_GUESTFS_DEBIAN_TRIXIE=y

-- 
2.51.0

[PATCH v2 14/15] github: add guest OS selection for CI testing

[Daniel Gomez]

From: Daniel Gomez <da.gomez@samsung.com>

Add manual guest OS selection to GitHub Actions workflows, allowing
testing of distribution-specific fixes across Debian and Fedora
guests. The workflow_dispatch trigger accepts 'default', 'debian-13',
or 'fedora-41', merging the corresponding guestfs config fragment to
override the defconfig's guest OS choice.

This enables validation of cross-distribution compatibility for fixes
like the locale and SELinux changes in this series.

Link: https://lore.kernel.org/kdevops/7e469eeb-1c96-47e2-8a7a-ccf1aa1245fa@kernel.org/
Generated-by: Claude AI
Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 .github/actions/configure/action.yml | 22 +++++++++++++++++++++-
 .github/workflows/kdevops.yml        | 10 ++++++++++
 2 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/.github/actions/configure/action.yml b/.github/actions/configure/action.yml
index 68c4e743..9c35b4a6 100644
--- a/.github/actions/configure/action.yml
+++ b/.github/actions/configure/action.yml
@@ -20,6 +20,10 @@ inputs:
     required: false
     type: string
     default: 'kdevops-ci'
+  guest_os:
+    required: false
+    type: string
+    default: 'default'
 
 runs:
   using: "composite"
@@ -112,11 +116,27 @@ runs:
           echo "Using Linux CI configuration (4GB/8core VMs)"
         fi
 
+        # Configure guest OS if specified
+        GUEST_OS_CONFIG=
+        if [[ "${{ inputs.guest_os }}" != "default" ]]; then
+          GUEST_OS_CONFIG="defconfigs/configs/guestfs-${{ inputs.guest_os }}.config"
+
+          if [[ ! -f "$GUEST_OS_CONFIG" ]]; then
+            echo "Error: Guest OS config not found: $GUEST_OS_CONFIG"
+            exit 1
+          fi
+
+          echo "Using guest OS configuration: $GUEST_OS_CONFIG"
+        else
+          echo "Using default guest OS from defconfig"
+        fi
+
         ./scripts/kconfig/merge_config.sh \
         -n .config \
         defconfigs/configs/diy.config \
         defconfigs/configs/ci.config \
-        ${VM_CONFIG_ARG}
+        ${VM_CONFIG_ARG} \
+        ${GUEST_OS_CONFIG}
 
     - name: Run kdevops make
       shell: bash
diff --git a/.github/workflows/kdevops.yml b/.github/workflows/kdevops.yml
index 6fc583c6..d94a7e7f 100644
--- a/.github/workflows/kdevops.yml
+++ b/.github/workflows/kdevops.yml
@@ -88,6 +88,15 @@ on:
         options:
           - 'kdevops-ci'
           - 'linux-ci'
+      guest_os:
+        description: 'Guest OS for testing'
+        required: false
+        default: 'default'
+        type: choice
+        options:
+          - default      # Use defconfig's default (typically Debian 13 on debian hosts)
+          - debian-13    # Force Debian 13 Trixie
+          - fedora-41    # Force Fedora 41
       tests:
         description: 'Custom test to run (for kdevops-ci mode only)'
         required: false
@@ -231,6 +240,7 @@ jobs:
         uses: ./.github/actions/configure
         with:
           ci_workflow: ${{ matrix.ci_workflow }}
+          guest_os: ${{ github.event.inputs.guest_os || 'default' }}
           kernel_ref: >-
             ${{
               github.event_name == 'schedule' && needs.generate_kernel_ref.outputs.kernel_ref

-- 
2.51.0

[PATCH v2 15/15] guestfs: increase SSH config timeout for Fedora on Debian hosts

[Daniel Gomez]

From: Daniel Gomez <da.gomez@samsung.com>

Fedora guests running on Debian hosts timeout after 60 seconds while
waiting for network configuration during first boot. The 60-second
timeout is insufficient due to slower boot times caused by SELinux
permissive mode initialization on non-SELinux hosts.

Increase the default timeout from 60 to 180 seconds to
accommodate Fedora boot times. Make the timeout configurable via
KDEVOPS_SSH_CONFIG_TIMEOUT environment variable for flexibility in
different environments.

Improve the error message to include the configured timeout value and
suggest using 'virsh console' for boot diagnostics.

Generated-by: Claude AI
Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
---
 scripts/update_ssh_config_guestfs.py | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/scripts/update_ssh_config_guestfs.py b/scripts/update_ssh_config_guestfs.py
index 40f1ccad..0ec32959 100755
--- a/scripts/update_ssh_config_guestfs.py
+++ b/scripts/update_ssh_config_guestfs.py
@@ -33,11 +33,15 @@ ssh_template = """Host {name} {addr}
 
 # We take the first IPv4 address on the first non-loopback interface.
 def get_addr(name):
+    # Timeout increased to 180s to account for slower boot times with Fedora guests
+    # on Debian hosts (SELinux permissive mode initialization takes longer).
+    timeout_seconds = int(os.environ.get("KDEVOPS_SSH_CONFIG_TIMEOUT", "180"))
     attempt = 0
     while True:
         attempt += 1
-        if attempt > 60:
-            raise Exception(f"Unable to get an address for {name} after 60s")
+        if attempt > timeout_seconds:
+            raise Exception(f"Unable to get an address for {name} after {timeout_seconds}s. "
+                          f"VM may be taking longer to boot. Check 'virsh console {name}' for boot status.")
 
         result = subprocess.run(
             [

-- 
2.51.0

Re: [PATCH v2 00/15] Fedora on Debian

[Chuck Lever]

On 10/29/25 8:40 AM, Daniel Gomez wrote:
> This series enables testing Fedora guest VMs on Debian host systems,
> addressing cross-distribution compatibility issues in guestfs workflow
> and adding manual CI workflow support for multi-distro testing.
> 
> The key technical challenge solved is SELinux context handling
> when building Fedora images on non-SELinux hosts like Debian, where
> libguestfs cannot persist security.selinux extended attributes. The
> series also fixes Ansible variable scope issues in 9P builds and adds
> configuration infrastructure to support distribution-specific guest
> selection.
> 
> The GitHub Actions workflow gains manual guest OS selection to validate
> distro-specific fixes across both Debian and Fedora environments.
> 
> kdevops-ci blktests_nvme validation test using Fedora on Debian:
> https://github.com/linux-kdevops/kdevops/actions/runs/18883031353
> 
> Signed-off-by: Daniel Gomez <da.gomez@samsung.com>

Reviewed-by: Chuck Lever <chuck.lever@oracle.com>

-- 
Chuck Lever

Re: [PATCH v2 00/15] Fedora on Debian

[Daniel Gomez]

From: Daniel Gomez <da.gomez@samsung.com>


On Wed, 29 Oct 2025 13:40:42 +0100, Daniel Gomez wrote:
> This series enables testing Fedora guest VMs on Debian host systems,
> addressing cross-distribution compatibility issues in guestfs workflow
> and adding manual CI workflow support for multi-distro testing.
> 
> The key technical challenge solved is SELinux context handling
> when building Fedora images on non-SELinux hosts like Debian, where
> libguestfs cannot persist security.selinux extended attributes. The
> series also fixes Ansible variable scope issues in 9P builds and adds
> configuration infrastructure to support distribution-specific guest
> selection.
> 
> [...]

PR created, thanks!

https://github.com/linux-kdevops/kdevops/pull/53

[01/15] base_image: restore locales-all installation for Debian Trixie
        commit: d1b3cd6d756711f7f2a472b462abe828c38eaacb
[02/15] guestfs: fix Kconfig indentation style
        commit: 046cd0cdb86e065c3fb406bc3cf1f9da93649e95
[03/15] guestfs: remove unused bringup debug Kconfig options
        commit: c91c2ec27f776d7a8d2880d2857b5bf44d8a17e3
[04/15] guestfs: fix spelling errors and Debian capitalization
        commit: 7263e0c52b699f14bc32846f52e8cc13b65c2773
[05/15] base_image: set selinux to permissive for fedora on debian hosts
        commit: 4ecfa2602defbb4b9e1c3d456ccaf478f53d2769
[06/15] ansible_provisioning: fix help text indentation style
        commit: b8e0ee9f48a4b7dde23fec736fa45083f273687b
[07/15] devconfig: fix undefined custom repos/packages variables
        commit: 986e302c02f06b611dee2994db575863e458d393
[08/15] devconfig: fix Ansible boolean conditional for custom repos
        commit: ee5f9c70eee98e72550d284855d97c339953ea0e
[09/15] bootlinux: fix os detection for 9p build dependency installation
        commit: 89e29f6f91381a30932c33ff9117b5838f72fcb2
[10/15] selftests: fix os detection for 9p build dependency installation
        commit: 38fd1912808664ed2298dc0a54c1a1a1fdf91050
[11/15] guestfs: generate fedora distribution-specific hostname prefixes
        commit: b341888d991b7d6238fdcb6ba74f9412c7a1b0c3
[12/15] defconfigs: add fedora-41 fragment for guestfs
        commit: 91dae79963985d1efa41adb89762a20c6c1eef81
[13/15] defconfigs: add debian-13 fragment for guestfs
        commit: 614c1cd6ffe113e4573cecf334c010cf9373073e
[14/15] github: add guest OS selection for CI testing
        commit: f96f43e39c8a21cdcb933f6744823a5323fbcd1d
[15/15] guestfs: increase SSH config timeout for Fedora on Debian hosts
        commit: df8beea887ebb2783cf92d772ed3b046b10e4b08

Best regards,
-- 
Daniel Gomez <da.gomez@samsung.com>

Re: [PATCH v2 09/15] bootlinux: fix os detection for 9p build dependency installation

[Chuck Lever]

On 10/29/25 8:40 AM, Daniel Gomez wrote:
> From: Daniel Gomez <da.gomez@samsung.com>
> 
> Dependency installation for 9P builds was checking ansible_os_family,
> which references the target guest's OS instead of the control host where
> packages are actually installed. This caused incorrect packages to be
> installed when building Fedora guests on Debian hosts.
> 
> Replace ansible_os_family checks with Kconfig distro variables
> (distro_debian_based, distro_fedora, etc.) which correctly detect
> the control host's distribution. Add fallback defaults to ensure the
> variables are always defined for standalone role usage.
> 
> Generated-by: Claude AI
> Suggested-by: Chuck Lever <chuck.lever@oracle.com>

Hrm. I might not have understood the whole picture.

Yes, distro_yada_based does pick the controller's OS version.
But so does ansible_os_family when the task is running on
localhost.

I just hit a problem with the "build linux on a separate
target node" configuration, where the target is running
Debian 11 and the controller is running Fedora 41. The
bootlinux install-deps/main.yml checks were coming to
the wrong conclusion.

So if build.yml was running on the controller, then
ansible_os_family should have been "Debian" for you.
Question is, where was it running? For 9p, I'll bet it
was running on the targets; it might need to run on
both localhost and the targets in this case.


> Signed-off-by: Daniel Gomez <da.gomez@samsung.com>
> ---
>  playbooks/roles/bootlinux/defaults/main.yml                  | 6 ++++++
>  playbooks/roles/bootlinux/tasks/build/9p.yml                 | 2 +-
>  playbooks/roles/bootlinux/tasks/install-deps/main.yml        | 6 +++---
>  playbooks/roles/bootlinux/tasks/install-deps/redhat/main.yml | 4 ++--
>  4 files changed, 12 insertions(+), 6 deletions(-)
> 
> diff --git a/playbooks/roles/bootlinux/defaults/main.yml b/playbooks/roles/bootlinux/defaults/main.yml
> index 1ae70b2c..78e4e28f 100644
> --- a/playbooks/roles/bootlinux/defaults/main.yml
> +++ b/playbooks/roles/bootlinux/defaults/main.yml
> @@ -141,3 +141,9 @@ bootlinux_fragment_x86: false
>  bootlinux_fragment_xarray: false
>  bootlinux_fragment_xarray_no_multi: false
>  
> +
> +# Distro controls
> +distro_debian_based: false
> +distro_fedora: false
> +distro_redhat_based: false
> +distro_suse_based: false
> diff --git a/playbooks/roles/bootlinux/tasks/build/9p.yml b/playbooks/roles/bootlinux/tasks/build/9p.yml
> index f390f028..809d342a 100644
> --- a/playbooks/roles/bootlinux/tasks/build/9p.yml
> +++ b/playbooks/roles/bootlinux/tasks/build/9p.yml
> @@ -14,7 +14,7 @@
>    when:
>      - target_linux_install_b4 is defined
>      - target_linux_install_b4
> -    - ansible_facts['os_family']|lower != 'debian'
> +    - not distro_debian_based|bool
>    run_once: true
>    delegate_to: localhost
>  
> diff --git a/playbooks/roles/bootlinux/tasks/install-deps/main.yml b/playbooks/roles/bootlinux/tasks/install-deps/main.yml
> index 51a20741..058f3926 100644
> --- a/playbooks/roles/bootlinux/tasks/install-deps/main.yml
> +++ b/playbooks/roles/bootlinux/tasks/install-deps/main.yml
> @@ -2,14 +2,14 @@
>  - name: Debian-specific setup
>    ansible.builtin.import_tasks: debian/main.yml
>    when:
> -    - ansible_os_family == "Debian"
> +    - distro_debian_based|bool
>  
>  - name: SuSE-specific setup
>    ansible.builtin.import_tasks: suse/main.yml
>    when:
> -    - ansible_os_family == "Suse"
> +    - distro_suse_based|bool
>  
>  - name: Red Hat-specific setup
>    ansible.builtin.import_tasks: redhat/main.yml
>    when:
> -    - ansible_os_family == "RedHat"
> +    - distro_redhat_based|bool
> diff --git a/playbooks/roles/bootlinux/tasks/install-deps/redhat/main.yml b/playbooks/roles/bootlinux/tasks/install-deps/redhat/main.yml
> index 7f1955bf..e9a0c6e2 100644
> --- a/playbooks/roles/bootlinux/tasks/install-deps/redhat/main.yml
> +++ b/playbooks/roles/bootlinux/tasks/install-deps/redhat/main.yml
> @@ -3,7 +3,7 @@
>    ansible.builtin.include_role:
>      name: epel-release
>    when:
> -    - ansible_distribution != "Fedora"
> +    - not distro_fedora|bool
>  
>  - name: Install packages we care about
>    become: true
> @@ -67,7 +67,7 @@
>    vars:
>      packages:
>        - btrfs-progs
> -  when: ansible_distribution == 'Fedora'
> +  when: distro_fedora|bool
>  
>  - name: Install clang
>    become: true
> 


-- 
Chuck Lever

Re: [PATCH v2 09/15] bootlinux: fix os detection for 9p build dependency installation

[Daniel Gomez]

On 07/11/2025 20.22, Chuck Lever wrote:
> On 10/29/25 8:40 AM, Daniel Gomez wrote:
>> From: Daniel Gomez <da.gomez@samsung.com>
>>
>> Dependency installation for 9P builds was checking ansible_os_family,
>> which references the target guest's OS instead of the control host where
>> packages are actually installed. This caused incorrect packages to be
>> installed when building Fedora guests on Debian hosts.
>>
>> Replace ansible_os_family checks with Kconfig distro variables
>> (distro_debian_based, distro_fedora, etc.) which correctly detect
>> the control host's distribution. Add fallback defaults to ensure the
>> variables are always defined for standalone role usage.
>>
>> Generated-by: Claude AI
>> Suggested-by: Chuck Lever <chuck.lever@oracle.com>
> 
> Hrm. I might not have understood the whole picture.
> 
> Yes, distro_yada_based does pick the controller's OS version.
> But so does ansible_os_family when the task is running on
> localhost.

Just a reminder that we control where tasks are deployed with --limit and/or
hosts: field in bootlinux.yml. For this case, IIRC, the playbook was run for
baseline:dev but tasks were "delegated_to" localhost.

> 
> I just hit a problem with the "build linux on a separate
> target node" configuration, where the target is running
> Debian 11 and the controller is running Fedora 41. The
> bootlinux install-deps/main.yml checks were coming to
> the wrong conclusion.

Can you share the output? And the --limit argument used in this case?
FYI, I normally enable CONFIG_KDEVOPS_MAKE_VERBOSE=y) which prints:

make bringup
+ make linux-clone
==> [guestfs/kdevops_nodes.yaml]
+ ansible-playbook playbooks/gen_nodes.yml --extra-vars=@./extra_vars.yaml
...
==> [linux-clone-9p]
+ ansible-playbook --limit localhost playbooks/bootlinux.yml
'--extra-vars=target_linux_git=/mirror/linux.git ...
...

> 
> So if build.yml was running on the controller, then
> ansible_os_family should have been "Debian" for you.
> Question is, where was it running? For 9p, I'll bet it
> was running on the targets; it might need to run on

I think that is correct. It gets a bit more tricky when we have baseline:dev but
we also use during the role execution the "delegate_to" localhost.

> both localhost and the targets in this case.

I thought about that option too but then, some/most of the tasks should be
executed on the guests. That path will require to exclude the controller node
from them.

Re: [PATCH v2 09/15] bootlinux: fix os detection for 9p build dependency installation

[Chuck Lever]

On 11/7/25 3:00 PM, Daniel Gomez wrote:
> On 07/11/2025 20.22, Chuck Lever wrote:
>> On 10/29/25 8:40 AM, Daniel Gomez wrote:
>>> From: Daniel Gomez <da.gomez@samsung.com>
>>>
>>> Dependency installation for 9P builds was checking ansible_os_family,
>>> which references the target guest's OS instead of the control host where
>>> packages are actually installed. This caused incorrect packages to be
>>> installed when building Fedora guests on Debian hosts.
>>>
>>> Replace ansible_os_family checks with Kconfig distro variables
>>> (distro_debian_based, distro_fedora, etc.) which correctly detect
>>> the control host's distribution. Add fallback defaults to ensure the
>>> variables are always defined for standalone role usage.
>>>
>>> Generated-by: Claude AI
>>> Suggested-by: Chuck Lever <chuck.lever@oracle.com>
>>
>> Hrm. I might not have understood the whole picture.
>>
>> Yes, distro_yada_based does pick the controller's OS version.
>> But so does ansible_os_family when the task is running on
>> localhost.
> 
> Just a reminder that we control where tasks are deployed with --limit and/or
> hosts: field in bootlinux.yml. For this case, IIRC, the playbook was run for
> baseline:dev but tasks were "delegated_to" localhost.

That's new since I did the "build kernel on a separate target node"
changes and the related clean-ups in the bootlinux playbook. Not a
finger-point, just saying we could have collided somewhere.


>> I just hit a problem with the "build linux on a separate
>> target node" configuration, where the target is running
>> Debian 11 and the controller is running Fedora 41. The
>> bootlinux install-deps/main.yml checks were coming to
>> the wrong conclusion.
> 
> Can you share the output? And the --limit argument used in this case?
> FYI, I normally enable CONFIG_KDEVOPS_MAKE_VERBOSE=y) which prints:
> 
> make bringup
> + make linux-clone
> ==> [guestfs/kdevops_nodes.yaml]
> + ansible-playbook playbooks/gen_nodes.yml --extra-vars=@./extra_vars.yaml
> ...
> ==> [linux-clone-9p]
> + ansible-playbook --limit localhost playbooks/bootlinux.yml
> '--extra-vars=target_linux_git=/mirror/linux.git ...
> ...

Here's from my scroll-back buffer earlier this afternoon:

TASK [install-rust-deps : Install Rust build dependencies]
*************************************************************************************
included:
/home/cel/src/kdevops/buildbot-configs/playbooks/roles/install-rust-deps/tasks/install-deps/main.yml
for kernel-builder

TASK [install-rust-deps : Install Rust build dependencies]
*************************************************************************************
changed: [kernel-builder]
FAILED - RETRYING: [kernel-builder]: Install packages we care about (3
retries left).
FAILED - RETRYING: [kernel-builder]: Install packages we care about (2
retries left).
FAILED - RETRYING: [kernel-builder]: Install packages we care about (1
retries left).

TASK [bootlinux : Install packages we care about]
**********************************************************************************************
task path:
/home/cel/src/kdevops/buildbot-configs/playbooks/roles/bootlinux/tasks/install-deps/redhat/main.yml:8
fatal: [kernel-builder]: FAILED! => {
    "ansible_facts": {
        "pkg_mgr": "apt"
    },
    "attempts": 3,
    "changed": false
}

MSG:

('Could not detect which major revision of dnf is in use, which is
required to determine module backend.', 'You should manually specify
use_backend to tell the module whether to use the dnf4 or dnf5 backend})')


As you can see, bootlinux is trying to install the redhat deps on
the target, but in fact the target is running Debian 11. This is
because the install-deps play is now looking at distro_yada_based
even though it is running on the target.


>> So if build.yml was running on the controller, then
>> ansible_os_family should have been "Debian" for you.
>> Question is, where was it running? For 9p, I'll bet it
>> was running on the targets; it might need to run on
> 
> I think that is correct. It gets a bit more tricky when we have baseline:dev but
> we also use during the role execution the "delegate_to" localhost.
> 
>> both localhost and the targets in this case.
> 
> I thought about that option too but then, some/most of the tasks should be
> executed on the guests. That path will require to exclude the controller node
> from them.

9p is a weird special case for all of this because the kernel is
built on the controller and consumed on the targets. I'll bet
dollars to donuts something is not right with build/9p.yml.


-- 
Chuck Lever

Re: [PATCH v2 09/15] bootlinux: fix os detection for 9p build dependency installation

[Daniel Gomez]

On 07/11/2025 21.17, Chuck Lever wrote:
> On 11/7/25 3:00 PM, Daniel Gomez wrote:
>> On 07/11/2025 20.22, Chuck Lever wrote:
>>> On 10/29/25 8:40 AM, Daniel Gomez wrote:
>>>> From: Daniel Gomez <da.gomez@samsung.com>
>>>>
>>>> Dependency installation for 9P builds was checking ansible_os_family,
>>>> which references the target guest's OS instead of the control host where
>>>> packages are actually installed. This caused incorrect packages to be
>>>> installed when building Fedora guests on Debian hosts.
>>>>
>>>> Replace ansible_os_family checks with Kconfig distro variables
>>>> (distro_debian_based, distro_fedora, etc.) which correctly detect
>>>> the control host's distribution. Add fallback defaults to ensure the
>>>> variables are always defined for standalone role usage.
>>>>
>>>> Generated-by: Claude AI
>>>> Suggested-by: Chuck Lever <chuck.lever@oracle.com>
>>>
>>> Hrm. I might not have understood the whole picture.
>>>
>>> Yes, distro_yada_based does pick the controller's OS version.
>>> But so does ansible_os_family when the task is running on
>>> localhost.
>>
>> Just a reminder that we control where tasks are deployed with --limit and/or
>> hosts: field in bootlinux.yml. For this case, IIRC, the playbook was run for
>> baseline:dev but tasks were "delegated_to" localhost.
> 
> That's new since I did the "build kernel on a separate target node"
> changes and the related clean-ups in the bootlinux playbook. Not a
> finger-point, just saying we could have collided somewhere.
> 
> 
>>> I just hit a problem with the "build linux on a separate
>>> target node" configuration, where the target is running
>>> Debian 11 and the controller is running Fedora 41. The
>>> bootlinux install-deps/main.yml checks were coming to
>>> the wrong conclusion.
>>
>> Can you share the output? And the --limit argument used in this case?
>> FYI, I normally enable CONFIG_KDEVOPS_MAKE_VERBOSE=y) which prints:
>>
>> make bringup
>> + make linux-clone
>> ==> [guestfs/kdevops_nodes.yaml]
>> + ansible-playbook playbooks/gen_nodes.yml --extra-vars=@./extra_vars.yaml
>> ...
>> ==> [linux-clone-9p]
>> + ansible-playbook --limit localhost playbooks/bootlinux.yml
>> '--extra-vars=target_linux_git=/mirror/linux.git ...
>> ...
> 
> Here's from my scroll-back buffer earlier this afternoon:
> 
> TASK [install-rust-deps : Install Rust build dependencies]
> *************************************************************************************
> included:
> /home/cel/src/kdevops/buildbot-configs/playbooks/roles/install-rust-deps/tasks/install-deps/main.yml
> for kernel-builder
> 
> TASK [install-rust-deps : Install Rust build dependencies]
> *************************************************************************************
> changed: [kernel-builder]
> FAILED - RETRYING: [kernel-builder]: Install packages we care about (3
> retries left).
> FAILED - RETRYING: [kernel-builder]: Install packages we care about (2
> retries left).
> FAILED - RETRYING: [kernel-builder]: Install packages we care about (1
> retries left).
> 
> TASK [bootlinux : Install packages we care about]
> **********************************************************************************************
> task path:
> /home/cel/src/kdevops/buildbot-configs/playbooks/roles/bootlinux/tasks/install-deps/redhat/main.yml:8
> fatal: [kernel-builder]: FAILED! => {
>     "ansible_facts": {
>         "pkg_mgr": "apt"
>     },
>     "attempts": 3,
>     "changed": false
> }
> 
> MSG:
> 
> ('Could not detect which major revision of dnf is in use, which is
> required to determine module backend.', 'You should manually specify
> use_backend to tell the module whether to use the dnf4 or dnf5 backend})')
> 
> 
> As you can see, bootlinux is trying to install the redhat deps on
> the target, but in fact the target is running Debian 11. This is
> because the install-deps play is now looking at distro_yada_based
> even though it is running on the target.

I think we need to detect both cases based on the target selection
(BOOTLINUX_TARGETS). Can you give this a try/check/review?

For 9p targets (controller node, ie BOOTLINUX_9P), we keep the
distro_yada_based. For builder targets (BOOTLINUX_BUILDER) we use the
ansible_os_family:

diff --git a/playbooks/roles/bootlinux/tasks/install-deps/main.yml b/playbooks/roles/bootlinux/tasks/install-deps/main.yml
index 058f3926..88d2baad 100644
--- a/playbooks/roles/bootlinux/tasks/install-deps/main.yml
+++ b/playbooks/roles/bootlinux/tasks/install-deps/main.yml
@@ -1,15 +1,36 @@
 ---
-- name: Debian-specific setup
+- name: Debian-specific setup (9p/controller node)
   ansible.builtin.import_tasks: debian/main.yml
   when:
     - distro_debian_based|bool
+    - bootlinux_9p|bool

-- name: SuSE-specific setup
+- name: Debian-specific setup (builder node)
+  ansible.builtin.import_tasks: debian/main.yml
+  when:
+    - bootlinux_builder|bool
+    - ansible_os_family == "Debian"
+
+- name: SuSE-specific setup (9p/controller node)
   ansible.builtin.import_tasks: suse/main.yml
   when:
     - distro_suse_based|bool
+    - bootlinux_9p|bool

-- name: Red Hat-specific setup
+- name: SuSE-specific setup (builder node)
+  ansible.builtin.import_tasks: suse/main.yml
+  when:
+    - bootlinux_builder|bool
+    - ansible_os_family == "Suse"
+
+- name: Red Hat-specific setup (controller node)
   ansible.builtin.import_tasks: redhat/main.yml
   when:
     - distro_redhat_based|bool
+    - bootlinux_9p|bool
+
+- name: Red Hat-specific setup (builder node)
+  ansible.builtin.import_tasks: redhat/main.yml
+  when:
+    - bootlinux_builder|bool
+    - ansible_os_family == "RedHat"

IIUC, this should return the correct ansible_os_family value when builder target
is selected because the task is executed on the guest with --limit baseline:dev.

> 
> 
>>> So if build.yml was running on the controller, then
>>> ansible_os_family should have been "Debian" for you.
>>> Question is, where was it running? For 9p, I'll bet it
>>> was running on the targets; it might need to run on
>>
>> I think that is correct. It gets a bit more tricky when we have baseline:dev but
>> we also use during the role execution the "delegate_to" localhost.
>>
>>> both localhost and the targets in this case.
>>
>> I thought about that option too but then, some/most of the tasks should be
>> executed on the guests. That path will require to exclude the controller node
>> from them.
> 
> 9p is a weird special case for all of this because the kernel is
> built on the controller and consumed on the targets. I'll bet
> dollars to donuts something is not right with build/9p.yml.
> 
> 

Re: [PATCH v2 09/15] bootlinux: fix os detection for 9p build dependency installation

[Chuck Lever]

On 11/7/25 3:47 PM, Daniel Gomez wrote:
> 
> 
> On 07/11/2025 21.17, Chuck Lever wrote:
>> On 11/7/25 3:00 PM, Daniel Gomez wrote:
>>> On 07/11/2025 20.22, Chuck Lever wrote:
>>>> On 10/29/25 8:40 AM, Daniel Gomez wrote:
>>>>> From: Daniel Gomez <da.gomez@samsung.com>
>>>>>
>>>>> Dependency installation for 9P builds was checking ansible_os_family,
>>>>> which references the target guest's OS instead of the control host where
>>>>> packages are actually installed. This caused incorrect packages to be
>>>>> installed when building Fedora guests on Debian hosts.
>>>>>
>>>>> Replace ansible_os_family checks with Kconfig distro variables
>>>>> (distro_debian_based, distro_fedora, etc.) which correctly detect
>>>>> the control host's distribution. Add fallback defaults to ensure the
>>>>> variables are always defined for standalone role usage.
>>>>>
>>>>> Generated-by: Claude AI
>>>>> Suggested-by: Chuck Lever <chuck.lever@oracle.com>
>>>>
>>>> Hrm. I might not have understood the whole picture.
>>>>
>>>> Yes, distro_yada_based does pick the controller's OS version.
>>>> But so does ansible_os_family when the task is running on
>>>> localhost.
>>>
>>> Just a reminder that we control where tasks are deployed with --limit and/or
>>> hosts: field in bootlinux.yml. For this case, IIRC, the playbook was run for
>>> baseline:dev but tasks were "delegated_to" localhost.
>>
>> That's new since I did the "build kernel on a separate target node"
>> changes and the related clean-ups in the bootlinux playbook. Not a
>> finger-point, just saying we could have collided somewhere.
>>
>>
>>>> I just hit a problem with the "build linux on a separate
>>>> target node" configuration, where the target is running
>>>> Debian 11 and the controller is running Fedora 41. The
>>>> bootlinux install-deps/main.yml checks were coming to
>>>> the wrong conclusion.
>>>
>>> Can you share the output? And the --limit argument used in this case?
>>> FYI, I normally enable CONFIG_KDEVOPS_MAKE_VERBOSE=y) which prints:
>>>
>>> make bringup
>>> + make linux-clone
>>> ==> [guestfs/kdevops_nodes.yaml]
>>> + ansible-playbook playbooks/gen_nodes.yml --extra-vars=@./extra_vars.yaml
>>> ...
>>> ==> [linux-clone-9p]
>>> + ansible-playbook --limit localhost playbooks/bootlinux.yml
>>> '--extra-vars=target_linux_git=/mirror/linux.git ...
>>> ...
>>
>> Here's from my scroll-back buffer earlier this afternoon:
>>
>> TASK [install-rust-deps : Install Rust build dependencies]
>> *************************************************************************************
>> included:
>> /home/cel/src/kdevops/buildbot-configs/playbooks/roles/install-rust-deps/tasks/install-deps/main.yml
>> for kernel-builder
>>
>> TASK [install-rust-deps : Install Rust build dependencies]
>> *************************************************************************************
>> changed: [kernel-builder]
>> FAILED - RETRYING: [kernel-builder]: Install packages we care about (3
>> retries left).
>> FAILED - RETRYING: [kernel-builder]: Install packages we care about (2
>> retries left).
>> FAILED - RETRYING: [kernel-builder]: Install packages we care about (1
>> retries left).
>>
>> TASK [bootlinux : Install packages we care about]
>> **********************************************************************************************
>> task path:
>> /home/cel/src/kdevops/buildbot-configs/playbooks/roles/bootlinux/tasks/install-deps/redhat/main.yml:8
>> fatal: [kernel-builder]: FAILED! => {
>>     "ansible_facts": {
>>         "pkg_mgr": "apt"
>>     },
>>     "attempts": 3,
>>     "changed": false
>> }
>>
>> MSG:
>>
>> ('Could not detect which major revision of dnf is in use, which is
>> required to determine module backend.', 'You should manually specify
>> use_backend to tell the module whether to use the dnf4 or dnf5 backend})')
>>
>>
>> As you can see, bootlinux is trying to install the redhat deps on
>> the target, but in fact the target is running Debian 11. This is
>> because the install-deps play is now looking at distro_yada_based
>> even though it is running on the target.
> 
> I think we need to detect both cases based on the target selection
> (BOOTLINUX_TARGETS). Can you give this a try/check/review?
> 
> For 9p targets (controller node, ie BOOTLINUX_9P), we keep the
> distro_yada_based. For builder targets (BOOTLINUX_BUILDER) we use the
> ansible_os_family:
> 
> diff --git a/playbooks/roles/bootlinux/tasks/install-deps/main.yml b/playbooks/roles/bootlinux/tasks/install-deps/main.yml
> index 058f3926..88d2baad 100644
> --- a/playbooks/roles/bootlinux/tasks/install-deps/main.yml
> +++ b/playbooks/roles/bootlinux/tasks/install-deps/main.yml
> @@ -1,15 +1,36 @@
>  ---
> -- name: Debian-specific setup
> +- name: Debian-specific setup (9p/controller node)
>    ansible.builtin.import_tasks: debian/main.yml
>    when:
>      - distro_debian_based|bool
> +    - bootlinux_9p|bool
> 
> -- name: SuSE-specific setup
> +- name: Debian-specific setup (builder node)
> +  ansible.builtin.import_tasks: debian/main.yml
> +  when:
> +    - bootlinux_builder|bool
> +    - ansible_os_family == "Debian"
> +
> +- name: SuSE-specific setup (9p/controller node)
>    ansible.builtin.import_tasks: suse/main.yml
>    when:
>      - distro_suse_based|bool
> +    - bootlinux_9p|bool
> 
> -- name: Red Hat-specific setup
> +- name: SuSE-specific setup (builder node)
> +  ansible.builtin.import_tasks: suse/main.yml
> +  when:
> +    - bootlinux_builder|bool
> +    - ansible_os_family == "Suse"
> +
> +- name: Red Hat-specific setup (controller node)
>    ansible.builtin.import_tasks: redhat/main.yml
>    when:
>      - distro_redhat_based|bool
> +    - bootlinux_9p|bool
> +
> +- name: Red Hat-specific setup (builder node)
> +  ansible.builtin.import_tasks: redhat/main.yml
> +  when:
> +    - bootlinux_builder|bool
> +    - ansible_os_family == "RedHat"
> 
> IIUC, this should return the correct ansible_os_family value when builder target
> is selected because the task is executed on the guest with --limit baseline:dev.
Hi Daniel -

None of these tasks will execute if bootlinux_targets == true, AFAICT.

Why can't this work based on which host the install-deps tasks are
running on? That was the original design I had in mind, and seems
most Ansible-like.


-- 
Chuck Lever

Re: [PATCH v2 09/15] bootlinux: fix os detection for 9p build dependency installation

[Daniel Gomez]

On 07/11/2025 21.53, Chuck Lever wrote:
> On 11/7/25 3:47 PM, Daniel Gomez wrote:
>>
>>
>> On 07/11/2025 21.17, Chuck Lever wrote:
>>> On 11/7/25 3:00 PM, Daniel Gomez wrote:
>>>> On 07/11/2025 20.22, Chuck Lever wrote:
>>>>> On 10/29/25 8:40 AM, Daniel Gomez wrote:
>>>>>> From: Daniel Gomez <da.gomez@samsung.com>
>>>>>>
>>>>>> Dependency installation for 9P builds was checking ansible_os_family,
>>>>>> which references the target guest's OS instead of the control host where
>>>>>> packages are actually installed. This caused incorrect packages to be
>>>>>> installed when building Fedora guests on Debian hosts.
>>>>>>
>>>>>> Replace ansible_os_family checks with Kconfig distro variables
>>>>>> (distro_debian_based, distro_fedora, etc.) which correctly detect
>>>>>> the control host's distribution. Add fallback defaults to ensure the
>>>>>> variables are always defined for standalone role usage.
>>>>>>
>>>>>> Generated-by: Claude AI
>>>>>> Suggested-by: Chuck Lever <chuck.lever@oracle.com>
>>>>>
>>>>> Hrm. I might not have understood the whole picture.
>>>>>
>>>>> Yes, distro_yada_based does pick the controller's OS version.
>>>>> But so does ansible_os_family when the task is running on
>>>>> localhost.
>>>>
>>>> Just a reminder that we control where tasks are deployed with --limit and/or
>>>> hosts: field in bootlinux.yml. For this case, IIRC, the playbook was run for
>>>> baseline:dev but tasks were "delegated_to" localhost.
>>>
>>> That's new since I did the "build kernel on a separate target node"
>>> changes and the related clean-ups in the bootlinux playbook. Not a
>>> finger-point, just saying we could have collided somewhere.
>>>
>>>
>>>>> I just hit a problem with the "build linux on a separate
>>>>> target node" configuration, where the target is running
>>>>> Debian 11 and the controller is running Fedora 41. The
>>>>> bootlinux install-deps/main.yml checks were coming to
>>>>> the wrong conclusion.
>>>>
>>>> Can you share the output? And the --limit argument used in this case?
>>>> FYI, I normally enable CONFIG_KDEVOPS_MAKE_VERBOSE=y) which prints:
>>>>
>>>> make bringup
>>>> + make linux-clone
>>>> ==> [guestfs/kdevops_nodes.yaml]
>>>> + ansible-playbook playbooks/gen_nodes.yml --extra-vars=@./extra_vars.yaml
>>>> ...
>>>> ==> [linux-clone-9p]
>>>> + ansible-playbook --limit localhost playbooks/bootlinux.yml
>>>> '--extra-vars=target_linux_git=/mirror/linux.git ...
>>>> ...
>>>
>>> Here's from my scroll-back buffer earlier this afternoon:
>>>
>>> TASK [install-rust-deps : Install Rust build dependencies]
>>> *************************************************************************************
>>> included:
>>> /home/cel/src/kdevops/buildbot-configs/playbooks/roles/install-rust-deps/tasks/install-deps/main.yml
>>> for kernel-builder
>>>
>>> TASK [install-rust-deps : Install Rust build dependencies]
>>> *************************************************************************************
>>> changed: [kernel-builder]
>>> FAILED - RETRYING: [kernel-builder]: Install packages we care about (3
>>> retries left).
>>> FAILED - RETRYING: [kernel-builder]: Install packages we care about (2
>>> retries left).
>>> FAILED - RETRYING: [kernel-builder]: Install packages we care about (1
>>> retries left).
>>>
>>> TASK [bootlinux : Install packages we care about]
>>> **********************************************************************************************
>>> task path:
>>> /home/cel/src/kdevops/buildbot-configs/playbooks/roles/bootlinux/tasks/install-deps/redhat/main.yml:8
>>> fatal: [kernel-builder]: FAILED! => {
>>>     "ansible_facts": {
>>>         "pkg_mgr": "apt"
>>>     },
>>>     "attempts": 3,
>>>     "changed": false
>>> }
>>>
>>> MSG:
>>>
>>> ('Could not detect which major revision of dnf is in use, which is
>>> required to determine module backend.', 'You should manually specify
>>> use_backend to tell the module whether to use the dnf4 or dnf5 backend})')
>>>
>>>
>>> As you can see, bootlinux is trying to install the redhat deps on
>>> the target, but in fact the target is running Debian 11. This is
>>> because the install-deps play is now looking at distro_yada_based
>>> even though it is running on the target.
>>
>> I think we need to detect both cases based on the target selection
>> (BOOTLINUX_TARGETS). Can you give this a try/check/review?
>>
>> For 9p targets (controller node, ie BOOTLINUX_9P), we keep the
>> distro_yada_based. For builder targets (BOOTLINUX_BUILDER) we use the
>> ansible_os_family:
>>
>> diff --git a/playbooks/roles/bootlinux/tasks/install-deps/main.yml b/playbooks/roles/bootlinux/tasks/install-deps/main.yml
>> index 058f3926..88d2baad 100644
>> --- a/playbooks/roles/bootlinux/tasks/install-deps/main.yml
>> +++ b/playbooks/roles/bootlinux/tasks/install-deps/main.yml
>> @@ -1,15 +1,36 @@
>>  ---
>> -- name: Debian-specific setup
>> +- name: Debian-specific setup (9p/controller node)
>>    ansible.builtin.import_tasks: debian/main.yml
>>    when:
>>      - distro_debian_based|bool
>> +    - bootlinux_9p|bool
>>
>> -- name: SuSE-specific setup
>> +- name: Debian-specific setup (builder node)
>> +  ansible.builtin.import_tasks: debian/main.yml
>> +  when:
>> +    - bootlinux_builder|bool
>> +    - ansible_os_family == "Debian"
>> +
>> +- name: SuSE-specific setup (9p/controller node)
>>    ansible.builtin.import_tasks: suse/main.yml
>>    when:
>>      - distro_suse_based|bool
>> +    - bootlinux_9p|bool
>>
>> -- name: Red Hat-specific setup
>> +- name: SuSE-specific setup (builder node)
>> +  ansible.builtin.import_tasks: suse/main.yml
>> +  when:
>> +    - bootlinux_builder|bool
>> +    - ansible_os_family == "Suse"
>> +
>> +- name: Red Hat-specific setup (controller node)
>>    ansible.builtin.import_tasks: redhat/main.yml
>>    when:
>>      - distro_redhat_based|bool
>> +    - bootlinux_9p|bool
>> +
>> +- name: Red Hat-specific setup (builder node)
>> +  ansible.builtin.import_tasks: redhat/main.yml
>> +  when:
>> +    - bootlinux_builder|bool
>> +    - ansible_os_family == "RedHat"
>>
>> IIUC, this should return the correct ansible_os_family value when builder target
>> is selected because the task is executed on the guest with --limit baseline:dev.
> Hi Daniel -
> 
> None of these tasks will execute if bootlinux_targets == true, AFAICT.

Sorry, I missed that target. I meant to add that condition too when we use
ansible_os_family case.

> 
> Why can't this work based on which host the install-deps tasks are
> running on? That was the original design I had in mind, and seems
> most Ansible-like.

I can't replicate the issue. I think we can revert the patch. Here my tests:

fedora: https://github.com/linux-kdevops/kdevops/actions/runs/19183690762
debian: https://github.com/linux-kdevops/kdevops/actions/runs/19183543710


> 
> 

Re: [PATCH v2 09/15] bootlinux: fix os detection for 9p build dependency installation

[Daniel Gomez]

On 08/11/2025 00.20, Daniel Gomez wrote:
> 
> 
> On 07/11/2025 21.53, Chuck Lever wrote:
>> On 11/7/25 3:47 PM, Daniel Gomez wrote:
>>>
>>>
>>> On 07/11/2025 21.17, Chuck Lever wrote:
>>>> On 11/7/25 3:00 PM, Daniel Gomez wrote:
>>>>> On 07/11/2025 20.22, Chuck Lever wrote:
>>>>>> On 10/29/25 8:40 AM, Daniel Gomez wrote:
>>>>>>> From: Daniel Gomez <da.gomez@samsung.com>
>>>>>>>
>>>>>>> Dependency installation for 9P builds was checking ansible_os_family,
>>>>>>> which references the target guest's OS instead of the control host where
>>>>>>> packages are actually installed. This caused incorrect packages to be
>>>>>>> installed when building Fedora guests on Debian hosts.
>>>>>>>
>>>>>>> Replace ansible_os_family checks with Kconfig distro variables
>>>>>>> (distro_debian_based, distro_fedora, etc.) which correctly detect
>>>>>>> the control host's distribution. Add fallback defaults to ensure the
>>>>>>> variables are always defined for standalone role usage.
>>>>>>>
>>>>>>> Generated-by: Claude AI
>>>>>>> Suggested-by: Chuck Lever <chuck.lever@oracle.com>
>>>>>>
>>>>>> Hrm. I might not have understood the whole picture.
>>>>>>
>>>>>> Yes, distro_yada_based does pick the controller's OS version.
>>>>>> But so does ansible_os_family when the task is running on
>>>>>> localhost.
>>>>>
>>>>> Just a reminder that we control where tasks are deployed with --limit and/or
>>>>> hosts: field in bootlinux.yml. For this case, IIRC, the playbook was run for
>>>>> baseline:dev but tasks were "delegated_to" localhost.
>>>>
>>>> That's new since I did the "build kernel on a separate target node"
>>>> changes and the related clean-ups in the bootlinux playbook. Not a
>>>> finger-point, just saying we could have collided somewhere.
>>>>
>>>>
>>>>>> I just hit a problem with the "build linux on a separate
>>>>>> target node" configuration, where the target is running
>>>>>> Debian 11 and the controller is running Fedora 41. The
>>>>>> bootlinux install-deps/main.yml checks were coming to
>>>>>> the wrong conclusion.
>>>>>
>>>>> Can you share the output? And the --limit argument used in this case?
>>>>> FYI, I normally enable CONFIG_KDEVOPS_MAKE_VERBOSE=y) which prints:
>>>>>
>>>>> make bringup
>>>>> + make linux-clone
>>>>> ==> [guestfs/kdevops_nodes.yaml]
>>>>> + ansible-playbook playbooks/gen_nodes.yml --extra-vars=@./extra_vars.yaml
>>>>> ...
>>>>> ==> [linux-clone-9p]
>>>>> + ansible-playbook --limit localhost playbooks/bootlinux.yml
>>>>> '--extra-vars=target_linux_git=/mirror/linux.git ...
>>>>> ...
>>>>
>>>> Here's from my scroll-back buffer earlier this afternoon:
>>>>
>>>> TASK [install-rust-deps : Install Rust build dependencies]
>>>> *************************************************************************************
>>>> included:
>>>> /home/cel/src/kdevops/buildbot-configs/playbooks/roles/install-rust-deps/tasks/install-deps/main.yml
>>>> for kernel-builder
>>>>
>>>> TASK [install-rust-deps : Install Rust build dependencies]
>>>> *************************************************************************************
>>>> changed: [kernel-builder]
>>>> FAILED - RETRYING: [kernel-builder]: Install packages we care about (3
>>>> retries left).
>>>> FAILED - RETRYING: [kernel-builder]: Install packages we care about (2
>>>> retries left).
>>>> FAILED - RETRYING: [kernel-builder]: Install packages we care about (1
>>>> retries left).
>>>>
>>>> TASK [bootlinux : Install packages we care about]
>>>> **********************************************************************************************
>>>> task path:
>>>> /home/cel/src/kdevops/buildbot-configs/playbooks/roles/bootlinux/tasks/install-deps/redhat/main.yml:8
>>>> fatal: [kernel-builder]: FAILED! => {
>>>>     "ansible_facts": {
>>>>         "pkg_mgr": "apt"
>>>>     },
>>>>     "attempts": 3,
>>>>     "changed": false
>>>> }
>>>>
>>>> MSG:
>>>>
>>>> ('Could not detect which major revision of dnf is in use, which is
>>>> required to determine module backend.', 'You should manually specify
>>>> use_backend to tell the module whether to use the dnf4 or dnf5 backend})')
>>>>
>>>>
>>>> As you can see, bootlinux is trying to install the redhat deps on
>>>> the target, but in fact the target is running Debian 11. This is
>>>> because the install-deps play is now looking at distro_yada_based
>>>> even though it is running on the target.
>>>
>>> I think we need to detect both cases based on the target selection
>>> (BOOTLINUX_TARGETS). Can you give this a try/check/review?
>>>
>>> For 9p targets (controller node, ie BOOTLINUX_9P), we keep the
>>> distro_yada_based. For builder targets (BOOTLINUX_BUILDER) we use the
>>> ansible_os_family:
>>>
>>> diff --git a/playbooks/roles/bootlinux/tasks/install-deps/main.yml b/playbooks/roles/bootlinux/tasks/install-deps/main.yml
>>> index 058f3926..88d2baad 100644
>>> --- a/playbooks/roles/bootlinux/tasks/install-deps/main.yml
>>> +++ b/playbooks/roles/bootlinux/tasks/install-deps/main.yml
>>> @@ -1,15 +1,36 @@
>>>  ---
>>> -- name: Debian-specific setup
>>> +- name: Debian-specific setup (9p/controller node)
>>>    ansible.builtin.import_tasks: debian/main.yml
>>>    when:
>>>      - distro_debian_based|bool
>>> +    - bootlinux_9p|bool
>>>
>>> -- name: SuSE-specific setup
>>> +- name: Debian-specific setup (builder node)
>>> +  ansible.builtin.import_tasks: debian/main.yml
>>> +  when:
>>> +    - bootlinux_builder|bool
>>> +    - ansible_os_family == "Debian"
>>> +
>>> +- name: SuSE-specific setup (9p/controller node)
>>>    ansible.builtin.import_tasks: suse/main.yml
>>>    when:
>>>      - distro_suse_based|bool
>>> +    - bootlinux_9p|bool
>>>
>>> -- name: Red Hat-specific setup
>>> +- name: SuSE-specific setup (builder node)
>>> +  ansible.builtin.import_tasks: suse/main.yml
>>> +  when:
>>> +    - bootlinux_builder|bool
>>> +    - ansible_os_family == "Suse"
>>> +
>>> +- name: Red Hat-specific setup (controller node)
>>>    ansible.builtin.import_tasks: redhat/main.yml
>>>    when:
>>>      - distro_redhat_based|bool
>>> +    - bootlinux_9p|bool
>>> +
>>> +- name: Red Hat-specific setup (builder node)
>>> +  ansible.builtin.import_tasks: redhat/main.yml
>>> +  when:
>>> +    - bootlinux_builder|bool
>>> +    - ansible_os_family == "RedHat"
>>>
>>> IIUC, this should return the correct ansible_os_family value when builder target
>>> is selected because the task is executed on the guest with --limit baseline:dev.
>> Hi Daniel -
>>
>> None of these tasks will execute if bootlinux_targets == true, AFAICT.
> 
> Sorry, I missed that target. I meant to add that condition too when we use
> ansible_os_family case.
> 
>>
>> Why can't this work based on which host the install-deps tasks are
>> running on? That was the original design I had in mind, and seems
>> most Ansible-like.
> 
> I can't replicate the issue. I think we can revert the patch. Here my tests:
> 
> fedora: https://github.com/linux-kdevops/kdevops/actions/runs/19183690762
> debian: https://github.com/linux-kdevops/kdevops/actions/runs/19183543710
> 
> 

I sent this too soon.
https://github.com/linux-kdevops/kdevops/actions/runs/19183690762/job/54845995905

+ ansible-playbook --limit baseline:dev playbooks/bootlinux.yml '--extra-vars=target_linux_git=/mirror/linux.git target_linux_tree=linux target_linux_ref=v6.15 target_linux_config=config-v6.15 target_linux_kernelrelease= target_linux_localversion= target_linux_shallow_depth=1 bootlinux_9p_host_path='\''/data4-xfs/gh/actions-runner/kdevops-ci-0019/_work/kdevops/kdevops/linux'\'' bootlinux_9p_msize='\''131072'\'' bootlinux_9p_fsdev='\''kdevops_9p_fsdev'\'' bootlinux_9p_security_model='\''none'\'' bootlinux_9p_driver='\''virtio-9p-pci'\'' bootlinux_9p_mount_tag='\''kdevops_9p_bootlinux'\'' bootlinux_cxl_test='
==> [linux]
Warning: : Could not match supplied host pattern, ignoring: dev
Warning: : Deprecation warnings can be disabled by setting `deprecation_warnings=False` in ansible.cfg.
[DEPRECATION WARNING]: The 'community.general.diy' callback plugin implements deprecated method 'v2_on_any'. This feature will be removed from the callback plugin API in ansible-core version 2.23. Use event-specific callback methods instead.
[DEPRECATION WARNING]: Passing `convert_data` to `template` is deprecated. This feature will be removed from ansible-core version 2.23.
PLAY: BOOTLINUX
TASK: Gathering Facts [kci-19183690762-181-nvme]
⠀⠀✓ [kci-19183690762-181-nvme]
TASK: Import optional extra_args file [kci-19183690762-181-nvme]
⠀⠀✓ [kci-19183690762-181-nvme]
TASK: Select the .config file for building the test kernel [kci-19183690762-181-nvme]
⠀⠀✓ [kci-19183690762-181-nvme]
...
TASK: Build the Linux kernel on the controller host [kci-19183690762-181-nvme]
⠀⠀✓ [kci-19183690762-181-nvme]
included: /data4-xfs/gh/actions-runner/kdevops-ci-0019/_work/kdevops/kdevops/playbooks/roles/bootlinux/tasks/build/9p.yml for kci-19183690762-181-nvme
TASK: Update apt cache [kci-19183690762-181-nvme]
⠀⠀⊘ [kci-19183690762-181-nvme]
TASK: Install Linux kernel build dependencies [kci-19183690762-181-nvme]
⠀⠀⊘ [kci-19183690762-181-nvme]
TASK: Install Linux kernel build dependencies for SUSE sources [kci-19183690762-181-nvme]
⠀⠀⊘ [kci-19183690762-181-nvme]
TASK: Enable installation of packages from EPEL [kci-19183690762-181-nvme]
⠀⠀⊘ [kci-19183690762-181-nvme]
TASK: Install packages we care about [kci-19183690762-181-nvme]
FAILED - RETRYING: [kci-19183690762-181-nvme -> localhost]: Install packages we care about (3 retries left).
FAILED - RETRYING: [kci-19183690762-181-nvme -> localhost]: Install packages we care about (2 retries left).
FAILED - RETRYING: [kci-19183690762-181-nvme -> localhost]: Install packages we care about (1 retries left).
⠀⠀FAILED: [kci-19183690762-181-nvme] => ['Could not detect which major revision of dnf is in use, which is required to determine module backend.', 'You should manually specify use_backend to tell the module whether to use the dnf4 or dnf5 backend})']
Error: : Task failed: Action failed: ('Could not detect which major revision of dnf is in use, which is required to determine module backend.', 'You should manually specify use_backend to tell the module whether to use the dnf4 or dnf5 backend})')
Origin: /data4-xfs/gh/actions-runner/kdevops-ci-0019/_work/kdevops/kdevops/playbooks/roles/bootlinux/tasks/install-deps/redhat/main.yml:8:3

6     - ansible_distribution != "Fedora"
7
8 - name: Install packages we care about
    ^ column 3

fatal: [kci-19183690762-181-nvme -> localhost]: FAILED! => {"attempts": 3, "changed": false, "msg": ["Could not detect which major revision of dnf is in use, which is required to determine module backend.", "You should manually specify use_backend to tell the module whether to use the dnf4 or dnf5 backend})"]}>>
>>

Re: [PATCH v2 09/15] bootlinux: fix os detection for 9p build dependency installation

[Chuck Lever]

On 11/7/25 6:20 PM, Daniel Gomez wrote:
>>> +- name: Red Hat-specific setup (controller node)
>>>    ansible.builtin.import_tasks: redhat/main.yml
>>>    when:
>>>      - distro_redhat_based|bool
>>> +    - bootlinux_9p|bool
>>> +
>>> +- name: Red Hat-specific setup (builder node)
>>> +  ansible.builtin.import_tasks: redhat/main.yml
>>> +  when:
>>> +    - bootlinux_builder|bool
>>> +    - ansible_os_family == "RedHat"
>>>
>>> IIUC, this should return the correct ansible_os_family value when builder target
>>> is selected because the task is executed on the guest with --limit baseline:dev.
>> Hi Daniel -
>>
>> None of these tasks will execute if bootlinux_targets == true, AFAICT.
> Sorry, I missed that target. I meant to add that condition too when we use
> ansible_os_family case.
> 
>> Why can't this work based on which host the install-deps tasks are
>> running on? That was the original design I had in mind, and seems
>> most Ansible-like.
> I can't replicate the issue. I think we can revert the patch. Here my tests:
> 
> fedora: https://github.com/linux-kdevops/kdevops/actions/runs/19183690762
> debian: https://github.com/linux-kdevops/kdevops/actions/runs/19183543710

OK, let me try to be less terse.  :-)

I'd like to see this instance of install-deps look like most of the
others: basically, key off only the ansible_os_family settings. I think
that will be more maintainable.

Those settings, however, need to properly reflect the environment where
install-deps is running. For the 9p case, it will run on both the
controller (where the kernel is built) and the targets (where the kernel
is installed); and I think bootlinux even runs the install-deps steps
twice for 9p to deal exactly with that duplication.

The same is true for the "separate builder" case: the kernel builder
runs on one target node, and the built artifacts are installed on other
target nodes; and bootlinux has to ensure the correct dependencies are
installed everywhere they are needed.

The way I tried to deal with that was to use "delegate_to:". But I think
you might have advanced a different mechanism, and I missed the
subtleties of that. Or, maybe providing execution locale information on
the Ansible command line just isn't appropriate in these cases. I
haven't thought it through.

I'm very happy to help drill into the 9p case that was not working for
you, instead of standing nearby lobbing uninformed suggestions.
Meanwhile, I'll keep a patch that reverts 0e9c8ac8bc68 in my private
tree.

-- 
Chuck Lever

Re: [PATCH v2 09/15] bootlinux: fix os detection for 9p build dependency installation

[Daniel Gomez]

On 08/11/2025 17.11, Chuck Lever wrote:
> On 11/7/25 6:20 PM, Daniel Gomez wrote:
>>>> +- name: Red Hat-specific setup (controller node)
>>>>    ansible.builtin.import_tasks: redhat/main.yml
>>>>    when:
>>>>      - distro_redhat_based|bool
>>>> +    - bootlinux_9p|bool
>>>> +
>>>> +- name: Red Hat-specific setup (builder node)
>>>> +  ansible.builtin.import_tasks: redhat/main.yml
>>>> +  when:
>>>> +    - bootlinux_builder|bool
>>>> +    - ansible_os_family == "RedHat"
>>>>
>>>> IIUC, this should return the correct ansible_os_family value when builder target
>>>> is selected because the task is executed on the guest with --limit baseline:dev.
>>> Hi Daniel -
>>>
>>> None of these tasks will execute if bootlinux_targets == true, AFAICT.
>> Sorry, I missed that target. I meant to add that condition too when we use
>> ansible_os_family case.
>>
>>> Why can't this work based on which host the install-deps tasks are
>>> running on? That was the original design I had in mind, and seems
>>> most Ansible-like.
>> I can't replicate the issue. I think we can revert the patch. Here my tests:
>>
>> fedora: https://github.com/linux-kdevops/kdevops/actions/runs/19183690762
>> debian: https://github.com/linux-kdevops/kdevops/actions/runs/19183543710
> 
> OK, let me try to be less terse.  :-)
> 
> I'd like to see this instance of install-deps look like most of the
> others: basically, key off only the ansible_os_family settings. I think
> that will be more maintainable.

100%.

> 
> Those settings, however, need to properly reflect the environment where
> install-deps is running. For the 9p case, it will run on both the
> controller (where the kernel is built) and the targets (where the kernel
> is installed); and I think bootlinux even runs the install-deps steps
> twice for 9p to deal exactly with that duplication.

I think you are referring to "Install essential build tools for 9P builds" task
in main.yml + "Install dependencies to build the Linux kernel" in build/9p.yml.
The first one executes on the guests while the second one is delegated to the
localhost.

> 
> The same is true for the "separate builder" case: the kernel builder
> runs on one target node, and the built artifacts are installed on other
> target nodes; and bootlinux has to ensure the correct dependencies are
> installed everywhere they are needed.

This is referring to the task "Install dependencies to build and install
the Linux kernel" in main.yml. Which is skipped for 9p (but included through
build/9p.yml + delegated_to).

> 
> The way I tried to deal with that was to use "delegate_to:". But I think
> you might have advanced a different mechanism, and I missed the
> subtleties of that. Or, maybe providing execution locale information on
> the Ansible command line just isn't appropriate in these cases. I
> haven't thought it through.

This is where it gets tricky. I've just found out that delegated tasks to a
host that is not included in the scope (such as localhost), do not have gathered
facts.

https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_delegation.html#delegating-facts

That explains why ansible_os_family returns the guest fact (e.g. RedHat
guest), not the localhost fact (e.g. Debian host) when we import_tasks:
install-deps/main.yml in build/9p.yml.

The use of distro_yada_based in patch "bootlinux: fix os detection for 9p build
dependency installation" allows to access the fact (os family) via Kconfig for
the localhost. But breaks builder and targets sub-roles.

> 
> I'm very happy to help drill into the 9p case that was not working for
> you, instead of standing nearby lobbing uninformed suggestions.
> Meanwhile, I'll keep a patch that reverts 0e9c8ac8bc68 in my private
> tree.
> 

Thanks Chuck. I think the correct approach is to revert patch 0e9c8ac8
"bootlinux: fix os detection for 9p build dependency installation" upstream,
while we try to sort this out in 9p.

For the revert part, please push:
Acked-by: Daniel Gomez <da.gomez@samsung.com>

FYI, I'm already working on a solution using delegate_facts + hostvars as
described in the Ansible documentation link above. That seems to be the right
approach. I'll send something soon for testing.

Re: [PATCH v2 09/15] bootlinux: fix os detection for 9p build dependency installation

[Chuck Lever]

On 11/8/25 3:12 PM, Daniel Gomez wrote:
>> The way I tried to deal with that was to use "delegate_to:". But I think
>> you might have advanced a different mechanism, and I missed the
>> subtleties of that. Or, maybe providing execution locale information on
>> the Ansible command line just isn't appropriate in these cases. I
>> haven't thought it through.
> This is where it gets tricky. I've just found out that delegated tasks to a
> host that is not included in the scope (such as localhost), do not have gathered
> facts.

This is surprising, but explains a lot. I didn't know this either!


> https://docs.ansible.com/ansible/latest/playbook_guide/
> playbooks_delegation.html#delegating-facts
> 
> That explains why ansible_os_family returns the guest fact (e.g. RedHat
> guest), not the localhost fact (e.g. Debian host) when we import_tasks:
> install-deps/main.yml in build/9p.yml.
> 
> The use of distro_yada_based in patch "bootlinux: fix os detection for 9p build
> dependency installation" allows to access the fact (os family) via Kconfig for
> the localhost. But breaks builder and targets sub-roles.
> 
>> I'm very happy to help drill into the 9p case that was not working for
>> you, instead of standing nearby lobbing uninformed suggestions.
>> Meanwhile, I'll keep a patch that reverts 0e9c8ac8bc68 in my private
>> tree.
>>
> Thanks Chuck. I think the correct approach is to revert patch 0e9c8ac8
> "bootlinux: fix os detection for 9p build dependency installation" upstream,
> while we try to sort this out in 9p.
> 
> For the revert part, please push:
> Acked-by: Daniel Gomez <da.gomez@samsung.com>
> 
> FYI, I'm already working on a solution using delegate_facts + hostvars as
> described in the Ansible documentation link above. That seems to be the right
> approach. I'll send something soon for testing.

For expediency, I had a patch that reverted just the install-deps/
main.yml hunk. Testing a full revert of 0e9c8ac8bc68 now, before
pushing.


-- 
Chuck Lever