[kernel] custom/patched kernel PKGBUILD

dtw · 2005-04-04 06:12:29

nice one, tomk, way to go to think on your feet!

Gnushoos: if your patching is failing it's simply the patch command in my build that you need to change. I see from big_gies that the software suspend has it's own applications script that you have to use? is that correct? the patch command in my PKGBUILD pretty much covers standard patchsets which are supposed to be applied in the root of the src dir - any thing else YMMV

dtw · 2005-04-12 11:12:06

OK - I'm going to update the PKGBUILD tomorrow to CORRECTLY address issues with 2.6.x.y branch and to allow a choice to make clean or just make.

I'll update all copies of the PKGBUILD and update the wiki

dtw · 2005-04-13 12:26:54

The wiki has been completely re-written and the PKGBUILD has been updated. The wiki now explains how and why the naming scheme is used and the PKGBUILD will now work for 2.6.x.y builds and you are now given an option to make or make clean

The PKGBUILD and variations are now also available on my server - see the wiki for details.

Please have read through the wiki - it really is much better

Suggestions still welcome

xerverius · 2005-04-13 13:25:07

Looks very nice, but i've just updated my kernel so i'm gonne use it when they release a new kernel version... Keep going on dibble

tomk · 2005-04-13 20:57:20

Hate to nitpick, dibble, but I've just done a 2.6.11.7 build with no patches, and I've still got a .y problem. Here's what's in the package:

Package Name: kernel26117.7.i5ka.20050413-2.6.11.7-1.pkg.tar.gz

/pkg/boot
System.map26117.7.i5ka.20050413
kconfig26117.7.i5ka.20050413
vmlinuz26117.7.i5ka.20050413

/pkg/lib/modules
2.6.11.7.i5ka.20050413

/pkg/usr/src
linux-2.6.11.7.7.i5ka.20050413

The only one of these that looks right to me is /lib/modules. Would it be possible NOT to include EXTRAVERSION in /boot and /usr/src when the source is 2.6.x.y?

tomk · 2005-04-14 01:27:48

Found the bug. On line 51, you're sedding .y out of _kernextra:

  _kernextra="`echo $_kernextra | sed "s|.4||g"`"

the problem being, of course, that you've left .4 hard-coded, so my .7 was ignored. I changed it to .7 and it worked perfectly.

dtw · 2005-04-14 05:08:45

I SCREWED UP THE PKGBUILD!

tomk - I'm so sorry, mate! Glad you spotted it - i found it last night and fixed it:

  # grab the 2.6.x.y version suffix from pkgver
  _y="`echo $pkgver | cut --delim "." --fields 4`"
  # remove .y version suffix from _kernextra
  _kernextra="`echo $_kernextra | sed "s|.$_y||g"`"

This is ok as long as no-one starts patching the Makefile with EXTRAVERSIONS with periods (.) and numbers in them - this really is the best i can think of at the moment and it should work perfectly, i just think it could be better

all PKGBUILDS updated - sincerest apologies - it was late...

tomk · 2005-04-14 09:37:01

No apologies necessary - you're doing all the work, and I'm just popping up with complaints!

I'll try one with a patch now........

tomk · 2005-04-14 23:54:10

Beautiful, dibble - that's the only word for it:

pkgname: kernel26117-mh2.i5ka.20050413-2.6.11.7-1.pkg.tar.gz

/pkg/boot
System.map26117-mh2.i5ka.20050413
kconfig26117-mh2.i5ka.20050413
vmlinuz26117-mh2.i5ka.20050413

/pkg/lib/modules
2.6.11.7-mh2.i5ka.20050413

/pkg/usr/src
linux-2.6.11.7-mh2.i5ka.20050413

From previous experience, I remembered to edit the patch file to look for .7 in EXTRAVERSION, and replace it with .7-mh2. After that, it was as smooth as silk.

Thanks for all the hard work.

dtw · 2005-04-15 05:31:42

great! a successful test!

One prob still tho which a lot of people may miss:

  if [ ${choice} = "NO" ] ; then
      make bzImage modules || return 1
  else
    make clean bzImage modules || return 1
  fi

should be:

  if [ "${choice}" = "NO" ] ; then
      make bzImage modules || return 1
  else
    make clean bzImage modules || return 1
  fi

this is now fixed in the wiki

phrakture · 2005-04-15 15:26:49

hey dibble: random suggestion... why not extrapolate the stuff that doesn't change into some bash functions so a kernel PKGBUILD would look (something) like this:

...blah
build()
{
   source ./kernel-functions
   add_patchset "zyx"
   build_menuconfig
}

yeah it's not exact... but the end result might be a cleaner/easier to read kernel PKGBUILD... just thinking out loud

dtw · 2005-04-17 07:33:35

that is a fair idea, like a PKGBUILD support file?

at this point i have tried to keep the PKGBUILD as verbose as possible purely in the hope that some people might try to follow how the naming schemes work - i could cut lots of that out for a start but i figure if people read it and understand it they might modify it themselves - i could offer that as another alt version tho

tomk · 2005-07-15 09:35:43

I just noticed a small problem with this PKGBUILD - the resultant package does not include /usr/src/<kernel_name>/Module.symvers. This affects the compilation of any external modules e.g. wlan-ng.

I have added the following line

cp Module.symvers $startdir/pkg/usr/src/linux-${_kernrel}

immediately after

# copy files necessary for later builds, like nvidia and vmware

as is done in the PKGBUILD for the stock kernel.

dtw · 2005-07-24 13:21:45

i dunno how i missed this post - the module.vers line was added recently to the stock kernel and my custom build was slow to catch up - someone fixed it tho

tomk · 2005-07-24 19:24:01

Yeah, me - was that not clear?

tomk wrote:

I have added the following line

dtw · 2005-07-24 20:51:47

I didn't even see the post - nevermind what you said

I have fixed them all now thanks

Mr Green · 2005-12-24 15:51:39

Err ok ... so initrd stuff is it going to be added to wiki page ...?

Are we going to go over to initramfs .... ?

Going to compare archck pkgbuild with wiki one, although thinking the wiki one may be better for me

/me reads more stuff

tomk · 2005-12-26 01:10:28

Here's how I see it:

You're thinking of using the wiki PKGBUILD to build your own custom kernel. When you're doing your kernel config, you can build into the kernel the modules required to boot your system. So, you don't need initird.

AFAIK, intird is deprecated in favour of initramfs - our devs went with initrd because they were familiar with it. If I am wrong about that, cool - correct me.

Mr Green · 2005-12-26 12:13:20

devs must know what they are doing (not going to argue that!) just there is talk of initramfs which is better me is very confused ....

As for wiki pkgbuild well may just use archck pkgbuild & adapt that ... wiki pkgbuild goes waaay over my head lol

Keeping an eye on archck kernel atm see how that develops

iphitus · 2005-12-26 13:28:38

Mr Green wrote:

devs must know what they are doing (not going to argue that!) just there is talk of initramfs which is better me is very confused ....
As for wiki pkgbuild well may just use archck pkgbuild & adapt that ... wiki pkgbuild goes waaay over my head lol
Keeping an eye on archck kernel atm see how that develops

I have an archck kernel working with initramfs, I just need to fix a few fbsplash issues.

The devs just didnt do their homework, if you take a look at the early-userspace documentation in the kernel, it's all about initramfs. During the 2.5 series there was also a little bit of fuss about initramfs, making it out to be this and that, which in the end, the code took a while to catch up to.

iphitus

tomk · 2005-12-26 17:17:48

Mr Green wrote:

As for wiki pkgbuild well may just use archck pkgbuild & adapt that ... wiki pkgbuild goes waaay over my head lol

Adapting the archck PKGBUILD seems to me to be the harder option, but it's your choice. I find the wiki PKGBUILD very straightforward - if you want to post any questions, I'd be happy to help if I can.

somedrew · 2007-06-06 08:08:04

Thanks for the PKGBUILD! Added arch and license flags to the wiki.

hpestilence · 2008-02-13 05:41:40

Could someone update the PKGBUILD on the wiki to reflect the changes in 2.6.24?

http://bbs.archlinux.org/viewtopic.php?id=43045

I tried modifying my local copy, but I still get the error in that thread.

big_gie · 2008-04-09 13:24:42

This is why I suggested adapting slightly the official kernel26's PKGBUILD to accept personification. That way, somebody can just run abs, copy the PKGBUILD directory, change the pkgname (from kernel26 to kernel26-mykernel for example) and it would built the same ARCH kernel, but with files and folders adapted to reflect the name change (/lib/modules/2.6.24-mykernel, /boot/kernel26-mykernel.img, etc).

That way, the same PKGBUILD could be used to build ARCH stock kernel and your own kernel, and install everything in parallel. The parallel stuff is important, as stated on the wiki, since you cannot risk of having a non-booting machine just because you wanted to try a certain patch.

It is also an interesting aspect to have the same PKGBUILD for stock and for custom: As you see, everything evolves rapidly, and keeping the wiki up to date is a hard task. Arch is using mkinitcpio but I did not see something about it on the wiki... The easiest thing would be to have the modifications in the official PKGBUILD.

Another positive thing is that more users could test PKGBUILDs, thus increasing the quality of it (not that it is bad). More users, more testing, thats the spirit of open-source. Right now, users cannot test easily new PKGBUILD, they need to ask the maintainer, via a bug report, then something might pop-up in [testing], which you might absolutely not know what changed. An easier way would be to allow the user to build/test their own kernel and reporting back, instead of waiting for [testing] and affecting all other users...

I've posted some patches for the kernel26's PKGBUILD back in 2.6.22.1 but did not had any response...
http://bbs.archlinux.org/viewtopic.php?id=37579

Would somebody still be interested in that? I know that each month I want to try something, test a new patch, new feature, etc. But I am falling short on the kernel building...

Leigh · 2008-11-05 05:03:59

This is how I been building and updating my custom kernel, using the official kernel26's PKGBUILD and modifying it to suit my needs. It's kind of confusing each time I update, trying to keep up with changes and some of it is a little over my head. If I were to loose the modified pkgbuild and configs, it would be a real pain to duplicate everything I altered. I really like big_gie's suggestion. It would make things very convenient, especially for those who only want to make few minor changes from the stock kernel.

Arch Linux

#76 2005-04-04 06:12:29

Re: [kernel] custom/patched kernel PKGBUILD

#77 2005-04-12 11:12:06

Re: [kernel] custom/patched kernel PKGBUILD

#78 2005-04-13 12:26:54

Re: [kernel] custom/patched kernel PKGBUILD

#79 2005-04-13 13:25:07

Re: [kernel] custom/patched kernel PKGBUILD

#80 2005-04-13 20:57:20

Re: [kernel] custom/patched kernel PKGBUILD

#81 2005-04-14 01:27:48

Re: [kernel] custom/patched kernel PKGBUILD

#82 2005-04-14 05:08:45

Re: [kernel] custom/patched kernel PKGBUILD

#83 2005-04-14 09:37:01

Re: [kernel] custom/patched kernel PKGBUILD

#84 2005-04-14 23:54:10

Re: [kernel] custom/patched kernel PKGBUILD

#85 2005-04-15 05:31:42

Re: [kernel] custom/patched kernel PKGBUILD

#86 2005-04-15 15:26:49

Re: [kernel] custom/patched kernel PKGBUILD

#87 2005-04-17 07:33:35

Re: [kernel] custom/patched kernel PKGBUILD

#88 2005-07-15 09:35:43

Re: [kernel] custom/patched kernel PKGBUILD

#89 2005-07-24 13:21:45

Re: [kernel] custom/patched kernel PKGBUILD

#90 2005-07-24 19:24:01

Re: [kernel] custom/patched kernel PKGBUILD

#91 2005-07-24 20:51:47

Re: [kernel] custom/patched kernel PKGBUILD

#92 2005-12-24 15:51:39

Re: [kernel] custom/patched kernel PKGBUILD

#93 2005-12-26 01:10:28

Re: [kernel] custom/patched kernel PKGBUILD

#94 2005-12-26 12:13:20

Re: [kernel] custom/patched kernel PKGBUILD

#95 2005-12-26 13:28:38

Re: [kernel] custom/patched kernel PKGBUILD

#96 2005-12-26 17:17:48

Re: [kernel] custom/patched kernel PKGBUILD

#97 2007-06-06 08:08:04

Re: [kernel] custom/patched kernel PKGBUILD

#98 2008-02-13 05:41:40

Re: [kernel] custom/patched kernel PKGBUILD

#99 2008-04-09 13:24:42

Re: [kernel] custom/patched kernel PKGBUILD

#100 2008-11-05 05:03:59

Re: [kernel] custom/patched kernel PKGBUILD

Board footer