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

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 <[email protected]>
>>>>
>>>> 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 <[email protected]>
>>>
>>> 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.
> 
>