Linux - GeneralThis Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.
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.
i browsed through the forum and found this thread.
i just started compiling kernel 2.4.21 to be included in a custom distro, and have done it pretty much successfully. i am thinking of including several patches (BlueZ, LTSP, and Con Kolivas' patch), i tried including only the BlueZ patch and it worked out fine. is it possible to include several patches and produce only one kernel? if it is, how do i do it? if not, is there a work-around for this?
There are 2 files that are used as a symbol table:
Every time you compile a new kernel, the addresses of various symbol names are bound to change.
/proc/ksyms is a "proc file" and is created on the fly when a kernel boots up. Actually, it's not really a file; it's simply a representation of kernel data which is given the illusion of being a disk file. Therefore, it will always be correct for the kernel that is currently running..
However, System.map is an actual file on your filesystem. When you compile a new kernel, your old System.map has wrong symbol information. A new System.map is generated with each kernel compile and you need to replace the old copy with your new copy.
Is it true that you only need system.map if you want to use modules?
This is from the initrd.txt and it explains reason you may want to use it.
The main motivation for implementing initrd was to allow for modular
kernel configuration at system installation. The procedure would work
1) system boots from floppy or other media with a minimal kernel
(e.g. support for RAM disks, initrd, a.out, and the Ext2 FS) and
2) /linuxrc determines what is needed to (1) mount the "real" root FS
(i.e. device type, device drivers, file system) and (2) the
distribution media (e.g. CD-ROM, network, tape, ...). This can be
done by asking the user, by auto-probing, or by using a hybrid
3) /linuxrc loads the necessary kernel modules
4) /linuxrc creates and populates the root file system (this doesn't
have to be a very usable system yet)
5) /linuxrc invokes pivot_root to change the root file system and
execs - via chroot - a program that continues the installation
6) the boot loader is installed
7) the boot loader is configured to load an initrd with the set of
modules that was used to bring up the system (e.g. /initrd can be
modified, then unmounted, and finally, the image is written from
/dev/ram0 or /dev/rd/0 to a file)
8) now the system is bootable and additional installation tasks can be
The key role of initrd here is to re-use the configuration data during
normal system operation without requiring the use of a bloated "generic"
kernel or re-compiling or re-linking the kernel.
A second scenario is for installations where Linux runs on systems with
different hardware configurations in a single administrative domain. In
such cases, it is desirable to generate only a small set of kernels
(ideally only one) and to keep the system-specific part of configuration
information as small as possible. In this case, a common initrd could be
generated with all the necessary modules. Then, only /linuxrc or a file
read by it would have to be different.
A third scenario are more convenient recovery disks, because information
like the location of the root FS partition doesn't have to be provided at
boot time, but the system loaded from initrd can invoke a user-friendly
dialog and it can also perform some sanity checks (or even some form of
Last not least, CD-ROM distributors may use it for better installation
from CD, e.g. by using a boot floppy and bootstrapping a bigger RAM disk
via initrd from CD; or by booting via a loader like LOADLIN or directly
from the CD-ROM, and loading the RAM disk from CD without need of
Thanks for your excellent newbie guide. I followed your instruction and everything went smoothly until last step, when I did "/sbin/grub-install ", I got an error message saying it's not the right syntax. So I tried "/sbin/grub-install '(hd0)' ", and got no more error messages.
But after I reboot the machine and chose to boot into the new kernel (2.4.22), I got the following messages and the computer just hanged there:
NET4: Unix domain sockets 1.0/SMP for linux NET4.0
ds: no socket drivers loaded.
kernel panic: VFS: unable to mount root fs on 03:40
When I did the make xconfig, I did choose Yes to every network socket option. So I can not tell what's wrong here.
My computer has two hard drives. The first (hda) runs WinXP Pro and the second runs Redhat linux 9.0 (kernel 2.4.20-20.9). The GRUB is installed at MBR on hda. The linux's root partition is at hdb5. Should I do sbin/grub-install at (hd0)? What should I pay attention to during make xconfig to get the drivers loaded?
And I have no problem to boot into the original kernel (2.4.20-20.8).
I saw a post similar about the APM shutdown problem with slackware elsewhere on LinuxQuestions, you may want to search for it. It describes a few changes that have to be made to a few system files. Wish I could be more help, but I didn't bookmark the the thread.