Do you want to run depmod against /lib/modules/2.6.16.23-custom ? Then,
depmod -a /lib/modules/2.6.16.23-custom
should do. If you add '-b foo', it will prepend the 'foo' to your default version (`uname -r`) which is what you are seeing.
Thank you for your time to respond. Yes I am attempting to build a custom kernel (and run depmod on the associated root file system location. I wonder if I am supposed to chroot into the root filesystem which is being constructed. I think not... as that is why the depmod options exist, correct; to build in another "./lib" than the native host's /lib at root "/"?
I had stated that I was experiencing an issue of "append" whereas (if I am not misinterpreting your answer) you offer an explanation for a prepend of pathname strings. That's cool. I am grateful for the dialog.
Here is my experience restated:
The native file system location "/lib/modules/2.6.18-53.1.14.el5" is being "APPENDED" to the base path I set with switch -b.
That is, I say the dir containing the file "modules.dep.temp" is in this directory:
./lib/modules/2.6.16.23-custom
which is /home/User/WorkDir/images/current/lib/modules/2.6.16.23-custom/lib/modules/2.6.18-53.1.14.el5/modules.dep.temp
So, you can see that:
/lib/modules/2.6.18-53.1.14.el5
is being appended to:
./lib/modules/2.6.16.23-custom
Thanks in advance for any advice.
Cheers, AZ
PS: The version, 2.6.18-53.1.14.el5, is clearly my build host. So that is coming from running (native) kernel, uname -r:
$ uname -r 2.6.18-53.1.14.el5