FS#12384 - Kernel PKGBUILD proposition: Ease custom kernel compilation.
Attached to Project:
Arch Linux
Opened by Nicolas Bigaouette (big_gie) - Monday, 08 December 2008, 18:18 GMT
Last edited by Tobias Powalowski (tpowa) - Thursday, 12 March 2009, 17:40 GMT
Opened by Nicolas Bigaouette (big_gie) - Monday, 08 December 2008, 18:18 GMT
Last edited by Tobias Powalowski (tpowa) - Thursday, 12 March 2009, 17:40 GMT
|
Details
Description:
I suggested a simple modification to the kernel26's PKGBUILD on the forum[1] and on the mailing list[2] with good feedback from users. Basically, these modifications allows to recompile a different kernel by only changing the pkgname. I am pasting what I have written: Hi all! Since a couple of years of using Arch, I often wanted to compile a custom kernel, as many others did. There is many, many, many! forum threads about that, a couple of wiki pages too, with questions and howtos. Many efforts has been put to create new PKGBUILDs[3-4] to ease the effort of this. Unfortunately, these PKGBUILDs suffer from some drawback: 1) They are placed on a wiki which can be edited by everybody. This mean it is not a trusted place to store a PKGBUILD, specifically one as vital as the kernel's. 2) They tend to be forgotten and not updated anymore. This can lead to an unbootable kernel, rendering all this useless. 3) They do not take advantage of the devs' work: They are the best one to trust for a quality PKGBUILD. They also have all the feedback from Arch users, bug reports, etc. They know what has changed in the kernel and what needs to be adapted for the installation, for example new "provides=()". A PKGBUILD from a wiki page or a forum post might be good at the time of post, but be outdated just days latter... 4) They build a kernel which is way different then the stock one, for example because they don't have the same patchset. Users most often wants to build a custom kernel just to try it, change some configurations, add one or two patch, optimize for their own machines, etc. Maily, they just want to take the existing one, change a couple of things, and be ready. One also wants to install this kernel side by side with the stock one, at least until his own kernel is stabilized and running as wanted. Actually, Arch's stock kernel does not allow that. What I propose is some simple modifications to the PKGBUILD so users can try to compile their own kernel based on the original, trusted, working and approved one. With theese modifications, one only needs to add a "kernel name" to the pkgname: "pkgname=kernel26-mykernel" for example. Nothing else is needed to compile a custom kernel. The created package would sit without problem side by side with the stock kernel. Also, if the pkgname is kept to "kernel26", then the stock -ARCH kernel will be built. This approach has many advatanges: 1) The patch is relativelly small: not much is changed in the original PKGBUILD. 1) Nothing changes for the devs. They continue to provide a quality kernel to Arch users. 2) Users who wants to compile a custom kernel can just sync abs, change the pkgname and install a new kernel, in the KISS philosophy. They know that if they just change the name, they will have the same package so they can easily test whatever feature/patch/bug solution/optimization they want. 3) Because one only needs to change the pkgname, they use the devs' high quality, tried and truth PKGBUILD. When a new kernel is out, they can sync the devs' modifications easily. 4) Bugs affecting the kernel can be easily tested for solutions. Affected users just need to compile a "-testing" kernel where a patch is applied, install it and see if it works, without having to risk breaking his system by replacing -ARCH kernel with an unbootable one. 5) Better feedback to the devs since the users would be using (almost) the same PKGBUILD as the original one. 6) Simplify a lot all these "custom kernels" threads and wiki posts. I did "maintained" such a patch for myself because I wanted to keep in sync with the original PKGBUILD. After posting it on the forum[5], I got some positive feedback. People reporting back said they liked the simplicity and the effectiveness of the method. They also positively tested it with different configuration. The patch should be applied to revision 19747 for i686 or 19749 for x86_64. It modifies the PKGBUILD and also slightly the kernel26.install and kernel26.preset file. Issues: 1) Firmwares are being installed to /lib/firmware by all kernels. Because of that, a kernel other than stock's "-ARCH" will delete the ${pkgdir}/lib/firmware directory, meaning they will depends on the stock kernel to provide them. Possible corrections: -One could add "kernel26" as a depdency -Put firmwares in a seperate package and make all kernels depend on it I am thus reporting this to be include in the official file. I think it would be a great addition to an already great distro. I am open to discussion on the subject. I hope I am posting this on the right mailing list and that it can be included! :) Sincerely, big_gie [1] http://bbs.archlinux.org/viewtopic.php?id=37579 [2] http://archlinux.org/pipermail/arch-general/2008-December/002937.html [3] http://wiki.archlinux.org/index.php/Kernel_Compilation_with_ABS [4] http://wiki.archlinux.org/index.php/Custom_Kernel_Compilation_with_ABS [5] http://bbs.archlinux.org/viewtopic.php?id=37579 Additional info: * package version(s) 2.6.27.7 |
This task depends upon
Closed by Tobias Powalowski (tpowa)
Thursday, 12 March 2009, 17:40 GMT
Reason for closing: Implemented
Additional comments about closing: 2.6.28.7-2
Thursday, 12 March 2009, 17:40 GMT
Reason for closing: Implemented
Additional comments about closing: 2.6.28.7-2
I must say there is one part which is not needed: the test for if the kernel has already been patched. I added this because it speeds up the recompilation. Run "makepkg -e" won't extract the source, so it does not need re-patching (which will fail because of the "|| return 1"). This is not needed for the custom kernel name, but a nice addition IMO, specifically if you build and rebuild and rebuild kernels (which you guys probably do a lot!)
_kernelname=${pkgname#*-} may work better and be more logical (remove everything up to the first dash)
I'd change the -eee comment to -custom or something, to make it more clear
I don't like the _arch_patched check, as you mentioned.
The if around the sed line seems silly, as if kernelname == "" then you will get the same behavior in both cases
And the firmware handling seems questionable. It almost makes me feel like we should split the firmware out into another package or something :S
Yeah to much of magic numbers... What I wanted here is to have a variable contaning "-NAME" or nothing (""). Then if pkgname=kernel26, the stock kernel will be built. But this kernel have "CONFIG_LOCALVERSION=-ARCH", so the modules will be installed to /lib/modules/2.6.28-ARCH/ but with "kernel26.img"...
So because the variable contains "-NAME" or nothing, then it can be addded after "kernel26" where relevant (for example in the mkinitcpio config).
Note that with this logic in mind, I cannot have the variable containing just "NAME" instead of "-NAME": I would need to add "-" between ${_kernelname} and "kernel26" but if ${_kernelname} is empty, I'll end up with "kernel26-".
So, to get back to the magic number. I'd like to find an "automatic" way. ${pkgname#*-} would return "NAME" (and not "-NAME"). Again I can't simply add "-" in from of ${pkgname#*-} because it would result in "kernel26-" for the stock kernel. Also, if "pkgname=kernel26", then ${pkgname#*-} return "kernel26" and not an empty string... So the best bet might be "${pkgname#kernel26}":
$ pkgname=kernel26
$ echo ${pkgname#kernel26}
$ pkgname=kernel26-custom
$ echo ${pkgname#kernel26}
-custom
$ pkgname=kernel26-eee
$ echo ${pkgname#kernel26}
$ pkgname=kernel26-e
$ echo ${pkgname#kernel26}
$
But then, its driving me crazy: How come I cannot match "kernel26" when I have "-*[e]" as the name??
2) -eee
Of course... done.
3) _arch_patched
How come you don't like it? Its faster if you recompile often. Its just to ease the maintenance...
I'll remove it anyway for this.
4) sed line
Wow your right, really useless ;) Removed!
5) Firmware
I think I never had the conflicting problem before 2.6.27 or something... It's probably included by default since .27. So our choices are:
-Keep the test to remove the firmware: hackish and not nice...
-Create a new package which will contain these firmwares, and make the kernel's PKGBUILD depend on it.
I would prefer another package... Because even the wiki page about custom kernel compilation does not talk about that. All custom kernels (installed side by side) will have conflict about these firmwares.
There is also another positive aspect of putting the firmwares in a separate packages. I remember reading something on the incompatible license of some firmwares. Correct me if I'm wrong, I would say the vanilla kernel does not have such problematic firmware included, but if it does, then one could make sure he has a clean system by not installing then if not necessary. That would make it an optinal dependency. Or it could be a real dependency if If there is no license problem and these firmwares are vital to any working systems.
TODO:
-Fix firmware issue
-e is a flag to echo, so it doesn't output it. I ran into it too.
This syntax will do what you want: ${pkgname/*-/-}
echo " ${pkgname/*-/-} " # note the spaces because of the -e thing here. this is JUST for echo
Other than that, I'm waiting for opinions from Thomas or Tpowa here 8)
${pkgname/*-/-} will match everything at the left of the _last_ "-", meaning if one have "kernel26-foo-bar", you'll end up with "-bar" only...
$ expr kernel-foo-bar : '[^-]*\(-.*\)'
I imagine a echo and sed might be a tad clearer to read...
$ echo kernel-foo-bar | sed 's/[^-]*\(-.*\)/\1/'
same regex in both cases
_kernelname=${pkgname#kernel26}
or
_kernelname=`echo ${pkgname} | sed 's/[^-]*\(-.*\)/\1/'`
?
2.6.28.2-1
I changed this part:
# load configuration
yes "" | make config
# build!
####################
# stop here
# this is useful to configure the kernel
#msg "Stopping build"
#return 1
####################
To:
####################
# stop here, this is useful to configure the kernel
msg "Stopping build, configure kernel in separate terminal and press key to continue"
read stuff
####################
This allows me to run make $favorite_.config_tweaker in a second terminal and continue building when it's ready.
One great thing would be to have a simple switch for disabling mkinitcpio completely somewhere in the PKGBUILD header (for static kernels). And ability to easily use a custom mkinitcpio${pkgname#kernel26}.conf along with the preset :)
It makes more sense to do something like that in the PKGBUILD instead of stopping like that
So first I let the extraction go, then when compilation starts I cancel that. I go in the source/linux-... dir, run make menuconfig myself, configure it the way I want, and then copy the .config back so it overwrite the origianl config (the one side-by-side with the PKGBUILD).
One I have a config which I like, I just keep it and use that one.
I even move the original config to config.arch, and put mine as config.mine, and create a symbolic link to the one I want to use. But then this is my workflow and does not influence the main topic... ;)
----------
# Configure the kernel. Replace the line below with one of your choice.
# make menuconfig # CLI menu for configuration
# make xconfig # X-based configuration
# ... or manually edit .config
yes "" | make config
----------
Because the firmwares depends on the modules being compiled or not (I think), all modules should be compiled to create the firmwares. This is why I "make allmodconfig" without any config file.
This is a proof of concept. A kernel package could depend on this one.
Also note that I kept the "if source is already patched, skip the patching" test to speed up compilation. It could be removed.
Thank you Nicolas for initiating this change and thanks to the whole team for making this happen.