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 95E0534D3B1 for ; Fri, 7 Nov 2025 20:00:44 +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=1762545644; cv=none; b=YNnTJ4rViaUb6Ef5qV74uHvMp3HWluVmR2Qy4FzwPXUBr6xLWlBUTTv7RV3VQr/aCxdrL+aOxCkNjwwUAPheNoNuizisIaa0bA0xyWHL6pW1LjxOKVECRXYIOuiSlmXpiRdxJmRbzMomSwrYkHgTwDYIIiA3Qq8yHnrwUIZxysY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762545644; c=relaxed/simple; bh=x8sY9z+l+EsbftjyS4RFDrVU1a5rXGoMPyUDuduD2jQ=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=BcvxY6N/wcyvvqosxHf5O5c6zwhcCVBGgrH+p+tdm2pe9I0j6q6w7T0XcLEUujwXezLBlMaFeSDQUy/uYfAhf/GguBWRvlLM3mAinnH/658OHrFaF3hvxTsUSXCricX4RCFgPtFNzanLuSO3hPUv8bw50MzBj03OSNVy5qlAgTM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=rJXLewUW; 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="rJXLewUW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3B461C113D0; Fri, 7 Nov 2025 20:00:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1762545644; bh=x8sY9z+l+EsbftjyS4RFDrVU1a5rXGoMPyUDuduD2jQ=; h=Date:Reply-To:Subject:To:Cc:References:From:In-Reply-To:From; b=rJXLewUW3SeICwvso/K54XRmlj1kW0x1OcDVAZpAfKHu7R3vXsHIb68NF/cbCcf3Q ZKJ7SRYG3Hto3Owv8ltn1+VPGGekLbwfqj0JNbc9UMnjNNOUeZlAdCeV5/pcmtLoB7 yAT7pK5cAmkmMETWqElI3mqqPNUf0zwEJZv5uzRtTNxqbV7eXPrwlpKJEZXQroR05s z4ESRX1jYlZiJGllDPCmX1k/3S6rGm6OcJXisTaGAJsv3rO3oTqQLl/x/n4JzEWkKG ycnOKhPE+mGFqmrJH4JzLNmojutzVDSrTO8rikekYFKepLEPthNv//53e1qjCX5puQ aSmbkGL0FIyGg== Message-ID: <9657ff48-8cc0-4ce6-b52c-ef1ab40c7a74@kernel.org> Date: Fri, 7 Nov 2025 21:00:40 +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> Content-Language: en-US From: Daniel Gomez Organization: kernel.org In-Reply-To: <7a126e42-a65c-4020-b7b4-3e8c784be593@oracle.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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. > > 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.