From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 66E3621257A for ; Fri, 7 Nov 2025 20:47:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762548449; cv=none; b=jHl/fNsYHIWCsJoPYr9R/L8uznbbDkn7h8LrnuusZ81IWIdHvgluJSw+kjIqZK2FfBEOiw6daXTA9YmJzbG/odLfYuYRkH1VxMvN3A7JiHUxlXuyyZlgQZqdYvFZRGcpoVV7vqMHyiJdXprf8ZJHdhTNy3zyCFj/4eHjpVhM7s0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762548449; c=relaxed/simple; bh=wbIV9bx63jcbtiavxAGJWoM/nx4dy7rmC+KF8TYre9w=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=S8M09D/AEt7+JUCWeE1iS70I/zdEJMbr6J8/oFVWBmGGRTHY8JdtDAzqmLLjCpT0H/DC2+wlDKmCE60IfIvhSQDghSEqASXiKmfGw4uw4v0TXuEvIq475XjwgHAu1EkVoOx9p4hieLHs9T5vOIRVGNEWzwnH2mMzQefyCPmLX0s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FQvK454K; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="FQvK454K" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2CD19C4CEF7; Fri, 7 Nov 2025 20:47:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1762548449; bh=wbIV9bx63jcbtiavxAGJWoM/nx4dy7rmC+KF8TYre9w=; h=Date:Reply-To:Subject:To:Cc:References:From:In-Reply-To:From; b=FQvK454Krg/O7zZTOOvM7stneK0Vez5XZ21f+SgwZzdLEKEo7420D8N3x7YB0ydpJ 9QRHQ5stP1wI5kWnkT6fItCdbBUrKbQY580lhIHL+0P4cNKzyz0vkUjkJPKGZmmxtb KXPJjhKCSaVVY0ab6bY/sDykrI5WhEhZIIm5VHXfXMy8/jKXNkfk1SxteGuG+F4Psi ArXeZiA/gTeOPnsp//3DnauGwxEdQCKoKouOdImJDW83lbXeRbWcbCb5h/wO/gGlaJ sRzGUHPlqhmxrkYzswCOkr3qGXiKnoxym24tkgs0m2lAPfCmluTWbR/iQKVQowtqfF pX2WTNTz8jL/A== Message-ID: <52e65c62-70eb-47da-b0e2-c92e5c514cbd@kernel.org> Date: Fri, 7 Nov 2025 21:47:26 +0100 Precedence: bulk X-Mailing-List: kdevops@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: Daniel Gomez Subject: Re: [PATCH v2 09/15] bootlinux: fix os detection for 9p build dependency installation To: Chuck Lever , Luis Chamberlain Cc: kdevops@lists.linux.dev, Daniel Gomez References: <20251029-fedora-on-debian-v2-0-ddc6e5bebc15@samsung.com> <20251029-fedora-on-debian-v2-9-ddc6e5bebc15@samsung.com> <7a126e42-a65c-4020-b7b4-3e8c784be593@oracle.com> <9657ff48-8cc0-4ce6-b52c-ef1ab40c7a74@kernel.org> <0439acaf-b96b-4553-9a3a-59cd7134e50b@oracle.com> Content-Language: en-US From: Daniel Gomez Organization: kernel.org In-Reply-To: <0439acaf-b96b-4553-9a3a-59cd7134e50b@oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 >>>> >>>> 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 >>> >>> 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. > >