x86 / linux boot process

There is quite a bit of documentation around the internet on the linux boot process, but Gustavo Duarte I think did an excellent job describing this in a clear and concise way.  He also has several links to the Linux  kernel source code and describes what is occurring step-by-step through the bootstrap phase all the way to the execution of /sbin/init.

His first entry lays the foundation of the basis of the x86 Intel chipset, memory map, and logical motherboard layout.   This provides a basic understanding about the traditional hardware motherboard implementations.

Next, he describes BIOS initialization, and loading of the MBR.  This briefly touches on the boot loader which starts the Linux bootstrap phase.

Finally, the kernel boot process is detailed with links to C and Assembly source code, with a brief narrative of exactly what is happening.

This was an awesome description of the early-on start up and initialization phases of hardware and bootstrapping of the O/S.  Gustavo provides a great description of real-mode and protected-mode CPU states.

Thanks Gustavo!

/proc/cpuinfo CPU flags?

Ever wonder what those CPU flags meant when looking at /proc/cpuinfo?

Check out cpufeature.h under /usr/src/kernels/<kernel>/include/

It’ll give you a basic description of what you’re looking at.

$ pwd
/usr/src/kernels/2.6.18-92.el5-i686/include
$ find . -name cpufeature.h
./asm-i386/cpufeature.h

$ grep flags /proc/cpuinfo
flags           : fpu tsc msr pae mce cx8 apic mtrr mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid xtpr

So what is fxsr?

$ grep -i fxsr /usr/src/kernels/2.6.18-92.el5-i686/include/asm-i386/cpufeature.h
#define X86_FEATURE_FXSR        (0*32+24) /* FXSAVE and FXRSTOR instructions (fast save and restore */
/* of FPU context), and CR4.OSFXSR available */

A bit of Linux humor

While catching up with some posts on the CentOS mailing list, I came across a post from a person who had managed to hose up his system by forcefully installing several RPMs. The user was using Oracle’s unbreakable Linux, and installing the RPMs had really done a number on his package repositories. I laughed silly when I read Jim Perrin’s response to the users plea for help:

Original poster> Hi, everyone, I have one conflict problem when I try to install Centos YUM
Original poster>on RHEL 4_X 86_64.

Original poster> Uname -a shows:

Original poster> Linux PT3 2.6.9-42.0.0.0.1.ELsmp #1 SMP Sun Oct 15 15:13:57 PDT 2006 x86_64
Original poster> x86_64 x86_64 GNU/Linux

Jim’s reply> This isn’t a RHEL kernel. This is the Oracle Unbreakable Linux kernel.
Jim’s reply> Congrats, you broke it.

Ahhhhhh — the humor we geeks find in the little things. :)

Making sense of libfoo.so.2.6 on Linux systems

If you have ever done a long listing of /usr/lib on a Linux system, you probably choked and asked yourself what the f$%^ is this mess? After reading through Peter Seebach’s article Dissecting Shared Libraries, things don’t seem so bad, and the large number of files actually starts to make sense. Step one in sorting out the library madness requires making sense of the digits (the major and minor revision numbers) that appear in the shared library file name. Peter’s article clarifies this with the following description:

“One of the potential advantages of dynamic linking, however, is in fixing bugs. It’d be nice if you could fix a bug in the library and not have to recompile a thousand programs to take advantage of that fix. So sometimes, you want to link to a newer version. Unfortunately, that creates some cases where you want to link to the newer version and some cases where you’d rather stick with an older version. There is a solution, though — two kinds of version numbers:

  • A major number indicates a potential incompatibility between library versions.
  • A minor number indicates only bug fixes.

So under most circumstances, it is safe to load a library with the same major number and a higher minor number; consider it an unsafe practice to load a library with a higher major number.”

This makes sense, and seems like a good thing for systems that don’t want to break applications. Now what about all those links in /usr/lib? Peter provides the following description:

To prevent users (and programmers) from needing to track library numbers and updates, the system comes with a large number of symbolic links. In general, the pattern is that

libexample.so

will be a link to

libexample.so.N

in which N is the highest major version number found on the system. For every major version number supported,

libexample.so.N

will be a link in turn to

libexample.so.N.M

in which M is the largest minor version number.

If you haven’t checked out IBM’s redbook or Linux developerworks sites, I highly recommend doing so. There are numerous awesome pieces of documentation spanning numerous technologies.