can i ask what differs on that page compared to what i have written, and how does it answer his question?

thank you for Drozz's effort!
i think that article have the same method with what Drozz write .
maybe APM can compile for a modules only?
can anyone answer me ?

do you mean maybe it only compiles as a module only?
if so i am not sure, and if it is only a module, then just load it up and set it to startup on bootup.

yeah, I want to compile apm IN the kernel ,but it cant work.so i use it as a module now.thank you everybody.

yah well like i said if its a module just set it to automatically startup, if it works it works, no need to fix what isn't broken :D

i browsed through the forum and found this thread. :study:

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?

thanks in advance. :)

well before starting everything off by issuing "make mrproper" apply all your patches ...

just going to give this a bump, just so that people may notice it before they ask how to do it, cause i noticed a few threads lately being kernel related.

Hello, Newbie Here.

Was lucky enough to stumble upon this extremely enlightening link.

Then lost it

Then found it again.

Got up to the make "modules_install" bit and all I get is after entering the command:

ln: when making multiple links, last argument must be a directory
make: *** [_modinst_] Error 1

and nothing happens...:scratch:

I'm running RedHat 9.0 on a Toshiba Satellite 5105-s607 and FINALLY SUCCESSFULLY added ACPI support (the 2.4.20) patch to Kernel 2.4.20.

Any suggestions or ideas would be appreciated!

Thanks!

Is it true that you only need system.map if you want to use modules?

Just heard about that...

thx

as opposed to what else?

OK I searched a bit and every site says that you need it... sorry, but i thought i read the opposite somewhere :study:

This is from the initrd.txt and it explains reason you may want to use it.

Usage scenarios
---------------

The main motivation for implementing initrd was to allow for modular
kernel configuration at system installation. The procedure would work
as follows:

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
loads initrd
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
approach.
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
performed

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
auto-detection).

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
floppies.

ds: no socket drivers loaded!
 

DrOzz;

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).

Thanks a lot for your help,

sean

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.