Patching kernel source

Ok, since I've only compiled a linux kernel a couple of times before, I'm kinda stuck. So, if you don't mind a semi-newbie question...

The source on the empeg website is the beta 11d source, and there are patches up to the current version. I've never patched a kernel before. The readme in the kernel source says to use patch, or the patch-kernel script.

I've tried both and can't seem to get them to work. Patch keeps saying that it can't find the file that it's trying to patch. I noticed that the path was empeg/kernel/Makefile, instead of linux/kernel/Makefile, so I created a sym link to /usr/src/linux and called it /usr/src/empeg. That didn't seem to help. I've played around with different -p values, but from looking at the file, I'd think it should be 0.

Am I going about this entirely the wrong way, or am I on the right track but overlooked something?



Bill B.
Mk.2 SN 080000183 - 38 GB / Green

Am I going about this entirely the wrong way, or am I on the right track but overlooked something?

You are on the right track.

Untar the sources in /home/foo/linux (or anywhere, really - there's absolutely no reason you should be putting them in /usr/src/linux or compiling as root).
cd /home/foo/linux
gzip -dc (wherever you put the patch)/kernel-patch-beta11d-beta12.gz | patch -p2

Another useful option of patch is --dry-run - let's you test things non-destructively. Without it, failed patches are a real pain to reverse.

Next hurdle will probably be setting up the cross-compilation environment...

Good luck,
Borislav

gzip -dc (wherever you put the patch)/kernel-patch-beta11d-beta12.gz | patch -p2

When I try to use gzip, it says they're not in gzip format, so I've been trying to do it without gzip. I guess I must be doing something wrong there.

Next hurdle will probably be setting up the cross-compilation environment...

I don't know if it makes a difference, but I neglected to mention that I set up a debian chroot environment on the empeg, based on Jim Pick's tarball, added make, patch, and a few other things, and am planning to compile directly on the empeg. Is this a bad idea? Not knowing any better, I figured it would be easier than setting up my linux box to cross compile.




Bill B.
Mk.2 SN 080000183 - 38 GB / Green

I've actually did the same thing. Compiling the kernel will take over 2 hours though...

Frank van Gestel

Compiling the kernel will take over 2 hours

That's OK, I'm sure the empeg's faster than my current linux box anyway...

Bill B.
Mk.2 SN 080000183 - 38 GB / Green

When I try to use gzip, it says they're not in gzip format, so I've been trying to do it without gzip. I guess I must be doing something wrong there.

Guess: you downloaded the patches with netscape. It has this annoying bug where it automatically decompresses the file while downloading (trying to be clever) but leaves the .gx extension on... Anyway, just look at the file with more or less or whatever, if you see text then it's not compressed.

Borislav

Actually, I downloaded the patches with IE5, but it seems the same thing has happened, since they're all in plaintext.

I've been playing around with it quite a bit, and I still can't seem to apply the patches. I did manage to get it to 'find' the first file, although the hunk still failed. I still can't get it to find any files after the first.

I've looked through the patchfiles themselves, and since I don't know much about any of this, it really didn't help, but it does lead me to a question -

I'm assuming that

--- empeg/kernel/Makefile:1.28 Tue Jul 4 15:25:13 2000

is the info for the existing version of the file, and that

+++ empeg/kernel/Makefile Sat Jul 15 17:58:04 2000

is the info for the patched version of the file? If so, does it matter that the date on the existing file doesn't match the date in the patch? (The date of the current file is June something, maybe 4th?)

Like I said, I haven't a clue about any of this - just a shot in the dark.



Bill B.
Mk.2 SN 080000183 - 38 GB / Green

If so, does it matter that the date on the existing file doesn't match the date in the patch?

No, the date shouldn't matter at all.

Are you sure you are patching the right kernel with the right patch? The patches should be applied in sequence, i.e use kernel-patch-beta11d-beta12.gz first.

Borislav

I unpacked the kernel source from linux-2.2.14-rmk5-np17-empeg27.tar.gz
and I'm trying to patch it with kernel-patch-beta11d-beta12.gz

Both of which were downloaded (by me) directly from empeg.com. I'm making the assumption that if the files on the website were wrong (or damaged) in some way, someone would've caught it long before me.

Is there anything that needs to be set up in the environment that may not have been set up with that Debian tarball? Or perhaps other packages that need to be installed?



Bill B.
Mk.2 SN 080000183 - 38 GB / Green

This is another shot in the dark. But these patch files are plain text, right? You were downloading and/or unzipping them with a Windows box?

Is this the old "CR vs. CR/LF" problem? Maybe the patching/compiling software just doesn't like the line endings on the files because they're windows-format instead of linux-format.

Like I said, it's a complete shot in the dark.

___________
Tony Fabris

That didn't occur to me. I just took a second to test that idea. I downloaded the patch from a shell account I have on a Sun box, ftp'd it down to my workstation and z-modemed it onto the empeg. Still compressed, and assumably untouched.

After modifying my commands to allow for the compressed file, I'm still having the same problem.

Bill B.
Mk.2 SN 080000183 - 38 GB / Green

Turns out it was a source path problem. I had originally created a symlink to /usr/src/linux and called it /usr/src/empeg, after seeing that the patch was looking for empeg/ kenel/makefile. I incorrectly assumed that it was looking for the makefile that resides in the kernel subdirectory of the source tree. Turns out it was looking for the makefile in the root of the source tree, and the whole source tree needed to be located at empeg/kernel/ rather than just empeg/. So,
ln -s /usr/src/linux /usr/src/empeg/kernel did the trick. Patch works fine now.

I appreciate all the help. Now if I can be annoying a little longer - I've run into another problem. Ok, actually I ran into several problems, but I've managed to fix most of them on my own(not the least of which was running into make errors because I forgot to turn on the swap).

I've successfully compiled the kernel, and am trying to upload it to the flash using the kernel uploader option of Tony's logo editor (I've also tried it from a command prompt). It starts to erase the flash, gets to 71% and fails with error code 1a2. It never even gets to the upload part.

Does the program by chance check the size of the kernel to determine how much flash to erase, or is it a set amount every time? If it does check size, maybe my kernel is too big? Maybe I'm on crack?

Anyone? Anyone?

Bill B.
Mk.2 SN 080000183 - 38 GB / Green

Does the program by chance check the size of the kernel to determine how much flash to erase, or is it a set amount every time?

If, by "the program", you mean my kernel downloader, the answer is No, it does not perform any verification on the file you're sending. It's just a straight compile of the raw "download.c" source code that's available at the Empeg web site (with only a tiny modification to reboot the player). Look at that code to see what it's doing.

___________
Tony Fabris

If, by "the program", you mean my kernel downloader

I guess I could've been more specific. I figured you wouldn't have built any other functionality into the download portion, and there's really no reason for the editor itself to do file verification. I was just hoping someone could tell me if the download program checked kernel size and erased an appropriate amount of flash, or if the amount it erased was static.

Look at that code to see what it's doing.

And I have, but unfortunately, my C programming skills are pretty pathetic. I can't really make heads or tails of it. Which is why I figured I'd bug everyone else.

Bill B.
Mk.2 SN 080000183 - 38 GB / Green

OK, I may be totally off track here, but I'm beginning to think it IS a size related issue. I went back and looked at the kernel sizes for the volume adjustment kernel, and the displayserver kernel (and a couple others that I don't remember what they were now), all of which are in the neighborhood of 500k +/-.

Even with the vanilla config file from here, my kernel size is still well over a meg.

I"m guessing something is configured incorrectly, but have no idea what that would be. Anyone know what would make my kernel so bloated?




Bill B.
Mk.2 SN 080000183 - 38 GB / Green

OK, nevermind. I'm an idiot. I told you I was new at this. I had the wrong %$#$%# file.

Problem fixed.


Bill B.
Mk.2 SN 080000183 - 38 GB / Green

Oh, and BTW - Thanks to everyone for the assistance.

(For some reason, I couldn't edit my last post)

Bill B.
Mk.2 SN 080000183 - 38 GB / Green