Am Samstag, 27. Dezember 2008 16:48:19 schrieb Harry Putnam: > > Dirk Heinrichs <dirk.heinri...@online.de> writes: > > > > What could help you here is a "make xconfig". It's similar to "make > > menuconfig" but has a nice QT user interface. I would recommend to > > browse through it once and look at the help texts which are shown in > > the lower right pane for each option you klick. Based on this > > information, you can then decide wether or not to enable that option > > or even compile it as module. > > I have looked at that before but didn't think it was any better than > `menuconfig' and the '/' help tool.
The difference is that you see the help texts right away, which is just handy
compared to menuconfig.
> Many times the help provided doesn't really explain what a given
> setting does. In fact in most cases it does not.
Yes, you're right. There's always room for improvement. But sometimes it also
points you to some additional information, like "See
Documentation/scheduler/sched-rt-group.txt for more information.".
> What is really aggravating is that it doesn't even really tell you
> what exact thing in .config is being set with the various hundreds of
> options. I mean when you do set something, you don't really get to see
> what is being set inside of .config.
This is simply false. In xconfig, the help text has it in the title (in
parentesis, just add a "CONFIG_" prefix). In menuconfig, it's the first line
of the help text.
> I don't have X running currently so its a mute point, but is the help
> provided in xconfig and different than that available in `menuconfig'?
The text itself is the same. However, menuconfig gives a bit more details, for
example where to find it in the menu and its dependencies.
> >> Details:
> >> I'm at a point where any pared down kernel config I've built and
> >> tried has some terrible thing wrong with it. Usually involving udev
> >> and openrc someway or other... things not getting started or
> >> mounted etc etc.
> >
> > With udev, those things usually work automatically. However, you
> > must make sure that everything needed for accessing the root
> > filesystem must be compiled into the kernel. That usually includes
> > the driver for the chipset that operates your harddisks, harddisk
> > support and the filesystem used for /.
> >
> >> I'd think there would be some kind of cross reference somewhere that
> >> would connect module names to what they do, and what .config options
> >> are associated.
> >
> > I don't know of any. But in most cases, the module name is listed in
> > the help text.
> >
> >> Another path is to find the *.ko names in /lib/modules and use the
> >> absolute name to track them down in the kernel sources where there is
> >> usually a README of some sort in the tree leading to the *.ko.
> >
> > Somtimes, you can also simply guess by module name, for example:
> > joydev.ko -> Joy(stick)Dev(ice).
> >
> >> But my god what a slow and painful way to find out what these
> >> modules do.
> >
> > Yes, that's true. The browsing method may give you a rough overview
> > within an hour or two.
> >
> >> Just rmmod is another way but again a very slow and painful way.
> >> Maybe a module is used only occasionally and rmmodding may not show
> >> what it was for right away. What ever fails may not happen
> >> immediately.
> >
> > Or try modprobe + dmesg instead. Usually a driver module tells
> > wether it has found some pice of supported hardware or not.
>
> Now that is a good piece of advice there... I did notice that rmmoding
> and modprobing can give you more info than you expect if you hit
> something that the module latches onto.
>
> I'm finding somewhat rough sledding in dmesg too. I find the ethernet
> stuff with no problem and, by now, know what I need there.
>
> My hardware is pretty common stuff, not even any sata discs, all ata.
> and I'm still not sure which driver is needed there.
It all comes down to three things: Chipset driver, harddisk support and
filesystem used on /. The chipset you'll get from "lspci -v", best used from a
LiveCD. Look for "Ide interface" and "Sata controller". The rest is
CONFIG_BLK_DEV_SD and your filesystem.
> On the last attempted kernel, I just went menuconfig on a copy of the
> genkernel .config and turned off a number of things I was pretty sure
> didn't apply to me (all wireless for example) or anything but ethernet
> under the network section. All firmware turned off.
> Stuff I've never needed before.
>
> Every thing mounted but still no network was started or any of the
> stuff listed in `rc-update show'.
Some things are twofold. Network is one of those. Under "Networking support",
you define the functionalities of your network interface(s). But only under
"Device Drivers" -> "Network Device Support" you'll find the drivers for your
actual hardware. You always need both. Which driver you need you'll get again
from "lspci -v".
> I was dumped out into a root shell where I was able to modprobe and
> '/etc/init.d/bla start' my way into a fully running system.
>
> So the stuff was there but something (I suspect udev) blocked it
> starting up like it should.
You mentioned openrc in your first mail. Are you already using 0.4.x? If so,
you should mask >=0.4.0, it seems it has some problems getting the boot order
right.
HTH...
Dirk
signature.asc
Description: This is a digitally signed message part.
