On Mon, Jan 4, 2010 at 5:56 PM, Simon Wilkinson <[email protected]> wrote:
> >> Using kmod's are fine, but dkms can be easier when upgrading kernels. >> >> To use the dkms rpm, add the epel repo, remove the kmod's, and run >> "sudo yum dkms openafs-dkms" >> >> dkms automatically compiles the needed openafs kernel module when the >> kernel is upgraded. >> > > dkms is fine as long as you don't care about reproducibility. But allowing > each machine to build its own kernel at an unpredictable moment > significantly increases the number of variables you have to deal with when > debugging large installations. For example - how do you know which tool > chain a given kernel module was built with? How can you be sure that a > module was built correctly, if just one machine is experiencing problems? > And so on ... > > For systems where you need to know exactly what's being run, there are > definite benefits to shipping binary modules to the clients. We don't ship > kmods because we're bored :) > > On that note, I should probably apologise for the lack of new kmods over > the holidays. We're experiencing cooling issues in the machine room where > the build host is situated, and it's one of the machines that has been shut > down to reduce the thermal load. > > Oh, so this could be the reason the kmod install wanted an older kernel version than my current Centos kernel? When installing with yum the kmod wanted to install an older kernel -- which failed. The kmod installed, but any attempt to insmod the afs kernel failed with a 'not found' message. So I assumed there were dependancies to the older kernel that just caused the kmod to fail. So I backed in out, and attempted the dkms road -- which lead to more interesting problems... > > Simon. > > -- David Bear College of Public Programs at ASU 602-494-0424
