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