终于搞定U盘挂载的问题了！！

长久以来，我的KDE4@gentoo无法挂载我的U盘。KDE可以识别出我插进入的U盘，但是挂载的时候
提示：

dmesg有

FAT: IO charset not found

的提示。
我曾google过这个问题，但是很奇怪，似乎很少有人遇到和我一样的问题，网上散布着不少转载的帖子，但都解决的如隔靴搔痒，不着根本。
一开始我以为是由于hal和hal-info的版本太低，于是冒着卸载system包的危险，卸载了e2fsprogs-libs等，最终升级hal和 hal-info到最新版本。问题非但没有解决，在我打算将升级过的软件包降级到稳定版本的时候，e2fsprogs-libs-1.41.3-r1居然编译不过去了！！无奈只好让已经被升级的util-linux,e2fsprogs,e2fsprogs-libs,hal,hal-info暂时安装为测试分支版本。不过这也激起了我另一个想法，通过在package.keywords中遵循一定的写法，保留目前被安装为测试分支版本的软件，升级到稳定分支的可能。这是后话，有空再说。
根据网上一些文章的提示，我开始翻阅{kernel_source_dir}/Documentation/filesytems/vfat.txt，凭借着直觉，感觉问题是出在codepage,iocharset和utf8这三个mount option的指定上。
最终，我在网上找到了woody老兄的《 shortname以及自动挂载》，这篇文章通过分析有关源代码，详细介绍了hal和KDE相互作用挂载U盘的原理，虽然woody兄是为了解决shortname的问题，但是对于解决我的问题，原理上是一回事。
顺着被启迪的思路，经过了一番摸索，明白了codepage,iocharset和utf8之间的相互作用关系，加之Linuxsir.org上 newsky_兄的一点帮助，我最终怀疑问题的根源是在内核配置上。
下午，在加上CONFIG_FAT_DEFAULT_IOCHARSET="cp936"后，重新genkernel，重启，插入U盘，问题就解决了。
原来是

CONFIG_FAT_DEFAULT_CODEPAGE=936
CONFIG_FAT_DEFAULT_IOCHARSET="cp936"

这两项不能为空。
我在以前某次配置内核的时候，把CONFIG_FAT_DEFAULT_IOCHARSET=置空了。
如今，加上CONFIG_FAT_DEFAULT_IOCHARSET="cp936"，重新genkernel自然就OK了。
原来，mount的vfat的时候制定-o utf8会忽略codepage和iocharset的设置（我手工mount一个vfat试过，指定了iocharset以后，不指定utf8和指定 utf8的挂在效果是不一样的，在utf8的locale下，前者是乱码，后者就显示正常的汉字了），但是却必须指定这两个参数。如果不指定的话，就会提示no found。
可以在通过/etc/hal/fdi/policy/storage-vfat.fdi中merge key一个iocharset=cp936，来达到让hal层面了解如何制定codepage,iocharset和utf8，但是KDE4的 kdebase-runtime中的kioslave组件只能识别utf8挂载选项，不能识别 iocharset和codepage。
所以如果kernel中，如果忽略了CONFIG_FAT_DEFAULT_CODEPAGE
和 CONFIG_FAT_DEFAULT_IOCHARSET的设置，即是在hal中添加了codepage,iocharset和utf8，也导致KDE 挂载U盘的时候失败，因为hal仅提供设备属性（lshal能看到对应设备出现了iocharset和codepage属性），真正的挂载动作还是KDE 执行的，KDE的kioslave天生没有识别并指定iocharset和codepage的能力，在挂载的时候就永远不会指定iocharset和 codepage挂载参数，导致挂载失败，其中内核配置的时候哪个没设置，就会在dmesg中提示哪个no found。
终于我走出迷宫了。

最后

以上就是清新水壶为你收集整理的终于搞定U盘挂载的问题了！！的全部内容，希望文章能够帮你解决终于搞定U盘挂载的问题了！！所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。