The make localmodconfig command is still the right tool for the job. In fact make localmodconfig runs scripts/kconfig/streamline_config.pl.
File input
When reading the streamline_config.pl (perl) source code, there is an undocumented feature my $lsmod_file = $ENV{'LSMOD'}; that allows file input for loaded module detection instead of the output from the lsmod command.
Live CD
Because localmodconfig uses the output lsmod to detect the loaded modules. We run a Ubuntu Live CD on each of the different hardware setups, open a terminal (Ctrl+Alt+T), run lsmod and save its output.
Concatenate output
By concatenating the lsmod output files while stripping consecutive headers lines you can quickly create an input file that covers all your required kernel modules. We like to review the module list by hand and use a more manual recipe:
$ cd linux-3.11.0/
or go the directory where you will run your make command
$ lsmod > lsmod.txt
creates a text file with your loaded modules
$ nano lsmod.txt
will open the nano text editor, of course you can use your favorite editor application
Append your desired modules that are not already there, to the bottom of this file (see for an example the bottom of this anwer), and save it when you are ready.
Note: use spaces not tabs to match the column tabulator positions.
$ make LSMOD="lsmod.txt" localmodconfig
this will tell localmodconfig to use your lsmod.txt file as input for loaded modules detection
With regards to Steven Rostedt - the author of steamline_config.pl - for suggesting a shorter notation in step 5.
Example for what to append and not append to lsmod.txt (step 4):
Because the Intel D33217CK main board has Intel thermal sensors that we would like to read, we append these lines:
x86_pkg_temp_thermal 13810 0
intel_powerclamp 14239 0
But we don't want to run virtual machines on this hardware, that is why we skip these lines:
kvm_intel 128218 0
kvm 364766 1 kvm_intel
tg3 152066 0
ptp 18156 1 tg3
pps_core 18546 1 ptp
We think we don't need volume mirroring, and therefor do not add:
dm_mirror 21715 0
dm_region_hash 15984 1 dm_mirror
dm_log 18072 2 dm_region_hash,dm_mirror
i915 589697 3
i2c_algo_bit 13197 1 i915
drm_kms_helper 46867 1 i915
drm 242354 4 i915,drm_kms_helper
r8169 61434 0
mii 13654 1 r8169
make-kpkg is a command from the package kernel-package, which used to be part of the official packaging infrastructure for the kernel packages that get shipped in the Debian distribution. It is not being used for that purpose anymore because the current maintainer for the kernel packages inside the Debian distribution chose to stop using it; however, the authors of the kernel-package package have not stopped maintaining it, so it is still an officially supported way of creating your own Debian packaged version of a kernel. It has various options and targets; the most important ones are the ones you refer to in your question, i.e., kernel-image (which builds a package containing the kernel and modules that you selected during make config), and kernel-headers (which contains the include files that you might need if you want to compile an out-of-tree module). The kernel-package package is maintained as part of the Debian (or derivative, like Ubuntu) release with which it was released, so as a result if things change in the Debian infrastructure then newer versions of kernel-package will be updated to incorporate it, and they will ship with that version of Debian. As a result, a kernel package created by the kernel-package package is always tailored best for the version of Debian on which it was created. However, if things change within the Linux kernel in a way that makes kernel-package break, then updating your kernel package for a stable version of Debian may be somewhat complicated.
make deb-pkg is a target in the Linux kernel's build infrastructure. It receives patches from Debian developers, but as it is not maintained within Debian itself, it always uses the tools and policies that are most up to date at the point in time where the kernel version you're trying to build was created. This means that in some cases, it might try to use a tool that isn't available on an older distribution yet. As it is not maintained inside Debian, it is not an officially-supported method (at least not from the point of view of Debian) for creating kernel packages; having said that though, it is mostly maintained by people who are involved in Debian, and so there is no reason to suspect that it won't work.
Whichever method you choose is just a matter of preference; unless you are heavily invested in peculiar outcomes of the package building options, both methods will work just fine.
Best Answer
From the top...
makecompiles and links the kernel image. This is a single file namedvmlinuz.make modulescompiles individual files for each question you answeredMduring kernel config. The object code is linked against your freshly built kernel. (For questions answeredY, these are already part ofvmlinuz, and for questions answeredNthey are skipped).make installinstalls your built kernel to/vmlinuz.make modules_installinstalls your kernel modules to/lib/modulesor/lib/modules/<version>.As for adding it to the list of available kernels, that's taken care of by the boot loader. It's different for each boot loader, but
grubis the most common on x86 and amd64 so I'll describe that. It's actually quite simple. Grub looks in/,/bootand/lib/modulesfor any thing that looks like it might be a working kernel and adds it. And yes, this is an oversimplified description.That extra "horrible stuff" in the Ubuntu documentation is extra stuff to create a
debpackage. When you're doing it for more than yourself it's far better to package it. You'll switch in time.Building the kernel and modules is kept separate because for the people who need to (i.e., kernel developers) they are often making changes to only a module. They can apply their changes, rebuild and install just the modules. This saves a lot of time when it has to be done 20 times a day. It will never be updated to have a single
make everythingcommand. You instead, runmake && make modules && make install && make modules_installjust like the documentation says to do. The build process favors kernel developers, not you. And that's the way it should be.In reality there's almost no reason for anybody except kernel developers or distro packagers to compile a kernel. In almost any circumstance the kernel feature you want has already been built for you and is available in one of the pre-packaged kernels. There are exceptions, but they are exceedingly rare these days.
Not that I'm discouraging you from doing building your own kernel, I actually encourage you to do it. I think building your kernel from scratch is an invaluable practice for learning about how it all works down there. In part, because maybe one day you will be the exception that needs to. But it also teaches you a lot about the kernel & boot process in general. You will be a better person for having done it.