[kernel] custom/patched kernel PKGBUILD

dtw · 2005-01-17 08:08:48

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
I just did some serious flaming of certain kernel PKGBUILDS for which I must apologise but the situation is getting ridiculous!

The custom kernel with ABS page on the wiki is supposed to remove the necessity for a individual PKGBUILD for each and every custom kernel and patch version created!

It's just daft! I think it is important that people are contributing to Arch and helping other users with their kernel compilation but how many more PKGBUILDS for nitro ARE ther going to be?! Until darckness dies?

The current PKGBUILD on the wiki cannot account for the LOCALVERSION variable that is now present in 2.6 - many other PKGBUILDS on the forum also cannot. the major problem is how to create custom module dir path names and /boot file names. this can be done using the EXTRAVERSION and LOCALVERSION vars (best as that is what the makefile tries to do).

I have had some success with this and appear to be the only one who actually tried!

however, when it comes to getting and arch pkgname that is representative of the kernel version you start to get problems.

in closing it should be possible to again create a bullet-proof PKGBUILD that can account for all patchsets, whether they set EXTRAVERSION or not, and can account for people making proper use of LOCALVERSION.

i can't bear to see the continuation of the current situation with so much replication of effort and divergence away from simple, straight-forward and standard!

dtw · 2005-01-17 08:15:46

i better add that i don't want to start a massive flame war about this - i just want to get a wiki page up that accounts for everything! it shoudl include one customizable PKGBUILD, notes on how to do that customization and we can even include sections about individual patchsets, especially releases.

i saw a really crap t-shirt to day with a valauble message

Together Everyone Accomplishes More

- ok you can throw stuff now!

Mr Green · 2005-01-17 09:32:16

Ok ....so like the Wiki PKGBUILDs are waaay out of date ...

A one for all pkgbuild is just going to work or will be way to complex ...

discuss .....

dtw · 2005-01-17 09:36:38

a one for all IS possible - i have something that i am sure is very close - i'll post it tomorrow

Mr Green · 2005-01-17 09:46:52

Sooo you have catered for rc mm etc ... extraversion localversion ... patch... adding extraversion to vmlinuz26 ...

great.... must be massive .....

O & a gui menu for config manager would be nice

dtw · 2005-01-17 09:52:21

Sooo you have catered for rc mm etc ... extraversion localversion ... patch... adding extraversion to vmlinuz26 ...

yup - a patch is a patch

great.... must be massive .....

no

O & a gui menu for config manager would be nice

that's not even funny

Mr Green · 2005-01-17 09:55:13

Ok...

might be good idea to remove old Pkgbuilds (or update) from Wiki

dtw · 2005-01-17 10:03:49

i now have every major patch i can find with google in 5 mins - will test all with my package build and demo the results tomorrow

i would like to add that i very much doubt i have produced a definitive example that's why i posted this post! but mr green called me out - and i hate being called out!

Mr Green · 2005-01-17 10:39:18

Sorry :cry:

Mith · 2005-01-17 19:45:48

@ dibblethewrecker

I am really curious about your results, so keep this uptodate

dtw · 2005-01-18 07:44:30

So, this is to put off any doubters. I downloaded as many patches as i could find - then i wrote a script called screwmrgreen, which i hope he doesn't take personally . it basically patches the kernels but doesn't compile them and shows us the results. you don't really need to follow the mechanics tho...

basically the results can be seen in this dir on my site:

http://dtw.jiwe.org/share/kernels

i used -dib as LOCALVERSION - just to show it works. each patch has it's own dir that includes the resulting pkg, showing the correct name but which is otherwise empty as i took out the build part, the PKGBUILD which shows the pkgname correctly set after the build and the patch version, plus a file (buildstats) which shows how the different version vars get set. (i do have another almost identical PKGBUILD which creates buildstats for every build - i like to have this as a record)

so, the actual working PKGBUILD is below. Please read it carefully before you use it, it is well annotated.

PKGBUILD removed - see wiki for latest version and updated guidlines!

THIS IS DEPRECATED!

As usual you can add stuff to the source array, patch section and whether you want the Arch logo - you don't need that explained. You also choose your config method by simply uncommenting the one you want to use - xconfig is uncommented by default as gconfig seems to be broken with the new gtk...

Other notes:
1) once you have your new config it is renamed with the date and time and put in your build dir.

2) IMPORTANT - at the end of the build the PKGBUILD is automatically altered with the correct pkgname - this is so that you can correctly gensync the new kernels.

this no longer apllies wrote:

this means that the EXACT same PKGBUILD cannot be reused without changing the pkgname back to kernel26 when you start the next build

As i said, this is not supposed to be a final solution but I am certain it does work as intended. maybe the final part should show you what the full pkgname should be and give you the choice to update it yourself or automatically - personally i have left that out for now as i think this is as simple/complicated as it needs to be.

dtw · 2005-01-20 06:48:21

i totally altered the wiki

http://wiki2.archlinux.org/index.php/Cu … 20later%29

IceRAM · 2005-01-20 07:29:52

dibblethewrecker wrote:

i totally altered the wiki

Thank you for doing so.
I severely lack the time to do it. I'm not really sure the Arch Users are interested in running pre-2.6.9 kernels though. Maybe the 2.6.8 page should be removed.

dtw · 2005-01-20 08:10:00

I'll leave the removal of pages to an expert - i have renamed and moved lots of them to clarify the situation.

I have also started a page on kernel patches and patchsets which i would greatly appreciate contributions for http://wiki2.archlinux.org/index.php/Po … 0patchsets

in particular:

could dp comment on -mm?
could lovechild comment on -love?
anyone know what the -ac patchset aims to do?

can people please add some more standalone patches they like to use?

i would appreciate any feedback and comments on patchset stability (crashes), reliability (fixes) and performance

kill · 2005-01-20 21:17:02

I added info for grsecurity patches.

dtw · 2005-01-21 05:29:57

thanks dude

i had a realization last night - my kernel package build does not create unique filenames in /boot !

if you build 2.6.9-ck3 and 2.6.10-ck3 they both produce a files in boot called $name-ck3 - which will obviously cause overwrites! whooops!

  cp System.map $startdir/pkg/boot/System.map26${_kerncust} 
  cp arch/i386/boot/bzImage $startdir/pkg/boot/vmlinuz26${_kerncust} 
  install -D -m644 Makefile  
    $startdir/pkg/usr/src/linux-${_kernrel}/Makefile 
  install -D -m644 .config  
    $startdir/pkg/usr/src/linux-${_kernrel}/.config 
  install -D -m644 .config $startdir/pkg/boot/kconfig26${_kerncust}

this is very easily resolved, and i will address this shortly:

i can simply add the pkgver to the names e.g:

System.map26-$pkgver${_kerncust}

System.map26-2.6.10-ck3-dibble

but that is a bit sucky looking i think this is better - which needs a bit more tweaking:

System.map2610-ck3-dibble

this requires a simple sed of the $pkgver and i'll make the fix, test it and update the PKGBUILD

SORRY!

dtw · 2005-01-22 08:23:47

ok - made some quite big changes. I realized that installations of the same patch version but different kernel version e.g. 2.6.9-cko3 and 2.6.10-cko3 would cause overwrites in /boot (both will give vmlinuz26-cko3) - this also led me to realize that when the pkgname is simply set as kernel26-cko3 - this is fine for every other pkg that pacman looks after, as new versions should be updated, but this is differnet with kernels - as per the above example you might want 2.6.9-cko3 and 2.6.10-cko3 but my pkgbuild gives them the same name - kernel26-cko3.

so, i fixed this. in the process i also figured out how to remove the need to be so miltant about the pkgname being declared as kernel26 at the start so that it can be changed later - i simply save that pkgname at the start and use sed to replace that with the new name -SIMPLE - how could i miss that?

PKGBUILD removed - see wiki for latest version!

dtw · 2005-01-27 04:18:22

http://bbs.archlinux.org/viewtopic.php? … highlight=

Oh the humanity! If i believed in God i'd beg him for help!

:cry:

tomk · 2005-01-27 12:21:30

Well - I'm using yours, dibble, and I have a couple of questions. I ran it with vanilla 2.6.10 and the mh2 bluetooth patch, and it all went fine. Pacmanned the package, and I now have a vmlinuz2610-mh2 in /boot. If I now compile another kernel using the same sources, I'm going to get another vmlinuz with the same name - right? So it will overwrite the first one, which is not the desired result.

I notice that you do not have the _kerrev= parameter that was in one of the previous PKGBUILDs on the wiki. If I add that in to yours, will I get something like

vmlinuz26-mh2<kerrev>

I'm used to putting the machine name and date on my kernels, and I was using kerrev for that.

dtw · 2005-01-28 10:56:32

ok - i'll check i understand your point here!

you built you a pkg which is called:

kernel2610-mh2-*-1.pkg.tar.gz

You want to build it again but not overwrite the previous one , i.e. you don't want:

kernel2610-mh2-*-2.pkg.tar.gz

when i was creating this PKGBUILD i wasn't think many people would want to do this but i knew it was accounted for anyway!

you can now use the LOCALVERSION setting in your config file to do what kerrev used to do - that is the easiest way to do it. that will get added to the pkgname and pacman will be able to distinguish it from you first pkg.

as far as i can tell that should achieve exactly the same result as using a kerrev but actually makes use of the features now provided by the kernel.

if you always add the date and machine name to your kernels you can just put that in your default config:

LOCALVERSION="-machinename-date"

you can set that before you build in a default config you might use or at the config stage manually each time - if you want to automate that you can easily use sed to set LOCALVERSION in your config during the build

e.g. THIS IS AN UNTESTED EXAMPLE! it assumes LOCALVERSION is blank

  # get rid of the 'i' in i686
  carch=`echo $CARCH | sed 's|i||'`
  cat ../config | sed "s|#CARCH#|$carch|g" >./.config

  cat ./.config | sed "s|LOCALVERSION=""|LOCALVERSION="-$HOSTNAME-`date +%d%m%y`"|g" >./.config

  ##### Load config - uncomment your prefered config method - remember to set LOCALVERSION if desired
  #yes "" | make config
  #make oldconfig || return 1
  #make menuconfig
  make xconfig
  #make gconfig

how's that?

EDITED missed the " at the end of the sed

tomk · 2005-01-28 15:15:02

dibblethewrecker wrote:

you built you a pkg which is called:
kernel2610-mh2-*-1.pkg.tar.gz

Correct - I'm not at my machine now, so I'll add the exact package name later.

dibblethewrecker wrote:

You want to build it again but not overwrite the previous one , i.e. you don't want:
kernel2610-mh2-*-2.pkg.tar.gz

Incorrect - I do want kernel2610-mh2-*-2. What I am concerned about is the the fact that my /boot now holds a kernel called vmlinuz2610-mh2, along with a corresponding config and system map, and /lib/modules holds a subdir called 2.6.10-mh2. None of these file or directory names contain any reference to the -1 included in the package name, so I am assuming that changing that to -2 or -3 etc will result in an identically-named set of files and directories, thereby overwriting the current ones.

Thanks for clarifying the usage of LOCALVERSION - I'll give that a go this evening - and I might even use your host/date automation....

dtw · 2005-01-29 07:22:37

REMEMBER that is an untested suggestion that came out of the top of my far from expert head!

sorry, i confused myself up there.

what i actually meant to say was you don't really want a *-2.pkg.tar.gz - because that would imply you intend to replace *-1.pkg.tar.gz with it, as you would for any normal pacman pkg.

you want a *-something-1.pkg.tar.gz

as i said you can add that something with the LOCALVERSION

i know you know - i am just clarify so that you know that i know what you meant and that the solution is the same

all the best

tomk · 2005-02-09 12:27:16

I'm back, dibble, with another question.

I want to build another 2.6.10-mh2 kernel, so I've gone back into the same PKGBUILD, changed pkgrel to 2, and changed the config method to make menuconfig. I run makepkg, and everything goes well until the patching phase, which throws up two "hunk ignored" errors. Then I get

==> ERROR: Build Failed.  Aborting...

and that's it.

Is that the way it's meant to work? Do I need to start afresh with a new PKGBUILD?

dtw · 2005-02-10 09:03:41

are you using fresh source code? you're not trying to repatch the previous compiled code are you? my PKGBUILD should not, in any way, affect how the patch applies, as long as the patch line is correct (i.e. the p option), that is where the PKGBUILD's reponsibility ends other than that it's your source and patch

HTH

by the way - i have slightly updated the pkgbuild again - not any ground breaking changes - just a good tweak for the pkgname reset at the end

tomk · 2005-02-16 10:26:42

Me again, dibble. I've got my head straight regarding the patching now, but I still have a problem, which i suspect is in my own misunderstanding of the process, but maybe you could shed some light on it?

As a general principle, I never want a new kernel package to replace an existing one. From previous posts, I believed that I could achieve this using your PKGBUILD, makepkg, and pacman, as long as I put a unique string in LOCALVERSION each time i recompiled. However, it appears that pacman knows nothing about LOCALVERSION - instead, pacman sees a new version of kernel26 and upgrades from the existing version. At one stage, my machine was running on a kernel and modules that did not exist in /boot or /lib/modules, because pacman had overwritten the running kernel with the new package! Surely this should not be possible?

For the moment, I'm using makepkg to create the package, but then I manually copy the new modules directory and the vmlinuz and kconfig files to the right directories. The directory and files carry the LOCALVERSION identifier and therefore do not overwrite the running kernel.

What am I missing here? Do I need to give each package (as opposed to each kernel) a unique name so that pacman will treat them as such? If so, where do I specify that name?

Arch Linux

#1 2005-01-17 08:08:48

[kernel] custom/patched kernel PKGBUILD

#2 2005-01-17 08:15:46

Re: [kernel] custom/patched kernel PKGBUILD

#3 2005-01-17 09:32:16

Re: [kernel] custom/patched kernel PKGBUILD

#4 2005-01-17 09:36:38

Re: [kernel] custom/patched kernel PKGBUILD

#5 2005-01-17 09:46:52

Re: [kernel] custom/patched kernel PKGBUILD

#6 2005-01-17 09:52:21

Re: [kernel] custom/patched kernel PKGBUILD

#7 2005-01-17 09:55:13

Re: [kernel] custom/patched kernel PKGBUILD

#8 2005-01-17 10:03:49

Re: [kernel] custom/patched kernel PKGBUILD

#9 2005-01-17 10:39:18

Re: [kernel] custom/patched kernel PKGBUILD

#10 2005-01-17 19:45:48

Re: [kernel] custom/patched kernel PKGBUILD

#11 2005-01-18 07:44:30

Re: [kernel] custom/patched kernel PKGBUILD

#12 2005-01-20 06:48:21

Re: [kernel] custom/patched kernel PKGBUILD

#13 2005-01-20 07:29:52

Re: [kernel] custom/patched kernel PKGBUILD

#14 2005-01-20 08:10:00

Re: [kernel] custom/patched kernel PKGBUILD

#15 2005-01-20 21:17:02

Re: [kernel] custom/patched kernel PKGBUILD

#16 2005-01-21 05:29:57

Re: [kernel] custom/patched kernel PKGBUILD

#17 2005-01-22 08:23:47

Re: [kernel] custom/patched kernel PKGBUILD

#18 2005-01-27 04:18:22

Re: [kernel] custom/patched kernel PKGBUILD

#19 2005-01-27 12:21:30

Re: [kernel] custom/patched kernel PKGBUILD

#20 2005-01-28 10:56:32

Re: [kernel] custom/patched kernel PKGBUILD

#21 2005-01-28 15:15:02

Re: [kernel] custom/patched kernel PKGBUILD

#22 2005-01-29 07:22:37

Re: [kernel] custom/patched kernel PKGBUILD

#23 2005-02-09 12:27:16

Re: [kernel] custom/patched kernel PKGBUILD

#24 2005-02-10 09:03:41

Re: [kernel] custom/patched kernel PKGBUILD

#25 2005-02-16 10:26:42

Re: [kernel] custom/patched kernel PKGBUILD

Board footer