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 |
***************************************************************************** |