I'm fiddling around with compiling a new kernel. To save myself time, I prefer to compile the new kernel on a non-production box so I don't tie up my production box. Convenient, for sure. When I complete the compilation, I easily copy the new kernel to my other boxes.

But on these other boxes, when I run a depmod -a I receive error messages. I expect this because the module dependencies are not updated on these other boxes. So my question is, how to easily migrate a recompiled kernel---and modules---to other boxes?

I can copy the kernel config file and run make modules and make modules_install on each box I install the new kernel, but that seems inefficient. Perhaps a better way is to copy/mirror the /lib/modules directory? If so, then should I use something like rsync? Or, if I am missing the big picture, what is a correct method to synchronize multiple boxes with a new kernel?

Thanks.

Hi,

You should move a copy of the generated modules for the kernel that was compiled. The make modules and make modules_install is for that kernel therefore it is dependent on these.

I use a build directory for this. This way I can create what I want and move it as a whole.

The use of a non-production box is done all the time. As long as the tree for the np box is the same for the other boxes this will not be a problem. I move these over then create a stanza in my lilo.conf to reflect the new test kernel. Then I run a test to make sure everything is working. You should now be able to dep -a for the test kernel.

@woodsman,

Another option would be,

1. export the /boot and /lib/module directories from the build server
2. install autofs on each production server to auto-mount /boot and /lib/modules from the build server
3. write a script to copy necessary files from the nfs to local /boot and /lib/modules, update lilo/grub configs, update boot loader and then reboot the server
4. from the build server, write a script to use rsh to call the script written in step 3 server by server (server list can be from a file)

If some steps are missing, please add them.

Hope it helps.

Thanks. Based upon your responses, I did a quick browse of the web to expand upon these thoughts. So what follows is Big Picture Stuff that I am asking for confirmation:

1. A build directory. New term for me . So I should copy the entire /usr/src/linux-2.x.x directory to a different location, such as to, for example, ~/kernel_builds/linux-2.x.x/src.

2. From my build directory I run the compiling process. In other words, I leave the original /usr/src/linux-2.x.x directory untouched.

3. Related to this build directory, I create a directory to store the new kernel module files, such as, for example, ~/kernel_builds/linux-2.x.x/modules.

4. Now, how do I steer the make utilities to know about this build directory location for installing the new modules? I found something about INSTALL_MOD_PATH. In my example above would I run:

make INSTALL_MOD_PATH=~/kernel_builds/linux-2.x.x/modules modules_install?

5. After finishing the entire exercise, I then perform a basic cp and chown to replicate the kernel and module files to other boxes. If on a LAN this probably is something for a cron job. Otherwise copy the files to a CD and manually install.

6. Question: When copying the updated module files to the other boxes, do I have to delete the existing contents of the /lib/modules/2.x.x directory before copying or just copy/overwrite the new module files as is?

Sorry for the seemingly obvious fundamental questions. I've done only a handful of kernel compiles, but now that I realize this type of task is going to become a regular event in my maintenance, I might as well do things similarly to how you experienced folks do this. New territory and all that, but the experience of others is usually golden!

Thanks again.

Hi there

I do it this way

1. Build the kernel (a working one with a previously tested configuration)

1a. # make modules_install

2. Make a package with the kernel itself (something like the official kernel package from the A series). The only thing there would be the contents of /boot with my kernel image.

3. Make a package with the modules from /lib/modules/2.x.x.x and the original schema from the official kernel-modules package from the A series (it had a postinstallation script and rc.modules).

4. Enjoy your kernel. (install it in all of your PCs)

So far I have had no problems with this method. Hope it will be useful for you.

May the Source be with you.

By the way, you have to make sure that

a) all you PCs have the same hardware

or

b) you kernel is generic enough as to work in every one

Greetings!

Hi there

You can even make a custom installer cd with your kernels. I do.

Check the Slackware installer CD. There you will find instructions. You can also check "Cooking up some Slack" (google for it, don't remember the URL).

Hi,

#1, I do a fresh install for my build directory which is /home/build. I use the pkgtool to get my packages.

#2, Yes

#3 You could

#4 If you do a;
You will see the link;

Obviously the link would be changed to the link for your build. (gws)

Edit: I should clarify this. You will install your kernel source, headers for the build. Once you make and install the modules this lib/modules will be installed via the version in the Makefile as noted in #6. (gws)

#5 several methods here, personal choice.

#6 NO! You will be adding to the tree. A new kernel with modules. I would suggest you use the extra version option of the Makefile. That way everything will be unique for each compile. Of course you will have to toggle this for each compile when needed. The reasoning is to have a testing session then if you need to then trim after your sure things are working. You could use the version to show machine dependency identification for ease of single machine compiles when a particular machine requires special needs.


BTW, no need to apologize! We all start at the same place just at different times.

Thanks for the replies.

Yes, that made sense to me many suns ago, long before I envisioned compiling my own kernels. As Ghost Busters might say: "Important safety tip---don't cross the streams!"

FWIW, I run with old boxes, which means I can strip a lot of overhead from the kernels if I wanted. I realize that much of the kernel is actually loadable modules, which never get loaded on my boxes, but those old boxes make things easier/simpler in many ways. I have used these older boxes for so long that I look at some of the kernel options and simply think, "What in tarnation is that option all about?" (Except I seldom use the word "tarnation." )

Do you mean use the installpkg --root option?

Yup, I see that! Now what purpose does that link serve? That is, which step in the compile process looks at that link? More specifically, I don't see how that link relates to my question of how to update the module files to a different location other than /lib/modules/2.x.x.

I understand that creating a build directory is a Good Thing. On my to-do list. Although, I notice that almost every how-to about compiling a kernel that I have run across is written to compile directly in the /usr/src/linux directory.

Regardless, seems to me that make bzImage and make modules is confined to working within that build directory. So far so good. However, the make modules_install command is the one that installs the newly made modules from the build directory to /lib/modules/2.x.x. So what purpose does the soft link above serve with respect to my original question? I'm guessing the make modules_install looks for that link, grabs the module (.o files?) from the location pointed to by the build link, and then installs the modules to /lib/modules/2.x.x---unless redirected by the INSTALL_MOD_PATH parameter.

Okay, so currently I have a /usr/src/linux-2.x.x and a /lib/modules/2.x.x directories. The kernel version numbers must match to update and install the new modules. So according to your suggestion, when I change the build soft link from /usr/src/linux-2.x.x to ~/kernel_builds/2.x.x-y, then do I understand correctly that the make modules_install command will install the new modules from my build directory to /lib/modules/2.x.x-y? Do I need to create this new directory or does make modules_install do this on-the-fly?

Doesn't that additional info get embedded into the kernel and does that extra version info mean that other packages must be recompiled? I thought I once read that by using the extra version parameter that the ALSA packages need to be recompiled. Is that correct or is my memory deteriorating? I realize I could learn some of these things through trial and error and personal experience, but at 2-1/2 hours a pop (I own old hardware) to compile a kernel, that option is inefficient!

I remain unclear how best to copy/replicate the updated /lib/modules/2.x.x directory to other boxes. Do I need to first delete the files in /lib/modules/2.x.x before copying the newer files, or perform some sort of rsync operation to match the files? Or do I run the make modules_install command on each box to perform the synchronizing?

Additionally, now that I have been using the original /usr/src/linux-2.x.x directory to perform my kernel compiles, what do I need to do to restore that directory to its original pristine condition before I create a build directory? Other than make mrproper, that is? Do I need to delete extra files or reinstall the tgz packages? AFAIK, those kernel source files are static so I could delete them all and simply reinstall the packages?

I again apologize, not for my ignorance---I'm ignorant about a lot of things in this universe , but for my verbosity. I know responding takes time to read and think and is potentially exhausting. If I write something poorly then I spin everybody's wheels getting nowhere because I was not clear. So I am trying to avoid that confusion. For whatever reason I find this compiling process mystical because most of the how-tos I run across are written by people with an IT or heavy computer background. They tend to skip a lot of things when explaining the process. I intend to update my own how-to from the results of this thread.

Thanks again!

Your welcome!

I install the package with pkgtool as a user not root. I only use the root when necessary.

That link is generated at the make modules_install to reference the builld.

You can continue to use the original but the intent of the use of a build directory will keep the original tree intact. This will also allow a user to experiment without worry of a potential problem. Also easier to move across platforms, especially if you build for different families.

I'll try to expand! If you are compiling for i86 and for Sparc platform. The build directory will help in preventing a potential confusion. Your confusion is the reasoning of the link. It is there for the purpose of identification of the modules that were built against the source. Thus preventing the fragmenting of an install if the modules are moved to a different or used against another kernel. It is simply a pointer to the parent.

Whoa! I never said you would directly change the link. You change this link when you have made a change in the Makefile extraversion variable and then make modules_install after compile.

Yes, the make will generate the directory and the build link.

Yes, you would compile your modules against the kernel version. That is why you should know your hardware needs.
You should use the lspci -vv to get some information.

First, by generating a unique kernel via the extraversion variable, this kernel will be unique to the tree that you move it to. If you have /lib/modules/2.4.31 and create a kernel with a extraversion=-woodsman then the /lib/modules/2.4.31-woodsman would be unique. The kernel you compiled would still be bzImage but when you copy this just tag it with the woodsman; cp bzImage /move_directory/vmlinuz-2.4.31-woodsman. Copy everything necessary and tag this way to keep things sane.

Just remove it and install the package. What have you done to the source tree?

If you remove and install to a fresh source then everything should be clean. That is one of the reasons for the use of a build directory. A true build directory is a target. We just use the build name to refer to an area that we are working with as another place to compile our source from. Thus preventing problems with the original.

Heck, if you want too then name it; /home/usr/src/linux

Quit apologizing! We would not respond if we didn't think necessary. Your clarity from your viewpoint is ok. Ommision is one thing we all do, be it intentional or by accident...

That's great that you wish to generate a howto. As simple as saying 'Tag your it'. Passing forward is always great.

Comfort zone!

Weeee ninny ninny!

Oh, so by using the EXTRAVERSION option in the Makefile, the make modules_install command will automatically, on-the-fly, update the soft link from /usr/src/linux-2.x.x to /usr/src/linux-2.x.x-y?

If correct, then let us back up a step. What happens if I manually edit the soft link to my new working area of ~/kernel_builds/2.x.x-y? Will make modules_install simply overwrite my effort?

Additionally, what happens if I manually modify that soft link and do not use the EXTRAVERSION option?

Okay, I do not understand how make and a makefile work. I presume the makefile contains the instructions to renew the soft link? Any recommended links for obtaining a basic understanding of how makefiles work?

So I have to recompile all packages that use kernel drivers stored in /lib/modules/2.x.x? If yes, then that's a bummer---more work, especially if I do not have a copy of the source files! I'll delay that portion of the adventure until either I obtain broadband or obtain the Slack CDs containing the sources.

So just copy the /lib/modules/2.4.31-woodsman to all other boxes along with updating the three /boot files? By using the EXTRAVERSION option I see how replicating to other boxes is simpler.

But for my learning curve, suppose I do not use the EXTRAVERSION option? After all, that is the method 99% of the how-tos recommend compiling a new kernel. Whether correct in this approach or appropriate is not an issue I want to discuss in this thread. I'm only curious what happens when I do not use that option. Seems then I need to delete the contents of /lib/modules/2.4.31 before copying the new module files? Which means creating a backup of that directory---just in case.

Nothing intentional except compile in that area---as suggested in 99% of the how-tos I've read. Moot point already. I deleted the directory (and /lib/modules) and restored from my backups. After several failed compile attempts yesterday (repeated depmod issues with each attempt), I shrugged and restored everything to my previous backup. The box boots just fine again with zippo error messages. I love backups!

Anyway, I created the new compile work area as suggested above and as I write, things seem to be working okay. I haven't yet run make modules_install therefore I do not know if my backup restorations will resolve those problems of yesterday. In between I've been revising my web site how-to. There remain some questions, but I'll continue this thread as those moments arrive.

Thanks again!

Hi,

You are confusing the issue! The word unique as defined by the link. You use the extraversion to do just that. Why manually change the softlink??? Only when necessary, if at all!
Just a suggestion; when you do a compile. One, change the extraversion=unque1 save the Makefile. Do your compile (make), then do a;
The only time you would change the link for the @build would be when you wish to re-compile for the particulair version. Meaning if you have 10 unique versions for different compiles and each has a different build source then you would change to the desired source before the regeneration/compile. So if I'm going to work on version unique1 I would make sure that the link points to the unique1 source within the /lib/modules-unique1.

We are outside the normal source tree! That is why you create the user space /home/build or /home/usr/src/linux directory for a normal user to edit,compile or whatever. If you desire to create the lib else where then look at the make.

As for your learning curve, try it!

Where are you doing the depmod? Not on the new compile from the build but from the copied machine I hope. That is if you want to create a test on the np machine then create a stanza in lilo after you copy the the correct files to the /boot. Update lilo then reboot on the np machine, on boot the depmod will be done. If you are using the test kernel to check, that's ok. But I would still revert to use of a stable kernel to do my compile on. ONce you have booted the test and modify, compile or whatever then the dep can be done against the test that is now current.

I would suggest that you understand the reasoning behind using a user account vs root account for the source build directory. You as the user can do anything on the source build directory without worry of root problems. You will edit, make or whatever within this directory as a user. When you need to su on account to say copy the bzImage to your copy or /boot directory then the permmisions would be set as need to root via su. Fiddle all you want with the build as user. If you mess up then just restore as the user. You can use your GUI for about anything on this work area as a user. If you want or need to then su when necessary. As root you should know not to gui when logged as root.

This is a good kernel guide

kernel link

Slackware link

I would suggest that you experiment with the uses as discussed, This way you will learn the process. Worry about the what ifs' later. KISS should be used! Hypothetical is later once you have thorough understanding of the standard uses.

I'm going to let this thread hang for a while. Other things have appeared on the priority list. However, with old hardware which takes about two hours to perform a kernel compile, asking questions is the only way I can hope to remain efficient with my time and experimentation.

One of the problems I had the past few days compiling a new kernel was copying the module files to another box. For some reason this failed. Today I decided to copy the files from the command line and through samba rather than Konqueror and the fish protocol. I was using fish simply because of the novelty and newness and because I haven't yet settled on how I want to assign file and directory permissions. Currently I have samba configured for read-only. Fish is a slick idea, but I'm uncertain the KDE developers have the bugs squashed. With reflection I think that might have been part of my problem with replicating my kernel mods to different boxes. My copying from the command line worked and upon reboot I had no depmod errors. Nada. I have no concrete idea what was occurring in my file transfers, but at least now my boxes are synched with the same kernel version as well as version 10.2 of Slack. Now I'm ready for 11.0.

I have configured a separate build directory and that idea is working just fine. So this thread has helped. There are a few remaining aspects of compiling I want to explore and my how-to is maturing nicely too. When I have further questions I'll bump this thread and likewise when I post my updated how-to.

Hi folks,

As promised I've updated my Compiling the 2.4.x Linux Kernel how-to:

Compiling the 2.4.x Linux Kernel

All comments and suggestions from both subject matter experts and inexperienced users are welcome, either here within this thread or by email. Thanks to all who helped!