freeBSD 14.1-RELEASE Bulding a custom minimal server kernel - need help

Hello All,

I am quite new to the freeBSD, but recently I started switching from Linux to freeBSD. The main reason was that I wanted to learn something new. The seconds reason are Jails. I pretty much love them, especially Bastille Jails. They work perfectly in my environment and added the extra isolation I needed.
For the most part, I switched all my HomeLab environment (with the exception of Proxmox PVE) to freeBSD and I would say I am very happy with my choise.
What I want to achieve is:

1. I want to build a custom minimal kernel, that I can use for all my VMs. Why?
- I do not want IPv6 (I do not want at all IPv6, I do not use it at all, and I do not like it)
- I do not want USB (I do not use USB, and I do not want to use USB on VMs)
- I do not want Audio (same as above)
- I do not want Wireless (same as above)
- I do not want RAID (same as above)
- I do not want ALL the things I do not use.

1.1 The things I want to use in my VMs:
- UFS
- IPv4 Only
- Jails
- PF

2. I want to be able to use freebsd-update to update my systems while keeping the custom kernel without the needed to rebuild it after every freebsd-update.
3. I would like to use 1 VM for development purposes, a.k.a for building custom kernels, which I can distribute to my other VMs, so that I can use the new custom kernel on them, without the needed to build custom kernel on each and every VMs I have.

I read the Docs regarding the process of building a custom kernel, and I am experimenting with it, however I have a hard time to properly understand how I can achieve everything from point 1 to 3 in the same time.

Could someone give me a hand here?

Thank you in advance!
 
2. I want to be able to use freebsd-update to update my systems while keeping the custom kernel without the needed to rebuild it after every freebsd-update.
I don't see a practical way to achieve this given the bits that you've wanted to excise.

OTOH, building a kernel isn't THAT painful. It might be easier just to update the complete (kernel) source tree and rebuild with a config file that you have previously "blessed" as appropriate for your needs.

You can always test drive the kernel before replacing it in all of your VMs.
 
In addition to Chapter 10. Configuring the FreeBSD Kernel in the Handbook, there's the FreeBSD Developers' Handbook that may also be of interest, although more geared for developers of course.

You speak of VMs and Jails. Although both these terms refer to virtualisation techniques, for easy distinction within the FreeBSD world we usually refer to VMs as the complete OS-es we run as bhyve(8) clients (or a flavor of VMWare); FreeBSD jails are referred by just "jails". I'm not really sure what you intend to use for what as jails do not have a kernel of their own: they use the host's kernel.

When you run jails on FreeBSD I recommend you consider using ZFS as this is more secure and offers more and better management facilities.
 
In addition to Chapter 10. Configuring the FreeBSD Kernel in the Handbook, there's the FreeBSD Developers' Handbook that may also be of interest, although more geared for developers of course.

You speak of VMs and Jails. Although both these terms refer to virtualisation techniques, for easy distinction within the FreeBSD world we usually refer to VMs as the complete OS-es we run as bhyve(8) clients (or a flavor of VMWare); FreeBSD jails are referred by just "jails". I'm not really sure what you intend to use for what as jails do not have a kernel of their own: they use the host's kernel.

When you run jails on FreeBSD I recommend you consider using ZFS as this is more secure and offers more and better management facilities.
Well in order to be more precise, I should describe what my current setup is:

Dedicated Server running Proxmox PVE (as I am not very confortable using BHYVE at the moment, as I am very new to freeBSD) with ZFS (2 x Datacenter NVME SSDs in mirror mode) , as the server doesn't have physical RAID controller.
VMs with freeBSD as OS (KVM VMs) running on that Proxmox PVE Host.
Inside each and every VM I have different set of softwares (web servers, postgresql servers, etc) running inside a Jails (Bastille Jails).
Basically I am trying to configure my HomeLab environment to be as secure as I can get it.

However as I mentioned in my initial post there are curtain things I do no use and I do not want to be loaded in the Kernel at all, like IPv6, Wireless drivers/modules, USB and so on. So I read a lot of posts in different forums (including this one) suggesting If I really want to disable entirelly IPv6 in freeBSD, the only option is to build my custom kernel. Along with the other things I do not use, this is the only valuable options for me. The only part I am worried about is the freebsd-update when I use custom kernel, and this is the main reason I opened this topic here.
 
Everything you don't statically put in the kernel config will be build as a module. As a matter of fact, even the things you did put in your custom config will be build as a module. So, unless you also exclude modules they're all going to be build. Just save yourself a lot of work for little gain and stick with the standard GENERIC kernel. Then you won't have an issue with freebsd-update(8) either.
 
So I read a lot of posts in different forums (including this one) suggesting If I really want to disable entirelly IPv6 in freeBSD, the only option is to build my custom kernel.
So, your only hard reason for wanting to build a custom kernel is to get rid of IPv6?

A few years ago, I would have said that's a bit short-sighted. Nowadays, it's a decision deliberately restricting what you can reach (unless you have some proxies, NAT, ... whatever outside your host "solving" the issue): The number of hosts unreachable via IPv4 is (slowly) growing.

That all said, it's straight forward to just not configure IPv6 if you really want that, and it works perfectly as expected. No need to disable it in the kernel for that.
 
I end up disabling what is not needed by my VMs via /boot/loader.conf and make a template of that "preconfigured" freeBSD, so I can easily spin-up other VMs with the same settings/configs.

Thank you all!
 
That one development VM you planned, run stable/14 on it. That will get you all the new bells and whistles that will be included in the next minor release. It also will provide the opportunity to play around and build(7) from source. Leave the rest of your VMs on -RELEASE with a GENERIC kernel for easy maintenance.
 
But why do you want to disable IPv6 and USB so thoroughly? My suggestion would be: Put your FreeBSD machine on a network that has no IPv6 traffic, and never plug any USB devices in, and a generic kernel will work perfectly fine.
 
There is a kernel called MINIMAL. Copy it and add what additional features/devices you need.
Actually (with NetBSD) I take the opposite approach: I start with "ALL" -- which won't build -- and remove the things that I don't need.

I find this preferable because I don't later discover that I forgot to ADD something to a smaller kernel. It also lets me see all of the things enumerated so I have a chance to ask myself if I might need any of them.
 
Actually (with NetBSD) I take the opposite approach: I start with "ALL" -- which won't build -- and remove the things that I don't need.

I find this preferable because I don't later discover that I forgot to ADD something to a smaller kernel. It also lets me see all of the things enumerated so I have a chance to ask myself if I might need any of them.
That's another way of doing it.

My kernel config includes generic through an include statement followed by nodevice and nooptions statements, with additional statements for options I need. A baseline kernel for all my systems, with kernel modules loaded for differences of each. Different approach to achieve the same objective.
 
Different approach to achieve the same objective.
Yes. I try to build ONE kernel that will run on the various boxes that I have, here. So, I have to pay particular attention to which drivers to include ("which NIC is installed in Yogi? And, what about BooBoo? Which HBAs in Pinky? How many spindles in Felix?")

So, I annotate the original "ALL" configuration file with notes to remind me about where each driver/device is needed so I don't forget to include it in the next kernel iteration. (It's REALLY annoying to install a new kernel on N machines and then discover that the N+1th won't run with it and all of that work was wasted)
 
I found that building up MINIMAL to something workable is real work. I don't remember, it might have been for PXE/NFS boot.
 
Back
Top