Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
You need to be subscribed to get your post through automatically. We may well be too busy to let them through otherwise, and they may even be lost completely without us noticing. On Thu, Jan 22, 2009 at 03:28:52PM +0100, LLLActive at GMX.Net wrote: > Lars Ellenberg wrote: > > On Wed, Jan 21, 2009 at 06:10:47PM +0100, LLLActive at GMX.Net wrote: > > > >> Log in Syslog: > >> modprobe: FATAL: Could not load > >> /lib/modules/126.96.36.199-0.21-default/modules.dep: No such file or directory > >> > >> Any Ideas? > >> > > > > install the drbd _module_? > > run depmod? > > > > > Hi again Lars, > > I made an online update from Novell for the SLES 10 SP2. The kernel > changed from 188.8.131.52-0.21-default to 184.108.40.206-0.33-default. > > The drbd-8.2.6-3.2.x86_64.rpm still does not install properly. > I decided to try installing from source for the current kernel. I tried to explain. I try again. There is a user land part (drbdadm, drbdsetup, drbdmeta and several scripts), in the drbd package. There is a kernel module part (in the drbd-km-<kernel-version> packages). You need to install _both_. You need to install the kernel module package matching your kernel. You need to install the userland matching your drbd kernel module version. The user land package cannot possibly depend on the "right" kernel module package, as it cannot know offhand, which kernel you intend to run. The kernel module does actually depend on the userland, as regardless of kernel version, they all depend on "the same" userland. the /lib/modules/kernel-version-and-flavour/modules.dep file is supposed to be installed with the kernel package, and regenerated when additional modules are installed, or even on each reboot by some init script. it may happen that modules.dep is out-of-date, which can be rectified by re-running depmod. though the post install scripts of the drbd-km package are supposed to take care of that. if it does not exist, you may have "removed" already your running kernel (which you should not, but which is possible, maybe because you have "upgraded" your kernel, i.e. installed a new kernel package, thereby removing your running one and its modules and dependencies, but not yet booted into the new one. which is a concept I consider to be bad practice. but I digress...). or something else is wrong. non-existence of modules.dep has nothing to do with drbd, but with you (or your packaging system) screwing up. and you asked in a private mail about /lib64/modules... there is no such thing. it is supposed to be /lib/modules/`uname -r`/... yes, there have been some out-of-tree kernel modules that tried to use /lib64/, but they are wrong. it is /lib/modules, because the kernel.org kernel Makefile says so. > Which source should I use for a production environment? I see the latest > on http://oss.linbit.com/drbd/ is *drbd-8.3.0.tar.gz* > <http://oss.linbit.com/drbd/8.3/drbd-8.3.0.tar.gz> 8.3.0 is supposed to be production ready. it is actually sort of a "8.2.8", but as it includes several features and enhancements formerly only available for paying customers of LINBIT, we thought it prudent to bump the second digit of the version number. things we do not consider to be production ready will be marked clearly as "beta" or "rc" (release candidate) or something like that. yes, there have been regressions in the past, new introduced bugs, or bug fixes for known bugs, which unfortunately introduced new ones. sorry, that is part of software development, shit happens. we try to avoid that, we do apply a regression test suit regularly, and keep adding new test cases to it. but there will always be something we did not cover, or some race conditions that do not trigger even during long term testing. we do use 8.3.0 in production, and recommend it. there are more conservativ people feeling more confident in using the feature-frozen 8.0 series for now. what you use, and how you use it is your responsibility. so you have to do your own testing to see if it is "good enough" for you. -- : Lars Ellenberg : LINBIT | Your Way to High Availability : DRBD/HA support and consulting http://www.linbit.com DRBD® and LINBIT® are registered trademarks of LINBIT, Austria. __ please don't Cc me, but send to list -- I'm subscribed