From nobody Fri Feb 16 10:37:33 2024 X-Original-To: virtualization@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TbpKZ17pRz5BWqw for ; Fri, 16 Feb 2024 10:37:38 +0000 (UTC) (envelope-from jo@durchholz.org) Received: from www382.your-server.de (www382.your-server.de [78.46.146.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TbpKY0Tvrz4CN2 for ; Fri, 16 Feb 2024 10:37:36 +0000 (UTC) (envelope-from jo@durchholz.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=durchholz.org header.s=default2202 header.b=TamU6skX; spf=pass (mx1.freebsd.org: domain of jo@durchholz.org designates 78.46.146.228 as permitted sender) smtp.mailfrom=jo@durchholz.org; dmarc=none DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=durchholz.org; s=default2202; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:To:Subject:MIME-Version:Date:Message-ID:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=E6OxibPjYaKGl/ZHf7Caq0QqRBWTtQTAOSXGnlcWCvI=; b=TamU6skXUKFHx46SlWUCwcUbKN Bbl1VDQgJ5VloI93hM9fLBRQleiU4HhkmJQTGXxrHWhpXSdJ/wyKpxcIRpa4B289DK2EhzFfJYGts e255yoDiDf49OxSms1O4KXjZb0vYUMWmKjz85be4ybiiH6d6A/BeFu6u/+BbXeAOveRPGGGvImc7g C3IQ1QDq2dhafr20MifBmp5qdAEgxU4CNMfC29uh0O/8jxC3QnUZnmTuI/gzgWCZHxbbq8Z9yK/gX CuuRaDwnDCczv2BH2SSVm0sIQydSWWQkW3TYUs99YptLbF+GxLVw3WEQsfZSrB7hWdYR/fie427fC RFJEHHTQ==; Received: from sslproxy03.your-server.de ([88.198.220.132]) by www382.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ravb4-000Gum-6n for virtualization@freebsd.org; Fri, 16 Feb 2024 11:37:34 +0100 Received: from [81.221.201.210] (helo=[192.168.178.48]) by sslproxy03.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ravb4-000Aq0-2g for virtualization@freebsd.org; Fri, 16 Feb 2024 11:37:34 +0100 Message-ID: <47e48541-15df-4c06-834a-6113694b3dba@durchholz.org> Date: Fri, 16 Feb 2024 11:37:33 +0100 List-Id: Discussion List-Archive: https://lists.freebsd.org/archives/freebsd-virtualization List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-virtualization@freebsd.org X-BeenThere: freebsd-virtualization@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Contributing the build of a KVM image To: virtualization@freebsd.org References: <8d266dd2-5ebc-40db-995f-4a4bfb9707eb@nomadlogic.org> <60f81e4d-8117-4410-b76b-e4ce3e076379@durchholz.org> <21ddd0c9-3b5d-a8ba-edaa-ebefc174172a@ShaneWare.Biz> Content-Language: en-US From: Jo Durchholz In-Reply-To: <21ddd0c9-3b5d-a8ba-edaa-ebefc174172a@ShaneWare.Biz> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: jo@durchholz.org X-Virus-Scanned: Clear (ClamAV 0.103.10/27187/Fri Feb 16 10:23:45 2024) X-Rspamd-Queue-Id: 4TbpKY0Tvrz4CN2 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.35 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.86)[-0.860]; R_SPF_ALLOW(-0.20)[+a]; R_DKIM_ALLOW(-0.20)[durchholz.org:s=default2202]; MIME_GOOD(-0.10)[text/plain]; XM_UA_NO_VERSION(0.01)[]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ASN(0.00)[asn:24940, ipnet:78.46.0.0/15, country:DE]; RCPT_COUNT_ONE(0.00)[1]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[durchholz.org]; HAS_X_AS(0.00)[]; ARC_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[virtualization@freebsd.org]; DKIM_TRACE(0.00)[durchholz.org:+] > So what is it that you want to change that the current images don't > provide? In hindsight, I found out there's already a qcow2 image and the only thing left to do would be a Vagrant configuration that used that image. > You may want to use a standard iso image to install FreeBSD > into a virtual machine and then do your modified build within that and > install over the standard system install. This is not for a modified build actually, it's for automated tests. So I don't need to do the build, except I wanted to study it to know where to insert the Vagrant configuration - I can't send a patch unless I know it builds cleanly, can I? I know it's probably possible to take shortcuts here, if the Vagrant configs are created during "make release", but I don't now enough about FreeBSD's build system to confidently do that, and I ultimately stopped the effort when the cross-build setup failed. > https://computingforgeeks.com/how-to-install-freebsd-on-kvm-virtualbox/ Good to know there's a ready-made set of instructions for interactive setup. Some KVM parameters aren't easy to understand, and would have required experimentation. It's based on an interactive tool, so I'll need to replace that with scripting for automated testing, and it's using an install image so there's a lot of interactive steps, but I found the for-VM images, including a qcow2 one, so I can whip something up I believe. I won't be able to use Vagrant, and I won't have the expectation that this specific kind of image will be available in future releases, but I guess there are no guarantees for that kind of stuff anyway. > You can also find a list of pre-built virtual disk images at the bottom > of the release announcement. > > https://www.freebsd.org/releases/14.0R/announce/ I found the images directly :-) >> Onwards to the next question: >> What would be the right place to ask questions about how to run `make`? >> >> In case this is already the right place, here they are: >> >> 1) I'm worried that make will write files to directories that I'm not >> aware of, or even overwrite stuff it has no business overwriting. >> How to I make sure that it does not write anywhere except >> ~/projects/freebsd (which is the place where I want to experiment with >> the freebsd build)? > > Running make buildworld will keep all build output within MAKEOBJDIRPREFIX I figured that much, but it's good to have a confirmation from somebody with more experience. >> 3) I need to run make on a Linux box. > > Aahh, so you are trying to cross compile FreeBSD on Linux. Seems this > should be easier than in the past, have you looked at > > https://docs.freebsd.org/en/books/handbook/cutting-edge/#building-on-non-freebsd-hosts Yeah, it fails on today's Debian. Autodetection does not find clang's cpp, possibly due to a quirk in Debian's clang setup, and even getting to that point was a lot of experimentation. I stopped trying that approach, since it was too much of "with each hurdle passed, another one comes up", which Isn't Worth It(tm) if there's an alternative approach available. > It is a few years old, but this creates a docker image to build FreeBSD > > https://github.com/sandvine/freebsd-cross-build That's for building FreeBSD inside a Docker container. It does some interesting things: - Download the gcc toolchain (at a specific version). - Configure it with some very specific option and build it. - Prepare things so the toolchain will be picked up by make.py. It does not start the actual build, which would (hopefully) be "just call make.py, the environment is already set up for this". I don't know why it uses a Docker container. One reason might be to allow doing the build on Windows, another one might be to isolate the build from the host to avoid any risk of environment pollution. It's using the gcc toolchain instead of clang, and I don't know of any justification for that, except maybe for better toolchain knowledge. Still, it's a useful baseline for those who want to run a build in a Docker contains. Regards, Jo