Difference between pages "Linux Fundamentals, Part 2" and "Building a Kernel from Source"

(Difference between pages)
m (Undo revision 9861 by 222.175.249.136 (talk))
 
m (Option one: Initrd with dracut)
 
Line 1: Line 1:
== Before You Start ==
+
Setting up a proper kernel yourself - lean, mean and tailored to your hardware,  is the challenge by which a linux user can graduate to becoming a Funtoo knight ;-)
  
=== About this tutorial ===
+
Even though many of us are using enterprise-ready kernels in datacenters, there is almost nobody who hasn't at least considered building a kernel for his laptop / PC.
Welcome to "Basic administration," the second of four tutorials designed to prepare you for the Linux Professional Institute's 101 exam. In this tutorial, we'll show you how to use regular expressions to search files for text patterns. Next, we'll introduce you to the Filesystem Hierarchy Standard (FHS), and then show you how to locate files on your system. Then, we'll show you how to take full control of Linux processes by running them in the background, listing processes, detaching processes from the terminal, and more. Next, we'll give you a whirlwind introduction to shell pipelines, redirection, and text processing commands. Finally, we'll introduce you to Linux kernel modules.
+
We are showing here how an intermediate Linux user can use an alternative to the standard beginners "genkernel" approach, to compile a custom kernel, in a relatively still speedy and easy set up.
  
This particular tutorial (Part 2) is ideal for those who have a good basic knowledge of bash and want to receive a solid introduction to basic Linux administration tasks. If you are new to Linux, we recommend that you complete [[Linux Fundamentals, Part 1|Part 1]] of this tutorial series first before continuing. For some, much of this material will be new, but more experienced Linux users may find this tutorial to be a great way of "rounding out" their basic Linux administration skills.
+
=== Minimum Requirements ===
 +
You should understand the way how things work in a terminal and how to use an editor and tweak config files. This is crucial.
 +
You don't need much knowledge about the linux kernel and it's internals. Nevertheless, you have to know at least where the files are located, how they are used and what is the file logic behind the overall structure. Otherwise you should consider using a non source based linux distribution.
 +
If you are scared now, don't worry - we are going to build a kernel the Funtoo way and you will pick up everthing necessary to accomplish this challenge, step by step, so the next time you do it yourself and become a real Funtoo knight!
  
For those who have taken the release 1 version of this tutorial for reasons other than LPI exam preparation, you probably don't need to take this one. However, if you do plan to take the exams, you should strongly consider reading this revised tutorial.
+
=== Assumptions ===
 +
You start from an installed Funtoo system on the disk, or at least, you are on stage3 in a chrooted environment from a live cd, following somehow the Funto [[Installation (Tutorial)|Installation Tutorial]].
  
== Regular Expressions ==
+
In this case we are building a kernel that is booting root in LVM over encrypted LUKS container.
 +
If you don't have this setup, don't worry, you just don't need all the modules, but everything else is similar.
  
=== What is a regular expression? ===
 
A regular expression (also called a "regex" or "regexp") is a special syntax used to describe text patterns. On Linux systems, regular expressions are commonly used to find patterns of text, as well as to perform search-and-replace operations on text streams.
 
  
=== Glob comparison ===
+
= Getting everything in order to start =
As we take a look at regular expressions, you may find that regular expression syntax looks similar to the filename "globbing" syntax that we looked at in Part 1. However, don't let this fool you; their similarity is only skin deep. Both regular expressions and filename globbing patterns, while they may look similar, are fundamentally different beasts.
+
  
=== The simple substring ===
+
First there is the decision which linux kernel sources we need.
With that caution, let's take a look at the most basic of regular expressions, the simple substring. To do this, we're going to use <span style="color:green">grep</span>, a command that scans the contents of a file for a particular regular expression. <span style="color:green">grep</span> prints every line that matches the regular expression, and ignores every line that doesn't:
+
There are plenty of them in the repositories around, often it is not easy to distinguish between them.
<pre>
+
$ grep bash /etc/passwd
+
operator:x:11:0:operator:/root:/bin/bash
+
root:x:0:0::/root:/bin/bash
+
ftp:x:40:1::/home/ftp:/bin/bash
+
</pre>
+
Above, the first parameter to <span style="color:green">grep</span> is a regex; the second is a filename. <span style="color:green">grep</span> read each line in /etc/passwd and applied the simple substring regex bash to it, looking for a match. If a match was found, <span style="color:green">grep</span> printed out the entire line; otherwise, the line was ignored.
+
  
=== Understanding the simple substring ===
+
I would always trust my distribution of choice and take what is has to offer - and funtoo has a lot to offer!
In general, if you are searching for a substring, you can just specify the text verbatim without supplying any "special" characters. The only time you'd need to do anything special would be if your substring contained a +, ., *, [, ], or \, in which case these characters would need to be enclosed in quotes and preceded by a backslash. Here are a few more examples of simple substring regular expressions:
+
  
* /tmp (scans for the literal string /tmp)
+
I really do recommend (especially if it is your first time) to build a debian-sourced genkernel like described in chapter 5 "Using Debian-Sources with Genkernel" in the [[Funtoo_Linux_Kernels| Funtoo Kernels Tutorial]].
* "\[box\]" (scans for the literal string [box])
+
* "\*funny\*" (scans for the literal string *funny*)
+
* "ld\.so" (scans for the literal string ld.so)
+
  
=== Metacharacters ===
+
From there you should have a running system booting nicely from your own build (just little bit bloated) kernel. This is more than you can expect from any other ready to go distribution.
With regular expressions, you can perform much more complex searches than the examples we've looked at so far by taking advantage of metacharacters. One of these metacharacters is the . (a period), which matches any single character:
+
<pre>
+
$ grep dev.sda /etc/fstab
+
/dev/sda3      /              reiserfs        noatime,ro 1 1
+
/dev/sda1      /boot          reiserfs        noauto,noatime,notail 1 2
+
/dev/sda2      swap            swap            sw 0 0
+
#/dev/sda4      /mnt/extra      reiserfs        noatime,rw 1 1
+
</pre>
+
In this example, the literal text dev.sda didn't appear on any of the lines in /etc/fstab. However, grep wasn't scanning them for the literal dev.sda string, but for the dev.sda pattern. Remember that the . will match any single character. As you can see, the . metacharacter is functionally equivalent to how the ? metacharacter works in "glob" expansions.
+
  
=== Using [] ===
+
{{Note}} We are using RedHat's dracut in order to build a nice initramfs (containing all the necessary tools and extra drivers our kernel might need to start the system). Although dracut is the way to go, more sophisticated and not as buggy as gentoo's genkernel approach, more and more funtoo geeks start using slashbeast's better-initramfs, which we will cover at the end of this howto! So after having set up a genkernel from debian or gentoo sources we are going to build a kernel with either (or both) dracut or/and better-initramfs. So gentoo sources with genkernel is always my backup if anything is not working correctly on my system. For the slightly more geeky approach with my own initram I am using pf-sources, ck-sources or any other more or less heavily patched sources.
If we wanted to match a character a bit more specifically than ., we could use [ and ] (square brackets) to specify a subset of characters that should be matched:
+
<pre>
+
$ grep dev.sda[12] /etc/fstab
+
/dev/sda1      /boot          reiserfs        noauto,noatime,notail 1 2
+
/dev/sda2      swap            swap            sw 0 0
+
</pre>
+
As you can see, this particular syntactical feature works identically to the [] in "glob" filename expansions. Again, this is one of the tricky things about learning regular expressions -- the syntax is similar but not identical to "glob" filename expansion syntax, which often makes regexes a bit confusing to learn.
+
  
=== Using [^] ===
+
Let's go!
You can reverse the meaning of the square brackets by putting a ^ immediately after the [. In this case, the brackets will match any character that is not listed inside the brackets. Again, note that we use [^] with regular expressions, but [!] with globs:
+
<pre>
+
$ grep dev.sda[^12] /etc/fstab
+
/dev/sda3      /              reiserfs        noatime,ro 1 1
+
#/dev/sda4      /mnt/extra      reiserfs        noatime,rw 1 1
+
</pre>
+
  
=== Differing syntax ===
+
== Kernel Sources ==
It's important to note that the syntax inside square brackets is fundamentally different from that in other parts of the regular expression. For example, if you put a . inside square brackets, it allows the square brackets to match a literal ., just like the 1 and 2 in the examples above. In comparison, a literal . outside the square brackets is interpreted as a metacharacter unless prefixed by a \. We can take advantage of this fact to print a list of all lines in '''/etc/fstab''' that contain the literal string dev.sda by typing:
+
We are going to use the kernel sources from the funtoo git repository.
<pre>
+
$ grep dev[.]sda /etc/fstab
+
</pre>
+
Alternately, we could also type:
+
<pre>
+
$ grep "dev\.sda" /etc/fstab
+
</pre>
+
Neither regular expression is likely to match any lines in your '''/etc/fstab''' file.
+
  
=== The "*" metacharacter ===
+
The source you use on your system is up to you and your needs.
Some metacharacters don't match anything in themselves, but instead modify the meaning of a previous character. One such metacharacter is * (asterisk), which is used to match zero or more repeated occurrences of the previous character. Note that this means that the * has a different meaning in a regex than it does with globs. Here are some examples, and play close attention to instances where these regex matches differ from globs:
+
For a laptop or desktop system, we recommend the following:
  
* ab*c matches abbbbc but not abqc (if a glob, it would match both strings -- can you figure out why?)
+
* '''sys-kernel/pf-sources'''
* ab*c matches abc but not abbqbbc (again, if a glob, it would match both strings)
+
* '''sys-kernel/ck-sources'''
* ab*c matches ac but not cba (if a glob, ac would not be matched, nor would cba)
+
* '''sys-kernel/gentoo-sources'''
* b[cq]*e matches bqe and be (if a glob, it would match bqe but not be)
+
* '''sys-kernel/git-sources'''
* b[cq]*e matches bccqqe but not bccc (if a glob, it would match the first but not the second as well)
+
* '''sys-kernel/sysrescue-std-sources'''
* b[cq]*e matches bqqcce but not cqe (if a glob, it would match the first but not the second as well)
+
* '''sys-kernel/debian-sources'''
* b[cq]*e doesn't match bbbeee (this would not be the case with a glob)
+
* .* will match any string. (if a glob, it would match any string starting with .)
+
* foo.* will match any string that begins with foo (if a glob, it would match any string starting with the four literal characters foo..)
+
  
Now, for a quick brain-twisting review: the line ac matches the regex ab*c because the asterisk also allows the preceding expression (b) to appear zero times. Again, it's critical to note that the * regex metacharacter is interpreted in a fundamentally different way than the * glob character.
+
Please, have a look in the ebuild description, look onto their homepage and take the one that suits you best!
 +
If you are unsure for now, use sys-kernel/gentoo-sources. That's always a safe bet for a general system.
  
=== Beginning and end of line ===
+
It is not a problem to have various kernels installed parallel, so go on with any one of them.
The last metacharacters we will cover in detail here are the ^ and $ metacharacters, used to match the beginning and end of line, respectively. By using a ^ at the beginning of your regex, you can cause your pattern to be "anchored" to the start of the line. In the following example, we use the ^# regex to match any line beginning with the # character:
+
<pre>
+
$ grep ^# /etc/fstab
+
# /etc/fstab: static file system information.
+
#
+
</pre>
+
  
=== Full-line regexes ===
+
I am going to use the sys-kernel/pf-sources now, as I already had the gentoo-sources installed.
^ and $ can be combined to match an entire line. For example, the following regex will match a line that starts with the # character and ends with the . character, with any number of other characters in between:
+
<pre>
+
$ grep '^#.*\.$' /etc/fstab
+
# /etc/fstab: static file system information.
+
</pre>
+
In the above example, we surrounded our regular expression with single quotes to prevent $ from being interpreted by the shell. Without the single quotes, the $ will disappear from our regex before grep even has a chance to take a look at it.
+
  
== FHS and finding files ==
+
== Prerequisites ==
  
=== Filesystem Hierarchy Standard ===
+
I don't know which tools you have already installed, so some information here might be redundant.
The Filesystem Hierarchy Standard is a document that specifies the layout of directories on a Linux system. The FHS was devised to provide a common layout to simplify distribution-independent software development -- so that stuff is in generally the same place across Linux distributions. The FHS specifies the following directory tree (taken directly from the FHS specification):
+
It doesn't harm to just copy and paste and do some steps again.
  
* / (the root directory)
+
First, we look into our <code>/etc/make.conf</code>:
* /boot (static files of the boot loader)
+
* /dev (device files)
+
* /etc (host-specific system configuration)
+
* /lib (essential shared libraries and kernel modules)
+
* /mnt (mount point for mounting a filesystem temporarily)
+
* /opt (add-on application software packages)
+
* /sbin (essential system binaries)
+
* /tmp (temporary files)
+
* /usr (secondary hierarchy)
+
* /var (variable data)
+
  
=== The two independent FHS categories ===
+
<console>
The FHS bases its layout specification on the idea that there are two independent categories of files: shareable vs. unshareable, and variable vs. static. Shareable data can be shared between hosts; unshareable data is specific to a given host (such as configuration files). Variable data can be modified; static data is not modified (except at system installation and maintenance).
+
###i## nano /etc/make.conf
 +
#These compiler flags are just tweaking (optimazation) and NOT necessary:
 +
CFLAGS="-O2 -pipe -march=native -ftracer -fforce-addr"
 +
CXXFLAGS="${CFLAGS} -fpermissive -fomit-frame-pointer"
 +
KDIR=/usr/src/linux
 +
KERNEL="symlink build"
 +
USE="$KERNEL ....here are your use flags...."
 +
## These modules are available:
 +
## DRACUT_MODULES="dracut_modules_biosdevname dracut_modules_btrfs dracut_modules_caps dracut_modules_crypt dracut_modules_crypt-gpg dracut_modules_dmraid dracut_modules_dmsquash-live dracut_modules_gensplash dracut_modules_iscsi dracut_modules_livenet dracut_modules_lvm dracut_modules_mdraid dracut_modules_multipath dracut_modules_nbd dracut_modules_nfs dracut_modules_plymouth dracut_modules_ssh-client dracut_modules_syslog"
 +
## We will use these modules for LVM / LUKS:
 +
DRACUT_MODULES="crypt lvm plymouth biosdevname dmraid crypt-gpg dmsquash-live ssh-client syslog"
 +
</console>
  
The following grid summarizes the four possible combinations, with examples of directories that would fall into those categories. Again, this table is straight from the FHS specification:
+
Next, we set the package keywords:
<pre>
+
<console>
+---------+-----------------+-------------+
+
###i## nano /etc/portage/package.use/dracut
|        | shareable      | unshareable |
+
sys-kernel/dracut dm net device-mapper crypt lvm
+---------+-----------------+-------------+
+
</console>
|static  | /usr            | /etc       |
+
|        | /opt            | /boot      |
+
+---------+-----------------+-------------+
+
|variable | /var/mail      | /var/run    |
+
|        | /var/spool/news | /var/lock  |
+
+---------+-----------------+-------------+
+
</pre>
+
  
=== Secondary hierarchy at /usr ===
+
{{Note}} If you don't have lvm over encrypted LUKS you probably just add the "net" keyword here, or "selinux".
Under '''/usr''' you'll find a secondary hierarchy that looks a lot like the root filesystem. It isn't critical for '''/usr''' to exist when the machine powers up, so it can be shared on a network (shareable), or mounted from a CD-ROM (static). Most Linux setups don't make use of sharing '''/usr''', but it's valuable to understand the usefulness of distinguishing between the primary hierarchy at the root directory and the secondary hierarchy at '''/usr'''.
+
  
This is all we'll say about the Filesystem Hierarchy Standard. The document itself is quite readable, so you should go take a look at it. You'll understand a lot more about the Linux filesystem if you read it. Find it at http://www.pathname.com/fhs/.
 
  
=== Finding files ===
+
After that we are going to build our packages:
Linux systems often contain hundreds of thousands of files. Perhaps you are savvy enough to never lose track of any of them, but it's more likely that you will occasionally need help finding one. There are a few different tools on Linux for finding files. This introduction will help you choose the right tool for the job.
+
<console>
 +
###i## emerge -av app-portage/gentoolkit sys-kernel/pf-sources sys-kernel/dracut sys-boot/plymouth sys-boot/plymouth-openrc-plugin
 +
</console>
  
=== The PATH ===
+
Finished? Well, then let's go on and
When you run a program at the command line, bash actually searches through a list of directories to find the program you requested. For example, when you type ls, bash doesn't intrinsically know that the ls program lives in '''/usr/bin'''. Instead, bash refers to an environment variable called PATH, which is a colon-separated list of directories. We can examine the value of PATH:
+
<pre>
+
$ echo $PATH
+
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin
+
</pre>
+
Given this value of PATH (yours may differ,) bash would first check '''/usr/local/bin''', then '''/usr/bin''' for the ls program. Most likely, ls is kept in /usr/bin, so bash would stop at that point.
+
  
=== Modifying PATH ===
+
== Preparing the kernel ==
You can augment your PATH by assigning to it on the command line:
+
<pre>
+
$ PATH=$PATH:~/bin
+
$ echo $PATH
+
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/home/agriffis/bin
+
</pre>
+
You can also remove elements from PATH, although it isn't as easy since you can't refer to the existing $PATH. Your best bet is to simply type out the new PATH you want:
+
<pre>
+
$ PATH=/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:~/bin
+
$ echo $PATH
+
/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/agriffis/bin
+
</pre>
+
To make your PATH changes available to any future processes you start from this shell, export your changes using the export command:
+
<pre>
+
$ export PATH
+
</pre>
+
  
=== All about "which" ===
+
We go now to the sources directory and enter the following commands to update the kernel's .config  file:
You can check to see if there's a given program in your PATH by using <span style="color:green">which</span>. For example, here we find out that our Linux system has no (common) sense:
+
<console>
<pre>
+
###i## cd /usr/src/linux/
$ which sense
+
###i## make clean
which: no sense in (/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin)
+
  CLEAN  .
</pre>
+
  CLEAN  arch/x86/kernel/acpi/realmode
In this example, we successfully locate <span style="color:green">ls</span>:
+
  CLEAN  arch/x86/kernel/cpu
<pre>
+
  CLEAN  arch/x86/kernel
$ which ls
+
  CLEAN  arch/x86/vdso
/usr/bin/ls
+
  CLEAN  arch/x86/lib
</pre>
+
  CLEAN  drivers/gpu/drm/radeon
 +
  CLEAN  drivers/net/wan
 +
  CLEAN  drivers/scsi/aic7xxx
 +
  CLEAN  drivers/tty/vt
 +
  CLEAN  drivers/video/logo
 +
  CLEAN  firmware
 +
  CLEAN  kernel
 +
  CLEAN  lib/raid6
 +
  CLEAN  lib
 +
  CLEAN  security/apparmor
 +
  CLEAN  security/selinux
 +
  CLEAN  usr
 +
  CLEAN  arch/x86/boot/compressed
 +
  CLEAN  arch/x86/boot
 +
  CLEAN  .tmp_versions
 +
  CLEAN  vmlinux System.map .tmp_kallsyms2.S .tmp_kallsyms1.o .tmp_kallsyms2.o .tmp_kallsyms1.S .tmp_vmlinux1 .tmp_vmlinux2 .tmp_System.map
 +
###i## zcat /proc/config.gz > /usr/src/linux/.config
 +
</console>
  
=== "which -a" ===
+
<console>
Finally, you should be aware of the <span style="color:green">-a</span> flag, which causes <span style="color:green">which</span> to show you all of the instances of a given program in your PATH:
+
###i## make localmodconfig
<pre>
+
</console>
$ which -a ls
+
/usr/bin/ls
+
/bin/ls
+
</pre>
+
  
=== whereis ===
+
You will get some questions which you can answer mostly with either M (compiled as a module) or Y (compiled directly into the kernel).
If you're interested in finding more information than purely the location of a program, you might try the <span style="color:green">whereis</span> program:
+
 
<pre>
 
<pre>
$ whereis ls
+
Enable different security models (SECURITY) [Y/n/?] y
ls: /bin/ls /usr/bin/ls /usr/share/man/man1/ls.1.gz
+
Enable the securityfs filesystem (SECURITYFS) [Y/?] y
</pre>
+
Socket and Networking Security Hooks (SECURITY_NETWORK) [Y/?] y
Here we see that <span style="color:green">ls</span> occurs in two common binary locations, '''/bin''' and '''/usr/bin'''. Additionally, we are informed that there is a manual page located in '''/usr/share/man'''. This is the man-page you would see if you were to type <span style="color:green">man ls</span>.
+
Security hooks for pathname based access control (SECURITY_PATH) [Y/?] y
 +
Low address space for LSM to protect from user allocation (LSM_MMAP_MIN_ADDR) [65536] 65536
 +
NSA SELinux Support (SECURITY_SELINUX) [Y/n/?] y
 +
  NSA SELinux boot parameter (SECURITY_SELINUX_BOOTPARAM) [N/y/?] n
 +
  NSA SELinux runtime disable (SECURITY_SELINUX_DISABLE) [N/y/?] n
 +
  NSA SELinux Development Support (SECURITY_SELINUX_DEVELOP) [Y/n/?] y
 +
  NSA SELinux AVC Statistics (SECURITY_SELINUX_AVC_STATS) [Y/n/?] y
 +
  NSA SELinux checkreqprot default value (SECURITY_SELINUX_CHECKREQPROT_VALUE) [1] 1
 +
  NSA SELinux maximum supported policy format version (SECURITY_SELINUX_POLICYDB_VERSION_MAX) [Y/n/?] y
 +
    NSA SELinux maximum supported policy format version value (SECURITY_SELINUX_POLICYDB_VERSION_MAX_VALUE) [19] 19
 +
TOMOYO Linux Support (SECURITY_TOMOYO) [Y/n/?] y
 +
  Default maximal count for learning mode (SECURITY_TOMOYO_MAX_ACCEPT_ENTRY) [2048] 2048
 +
  Default maximal count for audit log (SECURITY_TOMOYO_MAX_AUDIT_LOG) [1024] 1024
 +
  Activate without calling userspace policy loader. (SECURITY_TOMOYO_OMIT_USERSPACE_LOADER) [Y/n/?] y
 +
AppArmor support (SECURITY_APPARMOR) [Y/n/?] y
 +
  AppArmor boot parameter default value (SECURITY_APPARMOR_BOOTPARAM_VALUE) [1] 1
 +
Integrity Measurement Architecture(IMA) (IMA) [Y/n/?] y
 +
EVM support (EVM) [N/y/?] (NEW)
 +
Default security module
 +
  1. SELinux (DEFAULT_SECURITY_SELINUX)
 +
  2. TOMOYO (DEFAULT_SECURITY_TOMOYO)
 +
  3. AppArmor (DEFAULT_SECURITY_APPARMOR)
 +
> 4. Unix Discretionary Access Controls (DEFAULT_SECURITY_DAC)
 +
choice[1-4?]: 4
 +
warning: (ACPI_HOTPLUG_CPU) selects ACPI_CONTAINER which has unmet direct dependencies (ACPI && EXPERIMENTAL)
 +
warning: (MEDIA_TUNER) selects MEDIA_TUNER_TEA5761 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_MEDIA && I2C && EXPERIMENTAL)
 +
#
 +
# configuration written to .config
 +
#
 +
warning: (GFS2_FS) selects DLM which has unmet direct dependencies (EXPERIMENTAL && INET && SYSFS && CONFIGFS_FS && (IPV6 || IPV6=n))
 +
warning: (IMA) selects TCG_TPM which has unmet direct dependencies (HAS_IOMEM && EXPERIMENTAL)
 +
warning: (MEDIA_TUNER) selects MEDIA_TUNER_TEA5761 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_MEDIA && I2C && EXPERIMENTAL)
 +
warning: (ACPI_HOTPLUG_CPU) selects ACPI_CONTAINER which has unmet direct dependencies (ACPI && EXPERIMENTAL)
 +
root@[~src/linux] #
  
The <span style="color:green">whereis</span> program also has the ability to search for sources, to specify alternate search paths, and to search for unusual entries. Refer to the whereis man-page for further information.
 
 
=== find ===
 
The <span style="color:green">find</span> command is another handy tool for your toolbox. With find you aren't restricted to programs; you can search for any file you want, using a variety of search criteria. For example, to search for a file by the name of README, starting in '''/usr/share/doc''':
 
<pre>
 
$ find /usr/share/doc -name README
 
/usr/share/doc/ion-20010523/README
 
/usr/share/doc/bind-9.1.3-r6/dhcp-dynamic-dns-examples/README
 
/usr/share/doc/sane-1.0.5/README
 
 
</pre>
 
</pre>
  
=== find and wildcards ===
+
Now comes the most adventurous part!
You can use "glob" wildcards in the argument to -name, provided that you quote them or backslash-escape them (so they get passed to find intact rather than being expanded by bash). For example, we might want to search for README files with extensions:
+
<pre>
+
$ find /usr/share/doc -name README\*
+
/usr/share/doc/iproute2-2.4.7/README.gz
+
/usr/share/doc/iproute2-2.4.7/README.iproute2+tc.gz
+
/usr/share/doc/iproute2-2.4.7/README.decnet.gz
+
/usr/share/doc/iproute2-2.4.7/examples/diffserv/README.gz
+
/usr/share/doc/pilot-link-0.9.6-r2/README.gz
+
/usr/share/doc/gnome-pilot-conduits-0.8/README.gz
+
/usr/share/doc/gimp-1.2.2/README.i18n.gz
+
/usr/share/doc/gimp-1.2.2/README.win32.gz
+
/usr/share/doc/gimp-1.2.2/README.gz
+
/usr/share/doc/gimp-1.2.2/README.perl.gz
+
[578 additional lines snipped]
+
</pre>
+
  
=== Ignoring case with find ===
+
= Building the Kernel =
Of course, you might want to ignore case in your search:
+
<console>
<pre>
+
###i## make -j8  bzImage
$ find /usr/share/doc -name '[Rr][Ee][Aa][Dd][Mm][Ee]*'
+
###i## make -j8 modules
</pre>
+
###i## make modules_install
Or, more simply:
+
###i## make install
<pre>
+
</console>
$ find /usr/share/doc -iname readme\*
+
</pre>
+
As you can see, you can use <span style="color:green">-iname</span> to do case-insensitive searching.
+
  
=== find and regular expressions ===
 
If you're familiar with regular expressions, you can use the -regex option to limit the output to filenames that match a pattern. And similar to the <span style="color:green">-iname</span> option, there is a corresponding <span style="color:green">-iregex</span> option that ignores case in the pattern. For example:
 
<pre>
 
$ find /etc -iregex '.*xt.*'
 
/etc/X11/xkb/types/extra
 
/etc/X11/xkb/semantics/xtest
 
/etc/X11/xkb/compat/xtest
 
/etc/X11/app-defaults/XTerm
 
/etc/X11/app-defaults/XTerm-color
 
</pre>
 
Note that unlike many programs, <span style="color:green">find</span> requires that the regex specified matches the entire path, not just a part of it. For that reason, specifying the leading and trailing .* is necessary; purely using xt as the regex would not be sufficient.
 
  
=== find and types ===
+
'''Building an initramfs or not?'''
The <span style="color:green">-type</span> option allows you to find filesystem objects of a certain type. The possible arguments to -type are b (block device), c (character device), d (directory), p (named pipe), f (regular file), l (symbolic link), and s (socket). For example, to search for symbolic links in '''/usr/bin''' that contain the string vim:
+
<pre>
+
$ find /usr/bin -name '*vim*' -type l
+
/usr/bin/rvim
+
/usr/bin/vimdiff
+
/usr/bin/gvimdiff
+
</pre>
+
  
=== find and mtimes ===
+
The reason to build a kernel with an initramfs is mostly for interoperability (e.g. live-cd's) and special features like an included busybox, ssh, etc.  But mostly, and that's why we are doing this here now, to have a proper kernel up and running quick'n dirty in a reasonable time without fighting hours and days until a more or less exotic hardware is perfectly run by the kernel.
The <span style="color:green">-mtime</span> option allows you to select files based on their last modification time. The argument to mtime is in terms of 24-hour periods, and is most useful when entered with either a plus sign (meaning "after") or a minus sign (meaning "before"). For example, consider the following scenario:
+
After having a proper basic kernel running with the help of an initramfs, I really recommend you to go a step further and build a true kernel with all features includes without an initramfs. But this could be pain in the ass and very time consuming - so we do it the funtoo way here - at least in the second example when we stick to better-initramfs instead of Red-Hat's ''dracut''.
<pre>
+
$ ls -l ?
+
-rw-------    1 root    root            0 Jan  7 18:00 a
+
-rw-------    1 root    root            0 Jan  6 18:00 b
+
-rw-------    1 root    root            0 Jan  5 18:00 c
+
-rw-------    1 root    root            0 Jan  4 18:00 d
+
$ date
+
Mon Jan  7 18:14:52 EST 2003
+
</pre>
+
You could search for files that were created in the past 24 hours:
+
<pre>
+
$ find . -name \? -mtime -1
+
./a
+
</pre>
+
Or you could search for files that were created prior to the current 24-hour period:
+
<pre>
+
$ find . -name \? -mtime +0
+
./b
+
./c
+
./d
+
</pre>
+
  
=== The -daystart option ===
+
= Option one: Initrd with dracut =
If you additionally specify the <span style="color:green">-daystart</span> option, then the periods of time start at the beginning of today rather than 24 hours ago. For example, here is a set of files created yesterday and the day before:
+
<pre>
+
$ find . -name \? -daystart -mtime +0 -mtime -3
+
./b
+
./c
+
$ ls -l b c
+
-rw-------    1 root    root            0 Jan  6 18:00 b
+
-rw-------    1 root    root            0 Jan  5 18:00 c
+
</pre>
+
  
=== The -size option ===
+
To build the initrd we just execute
The <span style="color:green">-size</span> option allows you to find files based on their size. By default, the argument to <span style="color:green">-size</span> is 512-byte blocks, but adding a suffix can make things easier. The available suffixes are b (512-byte blocks), c (bytes), k (kilobytes), and w (2-byte words). Additionally, you can prepend a plus sign ("larger than") or minus sign ("smaller than").
+
  
For example, to find regular files in '''/usr/bin''' that are smaller than 50 bytes:
+
<console>
<pre>
+
# ##i##dracut -f --fstab --xz /boot/initramfs-3.2.6-pf.img  3.2.6-pf
$ find /usr/bin -type f -size -50c
+
</console>
/usr/bin/krdb
+
/usr/bin/run-nautilus
+
/usr/bin/sgmlwhich
+
/usr/bin/muttbug
+
</pre>
+
  
=== Processing found files ===
+
Generally, this really should be enough!
You may be wondering what you can do with all these files that you find! Well, <span style="color:green">find</span> has the ability to act on the files that it finds by using the <span style="color:green">-exec</span> option. This option accepts a command line to execute as its argument, terminated with ;, and it replaces any occurrences of {} with the filename. This is best understood with an example:
+
If you experience booting problems like missing modules / drivers then just boot from the genkernel section and fix the initrd building. You can look into the man page to tweak the command a bit (e.g. --add-drivers "xz dm_crypt" etc...).
<pre>
+
$ find /usr/bin -type f -size -50c -exec ls -l '{}' ';'
+
-rwxr-xr-x    1 root    root          27 Oct 28 07:13 /usr/bin/krdb
+
-rwxr-xr-x    1 root    root          35 Nov 28 18:26 /usr/bin/run-nautilus
+
-rwxr-xr-x    1 root    root          25 Oct 21 17:51 /usr/bin/sgmlwhich
+
-rwxr-xr-x    1 root    root          26 Sep 26 08:00 /usr/bin/muttbug
+
</pre>
+
As you can see, <span style="color:green">find</span> is a very powerful command. It has grown through the years of UNIX and Linux development. There are many other useful options to find. You can learn about them in the find manual page.
+
  
=== locate ===
+
Ok let's go on and finish the taks, we are going to tell now grub how to boot off correctly!
We have covered <span style="color:green">which</span>, <span style="color:green">whereis</span>, and <span style="color:green">find</span>. You might have noticed that find can take a while to execute, since it needs to read each directory that it's searching. It turns out that the <span style="color:green">locate</span> command can speed things up by relying on an external database generated by <span style="color:green">updatedb</span> (which we'll cover in the next panel.)
+
  
The locate command matches against any part of a pathname, not just the file itself. For example:
+
<console>
<pre>
+
###i## nano /etc/boot.conf
$ locate bin/ls
+
/var/ftp/bin/ls
+
/bin/ls
+
/sbin/lsmod
+
/sbin/lspci
+
/usr/bin/lsattr
+
/usr/bin/lspgpot
+
/usr/sbin/lsof
+
</pre>
+
  
=== Using updatedb ===
+
boot {
Most Linux systems have a "cron job" to update the database periodically. If your <span style="color:green">locate</span> returned an error such as the following, then you will need to run <span style="color:green">updatedb</span> as root to generate the search database:
+
        generate grub
<pre>
+
        default "Funtoo Linux dracut"
$ locate bin/ls
+
        timeout 3
locate: /var/spool/locate/locatedb: No such file or directory
+
}
$ su -
+
Password:
+
# updatedb
+
</pre>
+
The <span style="color:green">updatedb</span> command may take a long time to run. If you have a noisy hard disk, you will hear a lot of racket as the entire filesystem is indexed. :)
+
  
=== slocate ===
+
"Funtoo Linux genkernel" {
On many Linux distributions, the <span style="color:green">locate</span> command has been replaced by <span style="color:green">slocate</span>. There is typically a symbolic link to <span style="color:green">locate</span>, so that you don't need to remember which you have. <span style="color:green">slocate</span> stands for "secure locate." It stores permissions information in the database so that normal users can't pry into directories they would otherwise be unable to read. The usage information for <span style="color:green">slocate</span> is essentially the same as for <span style="color:green">locate</span>, although the output might be different depending on the user running the command.
+
        kernel kernel-genkernel[-v]
 +
        initrd initramfs-genkernel[-v]
 +
        params = quiet rootfstype=ext4
 +
        params += luks enc_root=/dev/sda3
 +
        params += lvm root=/dev/mapper/vg-root
 +
}
  
== Process Control ==
+
"Funtoo Linux dracut" {
 +
        kernel vmlinuz[-v]
 +
## this is the better-initramfs generated initrd
 +
        initrd initramfs[-v].img
 +
        params  = quiet rootfstype=ext4
 +
        params += luks enc_root=/dev/sda3
 +
        params += lvm root=/dev/mapper/vg-root
 +
}
 +
</console>
  
=== Staring xeyes ===
+
That's it almost!
{{fancynote|You may need to install xeyes on your system first. Consult your distro's documentation for instructions on installing}}
+
  
To learn about process control, we first need to start a process. Make sure that you have X running and execute the following command:
+
Now write to the <code>grub.cfg</code> with the new handy boot-update script from funtoo:
 +
<console>
 +
###i## boot-update -v
 +
</console>
 
<pre>
 
<pre>
$ xeyes -center red
+
root@[~src/linux] # sudo boot-update -v
</pre>
+
You will notice that an xeyes window pops up, and the red eyeballs follow your mouse around the screen. You may also notice that you don't have a new prompt in your terminal.
+
  
=== Stopping a process ===
+
boot-update 1.5.2 / Copyright 2009-2011 Funtoo Technologies
To get a prompt back, you could type Control-C (often written as Ctrl-C or ^C):
+
  
You get a new bash prompt, but the xeyes window disappeared. In fact, the entire process has been killed. Instead of killing it with Control-C, we could have just stopped it with Control-Z:
+
[use option "-l" for license info, "-h" for help]
<pre>
+
$ xeyes -center red
+
Control-Z
+
[1]+  Stopped                xeyes -center red
+
$
+
</pre>
+
This time you get a new bash prompt, and the xeyes windows stays up. If you play with it a bit, however, you will notice that the eyeballs are frozen in place. If the xeyes window gets covered by another window and then uncovered again, you will see that it doesn't even redraw the eyes at all. The process isn't doing anything. It is, in fact, "Stopped."
+
  
=== fg and bg ===
+
  * Generating config for grub...
To get the process "un-stopped" and running again, we can bring it to the foreground with the bash built-in <span style="color:green">fg</span>:
+
<pre>
+
$ fg
+
(test it out, then stop the process again)
+
Control-Z
+
[1]+ Stopped                xeyes -center red
+
$
+
</pre>
+
Now continue it in the background with the bash built-in <span style="color:green">bg</span>:
+
<pre>
+
$ bg
+
[1]+ xeyes -center red &
+
$
+
</pre>
+
Great! The xeyes process is now running in the background, and we have a new, working bash prompt.
+
  
=== Using "&" ===
+
DEFAULT > Funtoo Linux - vmlinuz-3.2.6-pf
If we wanted to start xeyes in the background from the beginning (instead of using Control-Z and bg), we could have just added an "&" (ampersand) to the end of xeyes command line:
+
          Funtoo Linux genkernel - kernel-genkernel-x86_64-3.2.6-pf
<pre>
+
$ xeyes -center blue &
+
[2] 16224
+
</pre>
+
  
=== Multiple background processes ===
+
* Completed successfully.
Now we have both a red and a blue xeyes running in the background. We can list these jobs with the bash built-in <span style="color:green">jobs</span>:
+
<pre>
+
$ jobs -l
+
[1]- 16217 Running                xeyes -center red &
+
[2]+ 16224 Running                xeyes -center blue &
+
 
</pre>
 
</pre>
The numbers in the left column are the job numbers bash assigned when they were started. Job 2 has a + (plus) to indicate that it's the "current job," which means that typing <span style="color:green">fg</span> will bring it to the foreground. You could also foreground a specific job by specifying its number; for example, <span style="color:green">fg 1</span> would make the red xeyes the foreground task. The next column is the process id or pid, included in the listing courtesy of the -l option to jobs. Finally, both jobs are currently "Running," and their command lines are listed to the right.
 
  
=== Introducing signals ===
+
Okay,... here you go..! :)
To kill, stop, or continue processes, Linux uses a special form of communication called "signals." By sending a certain signal to a process, you can get it to terminate, stop, or do other things. This is what you're actually doing when you type Control-C, Control-Z, or use the <span style="color:green">bg</span> or <span style="color:green">fg</span> built-ins -- you're using bash to send a particular signal to the process. These signals can also be sent using the <span style="color:green">kill</span> command and specifying the pid (process id) on the command line:
+
<pre>
+
$ kill -s SIGSTOP 16224
+
$ jobs -l
+
[1]- 16217 Running                xeyes -center red &
+
[2]+ 16224 Stopped (signal)        xeyes -center blue
+
</pre>
+
As you can see, kill doesn't necessarily "kill" a process, although it can. Using the "-s" option, kill can send any signal to a process. Linux kills, stops or continues processes when they are sent the SIGINT, SIGSTOP, or SIGCONT signals respectively. There are also other signals that you can send to a process; some of these signals may be interpreted in an application-dependent way. You can learn what signals a particular process recognizes by looking at its man-page and searching for a SIGNALS section.
+
  
=== SIGTERM and SIGINT ===
+
Reboot and see how it works!
If you want to kill a process, you have several options. By default, kill sends SIGTERM, which is not identical to SIGINT of Control-C fame, but usually has the same results:
+
<pre>
+
$ kill 16217
+
$ jobs -l
+
[1]- 16217 Terminated              xeyes -center red
+
[2]+ 16224 Stopped (signal)        xeyes -center blue
+
</pre>
+
  
=== The big kill ===
+
= Option two: using better-initramfs =
Processes can ignore both SIGTERM and SIGINT, either by choice or because they are stopped or somehow "stuck." In these cases it may be necessary to use the big hammer, the SIGKILL signal. A process cannot ignore SIGKILL:
+
<pre>
+
$ kill 16224
+
$ jobs -l
+
[2]+ 16224 Stopped (signal)        xeyes -center blue
+
$ kill -s SIGKILL
+
$ jobs -l
+
[2]+ 16224 Interrupt              xeyes -center blue
+
</pre>
+
  
=== nohup ===
+
Piotr's better-initramfs is another approach that is tiny, nice and shiny and seems to become more and more a favourite among funtoo'ers. The biggest plus is that, once built it is kernel version independant.
The terminal where you start a job is called the job's controlling terminal. Some shells (not bash by default), will deliver a SIGHUP signal to backgrounded jobs when you logout, causing them to quit. To protect processes from this behavior, use the nohup when you start the process:
+
<pre>
+
$ nohup make &
+
[1] 15632
+
$ exit
+
</pre>
+
  
=== Using ps to list processes ===
+
For using this you just do the following steps:
The <span style="color:green">jobs</span> command we were using earlier only lists processes that were started from your bash session. To see all the processes on your system, use <span style="color:green">ps</span> with the <span style="color:green">a</span> and <span style="color:green">x</span> options together:
+
 
<pre>
 
<pre>
$ ps ax
+
1. download sources
  PID TTY      STAT  TIME COMMAND
+
2. build kernel with "make bzImage"
    1 ?        S      0:04 init [3]
+
3. download better-initramfs
    2 ?        SW    0:11 [keventd]
+
4. run better-initramfs
    3 ?        SWN    0:13 [ksoftirqd_CPU0]
+
5. adjust /etc/boot.conf
    4 ?        SW    2:33 [kswapd]
+
    5 ?        SW    0:00 [bdflush]
+
 
</pre>
 
</pre>
I've only listed the first few because it is usually a very long list. This gives you a snapshot of what the whole machine is doing, but is a lot of information to sift through. If you were to leave off the <span style="color:green">ax</span>, you would see only processes that are owned by you, and that have a controlling terminal. The command <span style="color:green">ps x</span> would show you all your processes, even those without a controlling terminal. If you were to use <span style="color:green">ps a</span>, you would get the list of everybody's processes that are attached to a terminal.
 
  
=== Seeing the forest and the trees ===
+
Here is how in detail:
You can also list different information about each process. The <span style="color:green">--forest</span> option makes it easy to see the process hierarchy, which will give you an indication of how the various processes on your system interrelate. When a process starts a new process, that new process is called a "child" process. In a <span style="color:green">--forest</span> listing, parents appear on the left, and children appear as branches to the right:
+
<pre>
+
$ ps x --forest
+
  PID TTY      STAT  TIME COMMAND
+
  927 pts/1    S      0:00 bash
+
6690 pts/1    S      0:00  \_ bash
+
26909 pts/1    R      0:00      \_ ps x --forest
+
19930 pts/4    S      0:01 bash
+
25740 pts/4    S      0:04  \_ vi processes.txt
+
</pre>
+
  
=== The "u" and "l" ps options ===
+
Assuming you did install already a genkernel backup or at least you have a working bzImage + modules installed, we rush forward to step 3:
The <span style="color:green">u</span> or <span style="color:green">l</span> options can also be added to any combination of <span style="color:green">a</span> and <span style="color:green">x</span> in order to include more information about each process:
+
<pre>
+
$ ps au
+
USER      PID %CPU %MEM  VSZ  RSS TTY      STAT START  TIME COMMAND
+
agriffis  403  0.0  0.0  2484  72 tty1    S    2001  0:00 -bash
+
chouser    404  0.0  0.0  2508  92 tty2    S    2001  0:00 -bash
+
root      408  0.0  0.0  1308  248 tty6    S    2001  0:00 /sbin/agetty 3
+
agriffis  434  0.0  0.0  1008    4 tty1    S    2001  0:00 /bin/sh /usr/X
+
chouser    927  0.0  0.0  2540  96 pts/1    S    2001  0:00 bash
+
</pre>
+
<pre>
+
$ ps al
+
  F  UID  PID  PPID PRI  NI  VSZ  RSS WCHAN  STAT TTY        TIME COMMAND
+
100  1001  403    1  9  0  2484  72 wait4  S    tty1      0:00 -bash
+
100  1000  404    1  9  0  2508  92 wait4  S    tty2      0:00 -bash
+
000    0  408    1  9  0  1308  248 read_c S    tty6      0:00 /sbin/ag
+
000  1001  434  403  9  0  1008    4 wait4  S    tty1      0:00 /bin/sh
+
000  1000  927  652  9  0  2540  96 wait4  S    pts/1      0:00 bash
+
</pre>
+
  
=== Using top ===
+
=== download better-initramfs ===
If you find yourself running ps several times in a row, trying to watch things change, what you probably want is <span style="color:green">top</span>. <span style="color:green">top</span> displays a continuously updated process listing, along with some useful summary information:
+
<pre>
+
$ top
+
10:02pm  up 19 days,  6:24,  8 users,  load average: 0.04, 0.05, 0.00
+
75 processes: 74 sleeping, 1 running, 0 zombie, 0 stopped
+
CPU states:  1.3% user,  2.5% system,  0.0% nice, 96.0% idle
+
Mem:  256020K av,  226580K used,  29440K free,      0K shrd,    3804K buff
+
Swap:  136544K av,  80256K used,  56288K free                  101760K cached
+
  
  PID USER    PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM  TIME COMMAND
+
<console>
  628 root      16  0  213M  31M  2304 S      0  1.9 12.5  91:43 X
+
➜ # cd /usr/src/;
26934 chouser  17  0  1272 1272  1076 R      0  1.1  0.4  0:00 top
+
➜ # git clone https://github.com/slashbeast/better-initramfs.git
  652 chouser  11  0 12016 8840  1604 S      0  0.5  3.4  3:52 gnome-termin
+
  641 chouser    9  0  2936 2808  1416 S      0  0.1  1.0  2:13 sawfish
+
</pre>
+
  
=== nice ===
+
➜ # /src #  cd better-initramfs
Each processes has a priority setting that Linux uses to determine how CPU timeslices are shared. You can set the priority of a process by starting it with the <span style="color:green">nice</span> command:
+
➜ # better-initramfs git:(master) ls
<pre>
+
AUTHORS    LICENSE  README.rst  bootstrap  output  sourceroot
$ nice -n 10 oggenc /tmp/song.wav
+
ChangeLog  Makefile  TODO        examples  scripts
</pre>
+
</console>
Since the priority setting is called <span style="color:green">nice</span>, it should be easy to remember that a higher value will be nice to other processes, allowing them to get priority access to the CPU. By default, processes are started with a setting of 0, so the setting of 10 above means oggenc will readily give up the CPU to other processes. Generally, this means that oggenc will allow other processes to run at their normal speed, regardless of how CPU-hungry oggenc happens to be. You can see these niceness levels under the NI column in the ps and top listings above.
+
  
=== renice ===
+
=== build the better-initramfs ===
The <span style="color:green">nice</span> command can only change the priority of a process when you start it. If you want to change the niceness setting of a running process, use <span style="color:green">renice</span>:
+
<console>
<pre>
+
➜ # better-initramfs git:(master) sudo bootstrap/bootstrap-all
$ ps l 641
+
Passwort: xxx
  F  UID  PID  PPID PRI  NI  VSZ  RSS WCHAN  STAT TTY        TIME COMMAND
+
# from here go and grab a coffee
000  1000  641    1  9  0  5876 2808 do_sel S    ?          2:14 sawfish
+
➜ # sudo make prepare
$ renice 10 641
+
➜ # sudo make image
641: old priority 0, new priority 10
+
➜ # sudo mv output/initramfs.cpio.gz /boot
$ ps l 641
+
</console>
  F  UID  PID  PPID PRI  NI  VSZ  RSS WCHAN  STAT TTY        TIME COMMAND
+
000  1000  641    1  9  10  5876 2808 do_sel S    ?          2:14 sawfish
+
</pre>
+
  
== Text processing ==
+
=== adjust grub ===
  
=== Redirection revisited ===
+
Taking the above setup we edit the /etc/boot.conf
Earlier in this tutorial series, we saw an example of how to use the <span style="color:green">></span> operator to redirect the output of a command to a file, as follows:
+
as I installed genkernel first, and dracut after - you see this setup:
<pre>
+
$ echo "firstfile" > copyme
+
</pre>
+
In addition to redirecting output to a file, we can also take advantage of a powerful shell feature called pipes. Using pipes, we can pass the output of one command to the input of another command. Consider the following example:
+
<pre>
+
$ echo "hi there" | wc
+
      1      2      9
+
</pre>
+
The <span style="color:green">|</span> character is used to connect the output of the command on the left to the input of the command on the right. In the example above, the <span style="color:green">echo</span> command prints out the string "hi there" followed by a linefeed. That output would normally appear on the terminal, but the pipe redirects it into the <span style="color:green">wc</span> command, which displays the number of lines, words, and characters in its input.
+
  
=== A pipe example ===
 
Here is another simple example:
 
 
<pre>
 
<pre>
$ ls -s | sort -n
+
boot {
</pre>
+
        generate grub
In this case, <span style="color:green">ls -s</span> would normally print a listing of the current directory on the terminal, preceding each file with its size. But instead we've piped the output into <span style="color:green">sort -n</span>, which sorts the output numerically. This is a really useful way to find large files in your home directory!
+
        default "Funtoo Linux"
 +
        timeout 3
 +
}
  
The following examples are more complex, but they demonstrate the power that can be harnessed using pipes. We're going to throw out some commands we haven't covered yet, but don't let that slow you down. Concentrate instead on understanding how pipes work so you can employ them in your daily Linux tasks.
+
# Rootfs over lvm over luks
 +
# /dev/sda3 - encrypted lvm's pv
 +
# /dev/mapper/vg-root - rootfs's lv
  
=== The decompression pipeline ===
+
"Funtoo Linux" {
Normally to decompress and untar a file, you might do the following:
+
        kernel bzImage[-v]
<pre>
+
## this is the better-initramfs generated initrd
$ bzip2 -d linux-2.4.16.tar.bz2
+
        initrd initramfs.cpio.gz
$ tar xvf linux-2.4.16.tar
+
        params  = quiet rootfstype=ext4
</pre>
+
        params += luks enc_root=/dev/sda3
The downside of this method is that it requires the creation of an intermediate, uncompressed file on your disk. Since <span style="color:green">tar</span> has the ability to read directly from its input (instead of specifying a file), we could produce the same end-result using a pipeline:
+
        params += lvm root=/dev/mapper/vg-root
<pre>
+
}
$ bzip2 -dc linux-2.4.16.tar.bz2 | tar xvf -
+
</pre>
+
Woo hoo! Our compressed tarball has been extracted and we didn't need an intermediate file.
+
  
=== A longer pipeline ===
+
"Funtoo Linux dracut" {
Here's another pipeline example:
+
        kernel vmlinuz[-v]
<pre>
+
## this is the dracut generated initrd
$ cat myfile.txt | sort | uniq | wc -l
+
        initrd initramfs[-v].img
</pre>
+
        params  = quiet rootfstype=ext4
We use <span style="color:green">cat</span> to feed the contents of '''myfile.txt''' to the <span style="color:green">sort</span> command. When the sort command receives the input, it sorts all input lines so that they are in alphabetical order, and then sends the output to <span style="color:green">uniq</span>. <span style="color:green">uniq</span> removes any duplicate lines (and requires its input to be sorted, by the way,) sending the scrubbed output to <span style="color:green">wc -l</span>. We've seen the <span style="color:green">wc</span> command earlier, but without command-line options. When given the <span style="color:green">-l</span> option, it only prints the number of lines in its input, instead of also including words and characters. You'll see that this pipeline will print out the number of unique (non-identical) lines in a text file.
+
        params += luks enc_root=/dev/sda3
 +
        params += lvm root=/dev/mapper/vg-root
 +
}
  
Try creating a couple of test files with your favorite text editor and use this pipeline to see what results you get.
 
  
=== The text processing whirlwind begins ===
+
"Funtoo Linux genkernel" {
Now we embark on a whirlwind tour of the standard Linux text processing commands. Because we're covering a lot of material in this tutorial, we don't have the space to provide examples for every command. Instead, we encourage you to read each command's man page (by typing <span style="color:green">man echo</span>, for example) and learn how each command and it's options work by spending some time playing with each one. As a rule, these commands print the results of any text processing to the terminal rather than modifying any specified files. After we take our whirlwind tour of the standard Linux text processing commands, we'll take a closer look at output and input redirection. So yes, there is light at the end of the tunnel :)
+
        kernel kernel-genkernel[-v]
 
+
        initrd initramfs-genkernel[-v]
<span style="color:green">echo</span> prints its arguments to the terminal. Use the <span style="color:green">-e</span> option if you want to embed backslash escape sequences; for example <span style="color:green">echo -e "foo\nfoo"</span> will print foo, then a newline, and then foo again. Use the <span style="color:green">-n</span> option to tell echo to omit the trailing newline that is appended to the output by default.
+
        params = quiet rootfstype=ext4
 
+
        params += luks enc_root=/dev/sda3
<span style="color:green">cat</span> will print the contents of the files specified as arguments to the terminal. Handy as the first command of a pipeline, for example, <span style="color:green">cat foo.txt | blah</span>.
+
        params += lvm root=/dev/mapper/vg-root
 
+
}
<span style="color:green">sort</span> will print the contents of the file specified on the command line in alphabetical order. Of course, <span style="color:green">sort</span> also accepts piped input. Type <span style="color:green">man sort</span> to familiarize yourself with its various options that control sorting behavior.
+
 
+
<span style="color:green">uniq</span> takes an already-sorted file or stream of data (via a pipeline) and removes duplicate lines.
+
 
+
<span style="color:green">wc</span> prints out the number of lines, words, and bytes in the specified file or in the input stream (from a pipeline). Type <span style="color:green">man wc</span> to learn how to fine-tune what counts are displayed.
+
 
+
<span style="color:green">head</span> prints out the first ten lines of a file or stream. Use the <span style="color:green">-n</span> option to specify how many lines should be displayed.
+
 
+
<span style="color:green">tail</span> prints out the last ten lines of a file or stream. Use the <span style="color:green">-n</span> option to specify how many lines should be displayed.
+
 
+
<span style="color:green">tac</span> is like <span style="color:green">cat</span>, but prints all lines in reverse order; in other words, the last line is printed first.
+
 
+
<span style="color:green">expand</span> converts input tabs to spaces. Use the <span style="color:green">-t</span> option to specify the tabstop.
+
 
+
<span style="color:green">unexpand</span> converts input spaces to tabs. Use the <span style="color:green">-t</span> option to specify the tabstop.
+
 
+
<span style="color:green">cut</span> is used to extract character-delimited fields from each line of an input file or stream.
+
 
+
The <span style="color:green">nl</span> command adds a line number to every line of input. Useful for printouts.
+
 
+
<span style="color:green">pr</span> is used to break files into multiple pages of output; typically used for printing.
+
 
+
<span style="color:green">tr</span> is a character translation tool; it's used to map certain characters in the input stream to certain other characters in the output stream.
+
 
+
<span style="color:green">sed</span> is a powerful stream-oriented text editor. You can learn more about sed in the following Funtoo articles:
+
 
+
* [[Sed by Example, Part 1]]
+
* [[Sed by Example, Part 2]]
+
* [[Sed by Example, Part 3]]
+
 
+
If you're planning to take the LPI exam, be sure to read the first two articles of this series.
+
 
+
<span style="color:green">awk</span> is a handy line-oriented text-processing language. To learn more about awk, read the following Funtoo articles:
+
 
+
* [[Awk by Example, Part 1]]
+
* [[Awk by Example, Part 2]]
+
* [[Awk by Example, Part 3]]
+
 
+
<span style="color:green">od</span> is designed to transform the input stream into a octal or hex "dump" format.
+
 
+
<span style="color:green">split</span> is a command used to split a larger file into many smaller-sized, more manageable chunks.
+
 
+
<span style="color:green">fmt</span> will reformat paragraphs so that wrapping is done at the margin. These days it's less useful since this ability is built into most text editors, but it's still a good one to know.
+
 
+
<span style="color:green">paste</span> takes two or more files as input, concatenates each sequential line from the input files, and outputs the resulting lines. It can be useful to create tables or columns of text.
+
 
+
<span style="color:green">join</span> is similar to paste, but it uses a field (by default the first) in each input line to match up what should be combined on a single line.
+
 
+
<span style="color:green">tee</span> prints its input both to a file and to the screen. This is useful when you want to create a log of something, but you also want to see it on the screen.
+
 
+
=== Whirlwind over! Redirection ===
+
Similar to using <span style="color:green">></span> on the bash command line, you can also use <span style="color:green">&lt;</span> to redirect a file into a command. For many commands, you can simply specify the filename on the command line, however some commands only work from standard input.
+
 
+
Bash and other shells support the concept of a "herefile." This allows you to specify the input to a command in the lines following the command invocation, terminating it with a sentinal value. This is easiest shown through an example:
+
<pre>
+
$ sort <<END
+
apple
+
cranberry
+
banana
+
END
+
apple
+
banana
+
cranberry
+
 
</pre>
 
</pre>
In the example above, we typed the words apple, cranberry and banana, followed by "END" to signify the end of the input. The <span style="color:green">sort</span> program then returned our words in alphabetical order.
+
Okay,... here you go..! :)
 
+
=== Using >> ===
+
You would expect <span style="color:green">>></span> to be somehow analogous to <span style="color:green">&lt;&lt;</span>, but it isn't really. It simply means to append the output to a file, rather than overwrite as <span style="color:green">></span> would. For example:
+
<pre>
+
$ echo Hi > myfile
+
$ echo there. > myfile
+
$ cat myfile
+
there.
+
</pre>
+
Oops! We lost the "Hi" portion! What we meant was this:
+
<pre>
+
$ echo Hi > myfile
+
$ echo there. >> myfile
+
$ cat myfile
+
Hi
+
there.
+
</pre>
+
Much better!
+
 
+
== Kernel Modules ==
+
 
+
=== Meet "uname" ===
+
The <span style="color:green">uname</span> command provides a variety of interesting information about your system. Here's what is displayed on my development workstation when I type <span style="color:green">uname -a</span> which tells the <span style="color:green">uname</span> command to print out all of its information in one swoop:
+
<pre>
+
$ uname -a
+
Linux inventor 2.4.20-gaming-r1 #1 Fri Apr 11 18:33:35 MDT 2003 i686 AMD Athlon(tm) XP 2100+ AuthenticAMD GNU/Linux
+
</pre>
+
 
+
=== More uname madness ===
+
Now, let's look at the information that <span style="color:green">uname</span> provides
+
<pre>
+
info. option                    arg    example
+
kernel name                    -s      "Linux"
+
hostname                        -n      "inventor"
+
kernel release                  -r      "2.4.20-gaming-r1"
+
kernel version                  -v      "#1 Fri Apr 11 18:33:35 MDT 2003"
+
machine                        -m      "i686"
+
processor                      -p      "AMD Athlon(tm) XP 2100+"
+
hardware platform              -i      "AuthenticAMD"
+
operating system                -o      "GNU/Linux"
+
</pre>
+
Intriguing! What does your <span style="color:green">uname -a</span> command print out?
+
 
+
=== The kernel release ===
+
Here's a magic trick. First, type <span style="color:green">uname -r</span> to have the uname command print out the release of the Linux kernel that's currently running.
+
 
+
Now, look in the '''/lib/modules''' directory and --presto!-- I bet you'll find a directory with that exact name! OK, not quite magic, but now may be a good time to talk about the significance of the directories in '''/lib/modules''' and explain what kernel modules are.
+
 
+
=== The kernel ===
+
The Linux kernel is the heart of what is commonly referred to as "Linux" -- it's the piece of code that accesses your hardware directly and provides abstractions so that regular old programs can run. Thanks to the kernel, your text editor doesn't need to worry about whether it is writing to a SCSI or IDE disk -- or even a RAM disk. It just writes to a filesystem, and the kernel takes care of the rest.
+
 
+
=== Introducing kernel modules ===
+
So, what are kernel modules? Well, they're parts of the kernel that have been stored in a special format on disk. At your command, they can be loaded into the running kernel and provide additional functionality.
+
 
+
Because the kernel modules are loaded on demand, you can have your kernel support a lot of additional functionality that you may not ordinarily want to be enabled. But once in a blue moon, those kernel modules are likely to come in quite handy and can be loaded -- often automatically -- to support that odd filesystem or hardware device that you rarely use.
+
 
+
=== Kernel modules in a nutshell ===
+
In sum, kernel modules allow for the running kernel to enable capabilities on an on-demand basis. Without kernel modules, you'd have to compile a completely new kernel and reboot in order for it to support something new.
+
 
+
=== lsmod ===
+
To see what modules are currently loaded on your system, use the <span style="color:green">lsmod</span> command:
+
<pre>
+
# lsmod
+
Module                  Size  Used by    Tainted: PF
+
vmnet                  20520  5
+
vmmon                  22484  11
+
nvidia              1547648  10
+
mousedev                3860  2
+
hid                    16772  0  (unused)
+
usbmouse                1848  0  (unused)
+
input                  3136  0  [mousedev hid usbmouse]
+
usb-ohci              15976  0  (unused)
+
ehci-hcd              13288  0  (unused)
+
emu10k1                64264  2
+
ac97_codec              9000  0  [emu10k1]
+
sound                  51508  0  [emu10k1]
+
usbcore                55168  1  [hid usbmouse usb-ohci ehci-hcd]
+
</pre>
+
 
+
=== Modules listing ===
+
As you can see, my system has quite a few modules loaded. the vmnet and vmmon modules provide necessary functionality for [http://www.vmware.com/ VMWare Workstation], which allows me to run a virtual PC in a window on my desktop. The "nvidia" module comes from [http://www.nvidia.com/ NVIDIA] corporation and allows me to use my high-performance 3D-accelerated graphics card under Linux whilst taking advantage of its many neat features.
+
 
+
Then I have a bunch of modules that are used to provide support for my USB-based input devices -- namely "mousedev," "hid," "usbmouse," "input," "usb-ohci," "ehci-hcd" and "usbcore." It often makes sense to configure your kernel to provide USB support as modules. Why? Because USB devices are "plug and play," and when you have your USB support in modules, then you can go out and buy a new USB device, plug it in to your system, and have the system automatically load the appropriate modules to enable that device. It's a handy way to do things.
+
 
+
=== Third-party modules ===
+
Rounding out my list of modules are "emu10k1," "ac97_codec," and "sound," which together provide support for my SoundBlaster Audigy sound card.
+
 
+
It should be noted that some of my kernel modules come from the kernel sources themselves. For example, all the USB-related modules are compiled from the standard Linux kernel sources. However, the nvidia, emu10k1 and VMWare-related modules come from other sources. This highlights another major benefit of kernel modules -- allowing third parties to provide much-needed kernel functionality and allowing this functionality to "plug in" to a running Linux kernel. No reboot necessary.
+
 
+
=== depmod and friends ===
+
In my '''/lib/modules/2.4.20-gaming-r1/''' directory, I have a number of files that start with the string "modules.":
+
<pre>
+
$ ls /lib/modules/2.4.20-gaming-r1/modules.*
+
/lib/modules/2.4.20-gaming-r1/modules.dep
+
/lib/modules/2.4.20-gaming-r1/modules.generic_string
+
/lib/modules/2.4.20-gaming-r1/modules.ieee1394map
+
/lib/modules/2.4.20-gaming-r1/modules.isapnpmap
+
/lib/modules/2.4.20-gaming-r1/modules.parportmap
+
/lib/modules/2.4.20-gaming-r1/modules.pcimap
+
/lib/modules/2.4.20-gaming-r1/modules.pnpbiosmap
+
/lib/modules/2.4.20-gaming-r1/modules.usbmap
+
</pre>
+
These files contain some lots of dependency information. For one, they record *dependency* information for modules -- some modules require other modules to be loaded first before they will run. This information is recorded in these files.
+
 
+
=== How you get modules ===
+
Some kernel modules are designed to work with specific hardware devices, like my "emu10k1" module which is for my SoundBlaster Audigy card. For these types of modules, these files also record the PCI IDs and similar identifying marks of the hardware devices that they support. This information can be used by things like the "hotplug" scripts (which we'll take a look at in later tutorials) to auto-detect hardware and load the appropriate module to support said hardware automatically.
+
 
+
=== Using depmod ===
+
If you ever install a new module, this dependency information may become out of date. To make it fresh again, simply type <span style="color:green">depmod -a.</span> The <span style="color:green">depmod</span> program will then scan all the modules in your directories in '''/lib/modules''' and freshen the dependency information. It does this by scanning the module files in '''/lib/modules''' and looking at what are called "symbols" inside the modules.
+
 
+
=== Locating kernel modules ===
+
So, what do kernel modules look like? For 2.4 kernels, they're typically any file in the '''/lib/modules''' tree that ends in ".o". To see all the modules in '''/lib/modules''', type the following:
+
<pre>
+
# find /lib/modules -name '*.o'
+
/lib/modules/2.4.20-gaming-r1/misc/vmmon.o
+
/lib/modules/2.4.20-gaming-r1/misc/vmnet.o
+
/lib/modules/2.4.20-gaming-r1/video/nvidia.o
+
/lib/modules/2.4.20-gaming-r1/kernel/fs/fat/fat.o
+
/lib/modules/2.4.20-gaming-r1/kernel/fs/vfat/vfat.o
+
/lib/modules/2.4.20-gaming-r1/kernel/fs/minix/minix.o
+
[listing "snipped" for brevity]
+
</pre>
+
 
+
=== insmod vs. modprobe ===
+
So, how does one load a module into a running kernel? One way is to use the <span style="color:green">insmod</span> command and specifying the full path to the module that you wish to load:
+
<pre>
+
# insmod /lib/modules/2.4.20-gaming-r1/kernel/fs/fat/fat.o
+
# lsmod | grep fat
+
fat                    29272  0  (unused)
+
</pre>
+
However, one normally loads modules by using the <span style="color:green">modprobe</span> command. One of the nice things about the <span style="color:green">modprobe</span> command is that it automatically takes care of loading any dependent modules. Also, one doesn't need to specify the path to the module you wish to load, nor does one specify the trailing ".o".
+
 
+
=== rmmod and modprobe in action ===
+
Let's unload our "fat.o" module and load it using <span style="color:green">modprobe</span>:
+
<pre>
+
# rmmod fat
+
# lsmod | grep fat
+
# modprobe fat
+
# lsmod | grep fat
+
fat                    29272  0  (unused)
+
</pre>
+
As you can see, the <span style="color:green">rmmod</span> command works similarly to <span style="color:green">modprobe</span>, but has the opposite effect -- it unloads the module you specify.
+
 
+
=== Your friend modinfo and modules.conf ===
+
You can use the <span style="color:green">modinfo</span> command to learn interesting things about your favorite modules:
+
<pre>
+
# modinfo fat
+
filename:    /lib/modules/2.4.20-gaming-r1/kernel/fs/fat/fat.o
+
description: <none>
+
author:      <none>
+
license:    "GPL"
+
</pre>
+
And make special note of the '''/etc/modules.conf''' file. This file contains configuration information for modprobe. It allows you to tweak the functionality of modprobe by telling it to load modules before/after loading others, run scripts before/after modules load, and more.
+
 
+
=== modules.conf gotchas ===
+
The syntax and functionality of '''modules.conf''' is quite complicated, and we won't go into its syntax now (type <span style="color:green">man modules.conf</span> for all the gory details), but here are some things that you *should* know about this file.
+
  
For one, many distributions generate this file automatically from a bunch of files in another directory, like '''/etc/modules.d/'''. For example, Gentoo Linux has an '''/etc/modules.d/''' directory, and running the <span style="color:green">update-modules</span> command will take every file in '''/etc/modules.d/''' and concatenate them to produce a new '''/etc/modules.conf'''. Therefore, make your changes to the files in '''/etc/modules.d/''' and run <span style="color:green">update-modules</span> if you are using Gentoo. If you are using Debian, the procedure is similar except that the directory is called '''/etc/modutils/'''.
+
update the grub.cfg, then reboot and see how it works!
  
== Summary and Resources ==
+
<console>
 +
root@[~src/linux-3.2.6-pf] # boot-update -v   
  
=== Summary ===
+
boot-update 1.5.2 / Copyright 2009-2011 Funtoo Technologies
Congratulations; you've reached the end of this tutorial on basic Linux administration! We hope that it has helped you to firm up your foundational Linux knowledge. Please join us in our next tutorial covering intermediate administration, where we will build on the foundation laid here, covering topics like the Linux permissions and ownership model, user account management, filesystem creation and mounting, and more. And remember, by continuing in this tutorial series, you'll soon be ready to attain your LPIC Level 1 Certification from the Linux Professional Institute.
+
  
=== Resources ===
+
[use option "-l" for license info, "-h" for help]
Speaking of LPIC certification, if this is something you're interested in, then we recommend that you study the following resources, which have been carefully selected to augment the material covered in this tutorial:
+
  
There are a number of good regular expression resources on the 'net. Here are a couple that we've found:
+
* Generating config for grub...
  
* [http://www.zvon.org/other/reReference/Output/ Regular Expressions Reference]
+
DEFAULT > Funtoo Linux better-initramfs - vmlinuz-3.2.6-pf
* [http://zez.org/article/articleview/11/ Regular Expressions Explained]
+
          Funtoo Linux dracut - vmlinuz-3.2.6-pf
 +
          Funtoo Linux genkernel - kernel-genkernel-x86_64-3.2.6-ck
  
Be sure to read up on the Filesystem Hierarchy Standard at http://www.pathname.com/fhs/.
+
* Completed successfully.
  
Check out the other articles in this series:
+
root@[~src/linux-3.2.6-pf] #
*[[Linux Fundamentals, Part 1]]
+
*[[Linux Fundamentals, Part 3]]
+
*[[Linux Fundamentals, Part 4]]
+
  
In the "Bash by Example" article series, Daniel shows you how to use bash programming constructs to write your own bash scripts. This series (particularly Parts 1 and 2) will be good preparation for the LPIC Level 1 exam:
+
root@[~src/linux-3.2.6-pf] # reboot
*[[Bash by Example, Part 1]]: Fundamental programming in the Bourne-again shell
+
*[[Bash by Example, Part 2]]: More bash programming fundamentals
+
*[[Bash by Example, Part 3]]: Exploring the ebuild system
+
  
You can learn more about sed in the Sed by Example article series. If you're planning to take the LPI exam, be sure to read the first two articles of this series.
+
System going down for reboot!
*[[Sed by Example, Part 1]]
+
*[[Sed by Example, Part 2]]
+
*[[Sed by Example, Part 3]]
+
  
To learn more about awk, read the Awk by Example article series.
+
</console>
*[[Awk by Example, Part 1]]
+
*[[Awk by Example, Part 2]]
+
*[[Awk by Example, Part 3]]
+
  
If you're not too familiar with the vi editor, I strongly recommend that you check out my [http://www-106.ibm.com/developerworks/edu/l-dw-linuxvi-i.html Vi -- the cheat sheet method] tutorial. This tutorial will give you a gentle yet fast-paced introduction to this powerful text editor. Consider this must-read material if you don't know how to use vi.
 
  
__NOTOC__
+
[[Category:HOWTO]]
[[Category:Linux Core Concepts]]
+
[[Category:Featured]]
[[Category:Articles]]
+
[[Category:Kernel]]

Revision as of 17:30, 9 January 2014

Setting up a proper kernel yourself - lean, mean and tailored to your hardware, is the challenge by which a linux user can graduate to becoming a Funtoo knight ;-)

Even though many of us are using enterprise-ready kernels in datacenters, there is almost nobody who hasn't at least considered building a kernel for his laptop / PC. We are showing here how an intermediate Linux user can use an alternative to the standard beginners "genkernel" approach, to compile a custom kernel, in a relatively still speedy and easy set up.

Minimum Requirements

You should understand the way how things work in a terminal and how to use an editor and tweak config files. This is crucial. You don't need much knowledge about the linux kernel and it's internals. Nevertheless, you have to know at least where the files are located, how they are used and what is the file logic behind the overall structure. Otherwise you should consider using a non source based linux distribution. If you are scared now, don't worry - we are going to build a kernel the Funtoo way and you will pick up everthing necessary to accomplish this challenge, step by step, so the next time you do it yourself and become a real Funtoo knight!

Assumptions

You start from an installed Funtoo system on the disk, or at least, you are on stage3 in a chrooted environment from a live cd, following somehow the Funto Installation Tutorial.

In this case we are building a kernel that is booting root in LVM over encrypted LUKS container. If you don't have this setup, don't worry, you just don't need all the modules, but everything else is similar.


Getting everything in order to start

First there is the decision which linux kernel sources we need. There are plenty of them in the repositories around, often it is not easy to distinguish between them.

I would always trust my distribution of choice and take what is has to offer - and funtoo has a lot to offer!

I really do recommend (especially if it is your first time) to build a debian-sourced genkernel like described in chapter 5 "Using Debian-Sources with Genkernel" in the Funtoo Kernels Tutorial.

From there you should have a running system booting nicely from your own build (just little bit bloated) kernel. This is more than you can expect from any other ready to go distribution.

Note

{{{1}}}

We are using RedHat's dracut in order to build a nice initramfs (containing all the necessary tools and extra drivers our kernel might need to start the system). Although dracut is the way to go, more sophisticated and not as buggy as gentoo's genkernel approach, more and more funtoo geeks start using slashbeast's better-initramfs, which we will cover at the end of this howto! So after having set up a genkernel from debian or gentoo sources we are going to build a kernel with either (or both) dracut or/and better-initramfs. So gentoo sources with genkernel is always my backup if anything is not working correctly on my system. For the slightly more geeky approach with my own initram I am using pf-sources, ck-sources or any other more or less heavily patched sources.

Let's go!

Kernel Sources

We are going to use the kernel sources from the funtoo git repository.

The source you use on your system is up to you and your needs. For a laptop or desktop system, we recommend the following:

  • sys-kernel/pf-sources
  • sys-kernel/ck-sources
  • sys-kernel/gentoo-sources
  • sys-kernel/git-sources
  • sys-kernel/sysrescue-std-sources
  • sys-kernel/debian-sources

Please, have a look in the ebuild description, look onto their homepage and take the one that suits you best! If you are unsure for now, use sys-kernel/gentoo-sources. That's always a safe bet for a general system.

It is not a problem to have various kernels installed parallel, so go on with any one of them.

I am going to use the sys-kernel/pf-sources now, as I already had the gentoo-sources installed.

Prerequisites

I don't know which tools you have already installed, so some information here might be redundant. It doesn't harm to just copy and paste and do some steps again.

First, we look into our /etc/make.conf:

# nano /etc/make.conf
#These compiler flags are just tweaking (optimazation) and NOT necessary:
CFLAGS="-O2 -pipe -march=native -ftracer -fforce-addr"
CXXFLAGS="${CFLAGS} -fpermissive -fomit-frame-pointer"
KDIR=/usr/src/linux
KERNEL="symlink build"
USE="$KERNEL ....here are your use flags...."
## These modules are available:
## DRACUT_MODULES="dracut_modules_biosdevname dracut_modules_btrfs dracut_modules_caps dracut_modules_crypt dracut_modules_crypt-gpg dracut_modules_dmraid dracut_modules_dmsquash-live dracut_modules_gensplash dracut_modules_iscsi dracut_modules_livenet dracut_modules_lvm dracut_modules_mdraid dracut_modules_multipath dracut_modules_nbd dracut_modules_nfs dracut_modules_plymouth dracut_modules_ssh-client dracut_modules_syslog"
## We will use these modules for LVM / LUKS:
DRACUT_MODULES="crypt lvm plymouth biosdevname dmraid crypt-gpg dmsquash-live ssh-client syslog"

Next, we set the package keywords:

# nano /etc/portage/package.use/dracut
sys-kernel/dracut dm net device-mapper crypt lvm

Note

{{{1}}}

If you don't have lvm over encrypted LUKS you probably just add the "net" keyword here, or "selinux".


After that we are going to build our packages:

# emerge -av app-portage/gentoolkit sys-kernel/pf-sources sys-kernel/dracut sys-boot/plymouth sys-boot/plymouth-openrc-plugin

Finished? Well, then let's go on and

Preparing the kernel

We go now to the sources directory and enter the following commands to update the kernel's .config file:

# cd /usr/src/linux/
# make clean
  CLEAN   .
  CLEAN   arch/x86/kernel/acpi/realmode
  CLEAN   arch/x86/kernel/cpu
  CLEAN   arch/x86/kernel
  CLEAN   arch/x86/vdso
  CLEAN   arch/x86/lib
  CLEAN   drivers/gpu/drm/radeon
  CLEAN   drivers/net/wan
  CLEAN   drivers/scsi/aic7xxx
  CLEAN   drivers/tty/vt
  CLEAN   drivers/video/logo
  CLEAN   firmware
  CLEAN   kernel
  CLEAN   lib/raid6
  CLEAN   lib
  CLEAN   security/apparmor
  CLEAN   security/selinux
  CLEAN   usr
  CLEAN   arch/x86/boot/compressed
  CLEAN   arch/x86/boot
  CLEAN   .tmp_versions
  CLEAN   vmlinux System.map .tmp_kallsyms2.S .tmp_kallsyms1.o .tmp_kallsyms2.o .tmp_kallsyms1.S .tmp_vmlinux1 .tmp_vmlinux2 .tmp_System.map
# zcat /proc/config.gz > /usr/src/linux/.config
# make localmodconfig

You will get some questions which you can answer mostly with either M (compiled as a module) or Y (compiled directly into the kernel).

Enable different security models (SECURITY) [Y/n/?] y
Enable the securityfs filesystem (SECURITYFS) [Y/?] y
Socket and Networking Security Hooks (SECURITY_NETWORK) [Y/?] y
Security hooks for pathname based access control (SECURITY_PATH) [Y/?] y
Low address space for LSM to protect from user allocation (LSM_MMAP_MIN_ADDR) [65536] 65536
NSA SELinux Support (SECURITY_SELINUX) [Y/n/?] y
  NSA SELinux boot parameter (SECURITY_SELINUX_BOOTPARAM) [N/y/?] n
  NSA SELinux runtime disable (SECURITY_SELINUX_DISABLE) [N/y/?] n
  NSA SELinux Development Support (SECURITY_SELINUX_DEVELOP) [Y/n/?] y
  NSA SELinux AVC Statistics (SECURITY_SELINUX_AVC_STATS) [Y/n/?] y
  NSA SELinux checkreqprot default value (SECURITY_SELINUX_CHECKREQPROT_VALUE) [1] 1
  NSA SELinux maximum supported policy format version (SECURITY_SELINUX_POLICYDB_VERSION_MAX) [Y/n/?] y
    NSA SELinux maximum supported policy format version value (SECURITY_SELINUX_POLICYDB_VERSION_MAX_VALUE) [19] 19
TOMOYO Linux Support (SECURITY_TOMOYO) [Y/n/?] y
  Default maximal count for learning mode (SECURITY_TOMOYO_MAX_ACCEPT_ENTRY) [2048] 2048
  Default maximal count for audit log (SECURITY_TOMOYO_MAX_AUDIT_LOG) [1024] 1024
  Activate without calling userspace policy loader. (SECURITY_TOMOYO_OMIT_USERSPACE_LOADER) [Y/n/?] y
AppArmor support (SECURITY_APPARMOR) [Y/n/?] y
  AppArmor boot parameter default value (SECURITY_APPARMOR_BOOTPARAM_VALUE) [1] 1
Integrity Measurement Architecture(IMA) (IMA) [Y/n/?] y
EVM support (EVM) [N/y/?] (NEW)
Default security module
  1. SELinux (DEFAULT_SECURITY_SELINUX)
  2. TOMOYO (DEFAULT_SECURITY_TOMOYO)
  3. AppArmor (DEFAULT_SECURITY_APPARMOR)
> 4. Unix Discretionary Access Controls (DEFAULT_SECURITY_DAC)
choice[1-4?]: 4
warning: (ACPI_HOTPLUG_CPU) selects ACPI_CONTAINER which has unmet direct dependencies (ACPI && EXPERIMENTAL)
warning: (MEDIA_TUNER) selects MEDIA_TUNER_TEA5761 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_MEDIA && I2C && EXPERIMENTAL)
#
# configuration written to .config
#
warning: (GFS2_FS) selects DLM which has unmet direct dependencies (EXPERIMENTAL && INET && SYSFS && CONFIGFS_FS && (IPV6 || IPV6=n))
warning: (IMA) selects TCG_TPM which has unmet direct dependencies (HAS_IOMEM && EXPERIMENTAL)
warning: (MEDIA_TUNER) selects MEDIA_TUNER_TEA5761 which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_MEDIA && I2C && EXPERIMENTAL)
warning: (ACPI_HOTPLUG_CPU) selects ACPI_CONTAINER which has unmet direct dependencies (ACPI && EXPERIMENTAL)
root@[~src/linux] #

Now comes the most adventurous part!

Building the Kernel

# make -j8  bzImage
# make -j8 modules
# make modules_install
# make install


Building an initramfs or not?

The reason to build a kernel with an initramfs is mostly for interoperability (e.g. live-cd's) and special features like an included busybox, ssh, etc. But mostly, and that's why we are doing this here now, to have a proper kernel up and running quick'n dirty in a reasonable time without fighting hours and days until a more or less exotic hardware is perfectly run by the kernel. After having a proper basic kernel running with the help of an initramfs, I really recommend you to go a step further and build a true kernel with all features includes without an initramfs. But this could be pain in the ass and very time consuming - so we do it the funtoo way here - at least in the second example when we stick to better-initramfs instead of Red-Hat's dracut.

Option one: Initrd with dracut

To build the initrd we just execute

# dracut -f --fstab --xz /boot/initramfs-3.2.6-pf.img  3.2.6-pf

Generally, this really should be enough! If you experience booting problems like missing modules / drivers then just boot from the genkernel section and fix the initrd building. You can look into the man page to tweak the command a bit (e.g. --add-drivers "xz dm_crypt" etc...).

Ok let's go on and finish the taks, we are going to tell now grub how to boot off correctly!

# nano /etc/boot.conf

boot {
        generate grub
        default "Funtoo Linux dracut"
        timeout 3
}

"Funtoo Linux genkernel" {
        kernel kernel-genkernel[-v]
        initrd initramfs-genkernel[-v]
        params = quiet rootfstype=ext4
        params += luks enc_root=/dev/sda3
        params += lvm root=/dev/mapper/vg-root
}

"Funtoo Linux dracut" {
        kernel vmlinuz[-v]
## this is the better-initramfs generated initrd
        initrd initramfs[-v].img
        params  = quiet rootfstype=ext4
        params += luks enc_root=/dev/sda3
        params += lvm root=/dev/mapper/vg-root
}

That's it almost!

Now write to the grub.cfg with the new handy boot-update script from funtoo:

# boot-update -v
root@[~src/linux] # sudo boot-update -v

 boot-update 1.5.2 / Copyright 2009-2011 Funtoo Technologies

 [use option "-l" for license info, "-h" for help]

 * Generating config for grub...

 DEFAULT > Funtoo Linux - vmlinuz-3.2.6-pf
           Funtoo Linux genkernel - kernel-genkernel-x86_64-3.2.6-pf

 * Completed successfully.

Okay,... here you go..! :)

Reboot and see how it works!

Option two: using better-initramfs

Piotr's better-initramfs is another approach that is tiny, nice and shiny and seems to become more and more a favourite among funtoo'ers. The biggest plus is that, once built it is kernel version independant.

For using this you just do the following steps:

1. download sources
2. build kernel with "make bzImage"
3. download better-initramfs
4. run better-initramfs
5. adjust /etc/boot.conf

Here is how in detail:

Assuming you did install already a genkernel backup or at least you have a working bzImage + modules installed, we rush forward to step 3:

download better-initramfs

➜ # cd /usr/src/;
➜ # git clone https://github.com/slashbeast/better-initramfs.git

➜ # /src #  cd better-initramfs
➜ # better-initramfs git:(master) ls
AUTHORS    LICENSE   README.rst  bootstrap  output   sourceroot
ChangeLog  Makefile  TODO        examples   scripts

build the better-initramfs

➜ # better-initramfs git:(master) sudo bootstrap/bootstrap-all
Passwort: xxx 
# from here go and grab a coffee
➜ # sudo make prepare
➜ # sudo make image
➜ # sudo mv output/initramfs.cpio.gz /boot

adjust grub

Taking the above setup we edit the /etc/boot.conf as I installed genkernel first, and dracut after - you see this setup:

boot {
        generate grub
        default "Funtoo Linux"
        timeout 3
}

# Rootfs over lvm over luks
# /dev/sda3 - encrypted lvm's pv
# /dev/mapper/vg-root - rootfs's lv

"Funtoo Linux" {
        kernel bzImage[-v]
## this is the better-initramfs generated initrd
        initrd initramfs.cpio.gz
        params  = quiet rootfstype=ext4
        params += luks enc_root=/dev/sda3
        params += lvm root=/dev/mapper/vg-root
}

"Funtoo Linux dracut" {
        kernel vmlinuz[-v]
## this is the dracut generated initrd
        initrd initramfs[-v].img
        params  = quiet rootfstype=ext4
        params += luks enc_root=/dev/sda3
        params += lvm root=/dev/mapper/vg-root
}


"Funtoo Linux genkernel" {
        kernel kernel-genkernel[-v]
        initrd initramfs-genkernel[-v]
        params = quiet rootfstype=ext4
        params += luks enc_root=/dev/sda3
        params += lvm root=/dev/mapper/vg-root
}

Okay,... here you go..! :)

update the grub.cfg, then reboot and see how it works!

root@[~src/linux-3.2.6-pf] # boot-update -v     

 boot-update 1.5.2 / Copyright 2009-2011 Funtoo Technologies

 [use option "-l" for license info, "-h" for help]

 * Generating config for grub...

 DEFAULT > Funtoo Linux better-initramfs - vmlinuz-3.2.6-pf
           Funtoo Linux dracut - vmlinuz-3.2.6-pf
           Funtoo Linux genkernel - kernel-genkernel-x86_64-3.2.6-ck

 * Completed successfully.

root@[~src/linux-3.2.6-pf] #

root@[~src/linux-3.2.6-pf] # reboot

System going down for reboot!