An OpenBSD Kernel "Roughing-In" Tool

This approach is not supported by OpenBSD. Even though it's the way I've been doing things for 10 years they claim it won't work. If it doesn't work for you, don't post questions to misc@openbsd.org about it because they don't want to hear about it. Back up your original /bsd to /GENERIC as mentioned below and know how to use it. The worst problem I've had is that a device isn't recognized because I left it out. If that happens, put it back in, make and install a new kernel. Know how to boot from /GENERIC, and make sure you have a /GENERIC.

I've been using OpenBSD since about 2002, and I've built many custom kernels over the years. Mostly they've been to have a smaller kernel by leaving out devices, in the hope that might also be a tiny bit faster. The most successful ones I've made have been done by looking at each device in the kernel config file and trying to find it in dmesg output. (That doesn't always work anymore.) I've done that both "live" with grep, and sent it to a text file which I searched with a text editor. Either way, it takes a couple of hours to do it right. I always thought it should be possible to write a program to do that, so I finally did.

Isn't leaving out devices a bad idea? Only if you do it haphazardly. I'll never plug PCMCIA cards into my desktop, or use SCSI cards in my laptop. I always, on every new installation, cd to / and cp bsd to GENERIC then I know I have a way around any bad ideas I might have later. You could also copy one back in from an installation disk or download one, but I've never had to go that route. My kernels are usually about 1/2 the size of the full generic ones.

This is not a "wizard" for those who don't know how to troubleshoot a broken kernel config. It's a timesaving tool for those who accept that it probably won't make a perfect kernel. If you've made kernels before and had to fix them you might find this useful. If the kernel won't compile or some device doesn't work you're on your own. In my experience if it compiles and everything works you're probably not in for any surprises later. Plug in one of everything and try it: be sure you can mount a CD, a USB stick, that you can ifconfig any PCMCIA network cards, that SANE finds your scanner, etc. If you had edited the config by hand you'd have to do this anyway. Hint: you seem to need a scsibus at almost every pseudo-scsi device and they're not all in dmesg.

And if I haven't mentioned it enough, do a "cp /bsd /GENERIC" and hopefully that really is generic, or copy one from an install CD. When you "make install" a new kernel it copies your present kernel to /obsd. If your last attempt wasn't so good either you've got a backup with something wrong with it. Stick a known-good generic kernel at /GENERIC and it won't get overwritten. It'll come in handy if you add hardware too, just boot from it at the boot prompt. You can tell a kernel GENERIC from a config file GENERIC by the size (and where it is).

To start, plug in any removable (PCMCIA, USB, etc.) devices you want included. You can uncomment them later if you'd rather and know what to uncomment. Then reboot to a generic kernel if you're not already running one.

This process needs a dmesg output from a generic kernel, because that has almost every device driver known to OpenBSD included, so it will detect the devices you have plugged in. You can save it to a text file by doing "dmesg > somefile.txt" and use that, or the program will try to detect if you're running a generic kernel and offer to get a dmesg listing via a pipe. If you do the dmesg from something other than a generic kernel it'll have stuff left out.

This was written on an i386 machine because that's all I've got and all I've had any experience with. I did take a peek in /usr/src/sys/arch at the others, and a lot of them look similar, so I do a uname -m and use that string in the path to where to find the GENERIC config file. In some cases that guess will be wrong. Some don't have a conf/GENERIC at all.

I've also found from experience that there are a few (8 at present) devices in the kernel config that have to be included even though they don't show up in a dmesg output. Those may be different on non-i386 platforms.

Make sure you've got a PHY for each netowrk card. My xl0 was being very slow and showing up in ifconfig as not finding any media. I plugged in a second one and that had the same problems. Checked against a GENERIC kernel which was normal, the problem was that I needed a phy.

That being said, the program also needs a copy of a GENERIC kernel config file. On i386 that's at /usr/src/sys/arch/i386/conf/GENERIC. This file is opened and copied line by line. No changes are made to it. Oh, you will need to have at least the sys.tar.gz file extracted into the right place, that holds true for building a kernel by any method. The GENERIC kernel config should be unmodified. Extract a fresh copy if you've tampered with it.

OK, so download a copy of kr.tar.gz (3.5 k), extract it somwhere, do a make, and run it. I don't think it has any dependancies, it's just plain C. I won't claim it to be elegant.

Let it output into /usr/src/sys/arch/i386/conf/ if you want, then cd there and look it over. It comments out lines with "#kr " so it's easy to see what it did.

Running on my laptop, with OpenBSD 4.7 went like this:

c610# ./kr This seems to be a GENERIC kernel you're running. Use a dmesg from it (y/n)?y Taking your word for it. Accepted. 94 lines read from dmesg Use /usr/src/sys/arch/i386/conf/GENERIC as source (y/n)? y 853 lines read from GENERIC config. Name of output kernel source: c610kr1 Create output in /usr/src/sys/arch/i386/conf/? (y/n) y 62 devices found in dmesg c610#
Then later after building, installing, and rebooting uname -a shows:
OpenBSD c610.my.domain 4.7 c610kr1#0 i386

Do a config YOURNAME, and if that runs without errors, cd to ../compile/YOURNAME and make depend, then make. If that works do a make install and reboot to test it.

I wrote this on my desktop machine under OpenBSD 5.0 and when I got it working copied to my laptop with OpenBSD 4.7. It works under both. I initially thought if I could get down to a few lines that needed to be edited by hand I'd be doing well. You may need to change what's in the "always" struct of devices that should be included even though they don't show up in dmesg. If you add one, increase alwaystop.

This isn't black magic and it isn't rocket science, it's just manipulating text. This isn't doing anything to your system directly, it just helps in building a kernel. It might be a good time to put a known good copy of a generic kernel on your hard drive as /GENERIC and read the boot manpage before you "make install" your new kernel. You can always boot /obsd if you don't heed this warning, but that may not be much better.

Why is it called "Roughing In"? It's a term I've heard electricians use for the early stages of wiring a house before the sheetrock's on. They run the wires, mount the outlet and switch boxes, then they come back after the sheetrock's on to connect everything and put the faceplates on.

This works under OpenBSD 5.0 and 4.7 as of 4/14/2012. I'm not likely to maintain it, mostly because I'm on a modem and don't plan to upgrade at least as long as my hard drive is still under warranty. Downloading and installing 5.0 has taken me about 2 1/2 months by modem and I'm still not done.

AB1JX / calcs