Gentoo Archives: gentoo-user

From: Jerry McBride <mcbrides9@×××××××.net>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: kernel config hell
Date: Sun, 28 Dec 2008 00:39:46
Message-Id: 200812271748.02547.mcbrides9@comcast.net
In Reply to: [gentoo-user] Re: kernel config hell by Harry Putnam
1 On Saturday 27 December 2008 10:48:19 am Harry Putnam wrote:
2 > Nikos Chantziaras <realnc@×××××.de> writes:
3 >
4 >
5 > [...]
6 >
7 > >>> Well, my bit of wisdom here: Don't use modules. Do a "make
8 > >>> menuconfig", disable everything you don't need, and compile
9 > >>> everything you need in-kernel instead of as a module.
10 > >>
11 > >> I'd say the "disable everything you don't need" part is what Harry's
12 > >> mail is all about.
13 > >
14 > > Well, finding out what every installed module does isn't going to
15 > > help anyway. I'd start with only the modules currently used after a
16 > > fresh boot (lsmod). If you compile those in-kernel, it will boot.
17 > > Everything else can be tweaked later.
18 >
19 > Yeah, I talked about that in OP. But the only kernel I've got working
20 > at the moment is a genkernel and it installs 80+ modules.
21 >
22 > rmmoding my way through those is what lead to my post. Some indicate
23 > they are in use but I can see they aren't related to things I actually
24 > need. Digging that bit of info up is what I've been talking about.
25 >
26 > > Dirk Heinrichs <dirk.heinrichs@××××××.de> writes:
27 > >
28 > > What could help you here is a "make xconfig". It's similar to "make
29 > > menuconfig" but has a nice QT user interface. I would recommend to
30 > > browse through it once and look at the help texts which are shown in
31 > > the lower right pane for each option you klick. Based on this
32 > > information, you can then decide wether or not to enable that option
33 > > or even compile it as module.
34 >
35 > I have looked at that before but didn't think it was any better than
36 > `menuconfig' and the '/' help tool.
37 >
38 > Many times the help provided doesn't really explain what a given
39 > setting does. In fact in most cases it does not.
40 >
41 > What is really aggravating is that it doesn't even really tell you
42 > what exact thing in .config is being set with the various hundreds of
43 > options. I mean when you do set something, you don't really get to see
44 > what is being set inside of .config.
45 >
46 > I don't have X running currently so its a mute point, but is the help
47 > provided in xconfig and different than that available in `menuconfig'?
48 >
49 > >> Details:
50 > >> I'm at a point where any pared down kernel config I've built and
51 > >> tried has some terrible thing wrong with it. Usually involving udev
52 > >> and openrc someway or other... things not getting started or
53 > >> mounted etc etc.
54 > >
55 > > With udev, those things usually work automatically. However, you
56 > > must make sure that everything needed for accessing the root
57 > > filesystem must be compiled into the kernel. That usually includes
58 > > the driver for the chipset that operates your harddisks, harddisk
59 > > support and the filesystem used for /.
60 > >
61 > >> I'd think there would be some kind of cross reference somewhere that
62 > >> would connect module names to what they do, and what .config options
63 > >> are associated.
64 > >
65 > > I don't know of any. But in most cases, the module name is listed in
66 > > the help text.
67 > >
68 > >> Another path is to find the *.ko names in /lib/modules and use the
69 > >> absolute name to track them down in the kernel sources where there is
70 > >> usually a README of some sort in the tree leading to the *.ko.
71 > >
72 > > Somtimes, you can also simply guess by module name, for example:
73 > > joydev.ko -> Joy(stick)Dev(ice).
74 > >
75 > >> But my god what a slow and painful way to find out what these
76 > >> modules do.
77 > >
78 > > Yes, that's true. The browsing method may give you a rough overview
79 > > within an hour or two.
80 > >
81 > >> Just rmmod is another way but again a very slow and painful way.
82 > >> Maybe a module is used only occasionally and rmmodding may not show
83 > >> what it was for right away. What ever fails may not happen
84 > >> immediately.
85 > >
86 > > Or try modprobe + dmesg instead. Usually a driver module tells
87 > > wether it has found some pice of supported hardware or not.
88 >
89 > Now that is a good piece of advice there... I did notice that rmmoding
90 > and modprobing can give you more info than you expect if you hit
91 > something that the module latches onto.
92 >
93 > I'm finding somewhat rough sledding in dmesg too. I find the ethernet
94 > stuff with no problem and, by now, know what I need there.
95 >
96 > My hardware is pretty common stuff, not even any sata discs, all ata.
97 > and I'm still not sure which driver is needed there.
98 >
99 > On the last attempted kernel, I just went menuconfig on a copy of the
100 > genkernel .config and turned off a number of things I was pretty sure
101 > didn't apply to me (all wireless for example) or anything but ethernet
102 > under the network section. All firmware turned off.
103 > Stuff I've never needed before.
104 >
105 > Every thing mounted but still no network was started or any of the
106 > stuff listed in `rc-update show'.
107 >
108 > I was dumped out into a root shell where I was able to modprobe and
109 > '/etc/init.d/bla start' my way into a fully running system.
110 >
111 > So the stuff was there but something (I suspect udev) blocked it
112 > starting up like it should.
113 >
114 > At the same time a genkernel built kernel just boots as expected so
115 > clearly something was turned off that shouldn't have been.
116 >
117 > Right now my dmesg is clogged up with stuff since bootup so I'm going
118 > to reboot the genkernel built kernel and have a close look at dmesg
119 > (again for the 10th time ..) rmmod and modprobe and see what I find.
120
121
122 Jumping in the middle here....
123
124 On a new platform I usually just use lspci and "cat /proc/cpuinfo". From that
125 I can determine what processor I have and what hardware is plugged into the
126 pci bus... then all I have to consider is what gets plugged into the usb,
127 firewire, parallel or serial ports... I've always rolled my own kernels and
128 find it quite rewarding impressing the newbies with my efforts.
129
130 That said... always keep two kernels around... one you KNOW works and the
131 other for fine tuning or testing.
132
133 Cheers and Merry Christmas.
134
135
136
137
138
139 --
140
141 *****************************************************************************
142
143 From the desk of:
144 Jerome D. McBride
145
146 17:44:45 up 10 days, 23:48, 5 users, load average: 0.74, 0.51, 0.36
147
148 *****************************************************************************