Building first custom kernel

klenamenis · 2014-09-08 16:59:00

Hey,

I want to compile my first custom kernel, but have some questions regarding the best/recommended way to so. Everything but the drivers required by my current hardware shall be cut off, additionally I wish to implement/support the BFQ scheduler, virtualization (VirtualBox), CPU specific optimization, UKSM (and maybe some patches in the future). I already found/downloaded the desired patches (bfq, ck, UKSM, GCC).

After the initial set up, the update process should be as simple as possible. What way do you recommend me to accomplish my plans? According to our wiki, ABS seems to be the right choice, but neither am I familiar with it. Is there anything else I need to know? Any help or tips would be highly appreciated!

I don't use proprietary (graphic) drivers, wlan, bluetooth, floppy/optical discs or any "special" interfaces or devices.

Thanks in advance!

Last edited by klenamenis (2014-09-08 17:52:02)

jasonwryan · 2014-09-08 17:13:27

Use `localmodconfig` if you want simple updates. Also, look at graysky's modprobed-db in AUR if you want to automate your updates.

ewaller · 2014-09-08 18:28:28

If you want to do things beyond simple when using the files from the ABS, you will want to edit the PKGBUILD and remove the comment from the make menuconfig step. That will cause you to enter a curses menu to allow you to configure your kernel. You might want to consider having a few modules in addition to your kernel with everything built in, Examples of things you might want to modularize are file systems that you might one day need, or drivers for USB devices that might be attached to your system. By modularizing them, you don't need to have them loaded if you are not using them.

If you are really going to build everything into your kernel, then you do not need an initrd. I am going to suggest that the best solution would be to:

Grab the kernel source from kernel.org and unback it to a directory owned by your user (not root)
Get the configuration from the Arch Installation you are running (/proc/config.gz) and place it in the kernel source directory as .config
Find the modules that are in use on your Arch system using lsmod. Ensure those modules are selected to be be built in to your kernel.
Use one of the configuration menus from make to configure your kernel ( make menuconfig or make xconfig)
In your configuration, be sure to change the name of the kernel so it does not conflict with the stock kernel.
Compile your kernel.(make)

At this point, you have not done anything permanent. When ready, proceed with the following:

If you have any modules, install them with sudo make modules_install This installs the modules in a directory with the name of your kernel at /lib/modules/ This is why it is important that you change the name of the kernel in the configuration.

Copy the kernel, ./arch/x86/boot/bzImage, to /boot changing the name to something unique.
Configure your boot loader by adding your kernel, without an initrd, to your boot loader configuration.
Reboot and try it.

When it does not work Fall back to the default Arch kernel, fix your configuration, and try again.

You might want to read the Gentoo Handbook for some excellent guidance on how to build a kernel. Much of that document is directly applicable to Arch.

Good Luck, and enjoy.

Last edited by ewaller (2014-09-08 18:31:54)

graysky · 2014-09-08 18:57:05

jasonwryan wrote:

Use `localmodconfig` if you want simple updates. Also, look at graysky's modprobed-db in AUR if you want to automate your updates.

+1
This is precisely why I wrote it. I gave an example on the wiki page which shows the diff in # of modules built with and wo it. Have a look.

Roken · 2014-09-08 19:01:10

To be honest, I used to always build my own kernel, tailor made for my system. I had a config that I could load, and then nominally tweak for updates, but at the end of the day, both kernel size and performance increases were negligible and I stopped bothering.

Unless you have a very specific need. I wouldn't bother either. At some point, you WILL break something, and the time taken to fix it will outstrip any marginal benefits you get.

The Linux kernel is already pretty clean and streamlined, and the way the system works means you rarely have anything loaded that you don't need. Personally, I'd rather the odd thing slipped through than spend an age trying to find what I need and isn't there in a custom build.

Last edited by Roken (2014-09-08 19:01:32)

qinohe · 2014-09-09 10:26:03

@Roken, I don't agree with you totally, but, it's true, you won't gain a lot of performance boost.
You will at some point probably, end up with a unbootable kernel, but, I see this is a challenge, not a setback!

Well, if the kernel is clean, I'm mister Edet.
It's full of bloat you don't need, and some you will never use, so why not strip it?

@OP
It will give you a better picture of how Linux really works, so I say, do it, you will learn a lot from it. You will FI definitely know what modules you need and what they are for, otherwise your hardware won't work, or your encrypted disk won't be decrypted ;-)

I build two kernels, stable and mainline. Stable because I need some fall back if mainline ever gives up on me. Mainline, because I like to know about new things build for the kernel, and try them. It also gives you a nice window, when things stop working on mainline, you could anticipate and help solving the problem before it hits stable.

From me also, +1 on 'localmodconfig' & 'modprobed-db', they make life easy.

@ewaller, Why not use a PKGBUILD for that?, I also use a script to copy them to 'tmpfs',
and issue makepkg that way.

ewaller · 2014-09-09 15:28:30

qinohe wrote:

@ewaller, Why not use a PKGBUILD for that?, I also use a script to copy them to 'tmpfs',
and issue makepkg that way.

Old habits. Also, unless I go to moderate lengths, makepkg likes to start over at the beginning every time it is run. Using make allows for (easier) incremental building of the kernel. If you find you forgot something you need, just turn it on in the configuration and re-run make. The only thing that gets compiled at that point is the new module.

I am generally loath to use make to install things on my system outside of pacman. Having spent years with the penultimate distribution (Gentoo), I am comfortable using make for building and installing the kernel, therefore, I make the exception to using pacman. On the other hand when I break things, I do know it is up to me to fix them. In general, I've the ability.

qinohe · 2014-09-09 16:36:10

ewaller wrote:

qinohe wrote:
@ewaller, Why not use a PKGBUILD for that?, I also use a script to copy them to 'tmpfs',
and issue makepkg that way.
Old habits. Also, unless I go to moderate lengths, makepkg likes to start over at the beginning every time it is run. Using make allows for (easier) incremental building of the kernel. If you find you forgot something you need, just turn it on in the configuration and re-run make. The only thing that gets compiled at that point is the new module.
I am generally loath to use make to install things on my system outside of pacman. Having spent years with the penultimate distribution (Gentoo), I am comfortable using make for building and installing the kernel, therefore, I make the exception to using pacman. On the other hand when I break things, I do know it is up to me to fix them. In general, I've the ability.

Yes, old habits die hard... very hard..

Well, since I build in 'tmpfs' and not SSD, I couldn't care less issuing makepkg multiple times, and using ccache [Community], building takes 2 minutes. I don't know if you tried it, but if you didn't you should.. ;-)
I should definitely try to build a kernel by hand for Arch once.

Yeah, it makes sense, you don't really need pacman to manage the kernel, not much can go wrong I guess?

ewaller · 2014-09-09 16:44:32

qinohe wrote:

...and using ccache [Community], building takes 2 minutes. I don't know if you tried it, but if you didn't you should.. ;-)

I've not tried it, I'll look into it.

klenamenis · 2014-09-10 01:42:06

Wow, thanks for your feedback! localmodconfig and modprobed-db really help a lot with stripping down the kernel configuration. I went the ABS way and so far successfully added the patches to my PKGBUILD, updates checksums and started building. But as I already expected, after configuring the kernel (localmodconfig and xconfig make further adjustments), the compiling fails with

==> ERROR: A failure occurred in build().
    Aborting...

I guess, I configured something wrong and have to track it down. Is there any way to do this more effectively than manually rechecking the config? Furthermore: For now, each time a build failed I rerun makepkg just to get to the xconfig window again and fix/change something. I bet there is a faster way which does not require everything which got successfully compiled being recompiled, isn't it?

ewaller · 2014-09-10 02:36:05

klenamenis wrote:

I bet there is a faster way which does not require everything which got successfully compiled being recompiled, isn't it?

That is what qinohe and I were bantering about. My solution is to use make rather than makepkg. I think his suggestion of using ccache might be a really good way to handle it if using makepkg. I researched it at his suggestion, but I've not tried it yet.

Last edited by ewaller (2014-09-10 02:37:21)

qinohe · 2014-09-10 08:40:25

@ewaller, though I haven't tried, it should work building the way you do, from cli.
You want to change the 'export PATH'.
There are some limitations, but it will speedup compiling your program (not only the kernel of course) in most cases.
I guess you already found 'ccache.samba.org'

@OP, I want to give you another page, it was a classroom for building a kernel trough makepkg.
There a some very useful tips there you can use, and it tells you how the work flow should be.

https://archwomen.org/media/project_cla … kernel.txt

Figure things out, see which way to config the kernel suits you, there are more ways to do this. This and more will be clear after reading through that page.

klenamenis · 2014-09-10 17:12:35

I think im fine with PKGBUILD for now, as it's my first build. makepkg and ccache are running in /tmp so it doesn't last longer than 4 minutes or so, anyway. I successfully booted into my custom built kernel, but when I try to recompile with features like IPv6 or swap disabled, the building fails again. How can I check which other kernel features depend on IPv6 or swap space?

ewaller · 2014-09-10 17:41:58

klenamenis wrote:

I successfully booted into my custom built kernel,

Awesome! Well done.

but when I try to recompile with features like IPv6 or swap disabled, the building fails again. How can I check which other kernel features depend on IPv6 or swap space?

You may want to check out http://kernel-seeds.org/. The site is run by a guy named "Pappy" McFae, a legend in the Gentoo community. That site has a pretty darn good map/walk through of the kernel settings.

2ManyDogs · 2014-09-10 17:53:56

ewaller wrote:

You may want to check out http://kernel-seeds.org/. The site is run by a guy named "Pappy" McFae, a legend in the Gentoo community. That site has a pretty darn good map/walk through of the kernel settings.

^ this. Awesome site, useful instructions. And if you get stuck, do not hesitate to ask on the Gentoo forum, even though you are building an Arch kernel. Just be prepared to post your kernel config (wgetpaste or pastebinit). These guys are kernel experts. But if you value your sanity, do not mention systemd on the Gentoo forum.

Last edited by 2ManyDogs (2014-09-10 17:55:33)

stevenhoneyman · 2014-09-10 18:12:42

klenamenis wrote:

I think im fine with PKGBUILD for now, as it's my first build. makepkg and ccache are running in /tmp so it doesn't last longer than 4 minutes or so, anyway. I successfully booted into my custom built kernel, but when I try to recompile with features like IPv6 or swap disabled, the building fails again. How can I check which other kernel features depend on IPv6 or swap space?

the config tools won't let you disable something that is a requirement of something else. if you press '?' in menuconfig (& nconfig), it tells you why it is enabled at the bottom (try it on something obvious so you know what to look for)

klenamenis · 2014-09-10 18:58:31

stevenhoneyman wrote:

the config tools won't let you disable something that is a requirement of something else. if you press '?' in menuconfig (& nconfig), it tells you why it is enabled at the bottom (try it on something obvious so you know what to look for)

I use xconfig and there is no problem, conflict or error message (in ter terminal) when I uncheck parts. But I'll try menuconfig and '?', thanks for that!

Edit: '?' in menuconfig gives me the same information as xconfig already did. If there had been any hints that it was required by something else, I hadn't disabled it.

Last edited by klenamenis (2014-09-10 19:04:16)

stevenhoneyman · 2014-09-10 19:46:00

I'd say that means it should have been OK then. IPv6 and swap are disabled on my kernel config, and it works fine

klenamenis wrote:

I successfully booted into my custom built kernel, but when I try to recompile with features like IPv6 or swap disabled, the building fails again

Maybe it's a ccache/makepkg issue if it works once and then not again?

klenamenis · 2014-09-10 20:16:02

stevenhoneyman wrote:

I'd say that means it should have been OK then. IPv6 and swap are disabled on my kernel config, and it works fine
klenamenis wrote:
I successfully booted into my custom built kernel, but when I try to recompile with features like IPv6 or swap disabled, the building fails again
Maybe it's a ccache/makepkg issue if it works once and then not again?

Yeah, already thought that and reverted my CFLAGS back to default: voila, it works! It has probably something to do with the -march=native flag for cpu specific optimization. These are my custom CFLAGS I actually use:

CFLAGS="-march=native -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2"
CXXFLAGS="${CFLAGS}"

Does these parameters actually interfer with the applied GCC patch?

klenamenis · 2014-09-10 20:28:57

OK, I guess I trolled myself.. The patches haven't been applied at all (due to a typo in PKGBUILD) and I almost didn't even noticed while clicking myself through the config. I'll fix it, rebuild and post the result later

jasonwryan · 2014-09-10 20:30:36

klenamenis wrote:

OK, I guess I trolled myself..

Don't make ewaller pull out the banhammer.

stevenhoneyman · 2014-09-11 00:10:14

klenamenis wrote:

It has probably something to do with the -march=native flag for cpu specific optimization. These are my custom CFLAGS I actually use:
CFLAGS="-march=native -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2"
CXXFLAGS="${CFLAGS}"
Does these parameters actually interfer with the applied GCC patch?

The linux kernel build scripts don't use environment CFLAGS, it uses its own internal KCFLAGS
Flags that matter can be configured in .config - processor, optimization (-O2,-Os), and stack protection

klenamenis · 2014-09-11 17:08:55

When I try to rebuild I get the following:

The next patch would create the file block/bfq-cgroup.c,
which already exists!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored
The next patch would create the file block/bfq-ioc.c,
which already exists!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored
The next patch would create the file block/bfq-iosched.c,
which already exists!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored
The next patch would create the file block/bfq-sched.c,
which already exists!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored
The next patch would create the file block/bfq.h,
which already exists!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored
==> ERROR: A failure occurred in prepare().
    Aborting...

Then I just delete the /tmp/makepkg/linux-custom/ folder where everything gets build and rerun makepkg, but that's not how it's supposed to be, right? Does it have to do with how I apply my patches? Here is my PKGBUILD (what I changed in the default):

[...]
source=("https://www.kernel.org/pub/linux/kernel/v3.x/${_srcname}.tar.xz"
        "https://www.kernel.org/pub/linux/kernel/v3.x/patch-${pkgver}.xz"
	# bfq patches
	"http://algo.ing.unimo.it/people/paolo/disk_sched/patches/3.16.0-v7r5/0001-block-cgroups-kconfig-build-bits-for-BFQ-v7r5-3.16.patch"
	"http://algo.ing.unimo.it/people/paolo/disk_sched/patches/3.16.0-v7r5/0002-block-introduce-the-BFQ-v7r5-I-O-sched-for-3.16.patch"
	"http://algo.ing.unimo.it/people/paolo/disk_sched/patches/3.16.0-v7r5/0003-block-bfq-add-Early-Queue-Merge-EQM-to-BFQ-v7r5-for-3.16.0.patch"
	# ck patch
	"http://ck.kolivas.org/patches/3.0/3.16/3.16-ck2/patch-3.16-ck2.bz2"
	# UKSM patch
	"http://kerneldedup.org/download/uksm/0.1.2.3/uksm-0.1.2.3-for-v3.16.ge.1.patch"
	# GCC patch
	"https://github.com/graysky2/kernel_gcc_patch/blob/master/enable_additional_cpu_optimizations_for_gcc_v4.9%2B_kernel_v3.15%2B.patch"
        # the main kernel config file
        'config.x86_64'
        # standard config file for mkinitcpio ramdisk
        'linux.preset'
        'change-default-console-loglevel.patch'
        )
[...]
prepare() {
[...]
  patch -p1 -i "${srcdir}/0001-block-cgroups-kconfig-build-bits-for-BFQ-v7r5-3.16.patch"
  patch -p1 -i "${srcdir}/0002-block-introduce-the-BFQ-v7r5-I-O-sched-for-3.16.patch"
  patch -p1 -i "${srcdir}/0003-block-bfq-add-Early-Queue-Merge-EQM-to-BFQ-v7r5-for-3.16.0.patch"
  patch -p1 -i "${srcdir}/uksm-0.1.2.3-for-v3.16.ge.1.patch"
  patch -p1 -i "${srcdir}/enable_additional_cpu_optimizations_for_gcc_v4.9%2B_kernel_v3.15%2B.patch"
  bzcat "${srcdir}/patch-3.16-ck2.bz2" | patch -p1
[...]

stevenhoneyman · 2014-09-11 17:16:36

Ah, then this is a makepkg issue. Are you incrementing the release number each time? (you should be afaik)

I don't use makepkg for the kernel... to much automation and things to go wrong. I'd suggest build it normally something like: make menuconfig; make bzimage modules; make modules_install; cp arch/x86/boot/bzImage /boot/my-custom-linux-kernel; vim /boot/grub/grub.cfg; reboot
It means you wont need to keep rebuilding the bits that havent changed, and the patches only need applying once per kernel version

klenamenis · 2014-09-11 17:26:47

Increasing the release number makes no difference. I rather prefer the PKGBUILD way for now. Once it's working error-free, I won't build more than 3 kernels per month, I guess - so makepkg in conjuction with pacman seems a bit more comfortable to me then.

Last edited by klenamenis (2014-09-11 17:28:23)

Arch Linux

#1 2014-09-08 16:59:00

Building first custom kernel

#2 2014-09-08 17:13:27

Re: Building first custom kernel

#3 2014-09-08 18:28:28

Re: Building first custom kernel

#4 2014-09-08 18:57:05

Re: Building first custom kernel

#5 2014-09-08 19:01:10

Re: Building first custom kernel

#6 2014-09-09 10:26:03

Re: Building first custom kernel

#7 2014-09-09 15:28:30

Re: Building first custom kernel

#8 2014-09-09 16:36:10

Re: Building first custom kernel

#9 2014-09-09 16:44:32

Re: Building first custom kernel

#10 2014-09-10 01:42:06

Re: Building first custom kernel

#11 2014-09-10 02:36:05

Re: Building first custom kernel

#12 2014-09-10 08:40:25

Re: Building first custom kernel

#13 2014-09-10 17:12:35

Re: Building first custom kernel

#14 2014-09-10 17:41:58

Re: Building first custom kernel

#15 2014-09-10 17:53:56

Re: Building first custom kernel

#16 2014-09-10 18:12:42

Re: Building first custom kernel

#17 2014-09-10 18:58:31

Re: Building first custom kernel

#18 2014-09-10 19:46:00

Re: Building first custom kernel

#19 2014-09-10 20:16:02

Re: Building first custom kernel

#20 2014-09-10 20:28:57

Re: Building first custom kernel

#21 2014-09-10 20:30:36

Re: Building first custom kernel

#22 2014-09-11 00:10:14

Re: Building first custom kernel

#23 2014-09-11 17:08:55

Re: Building first custom kernel

#24 2014-09-11 17:16:36

Re: Building first custom kernel

#25 2014-09-11 17:26:47

Re: Building first custom kernel

Board footer