odd--for some reason I am unable to mount my 100GB portable HD (the HD with the mp3s, movies, etc on it) -- it is a vfat partition (fat32).
My kernel (kernel-2.6.12-r10-gentoo) has vfat support and mosdos fs support--but when I actually try to mount the drive, I get the error:
mount: uknown filesystem type 'vfat'
what do ya think?
appreciated as always,
chris
Last edited by TheLegend81 on Fri Sep 30, 2005 7:31 am, edited 2 times in total.
ASUS A8N-SLI Deluxe - AMD64 3500+
2x CorsairXMS3200XL-512MB (1024 total)
2x Seagate 80GB SATA barracuda HDs (not in raid)
1x PX-716SA (SATA DVD+/-RW)
It is evident by the mount and cat output that you have no support for vfat currently.
Maybe you compiled it as a module, try to modprobe it. Or maybe you compiled it but you are not running the right kernel, check your kernel compiletion time with 'uname -a' to see if the date is the date from your last kernel compilation. Another option is that you did not compile vfat support at all.
Output from 'cat /usr/src/linux/.config | grep vfat' may clear things up a bit.
upon rebooting, it seems that all the modules that previously worked no longer boot.
I was using the 2.6.13-gentoo-r1 kernel by mistake, and dropped back to the more reliable 2.6.12-gentoo-r10 version (this fixed the vfat problem)
now when I try to run /etc/init.d/net.ath0 start (my internet init script) it doesn't work b/c the devices aren't found--
upon further investigation, I found that modprobing the wlan0 (part of the madwifi-driver package) it was looking for modules in the 2.6.13-gentoo-r1 kernel directory as opposd to 2.6.12-gentoo-r10. what environmental variable or config file needs to be changed?
ASUS A8N-SLI Deluxe - AMD64 3500+
2x CorsairXMS3200XL-512MB (1024 total)
2x Seagate 80GB SATA barracuda HDs (not in raid)
1x PX-716SA (SATA DVD+/-RW)
esperto: I tried modules-update to no avail (although did not try rebooting afterwords)
dgaffuri: I would otherwise agree with you except this, I deleted my /root and /usr partitions after using the 2.6.13(r1)--this I imagine would knock out those sources. Before using 2.6.13(r1), grub was pointing to an older build of 2.6.12(r10). Leaving the boot partition alone, grub continued to point to the 2.6.12(r10) and the more recent 2.6.13(r1) build. After deleting the /root and /usr partitions, I fdisked them again creating new partitions, initiated a new file system (ext3) for both partitions and emerged gentoo sources which reported 2.6.12(r10) sources in the new /usr/src/linux. I built this kernel, copied the bzImage accidentally to 2.6.13(r1) as opposed to 2.6.12(r10) and likewise with the .config file. I edited the grub.conf file, erasing the 2.6.13(r1) boot option leaving the 2.6.12(r10).
So now I have the older 2.6.12(r10) build as well as the newer 2.6.12(r10) build accidentially named 2.6.13(r1) and a boot option to boot WinXP and 2.6.12(r10) -- clearly pointing to the older build. This resulted in the vfat problem I shared in this thread. After running ls -l in my /boot partition, I found out that my kernel image 2.6.13(r1) had a build date of 9-28--the date/time of my last 2.6.12(10) compilation--this is how I discovered the naming problem. Renaming both the kernel and .config 2.6.13(r1) appropriately to 2.6.12(r10) overwriting the older 2.6.12(r10) versions, I thought I had solved the problems.
Obviously I didn't. Im confused as to why its trying to access modules in 2.6.13(r1). I can understand why it can't find them, I just don't know why it's asking for them--or what file/setting/variable to change to correct it.
ASUS A8N-SLI Deluxe - AMD64 3500+
2x CorsairXMS3200XL-512MB (1024 total)
2x Seagate 80GB SATA barracuda HDs (not in raid)
1x PX-716SA (SATA DVD+/-RW)
I currently am at work and no longer have access to my comp remotely as SSHD is down (looking in the 2.6.13(r1) dir).
So if the makefile contains version information (which would seem to indicate you are right) -- then simply compiling a new kernel 2.6.12(r10) kernel should result with a new makefile with the correct information, there by having the kernel look in the correct directory. Is my logic correct here?
ASUS A8N-SLI Deluxe - AMD64 3500+
2x CorsairXMS3200XL-512MB (1024 total)
2x Seagate 80GB SATA barracuda HDs (not in raid)
1x PX-716SA (SATA DVD+/-RW)
TheLegend81 wrote:So if the makefile contains version information (which would seem to indicate you are right) -- then simply compiling a new kernel 2.6.12(r10) kernel should result with a new makefile with the correct information, there by having the kernel look in the correct directory. Is my logic correct here?
More or less. Makefile is the input to the build process, but the version info will go in your kernel, and from there modules will be looked in the correct directory. I hope