Generate custom kernel

lilsirecho · 2004-05-10 03:21:46

The following procedure provides a useable method of modifiying any arch kernel to produce a "custom" version (which must be repeated if subsequent kernel version upgrade is encountered).

------------------------------------------------------------------------------------------------------------------------------------------------------

*OVERVIEW*
------------------------------------------------------------------------------------

Command _ABS_ initiates a download into _/var/abs/kernels_ of all up-to-date data (CONFIG and PKGBUILD for example) for all kernels in arch archives (not the full kernels, just the data)
From the above location, the desired kernel data is derived by opening that directory and copying the _CONFIG_ and _PKGBUILD_ files to the _ /var/abs/local_
directory to permit customizing.
The two files are edited to your requirements to prepare them for _makepkg_,(_and they are saved_).
_makepkg PKGBUILD_ generates the new kernel _.pkg.tar.gz_. (This may entail a download of the kernel _.tar.bz2_ if it is not resident in your computer).
_Pacman -A kernel-x.x.x.pkg.tar.gz_ installs the new custom kernel.
_LILO_ or _GRUB_ are then configured. (If _*LILO_*, then _*/SBIN/LILO -v_* to verify correct install and kernel ID).
Reboot and select the new kernel ID at boot prompt.

-------------------------------------------------------------------------------------

Step by step procedure:

1. As root, _abs_ enter. (Download of data from arch archives)
2. _cd /var/abs/kernels_
3. Open desired kernel and _cp CONFIG and PKGBUILD_ files to _/var/abs/local_ directory.
4. _cd /var/abs/local_.
5. Open _CONFIG_ file and edit to your needs. _*SAVE AS CONFIG OVERWRITE_*.
6. Open _PKGBUILD_ file and edit it as follows;

a. Comment out _MD5_ entry
b. Enter at Pkgname...._pkgname=kernel-$pkgver-custom_ ..
Note 1: -custom can be your name selection...
c. Enter at pkgver...pkgver=_X.X.X_ ...(the kernel version numbers)
Note 2: If _conflicts= _ is in the entries set the entry as
follows: _conflicts= ( )_
7. Edit the _build _( ){ section as follows;

entry _yes""|make config_
Note3: If system is X based...change to... just _make xconfig_
Note4: If system is console based...change to..just....
_makemenuconfig_
8. _*SAVE AS_* PKGBUILD and _*OVERWRITE_*
9. Run _makepkg PKGBUILD_. (A long process with one break _Xqconf<2>_ which you can skip:File,Quit,Save Config.
10. When makepkg completes, open the /var/abs/local directory and obtain the ID of the new kernel.tar.gz which is needed verbatim in next step.
11. Run_pacman -A kernel-x.x.x-custom.pkg.tar.gz_
Note5: Use the ID from step 10, verbatim!
12. Its break time while the kernel pkg is generated in /var/abs/local directory..
13. At completion of pkg generation, open/var/abs/local/kernel/pkg/boot and derive the ID of the vmlinuz file. If its ID conflicts with your systems present ID's, rename the vmlinuz file, to perhaps: _vmlinuz26a_. (This file must reside in root/boot if you run things from there, or it must be copied to the /boot file that your system uses, possibly in some usr file.
14. _cd_ to root. Edit _*LILO.CONF_* or _*GRUB_* to your new kernel requirements.
Note6: If _*LILO_*, after config and _SAVE_, _cd enter_ , then
run_*/sbin/lilo -v_* to verify the kernel ID entered and
no errors) _IMPORTANT_ (no typo errors)
15. Reboot and at boot prompt, select your new kernel ID.

--------------------------------------------------------------------------------------
The following is a sample PKGBUILD ready for makepkg which shows the affected entries;

# $Id: PKGBUILD,v 1.14 2004/04/05 08:06:47 judd Exp $

# Maintainer: judd <jvinet@zeroflux.org>

pkgname=kernel-$pkgver-ramfs ...._CHANGE HERE_

pkgver=2.6.5 ...._CHANGE HERE_ Note: no dash numbers!(pkgrel=)

pkgrel=2

pkgdesc="The Linux Kernel and modules (IDE support)"

url="http://www.kernel.org"

backup=('boot/kconfig26')

depends=('module-init-tools')

install=kernel26.install

source=(ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-$pkgver.tar.bz2

config)

build() {

cd $startdir/src/linux-$pkgver

# get rid of the 'i' in i686

carch=`echo $CARCH | sed 's|i||'`

cat ../config | sed "s|#CARCH#|$carch|g" >./.config

make xconfig ...._CHANGE HERE_

make clean bzImage modules || return 1

mkdir -p $startdir/pkg/{lib/modules,boot}

make INSTALL_MOD_PATH=$startdir/pkg modules_install || return 1

cp System.map $startdir/pkg/boot/System.map26

cp arch/i386/boot/bzImage $startdir/pkg/boot/vmlinuz26

install -D -m644 Makefile $startdir/pkg/usr/src/linux-$pkgver/Makefile

install -D -m644 .config $startdir/pkg/usr/src/linux-$pkgver/.config

install -D -m644 .config $startdir/pkg/boot/kconfig26

mkdir -p $startdir/pkg/usr/src/linux-$pkgver/include

mkdir -p $startdir/pkg/usr/src/linux-$pkgver/arch/i386/kernel

for i in asm-generic asm-i386 config linux math-emu net pcmcia scsi video; do

cp -a include/$i $startdir/pkg/usr/src/linux-$pkgver/include/

done

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

cp -a scripts $startdir/pkg/usr/src/linux-$pkgver/

cp arch/i386/Makefile $startdir/pkg/usr/src/linux-$pkgver/arch/i386/

cp arch/i386/kernel/asm-offsets.s $startdir/pkg/usr/src/linux-$pkgver/arch/i386/kernel/

# copy in Kconfig files

for i in `find . -name "Kconfig*"`; do

mkdir -p $startdir/pkg/usr/src/linux-$pkgver/`echo $i | sed 's|/Kconfig.*||'`

cp $i $startdir/pkg/usr/src/linux-$pkgver/$i

done

cd $startdir/pkg/usr/src/linux-$pkgver/include && ln -s asm-i386 asm

chown -R root.root $startdir/pkg/usr/src/linux-$pkgver

cd $startdir/pkg/lib/modules/$pkgver &&

(rm -f build; ln -sf /usr/src/linux-$pkgver build)

}

---------------------------------------

dp · 2004-05-10 03:40:20

this would be much better in the wiki

lilsirecho · 2004-05-10 03:43:00

It was once in the wiki and was erased by other user. Rasat placed it there again and again it was erased.

dp · 2004-05-10 03:48:03

lilsirecho wrote:

It was once in the wiki and was erased by other user. Rasat placed it there again and again it was erased.

hmm ... this is not good - do we know, who erased it? (the ip-number should be logged somewhere)

Dusty · 2004-05-10 03:52:47

dp wrote:

this would be much better in the wiki

It has been posted to wiki and edited... he's posted it to the forum multiple times in different boards, I'm still not sure why.

Dusty

lilsirecho · 2004-05-10 03:55:14

You are free to look it up in the wiki as it is now entered by someone else. I don't recall the ID and wouldn't know what to do with it anyway.

I guess I can live with this post or another if necessary.

Dusty · 2004-05-10 04:24:44

I don't know who deleted it the first time.

I'm the one that edited it into its current version. I corrected grammar, changed some incorrect assumptions, tested the procedure and made it more user friendly. I believe that the current version (which has been further edited) is more useful than the original version; that is the point of a wiki, to let users collaborate to come up with better solutions.

Dusty

lilsirecho · 2004-05-10 05:55:31

I was unaware that editing meant to rewrite in first person.

General application of the procedure I include in this post permits all arch versions to be utilized. My example is included to illustrate one such custom case.

The present wiki is specific to kernel2.6.5 in areas sensitive to the entry of correct kernel data.

Typos occur with every one and /sbin/lilo -v must be observed to establish no error and the entry of the new custom data. Otherwise, either kernel panic, or default kernel boot. Been there, done that.

The correct kernel entry at pacman -A (etc) must be verbatim. The example given in the wiki cannot have been verbatim, I have done four such custom kernels and the format was different than that shown.

The correct entry of vmlinuz, referenced in the procedure listed in this post, is also an important step. You get no custom boot if the vmlinuz is the same as the original kernel being customized, it will default to the original. Corollary:custom kernel..custom vmlinuz in order to keep them separate.

Further, kernel ID is only the version and doesn't include the release dash number. The use of the dash will cause an error message, of course.

If I missed an option for the /config in PKGBUILD, I hope I can be excused for being ignorant of it.

In preparing for a kernel change, I find it best to put all changes in one file as my procedure outlines. The packages downloaded from ABS include the CONFIG files as well as the PKGBUILD files. Editing in this environment is stable and correctable and easily saved, the listings in CONFIG files are easily searched (esp if one has already printed out the 32 pages of data beforehand). I chose to OVERWRITE to keep the file to two items, no mistakes, no options! If the user utilizes the Xq(conf) <2> window to make custom changes and by mistake makes a keyboard entry causing abort of the build, he has to start over (been there, done that). Therefore, I recommend skipping it and save config set up initially.

The procedure in this post has performed well for four separate runs including a kernel upgrade custom change due to release number change! A note to this effect would alert users to the impact of this event. (Not a kernel version change, just release number).

Now, the basic misunderstanding in this area becomes evident if one examines the purpose of ABS. It provides the data for all arch kernels, not the kernel itself, and it would seem that such an action suggests it is provided to custom change an arch kernel using such data.
The procedure now in the wiki doesn't address the CONFIG file thus downloaded and therefore is no longer utilizing all the ABS data provided.

Because there are many, many options in the CONFIG files, ABS provides the needed files
for each kernel version to enable their use in "customizing arch supported elements of the kernel options".

If this is an incorrect or inadequate application of ABS, I am out in left field. I felt it met the intent of providing such datas. As outlined in this post, the data is kept saved and protected .

Perhaps, other custom activities involving any and all kernels in arch have a different flavor than that I surmise for ABS in which case the CONFIG file provided might not be utilized , as is now outlined in wiki.

For those cases which utilize the ABS data as provided, custom changes to the kernel are indeed possible and can be implemented for all arch kernels. ABS then is a kernel of data
for a new custom built kernel and seems to be slanted that way.

What am I missing, elements not intended to be handled by ABS CONFIG?

Dusty · 2004-05-10 20:08:02

I'm not sure that I'm following all your differences here. I've updated the Wiki entry to use 2.6.6 values (the version is just an example; any version could be used), and I addressed some of your concerns:

http://wiki.archlinux.org/index.php/Ker … with%20ABS

The wiki does suggest you run

lilo

after installing new kernels, and even suggests you configure it.

lilo -v

is simply verbose mode lilo, the -v parameter is not necessary for checking the mbr table.

One major difference between the current wiki system and yours is that it uses a custom PKGBUILD to install a custom kernel. The reason for this is that you can install your custom kernel alongside the stock Arch kernel. This permits you to, for example, list both the stock and custom kernel in lilo or grub. The advantage is that you can default to the stock kernel if something goes wrong. That is why the kernel name is kernel26-custom, so you don't *replace* the kernel26 package, you just add a second package.

Presumably, if all went well with your custom package, you could remove the stock kernel with

pacman -R kernel26

to clean out the old kernel.

I hope this addresses some of your concerns. I'd appreciate hearing anything else you think should be added. I will be writing official documentation on compiling the Arch kernel based on this wiki entry; I would like to ensure it is correct.

One note, I haven't tested the latest version of the wiki, as it will be a while before I can download the latest kernel sources. I will likely make more discoveries and changes at that time.

Dusty

lilsirecho · 2004-05-10 22:20:04

Dusty;

I have four such custom kernels available in /boot prompt(and the original Linux 2.6.5) and these were generated with the procedure I outlined. I can select the desired boot.

I emphasize the advantage of doing CONFIG in a protected file.

Arch Linux

#1 2004-05-10 03:21:46

Generate custom kernel

#2 2004-05-10 03:40:20

Re: Generate custom kernel

#3 2004-05-10 03:43:00

Re: Generate custom kernel

#4 2004-05-10 03:48:03

Re: Generate custom kernel

#5 2004-05-10 03:52:47

Re: Generate custom kernel

#6 2004-05-10 03:55:14

Re: Generate custom kernel

#7 2004-05-10 04:24:44

Re: Generate custom kernel

#8 2004-05-10 05:55:31

Re: Generate custom kernel

#9 2004-05-10 20:08:02

Re: Generate custom kernel

#10 2004-05-10 22:20:04

Re: Generate custom kernel

Board footer