@dr__Dan, there is no documentation like this in Fatdog's help so far, because nobody ever asked for it. We're slow and lazy, and only write stuff when people ask for it
@wognath, here are the next steps.
What you want to create in the end is:
A. vmlinuz (the kernel)
B. kernel-modules.sfs (containing kernel modules, firmware, and a few other tools).
(A) is easy. Just run make bzImage
(or any of its variants like make -j4 bzImage
), and you will find this file: arch/x86/boot/bzImage
. That "bzImage" is actually vmlinuz. All you need to do is rename it (from bzImage to vmlinuz).
(B) is a bit more complicated. Roughly speaking, the process is like this:
1. Collecting all the kernel modules.
2. Generating the modules dependency order.
3. Collecting the related firmware.
4. Building additional aufs tools (optional)
5. Building external kernel modules (modules which aren't included with the kernel source, e.g. the "wl" broadcom drivers, and many other Realtek-chip based wifis, etc). (also optional)
6. Making an SFS out of it.
(4) and (5) are optional, so we'll skip it for now. We'll focus on 1 - 3, and then 6.
(1). You can do this by running make modules_install INSTALL_MOD_PATH=modules
By doing this, you're installing the modules in a directory named "modules"
under the kernel source. You can of course point it elsewhere, e.g. INSTALL_MOD_PATH=/path/to/somewhere
, it's really up to you. But whatever directory you choose, you have to remember it, because you will have to use the same directory. For simplicity, it's best to stick with the example.
(2). This is done by running the command depmod -a -b "modules" KERNEL_VERSION
where KERNEL_VERSION represents the kernel of the version you're building (e.g. 4.19.5, etc), while "modules"
is the directory where you installed the modules in step (1) above.
If you forget to do this, the kernel wouldn't be able to load any kernel modules later.
(3). Now, this step is a bit of an art. There is no way to know exactly what firmware are used by the kernel. There are some hints and rule of thumbs - but they are just that, hints. As in, they don't always work. So I will leave them for later.
Instead, the best way to collect the firmware, is to use an existing collection. Get it from existing kernel-modules.sfs whose version is closest to the kernel version that you're building.
Firmware usage normally stays the same for all kernel series, e.g. almost all of 4.19.x kernels will use the same collection, so you can use the same firmware as the one you can find on an existing kernel-modules.sfs for 4.19.x kernels. If you can't find 4.19.x collection, then you can try 4.18.x or 4.17.x or even 5.0.x or 5.1.x.
Once you find this, copy the lib/firmware
directory inside the SFS you find, to module/lib/firmware
in your module directory (where again, "module"
represents the path, so if in step (1) you decided to put it to /path/to/somewhere
, the firmware path would be in /path/to/somewhere/lib/firmware
).
If later it turns out that you're missing some firmware, you can always add them manually, and re-generate the kernel-modules.sfs - which is the next and final step.
(6). Finally, you can now generate the kernel-modules.sfs by running dir2sfs modules
. This will create modules.sfs
, which you can rename to kernel-modules.sfs
. If you're in system where "dir2sfs" command doesn't exist, you can do it by using mksquashfs directly: mksquashfs modules kernel-modules.sfs -noappend -comp xz
.
That's it!
There is one step which I purposely omit: that's the kernel signing step. This is only necessary if you want the kernel to run with secure boot and UEFI. If you're building only for BIOS systems, or for UEFI without secure boot, you don't need to care about this.
PS: All the commands I give above, is to be run from inside the kernel build directory.
Good luck.