Lesson 2: Kernel-related files, directories and commands

Printer-friendly versionPrinter-friendly version

Before we get into configuring and building your new kernel, let's do a quick overview of what should already be on your Linux development host since, after you build and reboot a new kernel, part of the validation will be to check that all of the right pieces ended up in all the right places. Let's start with the kernel-related files and directories.

First, there's the /boot directory, which contains all boot-related kernel goodies. A quick check under there will show files of the form:

  • vmlinuz-*: The actual "compressed" Linux kernel (technically, not just compressed, there's more to it than that but, for now, we can be sloppy with our terminology).
  • initrd.img-*: An initial "ramdisk" for your kernel -- we won't get into that just yet but remember that it's there as it will show up in an upcoming lesson.
  • config-*: The "config" file that was used to configure the respective kernel -- you'll be looking at those later when you need to do an initial configuration.

Note well that, depending on how busy you've been, you might have several bootable kernels in that directory.

Next, we have the /lib/modules directory, which will contain one subdirectory of loadable modules per bootable kernel. I've kept a few standard Ubuntu kernels, plus configured and built one myself, so the contents of that directory on my system looks like:

$ cd /lib/modules
$ ls -1
3.3.0-rc7            <-- my hand-rolled kernel

Finally, there is the /proc directory which we'll mention only in passing for the moment, but if you pop in there, simply listing the contents of some of the more obvious files will tell you all sorts of interesting facts about your system:

$ cd /proc
$ cat version
Linux version 3.3.0-rc7 (rpjday@oneiric) ...
$ cat cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 42
model name      : Intel(R) Core(TM) i7-2630QM CPU @ 2.00GHz
... etc etc ...

While this directory (the "proc filesystem") will be covered in considerable detail in a future lesson, it's worth understanding at least the following. Those wonderfully informative files in /proc aren't really "files" as you normally understand them. If you check their attributes, they appear to have zero size:

$ ls -l cpuinfo
-r--r--r-- 1 root root 0 2012-03-12 14:52 cpuinfo

That's because they're not regular files. At the risk of over-simplification, what they represent are "windows" from user space into kernel space, where the simple act of listing them is translated into a call into kernel space, where a corresponding routine then calculates the output that will be passed back to the user. In short, think of them as callbacks and you won't be far wrong.

In addition to the files and directories above, there are a few commands you can use to check properties of the currently running kernel. We'll keep this list short for now. First, you can list various properties of the running kernel with:

$ uname -a
Linux oneiric 3.3.0-rc7 #1 SMP Mon Mar 12 11:21:17 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux

You can also list the currently loaded kernel modules:

$ lsmod
Module                  Size  Used by
nls_iso8859_1          12713  1 
nls_cp437              16991  1 
vfat                   17461  1 
fat                    61230  1 vfat
rfcomm                 46622  8 
bnep                   18144  2 
kvm_intel             132467  0 
... and so on and so on ...

That's really all you need for now, but remember these locations and commands since you'll use them again to see what's changed after you build and boot a new kernel.

Coming up next ... getting the kernel source.


  1. Spend some time wandering around the /proc directory, and list any file that looks interesting. Try to interpret its contents. What happens if you try to write to or edit one of those files?
  2. Take a look at the man page for the uname command and see how you can ask for very specific information about the current kernel.
  3. Are there any other commands you can think of that will tell you about the running kernel, and that would be useful to run again after booting a new kernel to see the differences?


dmesg is rather informative

Is dmesg worth mentioning in this section?

A 'dmesg | less' provides quite a view into the kernel's early boot output that's usually hidden with the 'quiet' boot argument in favor of pretty splash screens.

Yes, dmesg is useful, but not just yet.

I'll definitely be covering "dmesg" in detail in a future lesson. While it's useful, it's not technically necessary for this lesson so I quietly avoided it.

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd> <p> <br> <pre> <h1> <h2> <h3> <h4>
  • Lines and paragraphs break automatically.

More information about formatting options

By submitting this form, you accept the Mollom privacy policy.