Kushal Koolwal’s Debian Linux Blogs

Purpose:

If you have been using Linux for over two to three years than chances are that you may have been in a situation where you need to modify your Kernel’s Makeconfig or Kconfig files or adding a new device driver for your hardware from your hardware vendor which is not yet into the mainstream kernel (www.kernel.org).

Once you do all of the above then you may need to generate a patch (for the changes that you just made) so that other users can simply apply that patch rather than going into the kernel sources and manually modify all those files. This blog posting will explain in a simple way how you can do that. Although I think there might be several postings which will explain you how to do that but they may not be clear or may not cover your case specifically.

Let’s start with an example:

I downloaded Kernel source 2.6.24 into my /usr/src/linux directory. Suppose I need to add a framebuffer driver support, say for example, for my VIA’s Unichrome Graphic chipset. I copy the framebuffer driver source directory (provided by VIA) into my kernel directory as follow:

cd /usr/src/linux

cp -a /usr/src/fbdev-via-unichrome /usr/src/linux/driver/video/via

Note: The directory /usr/src/linux/driver/video/via did not existed when we installed 2.6.24 kernel source initally.

After this suppose we need to make changes to files Kconfig and Makefile in /usr/src/linux/drivers/video directory.

Say I add the following line in the Makefile:

obj-$(CONFIG_FB_VIA) += via/

and the following line in the Kconfig:

config FB_VIA
tristate “VIA UniChrome/Chrome 9 HC display support”
depends on FB && PCI
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
select FRAMEBUFFER_CONSOLE
help
This is the frame buffer device driver for the VIA CLE266, CN400, CN700, CN800,
CN896, CX700, PMN800, PMN880, P4M800CE-Pro, P4M890, P4M900, VN800, VN896 and
VX700 chipsets.

The above are examples from the www.viaarena.com website.

That’s it! Our kernel is now ready to be compiled and installed to get the framebuffer support for the VIA graphic chipset. However, what if there are several users who want to do the same since they also happen to have the same VIA graphic chipset and the driver has still not made into the mainstream kernel.

Here are the steps to generate a patch after your making your own Kernel modifications:

Step 1: Download and prepare kernel sources

Download again the 2.6.24 kernel source (same as you did above) against which you want to build the patch and name directory to something like linux-pristine. For example, your /usr/src directory should now look something like this:

debian:/usr/src# ls -l

total 57316

drwxr-xr-x 20 root root 4096 2008-02-11 03:48 linux-pristine

drwxr-xr-x 20 root root 4096 2008-02-11 03:48 linux-source-2.6.24

lrwxrwxrwx 1 root src 19 2008-04-06 00:20 linux -> linux-source-2.6.24

debian:/usr/src#

Basically, you now have two kernel source 2.6.24 directories:

One with changes that you made to incorporate VIA’s framebuffer driver called as linux (a link to linux-source-2.6.24 directory)

and

the other original 2.6.24 kernel sources (straight from www.kernel.org website) that you just downloaded called as linux-pristine

Step 2: Clean both the kernel directories

We need to make sure that we remove any object or executables files in both the kernel directories. Give the following commands:

debian:/usr/src# cd linux
debian:/usr/src/linux# make mrproper
debian:/usr/src/linux# make clean
debian:/usr/src/linux# cd ../linux-pristine/
debian:/usr/src/linux-pristine# make mrproper
debian:/usr/src/linux-pristine# make clean
debian:/usr/src/linux-pristine#

Step 3: Generate patch

Now give the following commands to create the patch:

debian:# cd /usr/src

debian:/usr/src# diff -Nur linux-pristine/drivers/video/ linux/drivers/video/ > patch-2.6.24-viafb

The format of the diff command is:

diff -options oldfile newfile > patch

where -options = -Nur

oldfile = linux-pristine/drivers/video/

newfile = linux/drivers/video/

patch = patch-2.6.24-viafb

Your patch is now ready and you can view your patch by using your favourite editor like gedit, less, nano, etc.

debian:/usr/src# less patch-2.6.24-viafb

Step 4: Test your patch

We need to make sure that the patch we just generated is correct or now. There is a simple way to do it.

Make a temporary copy of your linux-pristine directory as follow:

debian:/usr/src# cp -r linux-pristine/ /tmp/linux-test-patch

Now patch this kernel source by the patch that you just created in Step 3 above.

debian: cd /tmp/linux-test-patch/

debian:/tmp/linux-test-patch# patch -p1 < /usr/src/patch-2.6.24-viafb

You should be seeing some output as follow:

*******************************
patching file drivers/video/Kconfig
patching file drivers/video/Makefile
patching file drivers/video/via/accel.c
… … … … … … … … … … … … … … … …
patching file drivers/video/via/via_utility.h
patching file drivers/video/via/vt1622a.c
patching file drivers/video/via/vt1622.c
patching file drivers/video/via/vt1625.c
patching file drivers/video/via/vt1636.c
patching file drivers/video/via/vt1636.h
debian:/tmp/linux-test-patch#

*******************************

Finally give the following command to test your patch:

debian:/tmp# diff -rq linux-test-patch/drivers/video/ /usr/src/linux/drivers/video/

If your patch was successfully created in Step 3 than you should not see any output after giving the above command. Basically the above command makes sure that there is no difference in any of the files after you patched your kernel.

Note: If you want to see the explanations of the options of the “diff” command, please see the man page:

debian:/ man diff

Step 5: Tell your users how to use your patch

Just ask your users to patch their 2.6.24 kernel by giving the following command:

debian:/usr/src/linux-source-2.6.24# patch -p1 < /usr/src/patch-2.6.24-viafb

Congratulations! You have successfully created a patch that you can distribute to other users who do not want to make changes manually to the kernel sources as you did initially. Treat yourself with something you like to eat or just sit back and relax and enjoy seeing people using your patch.

As usual, please leave a comment/feedback, if you have any.

I guess most of us who have been an ardent user of Linux O.S. must have seen dreaded “Kernel Panic” error messages at some point of time and generally those are very difficult to solve and takes away lot of time researching on it.There are many reasons for Kernel Panic error messages and one of them is related to ACPI and APCI, which I am going to talk about in this post. ACPI has superseded the old APM.

Typically you will see error messages like this:

“kernel panic - not syncing: VFS: unable to mount root fs on unknown-block(0,0)”

Solution

Try passing the following kernel parameters (all at once) in your GRUB (menu.lst) or LILO (lilo.conf) configuration file:

“acpi=off pci=noacpi noapic nolapic”

There are 90% chances that your problem will solve if it is related to ACPI and APIC. Once you can boot your system by giving above parameters, try eliminating each one of them, one by one, to find which parameter actually is required. However, there could be more than one parameter that you will end up using. For example, in my case I had to give “acpi=off nolapic” to resolve my Kernel panic error.

If you are still getting Kernel panic even after giving the above four parameters, then try these addtional parameters in permutation and combination with the above four to see if you resolve the issue:

“pnpbios, pci=usepirqmask, pci=biosirq”

If you are still not able to solve it, then I suspect that it might not be an APCI and ACPI related issue. However, I strongly encourage you to boot from a Knoppix live CD or Ubuntu live CD and look at the “Help” section before it starts booting. In the help section they suggest many kernel parameters that you may have to give because of broken firmware or buggy BIOS in order to boot your system.

In my next part of this post, I will explain and also give some useful pointers as to why we need to give those parameters to safely boot the Linux Kernel and how can we boot the kernel without giving those parameters because in some situation (when you are using a laptop) you simply cannot give up ACPI features.

Purpose:
I have been a fan of Debian Linux operating system since last 3 years. The purpose of this post is to continuously list issues that I was able to resolve either by asking the Open Source community or by researching on the Internet or just by playing around with the problem. I hope that this post will help many people to solve similar/same issues and thus will save their valuable time.

Issue #1 - Splashy not working; Splashy Error Messages during boot
Date: 02/25/2008

Package: Splashy (Version 0.3.8-1)

OS version: Debian GNU/Linux 4.0 (codename etch)

Kernel: 2.6.24 (Debian Source)

Error Messages:
Splashy Error: Connection refused
Splashy ERROR: Couldn’t splashy_start_splashy(). Error -2
Splashy ERROR: Couldn’t splashy_start_splashy(). Error -3
Splashy ERROR: Couldn’t splashy_start_splashy(). Error -7
Cannot create /dev/fb0 or No such device

Also see this posting in which I posted my query to the splashy mailing list.

Resolution:
Rename /etc/rcS.d/S03udev to /etc/rcS.d/S03audev.

Command to be given:

debian# mv /etc/rcS.d/S03udev /etc/rcS.d/S03audev.

You can test whether splashy is working properly or not by giving the following command:

debian# splashy test

The above solution was suggested by Mike Kelland who happens to be on the same splashy mailing list as I am.

Also some of you might be wondering how to install splashy on Debian stable (Etch) since Splashy is only available in Lenny and Sid repository as of this writing. Please see my post on how to install splashy on Debian Stable.

Update:

Ok, you must be wondering why this issue occurs in the first place, right? Why don’t the developers fix this issue?

Here is mystery:
The way splashy is supposed to work is that it should start from initramfs (which superseded initrd) in the 2.6 kernel series. What is the difference between initrd and initramfs? I think that deserves a separate post/entry (may be for some later time, eh?). Any how, if you use initramfs to boot your kernel then you should not get any error messages. Debian system by default likes to use am initramfs during boot, but many people do not prefer to use an initramfs during the boot and thus built all the support for IDE controller and Filesystems into the Kernel itself (instead of modules), just like the way I like it. This is how you make your boot process free from using initramfs.

So in short if you don’t see an “initrd” entry into your /boot/grub/menu.lst, for example:

title Debian GNU/Linux, kernel 2.6.18-4-686
root (hd0,0)
kernel /boot/vmlinuz-2.6.18-4-686 root=/dev/hda1 ro

instead of

title Debian GNU/Linux, kernel 2.6.18-4-686
root (hd0,0)
kernel /boot/vmlinuz-2.6.18-4-686 root=/dev/hda1 ro
initrd /boot/initrd.img-2.6.18-4-686

it means that you are not using initramfs and you should follow the tip mentioned in the resolution section above.

Note: It is important to know that while the menu.lst file still says “initrd”, it actually means “initramfs”. For some reasons it is still being called by this name even when they switched to newer much improved “initramfs” in 2.6 Kernel. This thing kept me confused for a long time until someone just mentioned in one of my query.

In conclusion, if you don’t use initramfs/initrd during your boot process, then udev and splashy interferes with each other and you have to make sure that splashy is being called after udev script in the /etc/rcS.d directory. The only disadvantage is that you might end up seeing some text messages before splashy actually loads itself.

Also, I had a discussion with one of the splashy developer/maintainer regarding this issue which might give you further insight.

Issue #2 - Ethernet card does no get IP address

Coming soon…

As usual, please leave a comment/feedback.