HOWTO: Customising/Upgrading the Kernel - An Evolving HowTo

Printable View

Show 40 post(s) from this thread on one page

09-20-2005, 11:16 AM
firnsy

HOWTO: Customising/Upgrading the Kernel - An Evolving HowTo
HOWTO: Upgrading the kernel

News - Fri, 09 Jun 2006
* Finally updated using the semi-latest sources.

Change Log:
* Version 1.4 - Fri, 09 Jun 2006
Compiled using kernel version 2.6.16.20, additional information provided regarding cloop and unionfs compilation (thanks mcreel & hellospencer1).

* Version 1.3 - Sun, 02 Apr 2006
Summarised the solutions within the thread (thanks guys/girls??).

* Version 1.2 - Thu, 01 Dec 2005
Fixed ommission of making the actual kernel (thanks mcreel).

* Version 1.1 - Wed, 21 Sep 2005
Elaborated compilation of cloop and unionfs

* Version 1.0 - Tue, 20 Sep 2005
Initial write

Acknowledgements:
Snippets are taken from the "Knoppix Custom Kernel" wiki
* Daniel R. Tarsky
* Marc Haber
* Rich Ercolani

Contributing posters
* antoine.boutet
* hellospencer1
* mcreel
* meatwad
* tr

Disclaimer:
Always needed cause you just never know how people will interpret things. Please people, use this at your own risk. Whilst this method has and continues to work for me, I will not be held responsible for anything that might go wrong, due to an ommision or typo in this document. I too, like you, am human and do make mistakes.

Preface:
There are many excellent guides for remastering Knoppix on these forums. The better ones, continue to evolve such as UnderScore's at http://www.knoppix.net/forum/viewtopic.php?t=13867. The following should be used in conjuction with a Remastering Howto as it will not cover the requirements for establishing or finishing a remastering sesssion.

This howto is based on the way I replace kernels. I like nothing better than seeing a new kernel release over at kernel.org and upgrading my remaster to the bleeding edge. 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.

So you have downloaded your preferred version of Knoppix and there is a new kernel waiting at kernel.org, itching to be installed on your remaster. Taking Knoppix version 3.8.1/2 for example, it utlises the 2.6.11 kernel that has the command line properties patched to allow 512 characters instead of 256. And that's about it, it's exact configuration can be found at /boot/config-2.6.11 inside the compressed filesystem.

The miniroot
Knoppix utilises a special image file known as an Initial RAM Disk (inirtd) image (ie. minirt.gz) for bootup. The minirt.gz file is in fact a minitaure root environment for Knoppix. It has the essential elements of a minimal root filesystem and performs the folling process:
1. Probe the CD/DVD drive,
2. Find the compressed filesystem (on the CD),
3. Mount it,
4. Switch the boot process from the mini root environment to the now available (de)compressed filesystem.

A look inside the minirt.gz file will reveal a number of directories and symlinks. The directories are /cdrom, /etc, /mnt, /modules, /proc and /static. Everything else is symlinked to /KNOPPIX, which is where the compressed system image will be mounted once minirt has does it's job.

Aside from the symlinks, /modules and /static stick out as non-traditional directories. /static is where the special statically-linked ash shell resides, which also doubles as init and modutils. When miniroot is mounted as a boot/root environment, the kernel executes the linuxrc script on the 'root' of miniroot with the static ash-knoppix. Because ash-knoppix (or 'init' in this context) is statically linked with modutils, you may also need to recompile ash-knoppix to upgrade your modutils for any newer kernel versions that may require them. This is of course in addition to installing the new modutils in your Knoppix image source directory.

The only modules in the /modules folder are the cloop module for the system image, scsi modules in case you happen to boot your CD from a SCSI CD-ROM and unionfs for merging the CDROM with the RAMDisk.

As linuxrc executes, it attempts to find the compressed filesystem image (ie KNOPPIX) from the medium you are booting from (eg. CD-ROM, USB, etc). At this point the whole filesystem is still in ram, so the medium must first be mounted to access the compressed filesystem image. Once mounted, a second RAMdisk is created with a dynamic size (percentage of of available and free memory) which will be used for /home and /var directories. Finally, cloop.o is loaded into the kernel and the compressed system image is mounted on /KNOPPIX, making all the symlinks work as part of the root filesystem. Next, more symlinks are created and important system files are migrated to the RAMdisk so they can be written to if need be.

Once linuxrc is finished, it gives control back to the kernel init process which in turn starts running the rc boot scripts, most notably knoppix-autoconfig.

What are we going to replace/upgrade:
OK, the big issue with upgrading the kernel is that people are not always certain of what has to be replaced. If they encounter an error they first assumption is that not everything essential has been replaced. From my experience, in short, the steps are:

For the compressed filesystem (ie chroot environment, /source)
1. Untar linux source
2. Apply any patches
3. Perform a make, make modules and make modules_install
4. Copy bzImage, System.map and update symlinks in boot

For the miniroot image (ie /master)
1. Copy bzImage
2. Update modules with those created when compiling (eg. cloop, unionfs, etc).

In short, that is it ... now for a little elaboration

Compressed Filesystem (chroot environment)
In your chroot environment you need to extract your linux kernel source (eg. version 2.X.YY) to the /usr/src directory. It's always good to point the linux symlink to the working source.

Code:

tar -xjf /path/to/linux-2.X.YY.tar.bz2 -C /usr/src cd /usr/src ln -s linux-2.X.YY linux cd linux

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 make modules make modules_install

If you are unable to 'make oldconfig' or 'make menuconfig' becuase it borks with errors then it is likely that you just need to set up the asm symlink as follows:

Code:

cd include ln -s asm-i386 asm cd ..

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

Update the boot symlinks

Code:

cd /boot rm config System.map vmlinuz ln -s config-2.X.YY config ln -s System.map-2.X.YY System.map ln -s vmlinuz-2.X.YY vmlinuz

At this point you will need to obtain both the cloop and unionfs sources to ensure compatibilty with the new kernel. For this we will be using cloop-2.02-1 and until a stable unionfs 2.X release we will use the snapshot 20060503-0408, but you may use later (bleeding edge :twisted:) You can obtain these sources from:
- ftp://ftp.fsl.cs.sunysb.edu/pub/unio...03-0408.tar.gz
  ftp://debian.lcs.mit.edu/debian/pool...2Beb.10.tar.gz
I extract them to the /usr/src/modules directory for clarity.

Code:

tar -xzf /path/to/cloop-source.tar.gz -C /usr/src/modules tar -xzf /path/to/unionfs-source.tar.gz -C /usr/src/modules cd /usr/src/modules

Compiling cloop
When compiling cloop, you no longer require the conf.vars file (resides in /usr/src/linux), instead you can simply edit the cloop Makefile to specify the name of your kernel. Using 'vi' or your favourite equivalent text editor, open the Makefile.

Code:

cd cloop-XX.YY vi Makefile

Edit the line below to read the version of the kernel you are upgrading to (2.X.YY)

Code:

#!/usr/bin/make KVERSION=2.6.16.16-pk1 # Edit this to your new kernel version KERNEL_DIR=/lib/modules/$(KVERSION)/build

Save and close the file and start the compiling process.

Code:

make

The 2.02-X sources should compile with no worries what so ever, however for historic purposes if you come accross the following compilation issue:

Quote:

cc -I/usr/src/linux/include -I/usr/src/linux/include/asm/mach-default -D__KERNEL__ -DMODULE -fno-builtin -nostdlib -DKBUILD_MODNAME="cloop" -DKBUILD_BASENAME="cloop" compressed_loop.c -c -o compressed_loop.o
compressed_loop.c: In function `clo_read_actor':
compressed_loop.c:205: error: structure has no member named `buf'
compressed_loop.c: In function `clo_read_from_file':
compressed_loop.c:231: error: structure has no member named `buf'
make: *** [compressed_loop.o] Error 1

Chances are you just need to modify, funnily enough as the previous output says, lines 205 and 231 of compressed_loop.c from:

Quote:

205: struct clo_read_data *p = (struct clo_read_data*)desc->buf;
231: desc.buf = (char*)&cd;

to

Quote:

205: struct clo_read_data *p = (struct clo_read_data*)desc->arg.buf;
231: desc.arg.buf = (char*)&cd;

With that done cloop should compile just fine and resulting in a cloop.ko module in the current directory.

Compiling unionfs
Now for unionfs, the compilation requires ctags to be installed, so you'll have to apt-get install it if you haven't got it already. Similarly we will edit the Makefile to point to our new kernel version as well as remove the debugging symbols to reduce the size. Again using your favourite text editor.

Code:

cd ../unionfs-snapshot-YYYYMMDD vi Makefile

Find and edit the lines as shown below.

Code:

# this should point to where your kernel headers are KVERS=2.6.16.16-pk1 # Change this to your new kernel version MODDIR= /lib/modules/$(KVERS) LINUXSRC = /lib/modules/$(KVERS)/build TOPINC = -I${LINUXSRC}/include # This is where the make install target will put stuff PREFIX = /usr/local MANDIR = ${PREFIX}/man MODPREFIX= VERSION=20060503-0408 TAROPTS = czvf COMPEXT = .gz UNIONFS_DEBUG_CFLAG = # Remove the -g if present to remove debuggin symbols

Save and close this file. To aid the compiling process we will also build the fistdev.mk for some additional options.

Code:

vi fistdev.mk

Add the contents shown below to the fistdev.mk file.

Code:

LINUXSRC=/usr/src/linux-2.X.YY TOPINC=-I$(LINUXSRC)/include MODDIR=/lib/modules/2.X.YY/build EXTRACFLAGS=-DUNIONFS_NDEBUG

Save, close and start the compilation process.

Code:

make unionfs2.6 make install

There has been a number of issues with unionfs sources and the 2.6.14.xx and 2.6.15.xx kernels (haven't experienced it in the 2.6.16.xx as yet) with the following error:

Quote:

unionfs: Unknown symbol __rcuref_hash
FATAL: Error inserting unionfs (/lib/modules/2.6.15/kernel/fs/unionfs/unionfs.ko): Unknown symbol in module, or unknown parameter (see dmesg)

Essentially unionfs source hasn't kept up with the kernel sources and is using a lower level function that is being phased out. A patch, which essentially makes this "Unknown Symbol" available is shown 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 /**

If you find that your module is too big, you may be able to scrape a few KB's off by stripping the module.

With that done you should now have a unionfs.ko to be used at a later stage.

At this point, it's your choice to leave the kernel source intact when building the compressed image, but be warned that it can take a large chunk of space. Now we've done the compressed filesystem, time to update the miniroot image.

Miniroot image (minirt.gz)
Just before we update the minirt.gz image, we need to update the linux kernel in the master directory. Just copy the new vmlinuz-2.X.YY to the master/boot/isolinux directory

If you don't need SCSI support or you don't need to boot from a SCSI CD-ROM, you can safely remove all the scsi modules. If you do so, be sure to comment out the 'SCSIMODULES=' section of linuxrc and replace it with SCSIMODULES="" so the script will skip SCSI autoprobing.

Now what I do is remove the current cloop.o and unionfs.o module from the modules directory. Then copy the newly compiled cloop.ko and unionfs.ko to the modules directory. Lastly a simply modification to linuxrc will see us load the newly named cloop.ko and unionfs.ko modules. Search for any reference to cloop.o (or cloop.*o) and change to cloop.ko. and similarly, search for unionfs.o (or unionfs.*o) and change to unionfs.ko.

That is it

Closing:
This HOWTO is in its infancy and will continue to evolve from any constructive feedback received. For now ... use it, abuse it, and let me know what you think.
09-20-2005, 03:14 PM
mcreel

This is great, nice and clear even if it's brand new. Many thanks. The only part that is not crystal clear to me is the part about compiling cloop and unionfs. If you could add links to where to get the source, and the step by step instructions to compile each, then I think the whole thing would be very clear. I recently tried to compile the cloop source from inside a remaster using kernel 2.6.12, and I saw some error messages, even though I carefully followed the README in the cloop source. So for me seeing the details would be nice.

Also, is it necessary to link /usr/src/linux/include/asm-i386 to /usr/src/linux/include/asm ? I don't remember now.

Thanks again!
09-21-2005, 01:14 AM
firnsy

Quote:

Originally Posted by mcreel

This is great, nice and clear even if it's brand new. Many thanks. The only part that is not crystal clear to me is the part about compiling cloop and unionfs. If you could add links to where to get the source, and the step by step instructions to compile each, then I think the whole thing would be very clear. I recently tried to compile the cloop source from inside a remaster using kernel 2.6.12, and I saw some error messages, even though I carefully followed the README in the cloop source. So for me seeing the details would be nice.

Also, is it necessary to link /usr/src/linux/include/asm-i386 to /usr/src/linux/include/asm ? I don't remember now.

Thanks again!

As requested .. Updated with an elaboration on the compilation of cloop and unionfs
09-22-2005, 12:38 PM
ATT

Thanks for this nice howto, but I have an additional challenge ...

My challenge: I cannot boot Knoppix > 3.4 in the first place, because, for example, Knoppix 3.8, Knoppix 3.9, Knoppix 4.0.1 and so on have a kernal that Oopses instantly because of my hardware-configuration in the first place. This is also true for ubuntu 5.04 boot-cds etc. The debian 3.1 Sarge loadmod also oopses (but the install continues, if needed).

The culprit is the Highpoint 372 IDE controller. Something is very flawed in this kernal code. No matter which kernal boot option I try, or if I try kernal 2.4 versus 2.6, etc. - it oopses.

Thus, I have to replace the Knoppix kernal from an environment _outside_ of Knoppix.

I could, for example, install SuSe 9.1 , or boot Knoppix 3.4 , ... and then what? How do I use this for replacing the Kernal out of the ISO image? Is there a tool available?
Or could I be so renitent as to simply use Total Commander's ISO file support to replace a few files inside the ISO and get my own compiled Kernal booting?

(Uh, I just tried this on the 4.4 gig Debian 3.1 Sarge ISO: I can't spot the kernal file. Uh-oh.)

Any help very appreciated.
09-24-2005, 06:28 AM
firnsy

Quote:

Originally Posted by ATT

Thanks for this nice howto, but I have an additional challenge ...

My challenge: I cannot boot Knoppix > 3.4 in the first place, because, for example, Knoppix 3.8, Knoppix 3.9, Knoppix 4.0.1 and so on have a kernal that Oopses instantly because of my hardware-configuration in the first place. This is also true for ubuntu 5.04 boot-cds etc. The debian 3.1 Sarge loadmod also oopses (but the install continues, if needed).

The culprit is the Highpoint 372 IDE controller. Something is very flawed in this kernal code. No matter which kernal boot option I try, or if I try kernal 2.4 versus 2.6, etc. - it oopses.

Thus, I have to replace the Knoppix kernal from an environment _outside_ of Knoppix.

I could, for example, install SuSe 9.1 , or boot Knoppix 3.4 , ... and then what? How do I use this for replacing the Kernal out of the ISO image? Is there a tool available?
Or could I be so renitent as to simply use Total Commander's ISO file support to replace a few files inside the ISO and get my own compiled Kernal booting?

(Uh, I just tried this on the 4.4 gig Debian 3.1 Sarge ISO: I can't spot the kernal file. Uh-oh.)

Any help very appreciated.

That's pretty crappy, but I don't believe all is lost.

You can remaster knoppix anywhere in any environment on any distribution you want, it's just easier to do from Knoppix.

1. You just need to download the cloop source code and compile the module for you remastering environment.

2. Mount the knoppix cd in your remastering environment (eg. /cdrom)

3. You should be able to see:
- miniroot.gz (eg. /cdrom/boot/isolinux/miniroot.gz)
- linux (eg. /cdrom/boot/isolinux/linux)
- KNOPPIX (eg. /cdrom/KNOPPIX/KNOPPIX)

4. The large KNOPPIX file is the compressed filesytem and can be mounted with the aid of your newly compiled cloop module by:

Code:

sh /cdrom/KNOPPIX/KNOPPIX /mount/point

You can now access the filesystem as if you were booting live from the CD. This of course puts you in the position to setup your source/ and master/ directories to begin remastering and customise that kernel.

Let me know how you go.
10-26-2005, 08:48 AM
mcreel

Well, I tried this out using a 2.6.9 kernel (I want to use bproc, and the last patch is for that kernel). I couldn't get cloop to compile (neither 2.01 nor 2.02). There were errors regarding endian-ness, see below. The howto is nice and clear, though. I wish cloop weren't so touchy. Maybe squashfs would work?

root@not a tty[src]# cd cloop-2.01
root@not a tty[cloop-2.01]# make
( make -C advancecomp-1.9_create_compressed_fs advfs )
make[1]: Entering directory `/usr/src/cloop-2.01/advancecomp-1.9
_create_compressed_fs'
g++ -DHAVE_CONFIG_H -I. -I. -I. -g -O3 -DUSE_ERROR_SILENT -
DUSE_COMPRESS -c -o advfs.o `test -f 'advfs.cc' || echo './'`adv
fs.cc
In file included from /usr/include/asm/byteorder.h:57,
from advfs.cc:33:
/usr/include/linux/byteorder/little_endian.h:43: error: syntax e
rror before `('
token
/usr/include/linux/byteorder/little_endian.h:47: error: syntax e
rror before `*'
token
/usr/include/linux/byteorder/little_endian.h: In function `__u64

__le64_to_cpup(...)':
/usr/include/linux/byteorder/little_endian.h:49: error: `p' unde
clared (first
use this function)
/usr/include/linux/byteorder/little_endian.h:49: error: (Each un
declared
identifier is reported only once for each function it appears
in.)
/usr/include/linux/byteorder/little_endian.h: At global scope:
/usr/include/linux/byteorder/little_endian.h:51: error: syntax e
rror before `('
token
/usr/include/linux/byteorder/little_endian.h:55: error: syntax e
rror before `*'
token
/usr/include/linux/byteorder/little_endian.h:59: error: syntax e
rror before `('
token
/usr/include/linux/byteorder/little_endian.h:63: error: syntax e
rror before `*'
token
/usr/include/linux/byteorder/little_endian.h:67: error: syntax e
rror before `('
token
/usr/include/linux/byteorder/little_endian.h:71: error: syntax e
rror before `*'
token
/usr/include/linux/byteorder/little_endian.h:75: error: syntax e
rror before `('
token
/usr/include/linux/byteorder/little_endian.h:79: error: syntax e
rror before `*'
token
/usr/include/linux/byteorder/little_endian.h:83: error: syntax e
rror before `('
token
/usr/include/linux/byteorder/little_endian.h:87: error: syntax e
rror before `*'
token
advfs.cc: In function `int main(int, char**)':
advfs.cc:244: error: `__be64' undeclared (first use this functio
n)
advfs.cc:244: error: syntax error before `{' token
advfs.cc:244: error: `__x' undeclared (first use this function)
advfs.cc:244: error: syntax error before `)' token
advfs.cc:245: error: `tmp' undeclared (first use this function)
advfs.cc: At global scope:
advfs.cc:250: error: syntax error before `for'
advfs.cc:250: error: syntax error before `&&' token
advfs.cc:250: error: syntax error before `++' token
advfs.cc:255: error: `compressed_blocks' was not declared in thi
s scope
advfs.cc:255: error: ISO C++ forbids declaration of `free_cb_lis
t' with no type
advfs.cc:255: error: `int free_cb_list' redeclared as different
kind of symbol
advfs.cc:55: error: previous declaration of `void free_cb_list(c
b_list*)'
advfs.cc:256: error: syntax error before `return'
advfs.cc:258: error: ISO C++ forbids declaration of `cbp' with n
o type
advfs.cc:258: error: base operand of `->' is not a pointer
advfs.cc:259: error: `compressed_blocks' was not declared in thi
s scope
advfs.cc:259: error: ISO C++ forbids declaration of `free' with
no type
advfs.cc:259: error: `int free' redeclared as different kind of
symbol
/usr/include/stdlib.h:597: error: previous declaration of `void
free(void*)'
advfs.cc:259: error: ISO C++ forbids declaration of `compressed_
blocks' with no
type
advfs.cc:260: error: syntax error before `}' token
advfs.cc:261: error: ISO C++ forbids declaration of `fprintf' wi th no type
advfs.cc:261: error: `int fprintf' redeclared as different kind of symbol
/usr/include/stdio.h:322: error: previous declaration of `int fp rintf(FILE*,
const char*, ...)'
advfs.cc:261: error: initializer list being treated as compound expression
advfs.cc:261: error: invalid conversion from `const char*' to `i nt'
advfs.cc:262: error: syntax error before `return'
make[1]: *** [advfs.o] Error 1
make[1]: Leaving directory `/usr/src/cloop-2.01/advancecomp-1.9_ create_compressed_fs'
make: *** [advancecomp-1.9_create_compressed_fs/advfs] Error 2
root@not a tty[cloop-2.01]#
10-30-2005, 11:58 AM
firnsy

I too have run into some grief with cloop compilations, however, it would appear from that error log that cloop is not the problem but rather the little_endian header file. Two things I would double check is:
1. Does the bproc patch touch the erroneous header file, and
2. Does bproc patch cleanly.

That being said I switched to sqaushfs for my remaster/distro and am loving every minute of it. I like the easy one liner to create the compressed file system and more I like the extra 5-10% compression i'm getting.
11-02-2005, 09:45 AM
mcreel

Yes, the bproc patch applied with no problems. I'll check if it did anything to the header file. But maybe I'll try remastering starting with kanotix, since it uses squashfs, if I recall correctly. Thanks, M,
11-07-2005, 09:10 PM
nibl

This is great. Many Thanks, just what I was looking for :-)

One suggestion. Should this not enter the Knoppix Wiki, or otherwise have a permanent home. It's difficult for people to find a how-to inside a forum.
11-07-2005, 09:33 PM
Harry Kuhman

Quote:

Originally Posted by nibl

This is great. Many Thanks, just what I was looking for :-)

One suggestion. Should this not enter the Knoppix Wiki, or otherwise have a permanent home. It's difficult for people to find a how-to inside a forum.

If you have tried it and it works, then it certainly should be added to the wiki for the very reason you state. Why don't you do that? The wiki is a community thing; users like yourself are encouraged to make such additions and changes to the wiki.

At the moment there seem to be only a few of us contributing to the wiki. I, for one, am not going to add this to the wiki because I haven't done it myself and so don't really know the accuracy of it. The wiki needs people to share their experiences. Don't say "someone should put this in the wiki", say "I'll put this in the wiki".
11-18-2005, 06:21 PM
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.

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.
11-18-2005, 07:55 PM
nibl

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
11-19-2005, 03:47 PM
firnsy

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.
11-21-2005, 09:46 AM
mcreel

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.
11-25-2005, 01:47 AM
firnsy

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?
11-25-2005, 10:33 AM
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.
11-26-2005, 03:53 AM
firnsy

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.
11-29-2005, 12:09 AM
firnsy

[SOLVED] "unionfs.ko needs unknown symbol __rcuref_hash

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.
11-30-2005, 10:28 AM
mcreel

Re: HOWTO: Customising/Upgrading the Kernel - An Evolving Ho

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.
11-30-2005, 08:01 PM
tr

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-
12-01-2005, 09:57 AM
mcreel

I had the same trouble with that module. I think it's a bug in the kernel code for that module (...looking around for lightning bolts....). Whew! I just deselected that module, and the other modules and kernel compiled fine.

But I'm still having unionfs and cloop trouble. The latest attempt gave me an .iso that gets to
Accessing KNOPPIX CD at /dev/hdc...insmod: error inserting '/modules/cloop.kn': -1 Invalid module format

(qemu is great for this!)

I'm using cloop 2.02, unionfs 1.1.1, kernel 2.6.14.3, and I converted minirt.gz to the initramfs format, as explained in the other HOWTO by firnsy (worked great, by the way).
12-01-2005, 10:01 AM
firnsy

Quote:

Originally Posted by tr

What goes wrong?

Quote:

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]#

The bolded line is your problem, is this the debian kernel source or the vanilla kernel source from www.kernel.org. I only use the vanilla kernel sources and have not yet experienced this problem, in fact to a quick locate I see that my sdladrv.ko module has been built.

Have you applied any patches to the source and if so which ones?
12-01-2005, 10:47 AM
tr

Quote:

Originally Posted by tr

drivers/net/wan/sdladrv.c:2002: error: invalid lvalue in assignment

Quote:

Originally Posted by firnsy

The bolded line is your problem, is this the debian kernel source or the vanilla kernel source from www.kernel.org. I only use the vanilla kernel sources and have not yet experienced this problem, in fact to a quick locate I see that my sdladrv.ko module has been built.

Have you applied any patches to the source and if so which ones?

First, it's about some two or tree years ago I compiled a kernel in Knoppix environment. This time was the first attempt to compile new 2.6 kernel. I would prefer to use Debian kernel because they are already patched kernels.

Anyhow, I used vanilla kernel 2.6.14.3 (stable) from kernel.org without any extra patches. What patches should be applied?

I used also config file from Knoppix 4.0.2 (2.6.12 kernel) and made first 'make oldconfig' and added new modules at the same time. Then I made 'make menuconfig' just to check some things.

Everything seemed right so I thought to compile the kernel in a Debian way by make-kpkg. The kernel was done but modules not. And no deb package. Now I can take bzImage, System.map and .config but it profit me nothing without modules compiled for the new kernel.

If I try 'make-kpkg modules_image' I get cloop deb package fine (have installed sources for unionfs and cloop) - don't know why unionfs is not done by the same time. My sources are in /usr/src/modules directory.

I think this evening I try to compile new kernel in my installed system. That error message came in chroot environment.

-tapsa-
12-01-2005, 10:05 PM
tr

Okay, making modules succeeded after removing wan modules. Same error message both compiling wan to kernel or as module. Is there a patch existing to this?

Next thing is compiling cloop: Debian way 'm-a a-i cloop' complains of missing linux-kernel-headers. Where can I find them to 2.6.14.3 kernel? Anyhow making a deb package 'make-kpkg modules_image' works and cloop is done correctly.

No time to finnish this today. I tell you if I succeeded after a couple of days.

-tapsa-
12-02-2005, 10:59 PM
tr

Now I can compile kernel OK by 'make-kpkg kernel_image modules_image'. Then I can install deb packages OK and tested new kernel in my installed version of Knoppix (done also initrd.img). I used also ArchCK patchet from http://iphitus.loudas.com/archck.php.

The problem is then not compling a kernel but getting it to boot from CD.

Now I get after creating /ramdisk (using Qemu):
ERROR: CANNOT UNITE READ-ONLY MEDIA AND INITIAL RAMDISK!

So is the problem with initRAMFS or with unionfs? I have not stripped unionfs.ko which is 7031058 by size. I got unionfs-source by apt-get using unstable source (version 1.0.14-1). Where can I get newer unionfs (Linuxtag is not responding)?

-tapsa-
12-03-2005, 01:10 AM
firnsy

Quote:

Originally Posted by tr

Now I can compile kernel OK by 'make-kpkg kernel_image modules_image'. Then I can install deb packages OK and tested new kernel in my installed version of Knoppix (done also initrd.img). I used also ArchCK patchet from http://iphitus.loudas.com/archck.php.

The problem is then not compling a kernel but getting it to boot from CD.

Now I get after creating /ramdisk (using Qemu):
ERROR: CANNOT UNITE READ-ONLY MEDIA AND INITIAL RAMDISK!

So is the problem with initRAMFS or with unionfs? I have not stripped unionfs.ko which is 7031058 by size. I got unionfs-source by apt-get using unstable source (version 1.0.14-1). Where can I get newer unionfs (Linuxtag is not responding)?

-tapsa-

You're so close now ... mcreel and yourself highlight a good area that I should put in the howto and that is test your modules before going to the ISO creation stage.

Your problem is most definantly unionfs, the reason being is that if the module doesn't load correctly then the script just attempts to run the halt command. I was having that problem with the recent 2.6.14.3 kernel until I applied the patch on the previous page. Ensure you have compiled without any warnings, these can cause grief later on particularly if there symbol warnings.

I grab my unionfs source from the orinators ftp site located at ftp://ftp.fsl.cs.sunysb.edu/pub/unionfs it also has the latest snapshots so that too could be useful.

If you're wondering how I test my modules before I build the ISO here is a quick summary.

Firstly I have a seperate machine on which I do all my remastering. I have Knoppix 3.9 installed to HDD, the version doesn't matter becuase all you need is a linux environment, grub (my preference) and access to the CLI. I used 3.9 becuase it was all I had at the time and it defaulted with grub ... sweet.

I'll just clarify two things when I mention RE, I'm referring to the Remastering Environment, ie the system I use to create my Remasters. I'll refer to my Remasters as Live CD (LCD) ... just to confuse a little.

Now before I compile a new kernel for my LCD I test the kernel in my RE using exactly the same .config as I would for the LCD. Why you ask? Becuase linux allows you to have a number of kernels installed on any one box and with a quick edit of grub and a reboot, one can ensure that the kernel and associated modules work as required. Also a reboot is a lot quicker than building the KNOPPIX file and then the ISO.

Once the kernel is built and rebooted to on the RE I can go ahead and compile the additional modules such as cloop/squashfs, unionfs, etc and modprobe them straight away to see if they insert correctly. If everything inserts without error, validated by using lsmod, then I know my .config works. I transfer the .config to the LCD source directory, chroot and compile with the know working .config.

Technically I could just copy the /usr/src of the RE to the /usr/src of the LCD source directory, chroot, make modules_install, copy bzImage, and System.map and save myself another recompilation, but I don't.
12-03-2005, 03:14 PM
tr

Quote:

Originally Posted by firnsy

I grab my unionfs source from the orinators ftp site located at ftp://ftp.fsl.cs.sunysb.edu/pub/unionfs it also has the latest snapshots so that too could be useful.

Once the kernel is built and rebooted to on the RE I can go ahead and compile the additional modules such as cloop/squashfs, unionfs, etc and modprobe them straight away to see if they insert correctly. If everything inserts without error, validated by using lsmod, then I know my .config works. I transfer the .config to the LCD source directory, chroot and compile with the know working .config.

Thank you! I never even thought testing modules by moprobe. Here's what I get:

Code:

tapsa@linux:~$ modprobe unionfs FATAL: Error inserting unionfs (/lib/modules/2.6.14.3/kernel/fs/unionfs.ko): Operation not permitted

And dmesg nails it down...

Code:

unionfs: Unknown symbol __rcuref_hash

I thought this was corrected by the kernel patch I applied http://iphitus.loudas.com/archck.php but it was not or my version is too old. Now I got unionfs 1.1.1 from ftp://ftp.fsl.cs.sunysb.edu/pub/unionfs and am going to use it.

firnsy:
What extra modules you are using? I compiled ndiswrapper and downloaded new ndisrapper-utils and it works fine. What about madwifi? What else? What extra modules are compiled in original Knoppix? This is very important to me, because my remastered version is downloadable for others from Funet. Until this day I have not touched to the kernel itself but now is time to go little futher :) Is in Kanotix something special or could .config file (much newer than in Knoppix 4.0.2) be used as a base configuration?

-tapsa-
12-04-2005, 08:28 AM
firnsy

Quote:

Originally Posted by tr

tapsa@linux:~$ modprobe unionfs
FATAL: Error inserting unionfs (/lib/modules/2.6.14.3/kernel/fs/unionfs.ko): Operation not permitted
[/code]
And dmesg nails it down...

Code:

unionfs: Unknown symbol __rcuref_hash

I posted the patch to fix this at http://www.knoppix.net/forum/viewtop...?p=96724#96724

Quote:

Originally Posted by tr

I thought this was corrected by the kernel patch I applied http://iphitus.loudas.com/archck.php but it was not or my version is too old. Now I got unionfs 1.1.1 from ftp://ftp.fsl.cs.sunysb.edu/pub/unionfs and am going to use it.

As far as i'm aware the patch you applied does not fix it.

Quote:

Originally Posted by tr

What extra modules you are using?

The only additional modules i use are: fbsplash, unionfs and squashfs.

Quote:

Originally Posted by tr

What extra modules are compiled in original Knoppix?

I honestly couldn't say, i'm pretty sure the default config for all knoppix release are stored in /boot/config-XXXX
12-09-2005, 04:31 PM
tr

I still have problem compiling unionfs. I have tried stable 1.1.1 version and some latest snapshots, tried kernel 2.6.14.3 from kernel.org and 2.6.15-rc4 from Debian source - no success. This is what I get when compiling unionfs:

Code:

make ****************************************************************************** If you have questions about or problems building Unionfs, please read INSTALL. ****************************************************************************** make -C /lib/modules/2.6.14.3/build SUBDIRS=/usr/src/modules/unionfs-1.1.1 FISTDEVMK=/usr/src/modules/unionfs-1.1.1/fistdev.mk modules make[1]: Entering directory `/usr/src/linux-2.6.14.3' WARNING: Symbol version dump /usr/src/linux-2.6.14.3/Module.symvers is missing; modules will have no dependencies and modversions. CC [M] /usr/src/modules/unionfs-1.1.1/subr.o cc1: warnings being treated as errors /usr/src/modules/unionfs-1.1.1/subr.c: In function 'create_whiteout': /usr/src/modules/unionfs-1.1.1/subr.c:71: warning: pointer targets in passing argument 2 of 'strncat' differ in signedness /usr/src/modules/unionfs-1.1.1/subr.c: In function 'unionfs_refresh_hidden_dentry': /usr/src/modules/unionfs-1.1.1/subr.c:267: warning: pointer targets in passing argument 1 of 'lookup_one_len' differ in signedness make[2]: *** [/usr/src/modules/unionfs-1.1.1/subr.o] Error 1 make[1]: *** [_module_/usr/src/modules/unionfs-1.1.1] Error 2 make[1]: Leaving directory `/usr/src/linux-2.6.14.3' make: *** [unionfs.ko] Error 2 root@linux:/usr/src/modules/unionfs-1.1.1#

I have tried debian way 'make-kpkg --added-modules=unionfs modules_image' and pure make. What can I do more?

-tapsa-
12-10-2005, 12:41 AM
firnsy

I'm not at all familiar with the debian way of making kernel images. I'm familiar with compiling source and as such, unless you wish to compile the vanilla sources from kernel.org I can't really provide additional assistance. The debian way of compiling things just adds more cruff (ie ensures compiling conforms to debian specification), all of which I don't think is necessary if all i'm doing is replacing the kernel, and associated modules.

All that aside, from the look of your error, the Debian way of compiling is treating your compiler warnings (doesn't normally halt compiling) as errors (does halt compiling) and as such is halting the process on something that traditional compiling (ie make) will ignore.

Quote:

Originally Posted by tr

make
************************************************** ****************************
If you have questions about or problems building Unionfs, please read INSTALL.
************************************************** ****************************

make -C /lib/modules/2.6.14.3/build SUBDIRS=/usr/src/modules/unionfs-1.1.1 FISTDEVMK=/usr/src/modules/unionfs-1.1.1/fistdev.mk modules
make[1]: Entering directory `/usr/src/linux-2.6.14.3'

WARNING: Symbol version dump /usr/src/linux-2.6.14.3/Module.symvers
is missing; modules will have no dependencies and modversions.

CC [M] /usr/src/modules/unionfs-1.1.1/subr.o
cc1: warnings being treated as errors :(
/usr/src/modules/unionfs-1.1.1/subr.c: In function 'create_whiteout':
/usr/src/modules/unionfs-1.1.1/subr.c:71: warning: pointer targets in passing argument 2 of 'strncat' differ in signedness
/usr/src/modules/unionfs-1.1.1/subr.c: In function 'unionfs_refresh_hidden_dentry':
/usr/src/modules/unionfs-1.1.1/subr.c:267: warning: pointer targets in passing argument 1 of 'lookup_one_len' differ in signedness
make[2]: *** [/usr/src/modules/unionfs-1.1.1/subr.o] Error 1
make[1]: *** [_module_/usr/src/modules/unionfs-1.1.1] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.14.3'
make: *** [unionfs.ko] Error 2
root@linux:/usr/src/modules/unionfs-1.1.1#

That being said this HOWTO is aimed to replace the kernel using a more traditional method, rather than make-kpkg. Unless you experience these problems having followed the HOWTO as written, it can not be improved to ensure others don't experience similar obstacles.

Thus I would request that you attempt to compile using the methods detailed, and report your errors based on them, then I can provide better assistance. 8)
12-12-2005, 09:40 AM
knopx4me

Thanks alot for this great howto. I managed to get my 1st kernel on live CD. I obtained kernel 2.6.14-3 sources from here:
http://www.kernel.org/
and used Kanotix 2005-03 config file to configure it. I used cloop sources from here:
http://debian-knoppix.alioth.debian.org/sources/
My live CD is working perfictly. Now, I will start adding drivers to my remaster.

However, I do not know how to add kernel headers to my live CD since this is not a debian kernel source. Do you have an idea how to do that?
12-17-2005, 06:56 PM
tr

Quote:

Originally Posted by firnsy

That being said this HOWTO is aimed to replace the kernel using a more traditional method, rather than make-kpkg. Unless you experience these problems having followed the HOWTO as written, it can not be improved to ensure others don't experience similar obstacles.

Thus I would request that you attempt to compile using the methods detailed, and report your errors based on them, then I can provide better assistance. 8)

There's no difference if you use 'make' or 'make-kpkg kernel_image' to compile kernel and its modules (same error messages). I just like more of Debian way to compile kernel with make-kpkg. Also installing .deb packages is very simple and secure :) Only thing to remember is that 'make-kpkg clean' cleans also asm symlink from include sub-directory so it must be created again (ln -s asm-i386 asm).

So my problem was NOT the method itself but something else I still actually don't know. I can compile fine in my old Athlon 1300 MHz machine with 768 MB RAM but NOT in my 64-bit Atllon 3000+ machine with 2 GB RAM. So I think this must have something to do with 64-bit AMD processor. (?)

Now I have 2.6.15-rc4 kernel from Debian source with unionfs 1.0.14 and cloop 2.02 :) (Used Debian kernel because Knoppix is Debian based and Debian kernels are patched already)

Thank you, firmsy, of your howto and also of initRAMFS howto. Using initramfs helped much (no need to shrink unionfs. module).

-tapsa-
01-12-2006, 08:08 PM
sakiZ

Upgrade 2.6.9 kernel in Knoppix 3.7?

This is a most interesting discussion.

I have no interest in making a new CD. My interest is upgrading the 2.6.9 kernel in my Knoppix 3.7 HDD install.

Since I don't want 3 kernels in the OS, I want to remove the (buggy) 2.6.9 kernel. The venerable 2.4.27 kernel will stay -- for now.

I have downloaded the newest 2.6.15 kernel. How do I proceed?

I have never done anything like this before. :-)

sakiZ
01-17-2006, 04:33 PM
pracsec

Why not extend the initrd image

In order to fit the very large unionfs.ko module, it would seem reasonable to extend the initrd image, minirt.gz.

Any thoughts on why this is good or bad for Knoppix?
01-18-2006, 09:52 PM
firnsy

Re: Why not extend the initrd image

Quote:

Originally Posted by pracsec

In order to fit the very large unionfs.ko module, it would seem reasonable to extend the initrd image, minirt.gz.

Any thoughts on why this is good or bad for Knoppix?

When originally working with new kernels and unionfs I just extended the initrd image. This was fine, but I was getting sick and tired of the uncompressing, loopback mounting, copying, unmounting, compressing cycle. It wasn't until I found the alternate initRAMFS structure, this is essentially dynamic in size in that it doesn't require you to allocate the space for all the files.

Checkout my other HOWTO at http://www.knoppix.net/forum/viewtopic.php?t=22271
01-30-2006, 01:39 AM
pracsec

Re: Why not extend the initrd image

Quote:

Originally Posted by firnsy

Quote:

Originally Posted by pracsec

In order to fit the very large unionfs.ko module, it would seem reasonable to extend the initrd image, minirt.gz.

Any thoughts on why this is good or bad for Knoppix?

When originally working with new kernels and unionfs I just extended the initrd image. This was fine, but I was getting sick and tired of the uncompressing, loopback mounting, copying, unmounting, compressing cycle. It wasn't until I found the alternate initRAMFS structure, this is essentially dynamic in size in that it doesn't require you to allocate the space for all the files.

Checkout my other HOWTO at http://www.knoppix.net/forum/viewtopic.php?t=22271

Firnsy, I agree - it is tiring. I'll give your HOWTO a try and report back. Also, I think I can add some of my experience to this HOWTO. I just need to gather up my notes and get them in usable form.
02-09-2006, 02:45 PM
doktorn

Kernel patches needed?

Hello,

I'm about to put Xen-patched kernel 2.6.15 on a Knoppix CD for out LiveCD router simulator project. I've compiled a kernel that starts just fine (booted the CD-Rom but chose to load kernel from harddrive, which is possible thanks til GRUB). However, just that it starts and everything *seems* alright doesn't mean it is ;-)

As stated, the kernel is not knoppix-patched in any way. And that is because... I've never been into knoppix remastering until now. So, my questions are quite simple:

Are there and knoppix-patches to kernel that I really should apply? Or is a debian-kernel (which Xen-kernel is derived from) just fine?

I've heard something about patching the size of the kernel parameter (/proc/cmdline) because of the massive options list a Knoppix LiveCD can use. How about that?

Oh, and while I'm on the topic. I've had some fights with unionfs.ko before I got it all right. The size of the file was somewhere around 5.4MB. Stripping it, or compiling without -g in Makefile, made it smaller (2,4MB). But when I tried to load it, I got "Invalid module format". So I just made my miniroot larger, and put the unstripped version there. It loads just fine.
02-10-2006, 07:27 AM
firnsy

Re: Kernel patches needed?

Quote:

Originally Posted by doktorn

Hello,

I'm about to put Xen-patched kernel 2.6.15 on a Knoppix CD for out LiveCD router simulator project. I've compiled a kernel that starts just fine (booted the CD-Rom but chose to load kernel from harddrive, which is possible thanks til GRUB). However, just that it starts and everything *seems* alright doesn't mean it is ;-)

As stated, the kernel is not knoppix-patched in any way. And that is because... I've never been into knoppix remastering until now. So, my questions are quite simple:

Are there and knoppix-patches to kernel that I really should apply? Or is a debian-kernel (which Xen-kernel is derived from) just fine?

I've heard something about patching the size of the kernel parameter (/proc/cmdline) because of the massive options list a Knoppix LiveCD can use. How about that?

Oh, and while I'm on the topic. I've had some fights with unionfs.ko before I got it all right. The size of the file was somewhere around 5.4MB. Stripping it, or compiling without -g in Makefile, made it smaller (2,4MB). But when I tried to load it, I got "Invalid module format". So I just made my miniroot larger, and put the unstripped version there. It loads just fine.

Essentially the only remaining knoppix patch, if you could call it that, would indeed be the extension of the command line from default 256 characters up to 512. To tell you the truth I don't remember to do that everytime I recompile a new kernel (currently using 2.6.15.2).

It is true that unionfs can cause grief when stripped, although similarly to the kernel, I like to maintain cutting edge with this and the current snapshot of unionfs compiles to about 400k without debugging, so there are some definant improvements from that end.
02-12-2006, 09:50 PM
tr

Re: Kernel patches needed?

Quote:

Originally Posted by firnsy

Essentially the only remaining knoppix patch, if you could call it that, would indeed be the extension of the command line from default 256 characters up to 512. To tell you the truth I don't remember to do that everytime I recompile a new kernel (currently using 2.6.15.2).
.

I don't use that patch either because only very rarely (or never) you need more than 256 characters in command line in remastered version.

I use also 2.6.15.2 kernel from kernel.org at this time and unionfs from Debian unstable. If someone has problems in compiling, my files can be used from http://tapsa.terae.net/linux/knoppix...inux-2.6.15.2/. There's also corrected minirt.gz file (usb2 patch) and instructions how to get initRAMFS unzipped (using it according firmsy's howto). I have translated 'Welcome to Knoppix-live-DVD' in finnish - so please, use yor own language and repack minirt.gz again.

-tapsa-
02-21-2006, 09:04 PM
meatwad

So does anyone know why the Knoppix unionfs.ko module is only 77k in size and the ones all of us seem to be building are MUCH larger? (My most recent was 5.5Mb unstripped).

Show 40 post(s) from this thread on one page