| 1 |
On 28/09/06, Richard Broersma Jr <rabroersma@×××××.com> wrote: |
| 2 |
> > Sounds to me like the problem is on your linux box, not the windoze. |
| 3 |
> > machine. |
| 4 |
> > How did you compile your kernel? Are you sure you included cifs in it? |
| 5 |
> > If so, is it a module, and is it being loaded? |
| 6 |
> |
| 7 |
> I am pretty sure my original kernel had cifs built into the kernel. I also have samba installed |
| 8 |
> in the machine. |
| 9 |
> |
| 10 |
> I thought I could give a newer kernel source a try with cifs built as a kernel module. However, |
| 11 |
> modprobe doesn't seem to see it. Perhaps it is already loaded by default? |
| 12 |
|
| 13 |
If "grep cifs$ /proc/filesystems" doesn't show anything then support |
| 14 |
definitely isn't available. This means it's either not statically |
| 15 |
built into the kernel or that it's not available as a loadable moduel |
| 16 |
for whatever reason. |
| 17 |
|
| 18 |
If it is something you intend to use consistently then I don't see |
| 19 |
much point in building it as a module. Nonetheless, here are a few |
| 20 |
tips relating to the usage of loadable kernel modules: |
| 21 |
|
| 22 |
1) If you enable an option as a module where previously it wasn't |
| 23 |
enabled at all then, in most cases you can get away with: make modules |
| 24 |
&& make modules_install. The modules_install step is necesary to move |
| 25 |
them to the correct place under /lib/modules/($uname -r). |
| 26 |
|
| 27 |
2) There are some exceptions to the above rule. If in doubt, it's |
| 28 |
safer to do this: make && make modules_install. |
| 29 |
|
| 30 |
3) Make sure your bootloader is booting a kernel built from the source |
| 31 |
tree that you're actually manipulating! This is particularly pertinent |
| 32 |
if you have multiple source trees installed. For sanity's sake, also |
| 33 |
make sure you have /usr/src/linux symlinked to whichever tree you want |
| 34 |
to work from. |
| 35 |
|
| 36 |
4) Further to the previous point, make sure that the kernel referenced |
| 37 |
by your bootloader is the same as the one you most recently built. For |
| 38 |
example, if your bootloader is pointing to /boot/vmlinuz and you're |
| 39 |
using x86 arch: cmp /boot/vmlinuz /usr/src/linux/arch/i386/bzImage. If |
| 40 |
it differs in any way whatsoever then copy bzImage over vmlinuz and |
| 41 |
reboot immediately. Another good test is to run uname -a and check the |
| 42 |
build time. |
| 43 |
|
| 44 |
5) Never mix and match gcc versions when building any portion of the |
| 45 |
kernel (be it the kernel image itself or any loadable modules). Some |
| 46 |
people run into this issue because of the gcc-3.3->3.4 and gcc-4.1 |
| 47 |
upgrade scenarios. If you think you've been affected then back up your |
| 48 |
/usr/src/linux/.config file and run "make mrproper". Copy the .config |
| 49 |
file back again then build the kernel/modules all over again. |
| 50 |
|
| 51 |
6) You can "rescan" for available modules by running: |
| 52 |
/sbin/modules-update. Worth a shot if "modprobe -l" isn't showing the |
| 53 |
modules that you think should be available. The list should generally |
| 54 |
correspond with the output of: find /lib/modules/$(uname -r) -name |
| 55 |
"*.ko". |
| 56 |
|
| 57 |
HTH, |
| 58 |
|
| 59 |
--Kerin |
| 60 |
-- |
| 61 |
gentoo-server@g.o mailing list |
Archives