script for custom kernels

T-Dawg · 2005-05-11 00:33:56

I got sick of having to redo my kernel every time there was an update through pacman so I came up with this. Considering how abs can change the PKGBUILD script and other included files at any given day, I figured this was the best solution. It uses the current files in the abs kernel folder to customize, build, and install your kernel. First it will take you to make menuconfig, then ask if you want to use vim to edit the PKGBUILD then a final "do you want to build and install" confirmation. Next, the kernel will install through makepkg, then move it into a proper cache folder. Once the kernel is installed, the original PKGBUILD and config will be restored. Needless to say, a 'rebuild' of your kernel using this script can easily be accomplished as it allows you to modify your last config the same way. Also, it will compare kernel versions and releases in the PKGBUILD to what you already have installed before executing so you don't accidently do something funky.

file and sums can be found here

T-Dawg · 2005-05-11 02:41:42

EDIT: Added kernel release checking

T-Dawg · 2005-05-15 23:09:31

This will be the last time I update this thread unless I see positive feedback (I see dibble has a custom PKGBUILD -my apologies to him).
Anyways, I borrowed some code from makepkg to allow ONLY the temporary config file (the one that the user will modify for a custom kernel) to be accepted by makepkg when it checks for md5sums during install. THIS IS NOT the same as makepkg -g >>PKGBUILD, so any sum verification failure will be corrupt files from the download (according to arch's PKGBUILD). Thus, user intervention to manipulate the md5sums in PKGBUILD with vim will not be necessary and should not be touched. Still, I left the option open for you to choose whether to use it or not through a simple prompt...as well as a final build confirmation.

rasat · 2005-05-18 12:30:51

First I thought it was one of those "high tech" kernel configure tools but I was wrong. It does the basic when configuring a custom kernel. Did few initial tests, nicely done...... its great.

For my information, whenever I custom a kernel for my own usage I need Win4Lin patch. How do I include with the script?

Suggestion:
Give user a choice of selecting other editors than vim. Nano would be good. If other choices are include, make a script checking if the package is installed.

EDIT
About the idea of "Arch Tool", a tool with different user contributed scripts, I suggest to include this script. What's the name? ..... kernelctm (kernel customizor).

T-Dawg · 2005-05-18 15:14:15

For my information, whenever I custom a kernel for my own usage I need Win4Lin patch. How do I include with the script?

You should be able to give the command in the build() section of the PKGBUILD using the editor, thats why I gave the option to use it. The kernel installs through makepkg, reading the PKGBUILD, so it should work. You'll have to download the patch in the same directory as well. ....Maybe I'm misunderstanding you

Give user a choice of selecting other editors than vim. Nano would be good. If other choices are include, make a script checking if the package is installed.

Good idea, I will work on it when I have time later.

EDIT
About the idea of "Arch Tool", a tool with different user contributed scripts, I suggest to include this script. What's the name? ..... kernelctm (kernel customizor).

I was always thinking "kernelpac" but I guess kernelctm makes more sense...

T-Dawg · 2005-05-19 00:39:53

Ok, I added a menu for selecting the editor. Currently its vim, nano, and joe (emacs was giving me problems), and checks if they're installed. Also added md5sum and makepkg checks as well.

rasat · 2005-05-19 02:41:03

Penguin wrote:

For my information, whenever I custom a kernel for my own usage I need Win4Lin patch. How do I include with the script?
You should be able to give the command in the build() section of the PKGBUILD using the editor,....

When the patch line is typed in the PKGBUILD, will the script execute the line(s) before entering menuconfig mode? In menuconfig requires to config "yes" to "Include NeTraverse Win4Lin Support". In my brief reading the script, most likely it does.

Suggestion:
To add a patch in PKGBUILD which looks "messy" and confusing if not familiar, how about adding the patch lines somewhere else in a blank text file. The script adds the lines in PKGBUILD.

T-Dawg · 2005-05-19 03:30:56

It wont execute anything like that before the menu but, after looking at the makepkg code I found a very easy solution that I'm pretty sure will work....
Underneath line 211 where the source is set (and before it gets to the menu), type in a custom function name like rasatbuild
then run the script and edit the package build by creating that function and entering in ONLY your patch commands such as:

rasatbuild(){
patch bla bla bla
}

......When makepkg executes it will only be able to execute the functions in which it calls on. and it knows build() should be there. So, when makepkg executes it should not call on "rasatbuild" again because it doesn't know of it. Thats why calling on "rasatbuild" in my script should be the appropriate course fo action.

I tried this my self only using an echo "hi" (from "rasatbuild" in my script) which worked so I see no reason why your patch command wont work either. So, try something similar yourself to be sure it works before building. So to test do something like:

source $KERNELPAC
rasatbuild | cleanup
cleanup

I'm pretty sure that'll work. Let me know if it does, It shouldn't be to hard to incorporate into the script as another option.

EDIT: just dont change the default path in the editor otherwise it'll never work.

iphitus · 2005-05-19 07:42:16

whats wrong with the old method of

make menuconfig/oldconfig
make
make modules_install
cp arch/i386/bzImage /boot/bzImage${VER}

unless you plan to redistribute your kernel, it just seems to me so pointless to spend time on a script like this. Even then, if you're redistributing, you'd make a proper PKGBUILD.

you might say its to keep the system 'clean' but its not hard to remove the kernel without making a package. remove the /boot/bzimage, and remove its modules from /lib/modules and its gone.

iphitus

rasat · 2005-05-19 14:04:25

iphitus wrote:

whats wrong with the old method of make menuconfig/oldconfig, make....
it just seems to me so pointless to spend time on a script like this.

Same wrongness as in old ./configure method compiling a software. ... and pacman was created solving the problem. Whatever, here we are trying to do an experiment if any improvment can be done.

Penguin wrote:

It wont execute anything like that before the menu...

The script is out of sequence. PKGBUILD executes patches after tarball is downloaded (in current PKGBUILD many patches are already included). Without the kernel source, executing patches doesn't work..... that what happened to my Win4Lin patch. Menu should not appear until source is patched and fixed.

Proper sequence:
1. Edit PKGBUILD (include new patches in next line under "build()" ).
2. Run PKGBUILD until all patches and configs are fixed in the source.
3. Run menuconfig
4. Run remaining part of PKGBUILD.

T-Dawg · 2005-06-03 11:38:11

I've reworked this to rasat's suggestion above to work with extra patches (run menu part way through the build in makepkg). So basically it just inserts and modifies commands in the build() section according to the user selected option.

-r will allow one to modify on an existing configuration.
-n will allow modification to arch defaults.
-s will allow modification to kernel source defaults (very bare!)

It will also remember previously built packages and keep its own separate cache. This is done to be able to reinstall
a previous rebuild (-U) in the event a user may want to swap back and forth between the stock arch package (pacman -S <kernel>) and the custom rebuild.

So as an example, Proper syntax to rebuild kernel26 would be:
<scriptname> -r kernel26

Please note: this will not automatically adjust to unique local or extraversions! The purpose of this script is to simply reconfigure and replace your kernel using the standard name scheme. As I mentioned above, stock arch kernels can be restored using pacman -S. And, it will not update abs everytime so, your kernel will only be as new as the PKGBUILD.

Arch Linux

#1 2005-05-11 00:33:56

script for custom kernels

#2 2005-05-11 02:41:42

Re: script for custom kernels

#3 2005-05-15 23:09:31

Re: script for custom kernels

#4 2005-05-18 12:30:51

Re: script for custom kernels

#5 2005-05-18 15:14:15

Re: script for custom kernels

#6 2005-05-19 00:39:53

Re: script for custom kernels

#7 2005-05-19 02:41:03

Re: script for custom kernels

#8 2005-05-19 03:30:56

Re: script for custom kernels

#9 2005-05-19 07:42:16

Re: script for custom kernels

#10 2005-05-19 14:04:25

Re: script for custom kernels

#11 2005-06-03 11:38:11

Re: script for custom kernels

Board footer