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 |