I have been working on trying to build a kernel, but as this is my first ever attempt, I don't really know what I am doing. I have looked at some documentation and have been inside menuconfig, but I don't know which items to include and whether they should be built as modules or not. The two scenarios are:

1. Trying to build a kernel for a Crux install in Virtualbox, and
2. Figuring out what I need to build a kernel on a laptop.

I believe that laptops (in my case a Dell Vostro 3350) use IDE rather than SATA, so I would need to remember to include IDE when I build a kernel, but as to whether it should be built as a module or not, I haven't a clue. Likewise ethernet and wireless NIC, bluetooth, USB, my laptop also has a card reader (is that IDE?).

Likewise, Virtualbox emulates specific hardware, but how much of that needs to be configured in menuconfig, and what are the specs? I think you get the idea. Any help is appreciated.

I think you need to learn a lot about that....
In general there are 3 cases:
1. the driver (of a given device) is not required, not in use - in this case you can drop that functionality.
2. the device is built into the box therefore the driver needs unconditionally - in that case you can build that module into the kernel
3. the given device is sometimes there, but sometimes not (like a pendrive), therefore sometimes you need the module, sometimes not. In this case you will build the driver as module.
modules requires "more" work to be able to use, but built-in drivers cannot be unloaded, so probably they require more space...

1 members found this post helpful.

You want to make extensive use of kernel help. Kernel help is unlike any other help system that you have seen before! It not only tells you what each option means but often whether you need it or not. It tells you things like "If in doubt say yes" or "You only need this if you have such-and-such a device on your computer" or even "If you don't know what this means, you don't need it!" You can get help at any point by typing "h".

The other main rule is not to switch off anything unless you know what it is. The section you can cut most out of is the drivers section, because you don't need drivers for hardware that you don't have.

If you are not using an initrd, make sure you have built-in drivers (not modules) for your hard drive (PATA/SATA) and your root filesystem.

The command "make defconfig" will give you a starting .config file with sensible defaults.

1 members found this post helpful.

Why now download buildroot from git and build that? This gives you a full bootloader, kernel, and RFS.

1 members found this post helpful.

The "Gentoo" distribution is built on source code.

The "LFS = Linux From Scratch" project leads you through doing exactly what its name says.

While you are learning the process, I would suggest using a VM.

A pragmatic way to guess what modules may be required is to boot up a "rescue DVD" and notice what modules it selected.

Distros use an "initial RAMdisk' process in order to run device-discovery scripts, and package nearly everything as modules because they don't know what hardware they will find themselves running on. If you do know, you can custom-build a kernel with exactly the support you need, and eliminate that step entirely. I build filesystem support and fixed-hardware support into the kernel and use modules for removables.

The kernel configuration is kept in a hidden file. I make regular backup copies of (a not-hidden copy) of that file with every change. A version-control system such as git can also be used. It is very important to have known copies of every configuration that you ever made, and to reliably diff between them.

1 members found this post helpful.

Most people copy the hidden .config file into /boot as config-x.y.z to match /boot/vmlinuz-x.y.z. Then, when the time comes to upgrade your kernel, you can copy that file back as .config to provide a starting point for your next build.

1 members found this post helpful.

These days compiling your own kernel can be daunting. To configure a truly optimized kernel you must know a lot about how the kernel options work. The help for each setting is usually inadequate for a beginner, except when it explicitly tells you what to do.

Certain options will break the build on certain distros. Debian keeps oscillating between different build methods, preferring that PC users not compile their own kernel. And nowadays it's rarely necessary. Performance improvements are minimal. But the possible detriment to performance is extreme. If I was to compile the 4.14 kernel, I would concentrate on just disabling what is unnecessary, like device drivers.

On a laptop that works better, because for the most part the devices are not going to change. In a desktop you might add adapter cards to the system. Some people use to compile everything they needed to boot into the kernel (not modules) so they could get by without initrd. But for a PC of today that might be tricky.

Just make sure the kernel you are working on is not the only kernel on the system, and that you know how to switch kernels at boot time. Then, just mess around to your heart's content.

1 members found this post helpful.

Most stock kernels are optimised for the distro they belong to, and users are increasingly discouraged from "rolling their own". You might very well take out an option that some other piece of installed software depends on. But the OP wants to use Crux and that doesn't come with a stock kernel.

@OP: the IDE/SATA distinction is history as far as modern kernels are concerned. The old IDE driver has long been deprecated; instead you use the PATA/SATA driver, which works similarly on both types and treats everything as scsi. That's why modern hard drives are all called sd**, not hd**.

1 members found this post helpful.

Yeah, I was using Gentoo on an old machine, and with Gentoo everything is compiled-to-order using settings files which you arrange according to your hardware. I used it to take a machine that was sold with Windows-95 ... when that was the latest thing ... and to turn that machine into something that was positively quick, at least for its day. From power-on to desktop in six seconds flat. It became a bit of a game. Everything was precisely customized to what I knew that machine possessed, and nothing else.

(uptime was also a bit of a game. Once I left the machine running for a full year without turning it off. Before it finally blew a piston, I was using it as a graphics-rendering slave.)

Distro binary-package builders, although they do not use "exotic" processor-specific build options, do keep up with the times. Building a package from source code can take a long time and it must be done with very careful consideration of "everything else." All of which these folks undertake to do for you, and do very well. It is generally wise to just let them do it.

But I also will say this: "LFS = Linux From Scratch" is a very educational learning experiment, and Virtual Machines make it much easier to do than it was when I first did it. If you really, really want to know just how Linux operates, and are willing to invest the ... ... ... ... learning-time, you will learn a lot.

(In fact, I've been thinking about doing it a second time, just to see what's changed.)

And, if you want the best possible performance that your hardware can give you, and don't mind lengthy compile-times and a learning curve, Gentoo is also an excellent distribution.