Compile Linux Kernel 2.6

I have never done a blog on "kernel" compile in the past and with the growing ease of using Linux nowadays one would ask.  Who needs compiling it? Apparently, it has its uses and for those experimenting with Linux and or maybe doing a sort of review, prior to taking an exam.  I came across this wonderfully crafted easy to use kernel compile tutorial.  When I sifted through it, I realised how simple it was to compile Linux kernel.

I am taking this opportunity to re-post this article for purposes of good archiving as with all my other post.  I look for a candidate where I can equally enjoy and have the luxury of messing up the system if something goes wrong it won't be a big deal.  The target machine was a debian lenny 5.0 which I just downloaded (11-28-2010).  Installed the base and configured networking to set the stage. Read on.

How to: Compile Linux kernel 2.6

Compiling custom kernel has its own advantages and disadvantages. However, new Linux user / admin find it difficult to compile Linux kernel. Compiling kernel needs to understand few things and then just type couple of commands. This step by step howto covers compiling Linux kernel version 2.6.xx under Debian GNU Linux. However, instructions remains the same for any other distribution except for apt-get command.

Step # 1 Get Latest Linux kernel code

Visit http://kernel.org/ and download the latest source code. File name would be linux-x.y.z.tar.bz2, where x.y.z is actual version number. For example file inux-2.6.36.1.tar.bz2 represents 2.6.36.1 kernel version. Use wget command to download kernel source code:
$ cd /tmp
$ wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.36.1.tar.bz2
Note: Replace x.y.z with actual version number (in my case its the actual current kernel on the site).

Step # 2 Extract tar (.tar.bz2) file

Type the following command:
# tar -xjvf linux-2.6.36.1.tar.bz2 -C /usr/src
# cd /usr/src

Step # 3 Configure kernel

Before you configure kernel make sure you have development tools (gcc compilers and related tools) are installed on your system. If gcc compiler and tools are not installed then use apt-get command under Debian Linux to install development tools.
# apt-get install gcc
Now you can start kernel configuration by typing any one of the command:

• $ make menuconfig - Text based color menus, radiolists & dialogs. This option also useful on remote server if you wanna compile kernel remotely.
• $ make xconfig - X windows (Qt) based configuration tool, works best under KDE desktop
• $ make gconfig - X windows (Gtk) based configuration tool, works best under Gnome Dekstop.

Step # 4 Compile kernel

For example make menuconfig command launches following screen:
$ make menuconfig
You have to select different options as per your need. Each configuration option has HELP button associated with it so select help button to get help.

Start compiling to create a compressed kernel image, enter:
$ make
Start compiling to kernel modules:
$ make modules
Install kernel modules (become a root user, use su command):
$ su -
# make modules_install


Step # 5 Install kernel

So far we have compiled kernel and installed kernel modules. It is time to install kernel itself.
# make install
It will install three files into /boot directory as well as modification to your kernel grub configuration file:

• System.map-2.6.36.1
• config-2.6.36.1
• vmlinuz-2.6.36.1

Step # 6: Create an initrd image

Type the following command at a shell prompt:
# cd /boot
# mkinitrd -o initrd.img-2.6.36.1 2.6.36.1
* In my case I used mkinitramfs -o initrd.img-2.6.25 (which ever version number of kernel you downloaded)

initrd images contains device driver which needed to load rest of the operating system later on. Not all computer requires initrd, but it is safe to create one.

Step # 7 Modify Grub configuration file - /boot/grub/menu.lst

Open file using vi:
# vi /boot/grub/menu.lst

title           Debian GNU/Linux, kernel 2.6.36.1 Default
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.36.1 root=/dev/hdb1 ro
initrd          /boot/initrd.img-2.6.36.1 

savedefault
boot

Remember to setup correct root=/dev/hdXX device. Save and close the file. If you think editing and writing all lines by hand is too much for you, try out update-grub command to update the lines for each kernel in /boot/grub/menu.lst file. Just type the command:
# update-grub 
... Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
Found kernel: /vmlinuz-2.6.36.1
Found kernel: /vmlinuz-2.6.26-2-686
Updating /boot/grub/menu.lst ... done


Neat. Huh?

Step # 8 : Reboot computer and boot into your new kernel

Just issue reboot command:
# reboot

So depending on how you setup your menuconfig in the first part would dictate on how long the compile and the installation of the modules for the new kernel will take.  In my case its almost one day.  Good luck.


Notes:

1. If for example you experienced an error during the initial "make" chances are you have several packages that is missing one such package is the libncurses5-dev (if you are using debian based system) package.
2. Make sure you have enough disc space on the directory you will be building the sources, in my recent experience, I needed at least 6Gb of free space under /usr/src to get it done.

Understanding Priority Issues Impacting Business Operations

Huge enterprises have a network of complex policies that tightly knit together the business models and the support structure made of people managing technology tools.  The progression of decades in problem management/experience have lead to the creation of policies that provides a domino effect inherent in the support structure chain that responds immediately to certain events leading to a possible loss or something similar.  Thus change management came into the light along with risk management and systems audit management.  One of the most highly debunked support structure of this new areas in systems management was the creation of "Priority levels"

What are priority levels?  Priority levels are part of the change management chain and widely used by management and stakeholders to address issues on systems.

In this post I am going to detail a very important ingredient that highlights the life of a systems personnel (admins and developers alike),  addressing change management using priority levels.  It is my intention that a clear picture must be drawn, while discerning the events where priority levels take into account.

The P1 (Priority Level 1)  -- Response Time 1 hour (CRITICAL)

- Any major failure affecting an entire site/business or more than one device/server
- Business is loosing millions
- Impacting huge number of users

Priority level 1 is the most "CRITICAL" a  P1 is when you drop everything and focus on the problem.  However, this has been misused and abused by senior management who is paranoid of the fact of losing so much that isn't there.   I have seen and experience these scenarios happen in real life I myself was a victim of it!  To battle your way out those criteria must be present above to address a real P1 concern.  I hate it when P1 levels are brought down the test environment.  It's a complete mockery of the policy and virtually nothing to do with the real issues in dealing with those mentioned by definition.

Escalation:
 - Immediate notification to Engineers
-  Escalation direct to 3rd level Engineers
-  Escalation direct to Incident Manager / Senior Management

The P2 (Priority Level 2)  -- Response Time 8 hours  (HIGH)


- Incident affecting single, critical device/server
- Site/service functioning but performance is degraded.
- Affects only a small number of users.
- Incident during normal/critical period.

Priority level 2 P2 is considered "HIGH" importance is significant but requires that the issue be address within the business day span and not more than EOB (End of Business).  Normally, P2 will succeed a P1 in order of task to be undertaken.  A good example is when you have a key functionality in a system that is hampering expedient recourse to a given output or desired performance levels.  In my experience P2 issues in systems administration are the most "VAGUE" a P2 is raised due to a phenomenal behavior in the system which defies even the most prudent investigation procedure.  Often a fix is found by making the wrong decision for the right course of action, which eventually led to a key vulnerability issue or a kernel bug not yet known.

Escalation:
- Immediate notification to Help Desk Supervisor.
- Incident Manager also informed.
- Notification to Team leader/Manager if response SLA not met.


The P3 (Priority Level 3) -- Response Time 2 days (NORMAL)

- Normal service requests and incidents affecting non-critical device/server
- Site/service functioning but performance is degraded.
- Affects only a small number of end users.
- Incident during quiet period.

This level is a normal day to day affair that systems administrators must face. e.g. unlocking locked out users from the system, creation/removal of accounts.  Investigation to key services behaving normally and registered by the system however, unexpected results appear from time to time due to a bug in the code somewhere etc.  Tickets such as those pertaining to maintenance related works on the system take the course of this level.  Meaning an expected well define procedure is in place to execute a task which is about to happen.

Escalation:
- Notification to Team leader/Manager if response SLA not met.

Their is a P4 and P5 in some cases these levels are considered low and not-prioritized respectively.  Sysadmins are always at the forefront of making sure that the infrastructure supporting a sizeable application with huge monetary value is sitting on a very robust system.  Those levels presented above may or may hold true to your organizations use, but then again...management has the last say on where to put priorities especially if management has a good grasp of the technical workings involved (assuming your management team are former IT people).  Jack-of-all trades are the bane of most companies, again I will refer it to my previous post...http://myopensourcestints.blogspot.com/2010/05/law-of-multiplying-yourself.html.

If that is the case, then better throw in the towel and start looking elsewhere for an organization that respects these standards.


Reference:
http://as.exeter.ac.uk/media/level1/academicserviceswebsite/it/documents/PriorityMatrix.pdf

The Google 80/20 Innovation Model

What makes Google very  attractive place to work is because of the company's ability to bring out the best in its people.  This post is found in web and I am going to reiterate it here for purpose of good archive.  Read on!

Management Friday: Google’s 80/20 Innovation Model


This week I visited the “Googleplex,” Google’s 12,000 person Palo Alto campus. The trip gave me a lot of food for thought on innovation, work/life balance, recruiting, and employee retention. I’ll be posting on the work/life balance questions raised by my visit over the weekend; today I’m writing about Google’s 80/20 “innovation time off” (ITO) model, and how those of us in non-tech industries might apply the concept.

The ITO policy encourages Google employees to spend 80% of their time on core projects, and roughly 20% (or one day per week) on “innovation” activities that speak to their personal interests and passions. These activities may benefit the company’s bottom line – as in the case of Gmail, Google News, AdSense and Orkut. But more importantly they keep employees challenged and engaged in ways that aid retention and keep staff learning and growing.

A side note about why I think the 80/20 rule is especially interesting for working mothers. One of the reasons so many working mothers are unhappy with their jobs is the seemingly meaningless, frustrating, rote work that takes us away from our kids with little greater benefit.

Imagine a scenario where you could spend 20% of your time on projects that you think could benefit your company or world, and that you “own.” That could stimulate you to think differently and passionately about the other 80% of your work, leading to a more fulfilling professional experience. More fulfilling is good – it keeps mothers in the workplace. (I’ve written more about the importance of innovation in tough times here.)

Of course, this model works well for developers, engineers and other creative types. What about for the rest of us? Is there an 80/20 innovation model that could help your administrative assistant do his or her job better? Help middle managers make the leap more effectively to senior staff? Energize senior staff by offering mentoring and stewardship opportunities around such projects?

I say yes. I’ve talked before about how innovation is the key for companies surviving this economic downturn. I believe that more formal innovation policies and pipelines are critical not just for the high-tech and creative industries, but also for those of us in more traditional financial, non-profit, and management settings. Here are some thoughts on implementing an innovation policy in your workplace:

1. Create a formal process for project selection, monitoring, and evaluation. At Google they track innovation time and know exactly which projects are being pursued. Employees who want to take advantage of innovation time off should submit a brief proposal and timeline, and be able to articulate how they will measure success.

2. Don’t worry about failure. In some ways innovation, like so many other things, is a numbers game. You throw up 50 projects, and maybe one or two stick. Most will fail, but you can’t know which will work unless you try. Failure is a critical p[art of true innovation.

3. Start small. Successful pilot projects help to leverage support and build awareness. Encourage your employees to create scalable projects that can be launched with relatively little investment.

4. Let your staff shine. Champion good ideas by facilitating and advocating, but let your employee present directly to senior management. Managers benefit when CEOs see that they have recruited intelligent and insightful staff.

5. Manage expectations. Not every project can be seen to fruition – in fact 95% of projects generated by your innovation policy won’t go anywhere. You don’t want disappointed, disillusioned employees, so manage their expectations.

Interesting links on the 80/20 Innovation Time Off model:

* Scott Berkun talks about how and why the 80/20 model works.
* Scott Belsky talks about why the model is a good idea, even if 95% of Google revenues come from non-innovation business.
* Ron Wilson at Electronics Strategy, Design, News talks about why innovation has to go beyond the technical now more than ever.
* The HR Capitalist talks about recent developments at Google that are squeezing the innovation model.