MEPIS Community Forum

Stevo I used your version of kernelcheck from your post and compiled 2.6.33 for antiX without any issues. I need to do it again though as it was a test and I didn't disable as much as I could have. Thanks

EDIT: Quick question though, making these kernels does it take away any Mepis magic? I don't know if any tweaks are done to the kernels we get from scratch.

I had a message from Warren previously that he does use patches on the kernel, so it's not a vanilla build. The patches are available in the linux-patch-debian-2.6.32 package, but should be applied only to the linux-source package for the Mepis 2.6.32 kernel, not the vanilla kernel source, otherwise results may be unpredictable. You could take a look at what patches were applied, though.

You can also use Kernelcheck to apply the Liquorix patchset to the vanilla 2.6.33 original release, if you want a heavily patched kernel. It's a tribute to Warren's 2.6.32 that I can't really see any performance difference between his and the 2.6.33 Liquorix.

I actually thought about this too - I'll probably use it in the next version. I'm just not sure that if you build the kernel debs in a /home/user directory if the header links point to /home/user/linux/build or if they're correctly installed.

I have always had the build and source symlinks end up pointing to the build directory any time I do it manually or with kernelcheck, in /home or in the /usr/src/linux symlink. I think it's just a problem of having the original build directory still in existence when the headers deb is installed, since others that install the debs don't report that problem. I will experiment with removing /renaming that folder first next time I build a kernel.

bump

Just tried using the latest kernelcheck version that I can find which is contained in "kernelcheck-fixed-16_april_2010.zip". I've also tried others from bzr and sourceforge. The program is stopping at 10% whilst loading kernel info, this is the error message below;

>>>
Finding patch
Traceback (most recent call last):
File "/usr/share/kernelcheck/scripts/main.py", line 499, in get_data
patch_url, patch, stable, stable_url, OldKernelList, OldKernelLinks, prepatch, prepatch_url = self.kernelinfo()
File "/usr/share/kernelcheck/scripts/main.py", line 133, in kernelinfo
patch = KPParser.get_patch_pkg("patch")
File "/usr/lib/python2.6/dist-packages/KernelCheck/KernelPageParser.py", line 113, in get_patch_pkg
base_kernels.append(k)
UnboundLocalError: local variable 'base_kernels' referenced before assignment
>>>

Tried a few hacks but cannot get past the problem... I'd be very grateful if it could be fixed.

[edit] I've realized through experiment that this is probably not the only problem atm, because of kernel.org changes. ;(

Kernel.org was comprised by a hacker, and the kernel moved to github. I don't know if it's back yet. Hmmm...mirrors.kernel.org is back now...I haven't t looked at kernelcheck for a while, so it may not even be developed at all anymore.

Sorry I'd missed this msg before posting into the kernel thread. It'll be a pity if kernelcheck goes dead as it has been very useful to give to others as well as using it myself. I must have done hundreds of kernel builds for friends using it, I can't really trust myself these days to build from scratch sources!

There's one post from a month or two ago from the developer saying that the program is not dead, and he's working on an update that will work with the 3.0 kernel, and also not require root permissions to build a kernel.

If I was packaging it, I'd just have it depend on all the kernel tools it needs, so it would not check for and install them every single time it's run, and you would not need root for that step. Apparently the newest kernels have a deb packaging script internally, so the command to build doc, image, header, and firmware files is just "deb-dpkg".

Thanks for the info/update. I just tried another supposedly fixed version but it stalls at 10% of "loading kernel info". I'll just have to be patient as I can't hope to fix things... :)