Notes on building a kernel
First of all, why would you ever want to build a kernel? All binary Linux distros (and that means most distros) come with a ready-made "stock" kernel that will run on just about any type of hardware.
In the early days of Linux, many people built their own kernels because memory and disk space were both limited. It made sense to create a kernel that was lean and mean, that would contain drivers only for the hardware you actually had and no spare fat. Nowadays a stock kernel will run fast enough on any processor and there is plenty of space for the storage of modules. Moreover stock kernels are often optimised to run in the particular software environment that the distro provides. A home-made kernel might well not contain features that the distro developers assume to be present. So in general, the rule is to use the stock kernel and put up with the slowness with which it often loads.
Nevertheless there are source-based distros like Gentoo and Crux that expect you to build your own kernel. And of course you have to do this on Linux From Scratch. It would hardly be "from scratch" if you used a pre-existing kernel configuration. So here are a few useful guidelines if you find yourself in this kind of situation.
You will need the kernel source package and the basic build tools (which will automatically be present in any source-based distro). Unpack the source tarball in your home directory where you can work on it without needing to be root. Then cd to the new linux-x.y.z directory that has been created for you.
Next you will need a configuration file called ".config". If building for LFS, it is better not to use any configuration file that you might find in your host's /boot or in /proc directories. These contain the configuration for the host kernel, probably a stock kernel with loads of modules and not what you need at all. On the other hand, the config file from a previous kernel build, which you might have stored in /boot could be an ideal starting point; copy it over into the build directory under the name .config.
If you do not have a suitable initial configuration file, create one using the command make defconfig. This will create a default configuration file with sensible values and call it .config.
Now you need to call up the configuration menu. There are several commands that will do this. If you are building in an xterm or a text console, use make menuconfig. This gives you an ncurses-based pseudo-graphical menu which you can navigate with the arrow keys and tab. For a graphical menu that you can navigate with a mouse, use make xconfig in KDE or make gconfig in gnome or xfce.
The ncurses menu is ugly but serviceable. Paired square brackets at the left side indicate whether the option is included[*], excluded [ ] or built as a module [M]. You can cycle through the choices uses the space bar. But don't be surprised if some possibilities are not available. The menu has built-in checks for consistency: if feature A is dependent on feature B and you have opted to build B as a module, then A cannot be built in; it must be a module or nothing!
An arrow pointing right indicates a submenu. You can open it by pressing Enter. A line without an arrowhead indicates a potential submenu that is not active. It will become available only if you select that option. To get back to the higher level menu again, just hit Escape. Of course in a graphical menu, you will do all this by clicking on buttons!
At the bottom of the menu is a Help option or button. In menuconfig you activate it by tabbing to it or by pressing the H key at any time. I cannot praise the kernel help system too highly! It is a marvellous piece of work and you should use it as much as you can. Other help systems tell you what an option means; kernel help often tells you whether you should use it or not. It tells you things like "You only need this option if you have a GenSys frobnicator and want to use it" or "If you don't know what this is for, then you don't need it" or "If in doubt, say yes".
A few general rules for configuration:
1) Don't alter anything that you don't understand.
2) In the Drivers section, you can often do a lot of pruning. Don't build drivers for hardware that you don't have.
3) Make sure you build in the driver for your root filesystem (usually ext4). Don't build it as a module or your kernel will not boot without an initramfs. If booting from the hard drive, build in the PATA/SATA disk driver as well. If from a pen drive, make sure you build in USB storage.
4) If you have a network card that needs to have firmware loaded onto it (not unusual in wifi cards), build the driver as a module. Otherwise, it is usually safe to build it in.
5) Don't use deprecated or experimental features unless you know what you are doing.
Once you have configured the new kernel to your satisfaction, press Escape until you are asked whether to save your configuration. Say "Yes". Now you can carry out the build. Just type make . Then go away and make yourself a cup of tea. Building a kernel takes a long time.
To install your kernel when it is built requires two main operations. You must copy the main image into your boot directory where the bootloader can find it, and install the modules in /lib/modules. You must do this as root. Up till now you have been working as an unprivileged user but now you must use either su or sudo. I will use sudo in these instructions.
sudo cp arch/x86/boot/bzImage /boot/vmlinuz-x.y.z-whatever
sudo make modules_install
sudo cp .config /boot/config-x.y.z
sudo cp System.map /boot/System.map
The last two commands are not strictly necessary, but there are programs that like to have the kernel's system map to hand and /boot is the place to store it. Storing the configuration file somewhere safe is essential if your kernel does not boot first time. You will need to tweak it; you don't want to have to start again from zero!
Now fix your bootloader to boot that new kernel. How you do that is outside the scope of these instructions.
Don't be too upset if your new kernel panics, especially if it's the first one you ever built. Check whether you had the disk and filesystem drivers built in. Ask for help if necessary. To rebuild, enter the build directory and use the command make mrproper. This will clear all the built files out of the directory. It will also delete your .config file, so make sure you have a saved copy in /boot or elsewhere to copy back. Then try again and hope it works this time.
Note that as the kernel version is still the same, you will need to delete or rename the /lib/modules/x.y.z directory that you previously created before using make modules_install for the second time.
I assure you, there's no thrill like seeing your personally configured kernel boot for the first time.
In the early days of Linux, many people built their own kernels because memory and disk space were both limited. It made sense to create a kernel that was lean and mean, that would contain drivers only for the hardware you actually had and no spare fat. Nowadays a stock kernel will run fast enough on any processor and there is plenty of space for the storage of modules. Moreover stock kernels are often optimised to run in the particular software environment that the distro provides. A home-made kernel might well not contain features that the distro developers assume to be present. So in general, the rule is to use the stock kernel and put up with the slowness with which it often loads.
Nevertheless there are source-based distros like Gentoo and Crux that expect you to build your own kernel. And of course you have to do this on Linux From Scratch. It would hardly be "from scratch" if you used a pre-existing kernel configuration. So here are a few useful guidelines if you find yourself in this kind of situation.
You will need the kernel source package and the basic build tools (which will automatically be present in any source-based distro). Unpack the source tarball in your home directory where you can work on it without needing to be root. Then cd to the new linux-x.y.z directory that has been created for you.
Next you will need a configuration file called ".config". If building for LFS, it is better not to use any configuration file that you might find in your host's /boot or in /proc directories. These contain the configuration for the host kernel, probably a stock kernel with loads of modules and not what you need at all. On the other hand, the config file from a previous kernel build, which you might have stored in /boot could be an ideal starting point; copy it over into the build directory under the name .config.
If you do not have a suitable initial configuration file, create one using the command make defconfig. This will create a default configuration file with sensible values and call it .config.
Now you need to call up the configuration menu. There are several commands that will do this. If you are building in an xterm or a text console, use make menuconfig. This gives you an ncurses-based pseudo-graphical menu which you can navigate with the arrow keys and tab. For a graphical menu that you can navigate with a mouse, use make xconfig in KDE or make gconfig in gnome or xfce.
The ncurses menu is ugly but serviceable. Paired square brackets at the left side indicate whether the option is included[*], excluded [ ] or built as a module [M]. You can cycle through the choices uses the space bar. But don't be surprised if some possibilities are not available. The menu has built-in checks for consistency: if feature A is dependent on feature B and you have opted to build B as a module, then A cannot be built in; it must be a module or nothing!
An arrow pointing right indicates a submenu. You can open it by pressing Enter. A line without an arrowhead indicates a potential submenu that is not active. It will become available only if you select that option. To get back to the higher level menu again, just hit Escape. Of course in a graphical menu, you will do all this by clicking on buttons!
At the bottom of the menu is a Help option or button. In menuconfig you activate it by tabbing to it or by pressing the H key at any time. I cannot praise the kernel help system too highly! It is a marvellous piece of work and you should use it as much as you can. Other help systems tell you what an option means; kernel help often tells you whether you should use it or not. It tells you things like "You only need this option if you have a GenSys frobnicator and want to use it" or "If you don't know what this is for, then you don't need it" or "If in doubt, say yes".
A few general rules for configuration:
1) Don't alter anything that you don't understand.
2) In the Drivers section, you can often do a lot of pruning. Don't build drivers for hardware that you don't have.
3) Make sure you build in the driver for your root filesystem (usually ext4). Don't build it as a module or your kernel will not boot without an initramfs. If booting from the hard drive, build in the PATA/SATA disk driver as well. If from a pen drive, make sure you build in USB storage.
4) If you have a network card that needs to have firmware loaded onto it (not unusual in wifi cards), build the driver as a module. Otherwise, it is usually safe to build it in.
5) Don't use deprecated or experimental features unless you know what you are doing.
Once you have configured the new kernel to your satisfaction, press Escape until you are asked whether to save your configuration. Say "Yes". Now you can carry out the build. Just type make . Then go away and make yourself a cup of tea. Building a kernel takes a long time.
To install your kernel when it is built requires two main operations. You must copy the main image into your boot directory where the bootloader can find it, and install the modules in /lib/modules. You must do this as root. Up till now you have been working as an unprivileged user but now you must use either su or sudo. I will use sudo in these instructions.
sudo cp arch/x86/boot/bzImage /boot/vmlinuz-x.y.z-whatever
sudo make modules_install
sudo cp .config /boot/config-x.y.z
sudo cp System.map /boot/System.map
The last two commands are not strictly necessary, but there are programs that like to have the kernel's system map to hand and /boot is the place to store it. Storing the configuration file somewhere safe is essential if your kernel does not boot first time. You will need to tweak it; you don't want to have to start again from zero!
Now fix your bootloader to boot that new kernel. How you do that is outside the scope of these instructions.
Don't be too upset if your new kernel panics, especially if it's the first one you ever built. Check whether you had the disk and filesystem drivers built in. Ask for help if necessary. To rebuild, enter the build directory and use the command make mrproper. This will clear all the built files out of the directory. It will also delete your .config file, so make sure you have a saved copy in /boot or elsewhere to copy back. Then try again and hope it works this time.
Note that as the kernel version is still the same, you will need to delete or rename the /lib/modules/x.y.z directory that you previously created before using make modules_install for the second time.
I assure you, there's no thrill like seeing your personally configured kernel boot for the first time.
Total Comments 0
