public inbox for kdevops@lists.linux.dev
 help / color / mirror / Atom feed
From: Daniel Gomez <da.gomez@kernel.org>
To: Chuck Lever <chuck.lever@oracle.com>,
	Luis Chamberlain <mcgrof@kernel.org>
Cc: kdevops@lists.linux.dev, Daniel Gomez <da.gomez@samsung.com>
Subject: Re: [PATCH v2 09/15] bootlinux: fix os detection for 9p build dependency installation
Date: Sat, 8 Nov 2025 00:20:05 +0100	[thread overview]
Message-ID: <0551827c-a0bd-4589-b9e4-073aa545ccb0@kernel.org> (raw)
In-Reply-To: <a3bd8db8-06cf-4b38-85ac-0274cf627a7a@oracle.com>



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


> 
> 

  reply	other threads:[~2025-11-07 23:20 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-29 12:40 [PATCH v2 00/15] Fedora on Debian Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 01/15] base_image: restore locales-all installation for Debian Trixie Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 02/15] guestfs: fix Kconfig indentation style Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 03/15] guestfs: remove unused bringup debug Kconfig options Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 04/15] guestfs: fix spelling errors and Debian capitalization Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 05/15] base_image: set selinux to permissive for fedora on debian hosts Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 06/15] ansible_provisioning: fix help text indentation style Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 07/15] devconfig: fix undefined custom repos/packages variables Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 08/15] devconfig: fix Ansible boolean conditional for custom repos Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 09/15] bootlinux: fix os detection for 9p build dependency installation Daniel Gomez
2025-11-07 19:22   ` Chuck Lever
2025-11-07 20:00     ` Daniel Gomez
2025-11-07 20:17       ` Chuck Lever
2025-11-07 20:47         ` Daniel Gomez
2025-11-07 20:53           ` Chuck Lever
2025-11-07 23:20             ` Daniel Gomez [this message]
2025-11-07 23:24               ` Daniel Gomez
2025-11-08 16:11               ` Chuck Lever
2025-11-08 20:12                 ` Daniel Gomez
2025-11-08 20:56                   ` Chuck Lever
2025-10-29 12:40 ` [PATCH v2 10/15] selftests: " Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 11/15] guestfs: generate fedora distribution-specific hostname prefixes Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 12/15] defconfigs: add fedora-41 fragment for guestfs Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 13/15] defconfigs: add debian-13 " Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 14/15] github: add guest OS selection for CI testing Daniel Gomez
2025-10-29 12:40 ` [PATCH v2 15/15] guestfs: increase SSH config timeout for Fedora on Debian hosts Daniel Gomez
2025-10-29 13:49 ` [PATCH v2 00/15] Fedora on Debian Chuck Lever
2025-10-29 14:16 ` Daniel Gomez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0551827c-a0bd-4589-b9e4-073aa545ccb0@kernel.org \
    --to=da.gomez@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=da.gomez@samsung.com \
    --cc=kdevops@lists.linux.dev \
    --cc=mcgrof@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox