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

[Chuck Lever <chuck.lever@oracle.com>]

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