Operating Systems Lab Practical-02

 

Practical: 2 

Title: Study of Linux kernel configuration

While we talked before about kernel compilation and configuration, we focused on the general idea. This time we want to dig deeper into the configuration part, giving you useful advice you will need when tailoring a kernel to perfectly match your hardware.

The main idea behind this is that you will need to know your hardware extremely well in order to have a kernel built exactly for it. At the beginning we will cover what you will need in order to compile your kernel and after that we move into Linux kernel configuration, compilation and installation.

Software Requirements and Linux Command Line Conventions

Download Linux kernel source code

To get started, we will download the Linux source code from GitHub. This can be done with the following git command.

$ git clone https://github.com/torvalds/linux.git

Getting to know your hardware

To get some information about the hardware on your system, you can use the lspci command.

$ sudo lspci -vv > lspcioutput

This creates a file named lspcioutput (change the name if you want, of course) and fills it with the info from the command lspci, ran verbosely for more details. Open the created file with your favorite editor and keep it handy. Read it all to get a general idea about your hardware components.

How to configure the Linux kernel

We said earlier that we’ll describe our method: well, here it is. We use the distribution’s configuration, of course if we see it works with our hardware, which usually happens, since we have nothing exotic.

There should be a file config-5.13.0-27-generic inside your /boot directory, although the exact file name will likely be different, since it changes with each new Linux kernel version. We can simply copy this into our cloned Linux kernel directory’s .config file, which in our case is ~/linux/.config.

1. Adapt the following command to use your own paths and file names.

$ cp /boot/config-5.13.0-27-generic ~/linux/.config/.config

Use the version that’s as close version-wise as possible to the kernel you’re about to compile. Thus you will ensure that you’ll get no compatibility issues.

2. If you want to just use the config file as it is, just issue:

$ make oldconfig

Then, proceed with the compilation. However, we don’t want that, so we will just execute this command:

$ make menuconfig

3. You will see a curses-based, easy to use menu. Go to “Load an alternate configuration file” and enter the name of your config file (.config, in our example, and recommended). You can now proceed to alter options and save the configuration file in the end.Linux kernel configuration menu

4. In “General setup” we usually leave things as they are, but you, of course, are free to change anything you like. The usual warning applies : do not change what you don’t know. Remember that this type of configuration is dependency-based : if you disable/enable an item, those items that depend on it will also be affected. So, for example, if you disable networking, all network-related options will also be disabled automatically.

5. “Processor type and features” must be altered to reflect your target processor : we have an AMD K8-based CPU, so we selected “Processor family -> Opteron/Athlon64/Hammer/K8”.

6. In “Networking support”, since this is a desktop/workstation with a simple Ethernet connection, we disabled Amateur Radio, Infrared, Bluetooth, Wireless and other options that don’t apply. Of course your mileage may and will vary. Remember that each item has an associated Help menu, accessible through the “Help” button in the bottom part of the screen, and you’ll find out what the driver does, what hardware coverage it does have, etc.

7. Going further to “Device drivers”, here you’ll probably have a lot to disable, since here is the bulk of the hardware drivers that Linux supports. Keep the hardware configuration sheet handy and make sane choices. If at first your new kernel doesn’t boot, boot a working kernel (set your boot loader’s timeout to something like 10 seconds so you can have time to choose) and see what went wrong. Use the in-tree documentation and the Internet.

8. Going further to “Kernel hacking”, if you want to be(come) a kernel developer, here you’ll find options to help you isolate and document bugs. Otherwise, leave these as they are, as debugging options tend to bloat and slow down your system.

9. After you’re through, select “Save an alternate configuration file” and enter .config (recommended again), then Exit. You are now ready to compile your kernel. A last word of advice, though: start by playing it safe, then gradually eliminate unneeded drivers until you get a slim, working kernel. It’s easier going from big to smaller than the other way around.

Building and installing Linux kernel

Now that we have our kernel configured with the proper options, we can move on to compiling it. As mentioned earlier, the process of compiling could take quite a while, depending on your system’s hardware.

1. Building the Linux kernel is actually the same on any system:

2. # make

This will build the kernel image you will install later. You can use -jn as a make argument, where n will be the number of CPU cores in your system + 1 in order to enable parallel building which, of course, will speed up the process.

3. This next step is also universal:

4. # make modules_install

5. On most distros, this next step will also be identical. On some others, such as Arch, you will be required to use cp instead of make. You will find every distro’s way to install a custom kernel online, or you’ll want to create a kernel package and simply install it with the usual package management tools. However it will be, remember that the distribution’s documentation takes precedence here.

6. # make install

7. And now…you have a fresh kernel installed, let’s test it! Reboot and select the new kernel for booting.

Troubleshooting bugs in your kernel

If you built a vanilla kernel and you find a bug, like some oops or panic, read the documentation (REPORTING-BUGS in the root of the kernel tree) and document your bug as thoroughly as possible. If it’s a distro-patched kernel, use that distro’s bug reporting tools, of course, and the maintainers will talk to upstream to solve the issue.