[arch-general] Kernel PKGBUILD proposition: Ease custom kernel compilation.
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[1-2] 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[3], 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. 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://wiki.archlinux.org/index.php/Kernel_Compilation_with_ABS [2] http://wiki.archlinux.org/index.php/Custom_Kernel_Compilation_with_ABS [3] http://bbs.archlinux.org/viewtopic.php?id=37579
Nicolas Bigaouette wrote:
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[1-2] 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[3], 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.
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://wiki.archlinux.org/index.php/Kernel_Compilation_with_ABS [2] http://wiki.archlinux.org/index.php/Custom_Kernel_Compilation_with_ABS [3] http://bbs.archlinux.org/viewtopic.php?id=37579
+1 I used to run Lunar Linux and really liked the way each kernel upgrade happened; it'd store a copy of your .config (or, in the case of big_gie's recommendation, a copy of the arch dev's .config) away under var, then download the kernel source, apply any patches, run a "make oldconfig", then ask if you wanted to configure the kernel. If you chose yes, it'd look at an environment variable and depending on what it found, run "make menu{,x,g,q,}config" and upon saving the .config it'd kick off the compilation and installation of the kernel. That's really the only thing that I miss about Lunar since coming over to Arch. Anyhow, it's just a feature request. :) -Tim
On Sun, Dec 7, 2008 at 17:08, Nicolas Bigaouette <nbigaouette@gmail.com> wrote:
Hi all! <snip> 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
As I've mentioned on the forums, I love this idea. Big +10 from me.
On Sun, Dec 7, 2008 at 5:47 PM, Daenyth Blank <daenyth+arch@gmail.com> wrote:
On Sun, Dec 7, 2008 at 17:08, Nicolas Bigaouette <nbigaouette@gmail.com> wrote:
Hi all! <snip> 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! :)
As I've mentioned on the forums, I love this idea. Big +10 from me.
This seems like an OK idea. It does make the PKGBUILD more messy, however. Either way, if you stick this in the bug tracker, we can get it assigned to the proper person and see what they feel about it. Me personally, I use the stock kernel, so I don't have much of an opinion. But back when I used to compile my own kernel, something like this would have been great.
Why the PKGBUILD gets a lilte bit "messy" is to treat an "unamed" kernel. The rest is only adding "${_kernname}" at the end of "kernel26"... I also use the stock kernel on my main laptop, but I compile my own for other machines. I also sometimes try some patches which are not yet included. I opened a bug report at http://bugs.archlinux.org/task/12384 2008/12/8 Aaron Griffin <aaronmgriffin@gmail.com>
On Sun, Dec 7, 2008 at 5:47 PM, Daenyth Blank <daenyth+arch@gmail.com<daenyth%2Barch@gmail.com>> wrote:
On Sun, Dec 7, 2008 at 17:08, Nicolas Bigaouette <nbigaouette@gmail.com> wrote:
Hi all! <snip> 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! :)
As I've mentioned on the forums, I love this idea. Big +10 from me.
This seems like an OK idea. It does make the PKGBUILD more messy, however. Either way, if you stick this in the bug tracker, we can get it assigned to the proper person and see what they feel about it.
Me personally, I use the stock kernel, so I don't have much of an opinion. But back when I used to compile my own kernel, something like this would have been great.
Nicolas Bigaouette wrote:
Hi all!
* lots of text here *
Whoah, that PKGBUILD is HUGE. Take a look at mine, which I use for my custom configs. It doesn't do one thing though, and that's install the kernel headers. You need those if you want to compile out-of-tree modules like nvidia. I'm not sure if it's 100% OK because I haven't used it in a long time, but the logic I like to follow is there. Glenn pkgname=linux pkgver=2.6.28 pkgrel=1 pkgdesc='Linux is a clone of the operating system Unix' arch=( 'i686' ) url='http://www.kernel.org/' license=GPL depends=( 'coreutils' 'mkinitcpio' 'module-init-tools' ) makedepends=('gcc') backup=("etc/mkinitcpio.d/$pkgname.preset") install=linux.install source=( "http://www.kernel.org/pub/linux/kernel/v2.6/testing/$pkgname-$pkgver.tar.bz2" config-$pkgver.i686 'linux.preset' ) build() { # Apply configuration cat config-$pkgver.$CARCH > $startdir/src/$pkgname-$pkgver/.config # cd to the kernel build directory cd $startdir/src/$pkgname-$pkgver/ # Process the configuration to get CONFIG_LOCALVERSION . ./.config # Make necessary directories mkdir -p $startdir/pkg/boot mkdir -p $startdir/pkg/etc/mkinitcpio.d mkdir -p $startdir/pkg/usr/src/${pkgname}-${pkgver}${CONFIG_LOCALVERSION}/ # Make the boot image and kernel modules make vmlinux bzImage make modules # Install boot image and kernel modules make INSTALL_MOD_PATH=$startdir/pkg modules_install if [ "$CARCH" = "x86_64" ]; then cp $startdir/src/$pkgname-$pkgver/arch/x86_64/boot/bzImage $startdir/pkg/boot/linux else cp $startdir/src/$pkgname-$pkgver/arch/i386/boot/bzImage $startdir/pkg/boot/linux fi # Setup mkinitcpio echo "ALL_kver='${pkgver}${CONFIG_LOCALVERSION}'" > $startdir/pkg/etc/mkinitcpio.d/$pkgname.kver install -m664 -D $startdir/src/$pkgname.preset $startdir/pkg/etc/mkinitcpio.d/$pkgname.preset }
Thats another story... I agree that the PKGBUILD is huge. There is probably a reason for that. It is true it is not the easiest one to read. Maybe another bug report? 2008/12/8 RedShift <redshift@pandora.be>
Nicolas Bigaouette wrote:
Hi all!
* lots of text here *
Whoah, that PKGBUILD is HUGE. Take a look at mine, which I use for my custom configs. It doesn't do one thing though, and that's install the kernel headers. You need those if you want to compile out-of-tree modules like nvidia. I'm not sure if it's 100% OK because I haven't used it in a long time, but the logic I like to follow is there.
Glenn
pkgname=linux pkgver=2.6.28 pkgrel=1 pkgdesc='Linux is a clone of the operating system Unix' arch=( 'i686' ) url='http://www.kernel.org/' license=GPL depends=( 'coreutils' 'mkinitcpio' 'module-init-tools' ) makedepends=('gcc') backup=("etc/mkinitcpio.d/$pkgname.preset") install=linux.install source=( " http://www.kernel.org/pub/linux/kernel/v2.6/testing/$pkgname-$pkgver.tar.bz2 " config-$pkgver.i686 'linux.preset' )
build() { # Apply configuration cat config-$pkgver.$CARCH > $startdir/src/$pkgname-$pkgver/.config
# cd to the kernel build directory cd $startdir/src/$pkgname-$pkgver/
# Process the configuration to get CONFIG_LOCALVERSION . ./.config
# Make necessary directories mkdir -p $startdir/pkg/boot mkdir -p $startdir/pkg/etc/mkinitcpio.d mkdir -p $startdir/pkg/usr/src/${pkgname}-${pkgver}${CONFIG_LOCALVERSION}/
# Make the boot image and kernel modules make vmlinux bzImage make modules
# Install boot image and kernel modules make INSTALL_MOD_PATH=$startdir/pkg modules_install if [ "$CARCH" = "x86_64" ]; then cp $startdir/src/$pkgname-$pkgver/arch/x86_64/boot/bzImage $startdir/pkg/boot/linux else cp $startdir/src/$pkgname-$pkgver/arch/i386/boot/bzImage $startdir/pkg/boot/linux fi
# Setup mkinitcpio echo "ALL_kver='${pkgver}${CONFIG_LOCALVERSION}'" > $startdir/pkg/etc/mkinitcpio.d/$pkgname.kver install -m664 -D $startdir/src/$pkgname.preset $startdir/pkg/etc/mkinitcpio.d/$pkgname.preset }
On Montag, 8. Dezember 2008 19:50 Nicolas Bigaouette wrote: +1 for your patch because it will be easier to have own kernel packages with it. Great work and nice idea.
Thats another story... I agree that the PKGBUILD is huge. There is probably a reason for that. It is true it is not the easiest one to read. Maybe another bug report?
Here i must give a -1 because first the only one who need to understand what happens is the kernel maintainer and second i must say instead i'm not a dev the PKGBUILD of the kernel26 package is from my view understandable enough. I think there is even room to write some things in another way because you can use this pkgname=kernel26-eee _kernelname=${pkgname:8} or this _modname=eee pkgname=kernel26-${_modname} which is what i use in my own kernel package (in the lines later is use ${_modname} nearly in the same way as you). But before you missunderstood me i'm more joking than starting a serious discussion about that there be such different ways to do nearly the same.-) See you, Attila
participants (6)
-
Aaron Griffin
-
Attila
-
Daenyth Blank
-
Nicolas Bigaouette
-
RedShift
-
Tim Gelter