SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Distribution: Slint64-14.2rc on Lenovo Thinkpad W520
Originally Posted by H_TeXMeX_H
I'd say it's a VERY bad idea to build everything in ... you're gonna have tons of problems, I can guarantee it.
Could you please elaborate on that statement?
I just did that and though of course I didn't check everything be working, what I am using seems to work so far.
At least I feel safe as my laptop's fan is running
The only driver I had to modularize afterwards was "nouveau" as else I couldn't see anything on the console while booting:
Module Size Used by
nouveau 670383 2
[EDIT]I just figured out why nouveau has to be modularized reading this post from Linus: otherwise the firmware for the graphics card will never be loaded.
But be there any inconvenience in doing that -- especially if that could put my system at risk -- of course I'd be pleased to know which.
Meanwhile I must admit that for my own use cases I can't see much benefit in having everything built-in -- just wanted to try, considering your statement as a challenge
[EDIT] Of course I did "make localmodconfig" then "make localyesconfig". So it's not "everything built in" but "the drivers I use built in". Otherwise there is the "allyesconfig" target but I wouldn't advise anybody to use it -- except may be kernel developers but I very much doubt they need my advises anyway...
Last edited by Didier Spaier; 03-05-2010 at 06:30 PM.
Ok I finally did it. Now with a customized 2.6.32 kernel. localmodconfig is quite useful but not that well implemented yet. I had inserted my USB drive before running localmodconfig, but at the end of the compilation process I was left without any USB support. I did a make clean and make menuconfig again to check out what happened and saw that "USB Mass storage support" was off and many USB options weren't auto-detected. My soundcard module wasnt picked up either. It's a generic Intel sound card. So I had to enable those modules and recompile kernel. Now everything works great. However this option did help me getting rid of a lot of unnecessary stuffs quite easily.
Yeah I also ran into the USB thing since I hadn't plugged in any USB storage devices and like you said the modules weren't in use. I don't know if I would recommend this for first time kernel compilers but if you have some experience this is a great tool.
Well, the main problem is that you can't unload modules. So, this can cause problems if two modules are trying to use the same device, or if a module that you don't need tries to probe or probes excessively for a device that does not exist. Also, sometimes floppy drives malfunction if you build-in 'floppy', I've had this happen, had to build it as a module.
The only way to build everything in is if you only build-in modules that you know you will need. So, if you find a list of the modules that you know you need, you can safely build those in. But using "allyesconfig" just builds all modules in, which is crazy. Not sure why they put this as an option.
Distribution: Slint64-14.2rc on Lenovo Thinkpad W520
Originally Posted by H_TeXMeX_H
Well, the main problem is that you can't unload modules. So, this can cause problems if two modules are trying to use the same device, or if a module that you don't need tries to probe or probes excessively for a device that does not exist.
The only way to build everything in is if you only build-in modules that you know you will need. So, if you find a list of the modules that you know you need, you can safely build those in.
I agree. That's why I would recommend to those wanting to try (I suggest you start from an already modular running kernel which fits your needs) to do something like that:
zcat /proc/config.gz > .config
make menuconfig #to add what's missing
make menuconfig #to modularize what shouldn't be built-in
Also I suggest using "local version" option in "general setup" to differentiate between modules directories in /lib/modules
Also, sometimes floppy drives malfunction if you build-in 'floppy', I've had this happen, had to build it as a module.
Anybody still using floppy drives around here?
But using "allyesconfig" just builds all modules in, which is crazy. Not sure why they put this as an option.
My guess (only a guess) is that it is used only by kernel or driver developers looking for conflicting drivers. I'd guess of something similar for "localnoconfig". But "localrandconfig" is clearly the funniest.
Last edited by Didier Spaier; 12-11-2009 at 04:16 PM.
My guess (only a guess) is it used only by kernel or driver developers looking for conflicting drivers. I'd guess of something similar for "localnoconfig". But "localrandconfig" is clearly the funniest.
Well, I sometimes use floppies, but it's rare. Still, I expect the drive to work. I have a portable USB floppy.
Indeed, they might use it to prevent what I was talking about. I suppose, if they tested it well enough, they could eliminate any such issues.
Wow, this IS cool. Anything to move along the process of recompiling a custom kernel is great. :hatsoff: to the developers for this new feature.
1.8. Easy local kernel configuration
Most people uses the kernel shipped by distros - and that's good. But some people like to compile their own kernels from kernel.org, or maybe they like following the Linux development and want to try it. Configuring your own kernel, however, has become a very difficult and tedious task - there're too many options, and some times userspace software will stop working if you don't enable some key option. You can use a standard distro .config file, but it takes too many time to compile all the options it enables.
To make easier the process of configuration, a new build target has been added: make localmodconfig. It runs "lsmod" to find all the modules loaded on the current running system. It will read all the Makefiles to map which CONFIG enables a module. It will read the Kconfig files to find the dependencies and selects that may be needed to support a CONFIG. Finally, it reads the .config file and removes any module "=m" that is not needed to enable the currently loaded modules. With this tool, you can strip a distro .config of all the unuseful drivers that are not needed in our machine, and it will take much less time to build the kernel. There's an additional "make localyesconfig" target, in case you don't want to use modules and/or initrds.
Does this also mean it will make sure that framebuffer options is also compiled? Seeing how one of the most common mistakes with a recompiled kernel is the forgetting to compile that feature, resulting in a blank screen at boot up.
It looks like some real progress on this front. Congrats and THANKS to the kernel team!!
Years ago, I managed mainframes and we installed the OS from source every time. We use a "monitor generator" utility to create a set of definitions (an assembler header file) and then used "make" leaving things to run overnight. [grin]
One mon-gen feature I'd like to see worked like this.
1. Dialogs asked us to name the hardware that we wanted to use.
2. The tool then examined the currently running hardware making a compare with items we said that we wanted or expected. If things did not match, the tool saved what it knew and reported hardware install and config details for whatever was missing: "power on or add this controller" "connect that device" "load a tape" ... whatever.
3. After we danced with the hardware, we restarted mon-gen. Step #2 repeated until we agreed that expectations were met.
4. All these expectations either enabled or disabled or modified which features were available for option configuration. For example, absent network parts, all net specific config options were no longer available.
[(grin) I said this was on mainframes a while ago (grin)]
This process worked in onion-layer fashion: really basic hardware,
memory, disks, the console, more complex hardware, terminals, networking, and so on. Software was also layered in similar ways.
I cannot tell you how many hours were saved when mon-gen told me "you said to expect this feature at item #1 but I never found enabling parts at step #2. Here are things to do to resolve that conflict: A, B, ..., Z"
It would be nice to have similar "expectations" added to kernel config. It would be wonderful to have "expectations" added to distro install as well.
BTW/ During distro install, it might be nice if we layered the onion rather than relied so much on shell globbing or similar package processing. Start with minimum packages to install a kernel and modules. Add daemons and utilities that enable a running system.
This point might be a minimum configuration "single user" install.
Follow with application support that is closest to the hardware.
Add layer on related layer until done where each layer is a bootable
system with some set of features. -- just a thought
That is interesting news, and which will be very useful. On this note, I have always wondered if it was problematic with using a .config file from an earlier kernel release to use to build a new kernel from source. For example, if going from 22.214.171.124 to 2.6.32, if you load the .config from 126.96.36.199 into 2.6.32 when compiling, would problems result from this? The reason I ask is that I have done this before, and noticed when I loaded an older .config from an older kernel branch that there a few text exceptions thrown in the background, but couldn't quite make them out due to the kernel configuration menu being in the foreground. All seemed to build well with no errors in the process, so I don't know. Anyway, I'll be trying this new method in the future to see what results. Thanks for sharing this.
try running "make old_confg" this will bring older config up to speed with the newer kernel
"make def_iax86-64"or "make def_iax86" I think will probe the computer and give you a bare bones run almost all hardware
kernel 64bit or 32bit you will still need to set up file systems and other options
And I think filesystems and drivers for your HD and optical drives should be compiled in kernel. I have never used a functional initrd after the initial install when testing a new Slackware version. I have used them later only for aesthetic purposes (splash screens).