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.
_________________
"Defeat is a state of mind. No one is ever defeated, until defeat has been accepted as a reality." -- Bruce Lee

[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
_________________
Please stand by - The mailer daemon is busy burning your messages in hell...

[notageek]

[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.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[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.
_________________
"Defeat is a state of mind. No one is ever defeated, until defeat has been accepted as a reality." -- Bruce Lee

[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...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[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.
_________________
"Defeat is a state of mind. No one is ever defeated, until defeat has been accepted as a reality." -- Bruce Lee

[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.
_________________
Vanitas vanitatum et omnia vanitas.
Libera temet ex inferis.

[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...)
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?