Hello all,
I just finished going through the installation handbook and got Gentoo to boot. This post was originally supposed to be about a problem getting my Intel wifi card to work, but as I was reviewing my .config to make the post I figured out I didn't have iwlwifi set. Hopefully setting it and recompiling will do the trick. I am very much a noob and the kernel configuration process is still quite opaque to me so I wonder if anyone could provide some quick advice and answers to the following questions or point me in a good direction.
Are there better tools than lspci/lshw/lscpu/lsscsi/smartctl available for getting detailed enough hardware specs for kernel configuration?
In lshw output, do capabilities always map to a kernel option? Do lscpu output flags all map to a kernel option? If so, how does one quickly locate that option in menuconfig to enable?
How does one decide whether to make something a module or built-in?
How does one figure out whether making a feature built-in will mean that additional firmware needs to be compiled into the kernel?
What is a good method of systematically identifying and eliminating unused/unnecessary kernel features?
Besides manually figuring out how a hardware capability maps to a kernel option, is there an easier way to find out if hardware capabilities are being underutilized due to the kernel having a suboptimal configuration?
Thanks
Need general kernel configuration advice
Message
- Makersmarx
- n00b
- Posts: 58
- Joined: Sat Feb 16, 2019 12:32 am
- Location: Costa Rica
In my recent usage of Gentoo, I started with genkernel just to get my system running. Over time I learned more about how my hardware needed to be configured within the kernel and just started removing things and building my own kernel away from genkernel. The tools you listed are great and typically can get you the info you need. Once I was comfortable I ran make defconfig which deselected many of the genkernel options I was slowly removing from my own config and made it much easier for me to start from "scratch" while I tested & tailored it to my system. This was just my own trial and error approach to learning things the hard way lol, but in the long run worth it as I now have a much better understanding of how to navigate options within the kernel.
Here is a bookmark I used when I made the switch from Arch to Gentoo: https://www.linuxtopia.org/online_books ... 11s03.html I am sure this is in the wiki somewhere also, but I was not aware of all the config options when I jumped into this.
Here is a bookmark I used when I made the switch from Arch to Gentoo: https://www.linuxtopia.org/online_books ... 11s03.html I am sure this is in the wiki somewhere also, but I was not aware of all the config options when I jumped into this.
Pura Vida
- NeddySeagoon
- Administrator
- Posts: 56080
- Joined: Sat Jul 05, 2003 9:37 am
- Location: 56N 3W
There is only one way to make a really your own custom kernel. You start with make allnoconfig and then start enabling options you need. It takes very long time and you have to go thru all menus at least three times, in first few runs you even won't see all options you need, they will appear as other options they depend on get enabled. With kernel 5.x there are many options which need to be decided by you, security vs performance. In kernel 2 series there wasn't such trade-off dilemmas. There was a few in kernel 3.x and some more in kernel 4 series. There are defaults for every option, but you will see they often are not set to suit the purpose of your computer. It was believed although custom kernel is smaller it won't perform better than generic. This belief is not true any more with kernel 5 series.
We see here in forums every now and then how some users are searching for a magic wand which will configure their kernel automatically. Of course, there is none. People who dig deep into kernel secrets do not start threads here about kernel autoconfiguration, thus there is no way to tell what is the percentage of users who go thru this ordeal and run real custom kernels.
We see here in forums every now and then how some users are searching for a magic wand which will configure their kernel automatically. Of course, there is none. People who dig deep into kernel secrets do not start threads here about kernel autoconfiguration, thus there is no way to tell what is the percentage of users who go thru this ordeal and run real custom kernels.
(This may help you a bit but I do tend to rely on experience to tell me whether I need a particular feature or not so it's a bit hand-wavey.)
I'd suggest getting a working kernel first with Genkernel (I can't tell you how, though, as I've never used it) so that you can at least boot your system then having a go at configuring one yourself. If your kernel fails to boot, you can just choose the Genkernel one from the boot menu and have another go (if your kernel panics, its "dying words" are often a useful clue as to why).
When I'm configuring a kernel for a system for which I've not used built one before, I often start by reading the output of 'dmesg' from the installation media. That gives me a good "feel" for the overall system.
One thing to bear in mind is that the Gentoo minimal install ISO (at least as of the last time I used it) tends to load a metric shedload of unnecessary drivers - every SCSI and ATA controller and NIC under the sun, no matter how obscure, a bit like the old Windows NT installer - and some of them can be very verbose even if the hardware isn't present. (I've actually got a USB stick with a custom "runs on almost anything" Gentoo installation which has all the drivers I think I'm reasonably likely to encounter configured as modules and auto-loads the required ones via eudev hotplugging, which makes things much easier. I use this as my installation media these days, in addition to using it for diagnostics and suchlike.)
Having got an idea of what has been detected that way, 'lspci -v' is my next port of call for a list of PCI(e) devices; it will also tell you what driver is associated with each device if a driver has been loaded for it.
For onboard sensors, 'sensors-detect' will usually tell you the right drivers to use. You'll need the "/dev/port character device" (CONFIG_DEVPORT) and the "I2C device interface" (CONFIG_I2C_CHARDEV) for it to work fully.
Choosing the right audio codec driver is a little harder as most modern ones use 'snd-hda-intel' as their basic driver which will be shown by lspci but require an additional driver to actually do anything. If you happen to know that your board comes with, say, a Realtek codec (very common) then select that otherwise there's no harm in selecting them all as modules and seeing which ones get autoloaded. Your graphics card will need the HDMI audio codec driver to provide support for sound over the HDMI cable if you want that.
As for what to make a module and what to build in - I tend to build as little in as possible but that's a personal preference dating back to when I was running systems with so little memory that just unloading the floppy driver or whatever when I wasn't using it made a real difference (on-demand loading and automatic unloading of idle drivers were common then). It can still sometimes be handy to be able to unload and reload a driver, say if the hardware starts behaving oddly. At the other end of the spectrum, some people like to have everything built-in (some even disable module support altogether, if they don't need it for out-of-tree drivers like nvidia or virtualbox).
I'd suggest building in (rather than having as modules) at least the following:
I tend to start with the default config then turn off stuff I don't want and add extra things where needed in menuconfig. It's a little less laborious than starting with nothing at all configured (allnoconfig). There are a few places where you have to go back and revisit a part of the menus after going through everything once because stuff will sometimes deselect (or modularise) itself (or become available - or possible to deselect - as a result of later selections). The ones that spring to mind immediately are PCI MSI support (won't stop your system working but may hurt performance) and the SCSI subsystem and SCSI disk drivers.
I'd also suggest building in the microcode for your CPU. If you're on AMD then sys-kernel/linux-firmware includes the relevant files; for Intel, you can use sys-firmware/intel-microcode. Deciding which one to build in is fairly straightforward on AMD - just use the one relating to the processor family you have, eg. "amd-ucode/microcode_amd_fam15h.bin" for a Family 15h (FX-series) CPU. (The unadorned "amd-ucode/microcode_amd.bin" is for Family 10h.) On Intel, you need to look at the "cpu family", "model" and "stepping" values in /proc/cpuinfo; the hexadecimal equivalents will give you the filename, eg. family 6 model 15 stepping 11 corresponds with "intel-ucode/06-0f-0b".
Firmware relating to drivers configured as modules will be loaded as required from /lib/firmware. 'lshw' gives hints as to what firmware is used by different devices but the name it lists doesn't necessarily match the filename exactly (for example, lshw says "firmware=rtl8168f-1_0.0.5" for my NIC but the filename is actually "rtl_nic/rtl8168f-1.fw" if I wanted to build it into the kernel). The kernel will complain in dmesg (and tell you the file it wants) if firmware is missing. For most things, sys-kernel/linux-firmware will include the necessary files. Some hardware, especially wireless adaptors, may need other packages, though.
There's probably other stuff too but it's getting kind of late and my brain is trying to shut down for the night.
Good luck!
I'd suggest getting a working kernel first with Genkernel (I can't tell you how, though, as I've never used it) so that you can at least boot your system then having a go at configuring one yourself. If your kernel fails to boot, you can just choose the Genkernel one from the boot menu and have another go (if your kernel panics, its "dying words" are often a useful clue as to why).
When I'm configuring a kernel for a system for which I've not used built one before, I often start by reading the output of 'dmesg' from the installation media. That gives me a good "feel" for the overall system.
One thing to bear in mind is that the Gentoo minimal install ISO (at least as of the last time I used it) tends to load a metric shedload of unnecessary drivers - every SCSI and ATA controller and NIC under the sun, no matter how obscure, a bit like the old Windows NT installer - and some of them can be very verbose even if the hardware isn't present. (I've actually got a USB stick with a custom "runs on almost anything" Gentoo installation which has all the drivers I think I'm reasonably likely to encounter configured as modules and auto-loads the required ones via eudev hotplugging, which makes things much easier. I use this as my installation media these days, in addition to using it for diagnostics and suchlike.)
Having got an idea of what has been detected that way, 'lspci -v' is my next port of call for a list of PCI(e) devices; it will also tell you what driver is associated with each device if a driver has been loaded for it.
For onboard sensors, 'sensors-detect' will usually tell you the right drivers to use. You'll need the "/dev/port character device" (CONFIG_DEVPORT) and the "I2C device interface" (CONFIG_I2C_CHARDEV) for it to work fully.
Choosing the right audio codec driver is a little harder as most modern ones use 'snd-hda-intel' as their basic driver which will be shown by lspci but require an additional driver to actually do anything. If you happen to know that your board comes with, say, a Realtek codec (very common) then select that otherwise there's no harm in selecting them all as modules and seeing which ones get autoloaded. Your graphics card will need the HDMI audio codec driver to provide support for sound over the HDMI cable if you want that.
As for what to make a module and what to build in - I tend to build as little in as possible but that's a personal preference dating back to when I was running systems with so little memory that just unloading the floppy driver or whatever when I wasn't using it made a real difference (on-demand loading and automatic unloading of idle drivers were common then). It can still sometimes be handy to be able to unload and reload a driver, say if the hardware starts behaving oddly. At the other end of the spectrum, some people like to have everything built-in (some even disable module support altogether, if they don't need it for out-of-tree drivers like nvidia or virtualbox).
I'd suggest building in (rather than having as modules) at least the following:
- (VITAL!) the drivers necessary to access your root device: probably either NVMe if you're fortunate enough to have that or the SCSI subsystem & SCSI disk plus the driver for your SATA controller (almost certainly AHCI unless it's a very old system) or whatever you've got your SSD/HDD plugged into.
- (VITAL!) the filesystem driver for mounting your root device
- an I/O scheduler - BFQ is a good general-purpose one for desktop systems that maintains interactivity under load well
- the ACPI Processor driver is a good idea to ensure that thermal protection works properly
- the cpufreq governor and relevant driver (almost certainly acpi_cpufreq unless it's an old system) so it can take control as early as possible (I haven't tested recently but they never used to autoload either)
- the Packet Socket networking driver - it's needed right from the start and lots of things will go screwy if it doesn't get loaded for some reason
- assuming you're using a USB keyboard, the USB subsystem and controller drivers together with the HID bus and USB HID driver so you don't end up keyboardless if modules fail to load
- if you're using ECC RAM, I'd recommend having the EDAC subsystem and memory controller driver built-in
I tend to start with the default config then turn off stuff I don't want and add extra things where needed in menuconfig. It's a little less laborious than starting with nothing at all configured (allnoconfig). There are a few places where you have to go back and revisit a part of the menus after going through everything once because stuff will sometimes deselect (or modularise) itself (or become available - or possible to deselect - as a result of later selections). The ones that spring to mind immediately are PCI MSI support (won't stop your system working but may hurt performance) and the SCSI subsystem and SCSI disk drivers.
I'd also suggest building in the microcode for your CPU. If you're on AMD then sys-kernel/linux-firmware includes the relevant files; for Intel, you can use sys-firmware/intel-microcode. Deciding which one to build in is fairly straightforward on AMD - just use the one relating to the processor family you have, eg. "amd-ucode/microcode_amd_fam15h.bin" for a Family 15h (FX-series) CPU. (The unadorned "amd-ucode/microcode_amd.bin" is for Family 10h.) On Intel, you need to look at the "cpu family", "model" and "stepping" values in /proc/cpuinfo; the hexadecimal equivalents will give you the filename, eg. family 6 model 15 stepping 11 corresponds with "intel-ucode/06-0f-0b".
Firmware relating to drivers configured as modules will be loaded as required from /lib/firmware. 'lshw' gives hints as to what firmware is used by different devices but the name it lists doesn't necessarily match the filename exactly (for example, lshw says "firmware=rtl8168f-1_0.0.5" for my NIC but the filename is actually "rtl_nic/rtl8168f-1.fw" if I wanted to build it into the kernel). The kernel will complain in dmesg (and tell you the file it wants) if firmware is missing. For most things, sys-kernel/linux-firmware will include the necessary files. Some hardware, especially wireless adaptors, may need other packages, though.
There's probably other stuff too but it's getting kind of late and my brain is trying to shut down for the night.
Good luck!
I like to build video drivers and ethernet drivers as modules. usually build NOUVEAU and RADEON modules in case I need to switch video cards. Likewise for R8169 and e1000/e1000e (Realtek and Intel ethernet drivers) for the same reason. My motherboards all have Realtek on board but I also have a PCIe and a PCI Intel ethernet card. If onboard fails, I can quickly insert a card and reboot. I put "net.ifnames=0" as part of the boot command so I don't have to deal with goofy "predictable" names that no one can remember. If you have that phrase in your boot command and you only have one NIC, it is uber-predictable. It's always eth0. If you have more than one, it's best to use a udev rule and assign names based on MAC address rather than pci slot as the "predictable" names do. If you want an example I can post a short working example. A name like ETH0 doesn't work, butt lan0, nic0 do. You might want rtl0, int0. Not sure if the letter part can more or less than three letters. all the examples I've seen use three letters and one numeral.
I've managed to avoid having an initramfs since leaving genkernel. At one point IIRC, I ran "make allmodconfig" then removed all the modules that didn't load on my system. Then I made all hardware drivers except the video and ethernet drivers built-in. YMMV.
I'd concentrate on getting a working config without an initramfs working (booting a usable system) then fine-tune it. I could post mine but even if you have the same hardware, I have all the mitigations turned off. That's dancing on a high wire. I can't advise it.
A few things I do advise:
1. CONFIG_IKCONFIG_PROC=y This will embed a copy of the kernel config into the kernel where it will be avilable as /proc/config.gz and readable with zgrep and zcat. Too many people have been confused as to which kernel they are actually running. The space taken is negligible unless you are working with a one lung embedded system. I even have it in my 32 bit k6-3 0.75 G memory system.
2. CONFIG_CMDLINE_BOOL=y The kernel team says "Systems with fully functional boot loaders (i.e. non-embedded) should leave this option set to 'N'." but don't and I put my command line options like "vga=0x365 net.ifnames=0 " in CONFIG_CMDLINE. That's probably unnecessary now that I boot with reFind. I put those in the reFind default options. You can also put them in grub command lines. I've never had luck editing grub2 configurations.
I do set CONFIG_CMDLINE_OVERRIDE=n so that the boot loader can override my defaults.
3. CONFIG_EXTRA_FIRMWARE put your video & NIC firmware in here so that you don't need that initramfs
I've managed to avoid having an initramfs since leaving genkernel. At one point IIRC, I ran "make allmodconfig" then removed all the modules that didn't load on my system. Then I made all hardware drivers except the video and ethernet drivers built-in. YMMV.
I'd concentrate on getting a working config without an initramfs working (booting a usable system) then fine-tune it. I could post mine but even if you have the same hardware, I have all the mitigations turned off. That's dancing on a high wire. I can't advise it.
A few things I do advise:
1. CONFIG_IKCONFIG_PROC=y This will embed a copy of the kernel config into the kernel where it will be avilable as /proc/config.gz and readable with zgrep and zcat. Too many people have been confused as to which kernel they are actually running. The space taken is negligible unless you are working with a one lung embedded system. I even have it in my 32 bit k6-3 0.75 G memory system.
2. CONFIG_CMDLINE_BOOL=y The kernel team says "Systems with fully functional boot loaders (i.e. non-embedded) should leave this option set to 'N'." but don't and I put my command line options like "vga=0x365 net.ifnames=0 " in CONFIG_CMDLINE. That's probably unnecessary now that I boot with reFind. I put those in the reFind default options. You can also put them in grub command lines. I've never had luck editing grub2 configurations.
I do set CONFIG_CMDLINE_OVERRIDE=n so that the boot loader can override my defaults.
3. CONFIG_EXTRA_FIRMWARE put your video & NIC firmware in here so that you don't need that initramfs
Code: Select all
MSI /usr/src/linux # zgrep CONFIG_EXTRA_FIRMWARE /proc/config.gz
CONFIG_EXTRA_FIRMWARE="v4l-cx23418-enc.fw radeon/R600_rlc.bin radeon/RS780_uvd.bin firmware_2200.fw"
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
I found I nice way to select the right codec with Intel HDA. On my system, for example:molletts wrote:Choosing the right audio codec driver is a little harder as most modern ones use 'snd-hda-intel' as their basic driver which will be shown by lspci but require an additional driver to actually do anything. If you happen to know that your board comes with, say, a Realtek codec (very common) then select that otherwise there's no harm in selecting them all as modules and seeing which ones get autoloaded. Your graphics card will need the HDMI audio codec driver to provide support for sound over the HDMI cable if you want that.
Code: Select all
$ find /proc/asound -iname "*codec*" 2> /dev/null
/proc/asound/card0/codec#2
$ grep -i codec /proc/asound/card0/codec#2
Codec: Analog Devices AD1882