HOWTO: Customising/Upgrading the Kernel - An Evolving HowTo

Well, I'm currently creating an ISO after having followed this. A couple of notes:

* I'm installing kernel 2.14.2

* I used the cloop-2.02 sources, and had no problems. The 2.01.5 sources gave errors.

* I'm using unionfs 1.1.1. This requires installing e2fslibs-dev. You might note that.

* unionfs compiled to the point where I have a unionfs.ko, but there was a subsequent error. I'm assuming all I need is the kernel module, so I expect this is not a problem. If the error is a usual thing, you might note it.

* cloop.ko and unionfs.ko would not fit in minirt without deleting most scsi modules, even though I deleted the pre-existing cloop.ko, cloop.o and unionfs.ko. This was a surprise. I compiled the smallest unionfs.ko I could. Hoping for the best.

I'll report back once I know whether or not it works. Thanks, M.


OK, just tried to QEMU boot the ISO image, and no luck. Right after creating the ramdisk, it crashes saying UNABLE TO UNITE READ-ONLY MEDIA AND INITIAL RAMDISK

So, it seems those errors with unionfs compile may have been important after all.

Which Knoppix version is your base?
Sounds like post 3.8 because you already have unionfs in there.

If you are after a 2.4.x kernel, why not use Knoppix 3.7?
Of course you still need to add unionfs if that's what you're after, but maybe it's worth a try.

nibl

Quote:

---

Originally Posted by mcreel

Well, I'm currently creating an ISO after having followed this. A couple of notes:

* I'm installing kernel 2.14.2

* I used the cloop-2.02 sources, and had no problems. The 2.01.5 sources gave errors.

* I'm using unionfs 1.1.1. This requires installing e2fslibs-dev. You might note that.

* unionfs compiled to the point where I have a unionfs.ko, but there was a subsequent error. I'm assuming all I need is the kernel module, so I expect this is not a problem. If the error is a usual thing, you might note it.

* cloop.ko and unionfs.ko would not fit in minirt without deleting most scsi modules, even though I deleted the pre-existing cloop.ko, cloop.o and unionfs.ko. This was a surprise. I compiled the smallest unionfs.ko I could. Hoping for the best.

---

Just highlighting what is said in the introduction " The document will assume remastering of Knoppix since the inception of UnionFS and the solitary 2.6.x kernel. In time, support for more historic versions may be incorporated. "

Quote:

---

Originally Posted by mcreel

Well, I'm currently creating an ISO after having followed this. A couple of notes:
I'll report back once I know whether or not it works. Thanks, M.

---

Whilst it was not my intention to write support for 2.4.x kernels initially, I will appreciate and accept any of your findings.

Now moving on to your current problems:

1. I'm installing kernel 2.14.2
Becuase you are using a 2.4.x kernel, when compiling kernel modules the extension you will be looking for is the .o extension and not the .ko modules. The .ko extensions were introduced when the 2.6.x kernels were released.

2. I used the cloop-2.02 sources, and had no problems. The 2.01.5 sources gave errors.
Excellent, just remember you are after the .o module and not the .ko module.

3. I'm using unionfs 1.1.1. This requires installing e2fslibs-dev. You might note that.
Noted, I'll update the howto as soon as I get a chance to play with the new sources. I'll probably throw the current snapshot of 2.6.15 on at the same time ... can you tell I love a new kernel update. :D

4. unionfs compiled to the point where I have a unionfs.ko, but there was a subsequent error. I'm assuming all I need is the kernel module, so I expect this is not a problem. If the error is a usual thing, you might note it.
For the 2.4.x kernels I believe the way to compile is doing a

Code:

---

make unionfs2.4

---

5. cloop.ko and unionfs.ko would not fit in minirt without deleting most scsi modules, even though I deleted the pre-existing cloop.ko, cloop.o and unionfs.ko. This was a surprise. I compiled the smallest unionfs.ko I could. Hoping for the best.
Did you try stripping the module using

Code:

---

strip --stripuneeded

---

This can give save you some valuable bytes. I am in the middle of writing another howto for converting the current initrd version of minirt to an initramfs version. With initramfs, its a not a static block iamge but rather a compressed cpio image, very cool.

I maintain a filesytem of the minirt and with my remaster scripts it's as simple as doing a make.minirt and I have a current version of my minirt file.

Quote:

---

Originally Posted by firnsy

Just highlighting what is said in the introduction " The document will assume remastering of Knoppix since the inception of UnionFS and the solitary 2.6.x kernel. In time, support for more historic versions may be incorporated. "

---

Sorry, 2.14.2 was a typo, I meant 2.6.14.2, the current latest release.

(snip)

Quote:

---

Originally Posted by firnsy

Excellent, just remember you are after the .o module and not the .ko module.

---

Right, I got the .ko file.

Quote:

---

Originally Posted by firnsy

I maintain a filesytem of the minirt and with my remaster scripts it's as simple as doing a make.minirt and I have a current version of my minirt file.

---

Maybe you wouldn't mind posting that :D

To summarize, I start with Knoppix 4.0.2, and I'm trying to install a 2.6.14.2 kernel (vanilla, unpatched). I'm using unionfs 1.1.1 and cloop 2.02, I compile cloop without problems, and unionfs to the point where I have the unionfs.ko file, but then there are errors which I assume are other parts of the unionfs infrastructure. The unionfs.ko file is 1597111 bytes, and I need to delete most of the scsi modules to fit it into the minirt. The new ISO starts to boot, but crashes when attempting to merge the read-only and writable media (unionfs). So it seems like I have a unionfs problem. BTW, the unionfs.ko module needs to be in /lib/modules/2.6.14.2/kernel/fs, correct? Does cloop need to be there too? (I don't have it there - maybe that's the problem. Actually, I don't have _ANY_ modules there, except unionfs. So I think I have a make modules_install problem. I'll go back and try again.

Thanks, M.

After downloading the 2.6.14.2 kernel and unionfs-1.1.1 source I went through the howto. I no longer use cloop (replaced with squashfs) but you say you had no problems with 2.02 i'm not sure of your 2.01-5 compilation problems but I was able to compile my 2.01-5 source just fine. Anyways that is not the issue.

After the initial build of the kernel (i386 default) and subsequent compilation of unionfs-1.1.1 I noticed a warning when compiling the module regarding "__rcuref_hash" not being defined. Since it's a warning its still compiles giving you the unionfs.ko. However, attempting to insmod or modprobe this module will generate an error, of which after a dmesg you notice that the "__rcuref_hash" is causing the problems.

After some examintaion of what "__rcuref_hash" may do I found some connection between it and the CMPXCHG flag for the kernel. Knowing that the CMPXCHG is only valid for 486+ hardware, I recompiled the kernel with 486 default, I then recompiled unionfs and bingo it worked. It would seem that it was the kernel with the issue, perhaps some additional error checking is required with the unionfs source to accomodate for this. Anyways give the 486 default a go and let me know how you get on.

Quote:

---

Originally Posted by mcreel

* I'm using unionfs 1.1.1. This requires installing e2fslibs-dev. You might note that.

---

This was not required to enable unionfs, can you point me to the reference indicating this?

From the unionfs 1.1.1 README:

"You also need to have the headers for e2fsprogs installed, on Red Hat
derived systems (like Fedora Core), this means that you need to have
e2fsprogs-devel installed."

Maybe this is not important if all we need is unionfs.ko. Thanks for the hint about 486, I'll give it a try.

Quote:

---

Originally Posted by mcreel

From the unionfs 1.1.1 README:

"You also need to have the headers for e2fsprogs installed, on Red Hat
derived systems (like Fedora Core), this means that you need to have
e2fsprogs-devel installed."

Maybe this is not important if all we need is unionfs.ko. Thanks for the hint about 486, I'll give it a try.

---

That's why I would never find it ... who reads the README files :lol:

Given that Knoppix is Debian based, I anticipate the e2fsprogs headers are already available given that I didn't require any extra package installation.

With the latest 2.6.14.x kernels there is a problem compiling the unionfs.ko module in that it produces a warning message regarding "__rcuref_hash" not being a valid symbol. In fact with closer inspection it also cripples the nfsd modules as well as one of the generic usbe modules. I have been churning over this the last few days and alas have finally found a solution.

With your newer 2.6.14.x kernel you will need to edit kernel/rcupdate.c in the linux tree, with the two lines prefixed with a "+" below.

Code:

---

--- linux-2.6.14.3/kernel/rcupdate.c        2005-11-29 14:53:02.000000000 +1100
+++ linux-2.6.14.x-unionfs/kernel/rcupdate.c        2005-11-29 14:51:39.000000000 +1100
@@ -84,6 +84,8 @@
 spinlock_t __rcuref_hash[RCUREF_HASH_SIZE] = {
        [0 ... (RCUREF_HASH_SIZE-1)] = SPIN_LOCK_UNLOCKED
 };
+
+EXPORT_SYMBOL(__rcuref_hash);
 #endif
 
 /**

---

Alternatively if you hadn't guess you could build a patch file with the above text and use it that way. That being said I can't provide any guarantee for damage it may cause, the howto will be updated pending further tests.

Enjoy.

Quote:

---

Originally Posted by firnsy

<snip>


At this point I will apply any patches I want to use in the kernel, for example squashfs, gensplash, etc. Once the kernel is patched to your liking it is time to configure it. To ensure the new kernel is baselined from the Knoppix kernel I use the Knoppix config as the baseline. Taking Knoppix version 3.8.1/2 as an example, and using the default options that popup:

Code:

---

cp /boot/config-2.6.11 .config
make oldconfig
make menuconfig
make modules
make modules_install

---

<snip>

I don't do a 'make install' cause I find it simpler to just copy what I need.

Code:

---

cp arch/i386/boot/bzImage /boot/vmlinuz-2.X.YY
cp System.map /boot/System.map-2.X.YY
cp .config /boot/config-2.X.YY

---

---

In this section you never actually make the kernel, which could be confusing to someone who hasn't ever done it before.

I'm trying to compile 2.6.14.3 kernel using make-kpkg kernel_image but not succeeded. Compiling goes fine until making modules.

I tried to make modules also like this with the same errors:

Code:

---

root@3[linux]# make modules
  CHK    include/linux/version.h
  CC [M]  drivers/net/wan/sdladrv.o
drivers/net/wan/sdladrv.c: In function 'peek_by_4':
drivers/net/wan/sdladrv.c:962: warning: passing argument 1 of 'readb' makes pointer from integer without a cast
drivers/net/wan/sdladrv.c:968: warning: passing argument 1 of 'readl' makes pointer from integer without a cast
drivers/net/wan/sdladrv.c:976: warning: passing argument 1 of 'readb' makes pointer from integer without a cast
drivers/net/wan/sdladrv.c: In function 'poke_by_4':
drivers/net/wan/sdladrv.c:1044: warning: passing argument 2 of 'writeb' makes pointer from integer without a cast
drivers/net/wan/sdladrv.c:1050: warning: passing argument 2 of 'writel' makes pointer from integer without a cast
drivers/net/wan/sdladrv.c:1058: warning: passing argument 2 of 'writeb' makes pointer from integer without a cast
drivers/net/wan/sdladrv.c: In function 'sdla_start':
drivers/net/wan/sdladrv.c:1481: warning: passing argument 2 of 'writeb' makes pointer from integer without a cast
drivers/net/wan/sdladrv.c: In function 'detect_s514':
drivers/net/wan/sdladrv.c:2002: error: invalid lvalue in assignment
drivers/net/wan/sdladrv.c:2015: warning: passing argument 2 of 'writeb' makes pointer from integer without a cast
make[3]: *** [drivers/net/wan/sdladrv.o] Error 1
make[2]: *** [drivers/net/wan] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
root@3[linux]#

---

What goes wrong?


-tapsa-