# Is there a tool to validate kernel config

## notageek

Sure, if it boots, it is... err... validated but I was wondering something like 'make config_check' kind of thing that would check for 1)kernel config 2)and if it meets gentoo specific requirements (or at the very least, profile requirements). 

Thanks.

----------

## eccerr0r

Not sure what you mean by #1 (unless you want a tool to crosscheck the .config with hardware on that machine?)  but #2 is very dependent on what applications/utilities you have emerged and not dependent on the profile.  And it changes.  And it's not always clear (I think the mdadm package does not require CONFIG_MD, go figure.  One can argue that the system is as equally dead as udev missing CONFIG_DEVTMPFS, except it wouldn't affect as many people as not everyone has MDRAIDs). 

I suppose it would be interesting to have a tool go through every single ebuild installed and extract every needed kernel config option.  Then again there's a difference between needed and suggested, and some may be a tradeoff for security.

----------

## Dippmopser

Such a tool would be a great thing especially for newbies to kernel config.

Something that scans your hardware indicating what options are a must to get a running system an what options are well optional, would save a lot try an error.

----------

## ToeiRei

debian hcl is an online tool which takes 'lspci -n' and offers kernel modules which do support that hardware stuff read from lspci... maybe that helps a little

----------

## notageek

 *eccerr0r wrote:*   

> Not sure what you mean by #1 (unless you want a tool to crosscheck the .config with hardware on that machine?)  but #2 is very dependent on what applications/utilities you have emerged and not dependent on the profile.  And it changes.  And it's not always clear (I think the mdadm package does not require CONFIG_MD, go figure.  One can argue that the system is as equally dead as udev missing CONFIG_DEVTMPFS, except it wouldn't affect as many people as not everyone has MDRAIDs). 
> 
> I suppose it would be interesting to have a tool go through every single ebuild installed and extract every needed kernel config option.  Then again there's a difference between needed and suggested, and some may be a tradeoff for security.

 I don't recall a list of things that I'd like to check but yes, something like CONFIG_DEVTMPFS for instance, is strictly not needed for a kernel to boot but with portage scripts requiring it the tool could check for this (among others).

As far as checking hardware and making sure the kernel config contains it, is... well we could (and probably already have) use something that could scan lspci and suggest a kernel config. "make lspci_config" for example. Do-able. But that's not what I meant with this thread. 

I meant a tool that would check most dependencies are met and that could potentially guess if a kernel would be bootable.

----------

## eccerr0r

The kernel itself (makefile/config) will determine whether out dependencies are good, so I suspect that's not the problem.

So is the worry about these kinds of things?

CONFIG_DEVTMPFS not set - killing udev (but machine "boots")

CONFIG_MD not set - if you have a RAID and you get an unbootable system (autodetect) or boots only initrd

CONFIG_EXT3FS, etc. - unbootable machine if you forget (you have to explicitly tell which ones you want)

CONFIG_BLK_DEV_SD - missing SCSI disk layer - cannot boot unless you're using legacy ATA or CDROM as root

CONFIG_SYSVIPC - system 5 IPC - a lot of things will likely break but not everything...

COFNIG_MSDOS_PARTITION - partition table for most PC machines.

A lot of these are dependent on what you're doing with the machine and a simple script may or may not be able to figure out that you actually need them.  The filesystems one is especially iffy.  I bring these up because each of these would basically make my server dead on boot even if I have the correct disk drivers, etc.  but not all machines need these!

I suppose things like genkernel and the kernel seeds (is Pappy still maintaining? haven't seen him for a while) should help against most of these.

I suppose "sh*t happens" - was this concern more for preventing remote kernel upgrades from killing the box?  I completely dread this and never will attempt this - too risky for standard PCs.

----------

## notageek

Not just that but any feature you add, you'd want to know if it'll work. 

I'll give you one example, I had compiled into kernel one of my ethernet drivers (r8169) and left the other one (via-rhine) as loadable kernel module. This worked fine but I had not set CONFIG_DEVTMPFS so udev was not working (which wasn't a big problem since the drivers loaded fine and was working). But when I turned on CONFIG_DEVTMPFS for an ethernet driver unrelated reason, my ethernet drivers wouldn't load. At-least the one in the kernel was expected to work but it didn't. 

So, I had to move my ethernet driver out of kernel and recompile as a loadable module to get udev to detect my ethernet cards properly. 

I know at this point you're probably about to say "drivers always go into modules" but that's not the point. I'd like some drivers to be in the kernel, I tried ethernet but that didn't work but I'd like SCSI/SATA/PATA drivers to be in kernel, along with one of the filesystems. 

What if in the future udev started managing filesystems? Strike that. Why isn't having SCSI/SATA/PATA drivers in the kernel causing udev/CONFIG_DEVTMPFS to misbehave? Why does it affect only ethernet? The answer is probably it does not only affect the ethernet, it does affect others. Something I'm probably not aware of right now. (I see a lot of USB hub/device message in dmesg, not sure why they pop up every few minutes). 

All of these are unknown, so having something that validated if presence of one config affects the other or somesuch.

----------

## eccerr0r

Actually I'd call that a udev bug not "all drivers need to be modules" :)

I still haven't fully figured out how udev works with the "Predictable device names" deal.  Did you check other possible names for the other Ethernet devices?

Also it is possible to put your SCSI/SATA/IDE/FS drivers as modules too :)  Granted, initramfs will then be needed.

And this is sort of confusing, the machine will still "boot" if your Ethernet is wrong (but kicked off the net - this is the same remote network access case *shiver*) ... That's why it's a bit confusing as to what the exact nature of the issue is...

----------

## notageek

Oh, I don't have an issue. My issues were resolved. My ethernet works. My kernel boots. My gnome merges. etc. 

I was just wondering if 'make config_validate' or 'make config_check' exists.

----------

## jimmij

Just updated consolekit and at the end of process I discovered that it require CONFIG_AUDITSYSCALL which was not set.

Another example of post-emerge discovery was (some time ago) cups, which required CONFIG_USB_PRINTER=n.

So yes, it would be great to have a tool which checks if all packages in world have proper kernel config.

----------

## eccerr0r

The problem is that you won't know what packages you have installed until they are installed...  And then you'll know the kernel dependencies.

At least CONF_AUDITSYSCALL and CONFIG_USB_PRINTER are not fatal, there is a chance of fixing them after you reboot.  Not sure of the best way of helping prevent the critical ones though, plus they change...

Almost seems there needs to be a decision diagram:

0. Are you planning on using modules for boot-needed drivers? (This is a USER chosen option, and hard for a computer to tell via a script).  And it also depends on if your linuxrc will actually load the modules!

If yes, ensure CONFIG_INITRAMFS is enabled

1. Are you using MD?  What raid levels are you using?  Make sure CONFIG_DM is also checked.

2. Are you planning on using udev or systemd instead of static-devs? make sure CONFIG_DEVTMPFS is enabled.

3. Are you using root-on-nfs? How can the script tell?  Make sure nfs is checked as well as kernel boot time config...  Also make sure your network drivers are checked.

4. Ensure your root disk hardware are enabled in config.  This is a bit easier to check for as the data is in pci tables.

5. Ensure your root filesystem is enabled in config.

6. Ensure network hardware and console is enabled.  Imagine disabling console for a remote install and disabling network driver for a local install.  Yes I have these crossed for a deadly case...

...

this list isn't even complete..  can't think of a version agnostic method of checking everything.  Devtmpfs was relatively recent dependency, not to mention the mess that the initramfs does.

(In my opnion everyone should have CONFIG_INITRAMFS checked.  This is a really useful feature IMHO despite it can be a pain to set an initramfs image up.  And for embedded systems it'd be a waste of ram most of the time...)

----------

