Custom kernel best practices (built-in vs. modules, encryption...)

jwhendy · 2011-03-16 20:02:59

I just built a custom kernel to get rid of a lot of crap I don't need in the default one. I have some questions about things I noticed in the process...

---( intel i915 mode setting )---
From the WIKI I know that mode setting is mandatory now. I've been doing fine by having intel_agp and i915 added to the modules line of mkinitcpio.conf. Now that I built a kernel, I though I'd just build both of those in... but the standard switch to proper resolution never happened during boot. If I build them as modules, it does.

What's the best practice here? Is the switch not happening because modules can be built into the initramfs and the boot text is happening before the kernel is loaded?

---( wireless support )---
Similarly, with wireless, if I build in support for Intel 4965... I get an error at boot about not being able to find the firmware, but it's actually there. Built as a module, no such issue.

---( encryption )---
When I boot, I used to get a nice brief text, black screen, then switch to native resolution, and then this prompt:

Enter passphrase to mount /dev/sda2:

Or something to that effect (anyone with encryption knows that I'm talking about). Now that gets overrun with several notes about discovering USB devices so it looks something like this:

Enter passphrase to mount /dev/sda2: New USB device found on 4-1: fingerprint reader
USB 4-1 registered by kernel26 uhci_0
Something else about USB

At first I thought my custom kernel failed to read the drive and was waiting for it to tell me it was panicking and needed to reboot. It appeared hung so I pressed enter and it gave me the message about not finding a disk with that passphrase. That's when I realized it was really still waiting for my password. I can enter it... I just wonder why the prompt is being overrun by USB messages.

Lastly, can I remove the 'encrypt' hook from mkinitcpio.conf if I have dm_crypt built into the kernel? Same with crc32c? I get errors when running mkinitcpio with the new kernel that these two modules aren't found, but things boot... so they are successfully built in. Just wondering.

Thanks!

Stebalien · 2011-03-16 21:46:11

1. Did you enable kms in your kernel config? (CONFIG_DRM_I915_KMS=y)
2. Never build wireless/wired modules into the kernel. If you use fuse, don't build that into your kernel either.
3. No idea
4. No, AFIAK it does more than just load the module (see /lib/initcpio/hooks/encrypt).

Also, you should take a look at http://kernel-seeds.org/.

jwhendy · 2011-03-16 23:33:48

@stebalien:
1. yes (edit: sorry... I did have it built in, but don't anymore because the boot process stayed at huge text (~800x600) rather than actually switch to native res so I built it as a module and now it's fine)
2. sounds good -- any particular reason?
3. k
4. good to know. I wonder why it complains about not finding dm-crypt. Oh well, it performs just fine.

Re. kernel-seeds. I'll have a look. I'm pretty familiar with building my own kernels and the options for my hardware, but I'd be interested in reading why they make a "seed" the way they do. Thanks for the reference.

Last edited by jwhendy (2011-03-16 23:35:12)

bigman2126 · 2011-03-18 06:12:36

Stebalien wrote:

2. Never build wireless/wired modules into the kernel. If you use fuse, don't build that into your kernel either.

I would like to know the reason too, I tend to build my custom kernels so that the hardware and things I use are compiled into the kernel.

bangkok_manouel · 2011-03-18 07:31:20

because the firmware is loaded later so the module is not properly initialized (or some word that sounds like this)

ngoonee · 2011-03-18 07:33:59

I've read before that with current hardware the performance difference between built-in and module is so small as to be non-perceptible. Make of that what you will.

kernel-seeds is currently down from here, but from the google cache description it does seem like a time-saver.

bangkok_manouel · 2011-03-18 07:44:08

i've seen some really random decisions on kernel seeds (especially on the network side). better use the default config and read Help. there should not be so much difference in terms of speed but if you like to test many different kernels (-mm -db -ck -pf -git -next -mainline, etc...) then it's better to build them in 2 minutes then 30...

/edit: typo

Last edited by bangkok_manouel (2011-03-18 07:45:13)

redden0t8 · 2011-03-18 13:28:30

bigman2126 wrote:

Stebalien wrote:
2. Never build wireless/wired modules into the kernel. If you use fuse, don't build that into your kernel either.
I would like to know the reason too, I tend to build my custom kernels so that the hardware and things I use are compiled into the kernel.

bangkok_manouel wrote:

because the firmware is loaded later so the module is not properly initialized (or some word that sounds like this)

That *has* to depend on the specific wifi driver because I have iwlwifi-1000 built into my kernel as we speak and it loads the firmware fine.

As far as i915 and modesetting goes, I had the exact same issues. It turned out in my case another driver was stealing control before the intel kms one could grab it (maybe FB_VESA?). Anyways, here's the relevant part of my kernel config that does work with i915 kms built-in:
http://pastebin.com/jaCAqPjh

jwhendy · 2011-03-18 15:27:44

@bangkok: thanks for the explanation re. firmware.

@ngoonee: I'll have to check that out later. I really, really, really got into building kernels for my Macbook when I was running Zenwalk. I went through every option and tried to find out about it. I was pretty sure I had everything stripped out, though having just started playing with custom kernels on Arch again, I'm not sure about some of the network options. That's where kernel-seeds might come in handy. I'm reasonably confident about all my driver, filesystem, etc. choices... but just the other day stumbled on a whole submenu about network protocols and had no idea. I use vpnc to vpn into my company's network and wasn't sure what I needed for that. I have never use iptables... but have heard them enough that I figured I should make them available. Stuff like that is where I don't have much knowledge.

A lot of the rest comes down to researching your hardware, I think.

@all: my i915 issue was one of overlooking to also build in the issue of making kernel modesetting the default as well (option is right underneath making i915 the default driver)

Arch Linux

#1 2011-03-16 20:02:59

Custom kernel best practices (built-in vs. modules, encryption...)

#2 2011-03-16 21:46:11

Re: Custom kernel best practices (built-in vs. modules, encryption...)

#3 2011-03-16 23:33:48

Re: Custom kernel best practices (built-in vs. modules, encryption...)

#4 2011-03-18 06:12:36

Re: Custom kernel best practices (built-in vs. modules, encryption...)

#5 2011-03-18 07:31:20

Re: Custom kernel best practices (built-in vs. modules, encryption...)

#6 2011-03-18 07:33:59

Re: Custom kernel best practices (built-in vs. modules, encryption...)

#7 2011-03-18 07:44:08

Re: Custom kernel best practices (built-in vs. modules, encryption...)

#8 2011-03-18 13:28:30

Re: Custom kernel best practices (built-in vs. modules, encryption...)

#9 2011-03-18 15:27:44

Re: Custom kernel best practices (built-in vs. modules, encryption...)

Board footer