Date: Fri, 16 Feb 2024 11:37:33 +0100 From: Jo Durchholz <jo@durchholz.org> To: virtualization@freebsd.org Subject: Re: Contributing the build of a KVM image Message-ID: <47e48541-15df-4c06-834a-6113694b3dba@durchholz.org> In-Reply-To: <21ddd0c9-3b5d-a8ba-edaa-ebefc174172a@ShaneWare.Biz> References: <dad74102-853b-4738-abd2-30b98b73ab33@durchholz.org> <8d266dd2-5ebc-40db-995f-4a4bfb9707eb@nomadlogic.org> <60f81e4d-8117-4410-b76b-e4ce3e076379@durchholz.org> <21ddd0c9-3b5d-a8ba-edaa-ebefc174172a@ShaneWare.Biz>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47e48541-15df-4c06-834a-6113694b3dba>