Getting lost in kernel compilations

anadyr · 2006-12-09 02:06:26

Hey people,

I have been using slackware a long time ago, but since I switched to Arch (about three, four years ago) I always compiled my own kernels. But now this seems to become harder and harder, and I just do not understand the stuff anymore,

What I used to do was
1) make bzImage, make modules, make modules_install
2) copy bzImage to /boot/vmlinuz2xxx
3) change lilo.conf

I did this for about three years, and everything always went fine. But the last few months, when I want to build a new kernel, I hardly succeeded. I have a few particular questions, because it drives me crazy sometimes, not being able to boot after a new kernel. This happens too many times the last few months, whereas it never was a problem in the past.

1) What are the other files in the /boot folder (such as system.map26), and do I have to change any of those if I compile a new kernel
2) what is initrd.img and initrd-full.img and do I need to mess with them with a new compiled kernel?
3) related: what does mkinitrd and mkinitcpio do, and do I have to do anything with it in a custom built kernel?

Anyways, I want to keep building my own kernels, since I can make the startup a lot faster that way. And I also want to keep using "my old way" of compiling kernels,albeit with one or two extra steps. But I do not want to use ABS.
Could someone please explain to me once and for all the above three questions?

A fourth question could be btw: why on earth are the udev upgrades are incompatible with old kernels?

F · 2006-12-09 04:26:39

short answer:

# pacman -S kernel26;

long answer:

# make mrproper; make xconfig; make dep; make clean; make bzImage;
# make modules; make modules_install;
# cp bzImage /boot/bzImage-KERNEL_VERSION;
# cp System.map /boot/System.map-KERNEL_VERSION
# ln -s /boot/System.map-KERNEL_VERSION /boot/System.map

I think thats about it. Then configure your bootloader.

noriko · 2006-12-09 08:35:28

if u provide some error logsor something, it can be help...
the initrd*.img is the ranfs, used by the kernel to load extra modules not kompiled into the kernel..they are generated using mkinitrd;

we've switched to mkinitcpio a while ago;
it's more or less the same as mkinitrd, phrakure posted why the name changed somewhere on the forums.. basically u'd now use mkinitcpio to generate the ramfs.. which in the repo/kernels are named kernel*.img ..

why do u compile the kernel?
i've done this many times but there apears to be no benfits from a speed pov..

repo/kernels give be approx 20 seconds boot time .. most apps starts within 1 second.
even firefox, although i compile for size , -Os rather than do anyti-O3, since i don't do anything needing that/....

anadyr · 2006-12-09 09:52:37

hmm, and is it necessary to have a ramfs, and an entry initrd in your bootloader? Or can I just build a kernel/modules and remove the initrd entry?

Unfortunately I do not have errorlogs. Only descriptions:

kernel panic: /bin/sh: cant access tty, job control turned off
kernel panic: Spurious ACK on isa0060/serio0
filesystem check failed (first due to udev)
filesystem check failed (second due to localtime/UTC bug)

and some other things as well...

noriko · 2006-12-09 10:26:44

if u compile everythign into the kernel image, then there is no need for the initramfs.. and therefore no need for the initrd line..
however, in that case i think u'd need to tell the kernel not to try loadign one..
add `noinitrd` to the kernel line(i think taht's what it is...)

i've tried doing this many times, i've never managerd to compile everything into it.. don't ask y... that idea just doesn't like me lol..
if u try (in my experience) if u try loading the kernel without the initrd when it needs it.. ur gonna get cryptic errors.

phrakture · 2006-12-10 10:01:33

And now you see the reason why many of us will highly recommend using the stock kernels over one you compile yourself. There is very little detrimental effects from using the stock kernels. Compiling everything in will gain you... what? a 1 second speedup?
If you want to do it "the arch way", I suggest you check the wiki.

anadyr · 2006-12-10 10:20:33

hmm I suppose. If I use the stock kernel (as I do now), I have the feeling that I do not control or understand what is happening. For instance, lsmod gives a zillion modules now, whereas I always created a few. Second thing is that /boot/vmlinuz26 was not replaced when I pacmanned to a new kernel. But it has indeed been updated... I find this very strange indeed.

vacant · 2006-12-10 10:33:06

anadyr wrote:

Anyways, I want to keep building my own kernels, since I can make the startup a lot faster that way.

That's what I call the "gentoo" mentality Ever subtracted the "saved startup times" (seconds) from the time spent tweaking, compiling and trouble-shooting your own kernel (hours) ?

I've used many distros and settled on slackware for some years before Arch. The three noticeably quickest distos in real life on my PC were Gentoo, Arch and Yoper - the latter two ready-compiled binaries for i686, Gentoo I compiled myself.

To get your startup time down:

(a) work out which modules your kernel needs to boot - you can improve on /etc/mkinitcpio.conf, here's mine (can't quite remember why I needed edd):

MODULES="ide-core ide-disk generic edd via82cxxx reiserfs"
BINARIES=""
FILES=""
HOOKS="base udev"

(b) Don't start unneeded services and after the network daemon, "background" some daemons in /etc/rc.conf e.g.

@fam @cups @ntpd @samba @alsa @squid @crond

phrakture · 2006-12-10 21:48:22

anadyr wrote:

hmm I suppose. If I use the stock kernel (as I do now), I have the feeling that I do not control or understand what is happening. For instance, lsmod gives a zillion modules now, whereas I always created a few. Second thing is that /boot/vmlinuz26 was not replaced when I pacmanned to a new kernel. But it has indeed been updated... I find this very strange indeed.

Why do I have to go over this time and time again? You know if you build things into the kernel, it's 99% identical to loading the module, right? So everything listed in 'lsmod' IS actually there, it just doesn't show in lsmod. If you didn't have the 'lsmod' command, would you feel better?

Secondly, as to the vmlinuz26 not being replaced... are you sure /boot was mounted when you upgraded?

Arch Linux

#1 2006-12-09 02:06:26

Getting lost in kernel compilations

#2 2006-12-09 04:26:39

Re: Getting lost in kernel compilations

#3 2006-12-09 08:35:28

Re: Getting lost in kernel compilations

#4 2006-12-09 09:52:37

Re: Getting lost in kernel compilations

#5 2006-12-09 10:26:44

Re: Getting lost in kernel compilations

#6 2006-12-10 10:01:33

Re: Getting lost in kernel compilations

#7 2006-12-10 10:20:33

Re: Getting lost in kernel compilations

#8 2006-12-10 10:33:06

Re: Getting lost in kernel compilations

#9 2006-12-10 21:48:22

Re: Getting lost in kernel compilations

Board footer