Re: [gentoo-user] Re: kernel config hell
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
Re: [gentoo-user] Re: kernel config hell
Am Samstag, 27. Dezember 2008 20:27:37 schrieb Nikos Chantziaras: Harry Putnam wrote: Summary of request for help: Are there hardcore kernel builders in the house who can steer me to a faster way of figuring out what the installed modules do... for sure. Well, my bit of wisdom here: Don't use modules. Do a make menuconfig, disable everything you don't need, and compile everything you need in-kernel instead of as a module. I'd say the disable everything you don't need part is what Harry's mail is all about. Bye... Dirk signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: kernel config hell
I would suggest to follow the Gentoo handbook first. Leave all options you are not sure as default, using lspci to find out more about your hardware specifications. From my experiences I will make sure that the kernel is bootable first then adapt it to hardware later. Use modules or not is your choice, both ways work fine. If you want to make sure that thing is stable, you can back up your old config later then have a bunch of test kernels to test. The help from kernel config interface does help you to get a general idea about what is the purpose of the option. Not everyone can get the kernel work for the first try, do not panic. Once you get through the first time, thing will go more smoothly than you thought. It happened to me one year before but now it take me about less than 10 minutes to have the new kernel configured in my computer. Good luck,
Re: [gentoo-user] Re: kernel config hell
Hung Dang wrote: I would suggest to follow the Gentoo handbook first. Leave all options you are not sure as default, using lspci to find out more about your hardware specifications. From my experiences I will make sure that the kernel is bootable first then adapt it to hardware later. Use modules or not is your choice, both ways work fine. If you want to make sure that thing is stable, you can back up your old config later then have a bunch of test kernels to test. The help from kernel config interface does help you to get a general idea about what is the purpose of the option. Not everyone can get the kernel work for the first try, do not panic. Once you get through the first time, thing will go more smoothly than you thought. It happened to me one year before but now it take me about less than 10 minutes to have the new kernel configured in my computer. Good luck, I'll second what Hung said, getting your kernel right takes a bit of time. However I'll add a few points. Back in the day I used to build super stripped down kernels, but eventually realized it was kinda ridiculous. Why spend almost thirty hours for almost no real world gain other than driving yourself insane? It was almost worth my time on a Sparc5 with 64MB, but today you're better off spending your time cooking dinner and spending the $20 you saved vs the restaurant on RAM. Well maybe you'd need to do that twice. :-) On the other hand I learned a fair amount about what not to screw with by ripping everything out. If you want to go that route, it'll take you around a week to make almost all the mistakes. Realize this will happen and then enjoy the process. I also recommend taking notes or you'll keep repeating your mistakes. The other thing is don't get carried away in stripping things out of your kernel. Need to mount and ISO, oops you removed loopback support. Need to make your machine into a DHCP server, oops your removed (gah I should remember this) sockets (i think). Need to use OpenVPN, oops you removed tap/tun interfaces. The list goes on and on. Yeah you can install those as modules once you figure out that they are missing which can be frustrating when the errors aren't very clear. My advice is take the middle path. Cut the complete crap out like parallel ports, ISDN, and SCSI cards that aren't actually in your system. Leave most of the rest alone for the most part unless you're pretty sure you know what it is. As you get a bit more comfortable and have a history of working kernels you can experiment more. kashani
Re: [gentoo-user] Re: kernel config hell
back in the day, this was why i went gentoo in the first place. i needed a better scheduler and compiling a new kernel off red hat for instance almost always broke other stuff. gentoo made my life easier. On 12 28, 08, at 7:32 AM, kashani wrote: I'll second what Hung said, getting your kernel right takes a bit of time. However I'll add a few points. Back in the day I used to build super stripped down kernels, but eventually realized it was kinda ridiculous. Why spend almost thirty hours for almost no real world gain other than driving yourself insane? It was almost worth my time on a Sparc5 with 64MB, but today you're better off spending your time cooking dinner and spending the $20 you saved vs the restaurant on RAM. Well maybe you'd need to do that twice. :-) On the other hand I learned a fair amount about what not to screw with by ripping everything out. If you want to go that route, it'll take you around a week to make almost all the mistakes. Realize this will happen and then enjoy the process. I also recommend taking notes or you'll keep repeating your mistakes. LOL yeah. this happened to me. The other thing is don't get carried away in stripping things out of your kernel. Need to mount and ISO, oops you removed loopback support. Need to make your machine into a DHCP server, oops your removed (gah I should remember this) sockets (i think). Need to use OpenVPN, oops you removed tap/tun interfaces. The list goes on and on. Yeah you can install those as modules once you figure out that they are missing which can be frustrating when the errors aren't very clear. *nods* i do this too. i strip everything off--- hardware that i don't need but i do keep a lot of things turned on like FS stuff. if the box isn't a server, i turn on the networking stuff like tap/tun interfaces as modules. if the box is a server then it gets turned on. i also make sure that i turn a lot of FS on. even reiserfs. especially ntfs. etc. etc. you never know if you'll need those in the future. My advice is take the middle path. Cut the complete crap out like parallel ports, ISDN, and SCSI cards that aren't actually in your system. Leave most of the rest alone for the most part unless you're pretty sure you know what it is. As you get a bit more comfortable and have a history of working kernels you can experiment more. kashani but yeah, really took a lot of time and learning and messing around. have fun! Cocoy www.twitter.com/cocoy People who are really serious about software should make their own hardware -- Alan Kay
Re: [gentoo-user] Re: kernel config hell
On Saturday 27 December 2008 10:48:19 am Harry Putnam wrote: Nikos Chantziaras rea...@arcor.de writes: [...] Well, my bit of wisdom here: Don't use modules. Do a make menuconfig, disable everything you don't need, and compile everything you need in-kernel instead of as a module. I'd say the disable everything you don't need part is what Harry's mail is all about. Well, finding out what every installed module does isn't going to help anyway. I'd start with only the modules currently used after a fresh boot (lsmod). If you compile those in-kernel, it will boot. Everything else can be tweaked later. Yeah, I talked about that in OP. But the only kernel I've got working at the moment is a genkernel and it installs 80+ modules. rmmoding my way through those is what lead to my post. Some indicate they are in use but I can see they aren't related to things I actually need. Digging that bit of info up is what I've been talking about. 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. Many times the help provided doesn't really explain what a given setting does. In fact in most cases it does not. 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. 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'? 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. 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'. 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. At the same time a genkernel built kernel just boots as expected so clearly something was turned off that shouldn't have been. Right now my dmesg is clogged up with stuff since bootup so I'm going to reboot the genkernel built kernel and have a close look at dmesg
Re: [gentoo-user] Re: kernel config hell
You may also want to try lspci -v. It shows you what modules the hardware uses and it should be able to boot with those at least. Example: 00:02.2 USB Controller: nVidia Corporation nForce2 USB Controller (rev a3) (prog-if 20 [EHCI]) Subsystem: ABIT Computer Corp. Device 1c02 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 10 Memory at e0003000 (32-bit, non-prefetchable) [size=256] Capabilities: [44] Debug port: BAR=1 offset=0080 Capabilities: [80] Power Management version 2 Kernel driver in use: ehci_hcd The last line shows what modules my USB controller uses. Also, those are compiled in even tho it shows them as modules. Hope that helps. Dale :-) :-)
Re: [gentoo-user] Re: kernel config hell
Harry Putnam wrote: Nikos Chantziaras rea...@arcor.de writes: Harry Putnam wrote: Nikos Chantziaras rea...@arcor.de writes: [...] Well, my bit of wisdom here: Don't use modules. Do a make menuconfig, disable everything you don't need, and compile everything you need in-kernel instead of as a module. I'd say the disable everything you don't need part is what Harry's mail is all about. Well, finding out what every installed module does isn't going to help anyway. I'd start with only the modules currently used after a fresh boot (lsmod). If you compile those in-kernel, it will boot. Everything else can be tweaked later. Yeah, I talked about that in OP. But the only kernel I've got working at the moment is a genkernel and it installs 80+ modules. The way I do it, is to simply know what hardware is in the machine (dmesg, lspci and hwinfo for things I'm not sure about) and look for it in the kernel configuration. For the few modules that remain where I don't know what they do, I just google their names. The important stuff is just the PATA/SATA controller, SCSI disk support and keyboard/mouse though. The rest I add later. Sounds like a plan... thanks. Maybe eventually some of that output will be a little easier. Here I just mean dmesg... lspci is easy enough. I must need some specific package to see hwinfo. Its unknown to bash here. emerge hwinfo should help with that. Dale :-) :-)
Re: [gentoo-user] Re: kernel config hell
Harry Putnam wrote: Dale rdalek1...@gmail.com writes: You may also want to try lspci -v. It shows you what modules the hardware uses and it should be able to boot with those at least. Example: Well son-of-a-gun... that is nice. Thanks Yea, thanks to whoever mentioned it a while back. I have no clue how I remembered that command either. Usually, I forget if I haven't used it in a while. That should also work from the CD as well in case someone else should see the need to use it. Also, keep in mind that you can search for the module in make menuconfig. Hit the / key then type in the module name. Should show the path to get to it as well. Us old farts do have some tricks. LOL Dale :-) :-)
