kernel patching options and problems with 2.6.36
 

I'm trying to patch the 2.6.36 kernel with a squashfs-lzma patch and it gives me this output

am I doing it wrong?
here's the patch info
http://www.mail-archive.com/pld-cvs-...msg234515.html

using kernel.org 2.6.36 source
thanks for any help

Try removing these lines from the patch:

I wouldn't recommend that, this appears to be a patch for a patch file - see the lines like

Yes, it is a patch for
The OP needs to get the 1.6 patch file, and then patch that.

Patching patches... sounds like we are making a quilt.

ah
so I need the 1.6 patch also?

none of the above has worked so far either....
thanks for helping too

Yes. This file only patches the patch, which will have a lot of other changes in it.

If you only apply the changes in this patch (which you could do after manually editing the patch), you will only get a subset of the changes you need. In other words, I should have not posted my first reply.

ok
I found this too
http://cvs.pld-linux.org/cgi-bin/cvs...hfs-lzma.patch

so, I patch the source with 1.6 then 1.7 or what to do exactly?
thanks

Ah, that page is better. What you want to do is click on the download link next to "Revision 1.7:", this will give you the latest version of the complete patch file. Then you can apply it as you originally intended.

If there is then a Revision 1.8 patch it gets a little more complicated. You could reverse the 1.7 patch, then download and apply the complete 1.8 patch. Or you could reverse the 1.7 patch, update the patch file with the 1.7-1.8 patch, then apply it.

well, neither patch works
1.6 or 1.7
it gives the same output

any ideas??

I also found these patches
https://dev.openwrt.org/browser/trun...patches-2.6.36

005
006
007
008
997
998

I applied all 6 patches and it ends making with a zlib_deflate error issue..(sigh)

I did find a good aufs2 patch here
http://cvs.pld-linux.org/cgi-bin/cvs...el-aufs2.patch

so, you can make a livecd as long as you have aufs2 and squashfs like in reg kernel
but reg squashfs iso will be much bigger than squashfs-lzma iso
might have to wait awhile on squashfs-lzma...
Does anyone know what version of squashfs is in kernel 2.6.36??
thanks for you help!

It doesn't appear to me that you downloaded the right file - it should have been this link:
http://cvs.pld-linux.org/cgi-bin/cvs...e=text%2Fplain

At any rate your kernel source tree is now not pristine, so you'd probably need to re-extract the source to use it.

The squashfs version as reported on my 2.6.36 kernel source is 4.0.

Something you should keep in mind that while lzma does provide better compression (maybe 25% better than zlib) it's generally quite a bit slower to decompress - there a table here that shows the results for just the kernel:
http://free-electrons.com/blog/lzo-kernel-compression/

According to this lzma takes more than 5 times as long to load due to the decompression overhead.

hello ciotog
thanks for that link, dont know why I did the wrong one..

your right, lzma does have a disadvantage
but; take for example my nFluxOS Slackware build, it's about 690mb or so
if I used squashfs 4.0 it would be about 900mb or more
thus I would have to remove alot of stuff to get a squashfs 4.0 iso at 700mb

it would be easier to use squashfs 4.0 because it's already in the kernel but as I said the size difference is big
Plus, my lzma distros (arch/slackware) boot pretty fast off usb compared to the same ubuntu/debian builds with 4.0, as they boot just a bit slower
they are supposed to be adding lzma support to the vanilla kernel as they have added lzo already
thanks for all your help too
the patches applied successfuly and I compiled a live kernel though I left LZO as not compiled because it would not compile...but the kernel works good anyway
there is a bug with either posivxl or aufs2 patch as persistent changes on fat32 usb has issues so you should use changes=slxsave.xfs
anyway, thank you again!

EDIT: also, the article you linked to is about how the kernel itself is compressed right?
I compile them to use gzip; the only thing the lzma is used for is to compress the root filesystem into .lzm's for the livecd using mksquashfs/unsquashfs 4.1-lzma cvs. and the initrd is gzip also
so thats better right, using gzip to compress the kernel?

The issue with the FS being compressed is that it gets accessed a lot more than the kernel - the kernel gets loaded only once, so if there's a delay of 4 seconds more because of the compression type then it's really not much of an issue. If the filesystem is compressed requiring a cpu intensive decompression method, then the whole system will seem boggy.

Really it's a matter of weighing the pros and cons... If you need the extra compression in order to fit constraints, then you don't have much choice.