From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Description of problem:
I have successfully mounted with read/write permission my second hard
disk with windows on it in the past. Now when i mount it and try to
access it through on the deck top it seems to hang when clicking the
folders on the fat32 drive. It opens a popup window that says: Opening
"Documents and Settings", You can stop this operation by clicking
cancel.-----It just hangs there and never opens the folder.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.mount /dev/hda2 /mnt/hda2 -t vfat -o,rw,umask=2220
2.click open the hda2 foler under /mnt
Actual Results: hangs and never opens the folder
Expected Results: it would open and display the contents of the folder
Just updated all files (kernel-2.6.8-1.526) and tried to access my
fat32 disk again. used: mount -t vfat /dev/hda2 /mnt/hda2 and it does
not work. When i get to the directory where all of my files are and
try clicking it to open its says: Opening "Documents and Settings".You
can stop this operation by clicking cancel.
And hangs there. What can I do??
Created attachment 103207 [details]
just tried accessing my fat32 disk from linux and again no luck. I am
using kernel-2.6.8-1.521. Something changed in the newer kernel where
i can no longer access the fat32 disk. I used to be about to do it by
using this command. mount /dev/hda2 /mnt/hda2 -t vfat -o,rw,umask=2220.
This is a big problem. Please let me know what to do.
I have this problem with two ThinkPad laptops. The kernel is
2.6.8-1.521 (i686). Neither command line nor nautilus can list the
content of fat32 disk. Sometimes it can access the "root" directory,
but not the sub-directories.
Seems very similar to bug 133919, and it seems the kernel is somehow
involved. However, in bug 133919, people claim access from the command
like works, but Ling here says that is borken too.
I can access the fat32 from the command line also. It just will not
open directories using the gui approach.
I can confirm that the command line can work on _some_ directories,
but not for all (as I said before). Without even using nautilus, I got
a segmentation fault when list the content of one directory. That one
contains mixture of text files and binary files, and some files have
CJK characters in the filenames. I guess the CJK characters might be
one reason, since several directories that have them failed the kernel.
Created attachment 104661 [details]
screen snapshot while list a vfat directory with CJK fonts in filenames
Oh. I think i know what is happening. It seems to be a bug in filename
charset conversion. It might be related to the iocharset specified,
and the exact filenames in the folders.
How is the filesystem mounted in /etc/fstab?
Since my last posting I have done a clean install of test 2 core 3 and
then updated all the files to the latest. Before I updated all the
files I got the same problem with test 2 core 3 as i did with core 2.
After updating all files i now can not boot---it hangs at a point and
says setting kernel parameters. I will go in with rescue and try to
get the info you requested in the fstab. But I just wanted to report
the problem seems to be present in the upcoming core 3 release also.
I bet thats related to some udev change. I've seen it mentioned on the
*** Bug 133919 has been marked as a duplicate of this bug. ***
It is /dev/hda8, or /mnt/dosd, in my /etc/fstab:
/dev/hda8 /mnt/dosd vfat noauto,user 0 0
I used to have noatime.
/dev/hda2 /media/idedisk vfat noauto,user,exec,managed
Here is mine.
*** Bug 121957 has been marked as a duplicate of this bug. ***
No iocharset in the mount lines. However, this still does look like
its related to encoding of files on the filesystem. And given the
kernel oops and the problem in the console this is a kernel bug.
I just updated to the latest files. kernel-2.6.8-1.603. I click my
other disk's icon and it opens a window showing all of my folders and
when i click to open a folder i get the same old message: Opening
"Documents and Settings". It says you can cancel the operation by
clicking cancel. Even if you do when you shutdown it shows that it is
still trying to access my windows disk. This problem is significant.
I hope someone will fix it before core 3 comes out.
It's exactly the same case with me as Don's. It seems that
kernel-2.6.8-1.603 is not intended for this bug fix. I agree with
Don's comment on the significance because anybody who wants to migrate
from windows to Linux would be detered.
I have the latest files as of today and someone needs to fix this
problem. I can not imagine going out with core 3 with this problem not
fixed. Windows disks are on 95% of the PCs in the world and people
wanting to use linux will likely need to access their windows disk
partitions (mine is fat32 for that reason).
I tried with '-o utf8' on a remote box and the command line test
didn't give any errors. I will try this and isocharset with nautilus
on my laptop tomorrow.
Nautilus works well with -o utf8 or -iocharset=utf8.
To compare the behavior of kernel 2.4 and 2.6 on vfat fs:
2.4 (without iocharset or utf8): warning that some unicode cannot be
2.6 (without iocharset or utf8): hang up or core dump.
This is definitely a problem here too.
I have core 3 now with all updates and still have the problem.
I have the same problem with a fresh install of Fedora Core 3, updated
to kernel 2.6.9-1.668_FC3smp.
I can open the FAT32 partition using Nautilus, but opening any
subdirectories fails. A dialog box appears "Cancel open? Opening
<directory name>. You can stop this operation by clicking cancel"
My /etc/fstab entry reads:
"/dev/hdb1 /mnt/windrv vfat
noauto,users,rw 0 0"
I can view the directories using the command line, and open documents
eg pdf files.
CJK is definitely a problem. The OOPS says uni2char is barfing on
something and it only dies on certain directories that have unicode
characters. With konqueror, the whole app just crashes when trying
to go into a directory with a specially crafted filename. I'm
running 2.6.9-1.6_FC2. It seems to have been introduced around 2.6.6
or so. Fedora JP seems to have hit this too:
I use Chinese myself.
Options for autofs:
Tried uni_xlate, which can also oops. I'll attach my stack trace as
it seems to be different from others I have seen here.
Created attachment 107306 [details]
Konqueror driven vfat oops accessing dir with unicode pathname
Interesting tidbit: uni2char is implemented in each NLS codepage. See
Comments from nls code:
* Generated automatically from the Unicode and charset
* tables from the Unicode Organization (www.unicode.org).
Comments from uni16_to_x8:
38 * filenames. We could get into some trouble with long Unicode
39 * but ignore that right now.
If someone could run through the different codepages with iocharset,
it possibly can be narrowed down. From the mount man page:
Character set to use for converting between 8 bit
and 16 bit Unicode characters. The default is
filenames are stored on disk in Unicode format
I have discovered that the difference between 2.6.5 and 2.6.8/2.6.9
is that nls_cp437.ko is missing which is the DOSLatinUS codepage and
gets loaded when mounting a vfat fs along with nls_utf8.ko. I think
the config needs to be re-checked to see if this codepage is
configured in the system. I have a FC2 with 2.6.5 that works fine
Nonetheless, the kernel should handle the error when a codepage
module doesn't exist! But, that won't be done unless this issue is
made visible on lkml. I don't have time to get into that...:(
Please check the kernel config on 2.6.8+ kernels. Thanks!
Same oops as everyone else with kernel-2.6.8-1.681_FC3 when I try to
list a VFAT directory with Unicode characters in it. If I mount with
-o iocharset=iso8859-1,codepage=850 then the oops no longer occurs.
comment #28 is right on. By default codepage 437 is assumed, but
nls_cp437.ko is missing. To work around the problem, one can specify
'codepage=949' (for Korean), 'codepage=936' (for Simplified Chinese),
'codepage=932' (for Japanese), 'codepage=950' (for Traditional
Chinese) at the command line :
$ mount -t vfat -o codepage=949,utf8 /dev/sda1 /media/FlashDisk
(if you're mounting a usb memory stick with VFAT in codepage 949)
A lot of people will prefer 850 to 437 anyway, so kicking 437 out of
the default config is good
At least with 2.6.9-1.724_FC3, nls_cp437.ko is missing because it's
built right into the kernel:
Right now I'm still in the process of figuring out how I'm going to
reproduce this. In the meantime, could anyone who is having this bug
try 2.6.10-1.727_FC3 and let us know if it still happens?
I'd appreciate if someone could do the following:
1. mount the crashing fat32 filesystem with the "utf8" option
2. ls --color=none -1 /some/crashing/directory > somefile
(that is, run "ls --color=none -1" on some directory that usually
crashes without mounting as "utf8")
3. look at the contents of "somefile" to make sure there's nothing
confidential in there
4. attach "somefile" to this bug
Basically, CJK filenames alone aren't enough to make it oops. I think
there must be something else triggering the oops (either number of
files or some specific property of the file names, or both) -- and I
don't have enough information right now to guess what it might be. So
right now I have no way of triggering the oops. :(
If all else fails, I could create a special debugging kernel which
would give me more information that I could use to create a second
special debugging kernel which would give me some more information
which might let me figure out what's causing this crash. However, it
would be better if I just had a way of crashing one of my own computers...
Created attachment 109499 [details]
here you go--somefile as you requested
Also, if I mount using -t vfat without any options it hangs but when I mounted
the windows drive using -o utf8 I am able to clink into folders normally. Also
this mount command worked: mount /dev/hda2 /mnt/hda2 -o
iocharset=iso8859-1,codepage=850 -t vfat
Here is another problem with working with the windows drive. When trying to
umount it it does this:
[root@localhost ~]# umount /mnt/hda2
umount: /mnt/hda2: device is busy
umount: /mnt/hda2: device is busy
Don, quoting from one of your earlier comments:
> I can access the fat32 from the command line also. It just will not
> open directories using the gui approach.
I need output from a directory that usually crashes *from the command
line*. Sorry; I should have made that clear.
It does not crash from the command line---only when using gui
Don, does running "find /mnt/hda2" crash or hang, or does it
Ok, I mounted the fat32 drive with this command: mount/dev/hda2
Then I typed in: find /mnt/hda2 -- it listed bunches of files and
directories until it got the the main windows directory /mnt/hda2/winnt
Then it just hung.
Sorry -- the mount instead was: mount /dev/hda2 /mnt/hda2 -t vfat
Ok. What I'd like you to do is to reboot (if you haven't already done
so), then "mount /dev/hda2 /mnt/hda2 -t vfat" and "ls
/mnt/hda2/winnt", and see if that hangs. If it does, then reboot again
(sorry about this), and repeat my instructions from comment 34, using
"/mnt/hda2/winnt" as "/some/crashing/directory".
1. mounted driving using: "mount /dev/hda2 /mnt/hda2 -t vfat"
2. exited as root and then did as normal user: "ls /mnt/hda2/winnt"
3. got a segmentation fault message
4. rebooted and remount drive using same command
5. did "ls --color=none -1 /mnt/hda2/winnt > somefile"
6. got another segmentation fault message
In step 4 you need to use the "utf8" option when mounting (that should
prevent the segmentation fault). Again, I'm sorry if I wasn't clear
enough in my last comment.
Created attachment 109515 [details]
Here you go
Here is the somefile result.
Thank you! I'm looking at this now.
Don, would you mind trying again one last time? This time, with the
following ls command instead:
ls --color=none -1f /mnt/hda2/winnt > somefile
Created attachment 109520 [details]
Here you go
I used: ls --color=none -1f /mnt/hda2/winnt > somefile
Sure hope you can fix this. I don't the millions of windows users moving to
linux until they can access their windows disk.
Unfortunately I'm still having trouble trying to reproduce this bug --
but at least I don't need you to repeat those steps again. :) This
doesn't mean I'm completely at a dead end, just that I need to think a
bit more about how to proceed next.
Just to make sure I understand the situation completely, what version
of the kernel are you running? (Run "uname -r" if you are not sure.)
2.6.9-1.724_FC3 plus I have updated all other files.
Would you mind trying 2.6.10-1.727_FC3? It's a test kernel available here:
If it still has the problem, then once the problem (freeze or
segmentation fault) happens, save the output of "dmesg" to a file and
attach that file to this bug. The 727 kernel has extra debugging code
in it, so it may be able to give more information in dmesg (*after*
the freeze or crash happens).
Created attachment 109530 [details]
copy of dmesg after hang
I mounted using: "mount /dev/hda2 /mnt/hda2 -t vfat". Then I clicked into the
fat32 disk from gui and got the same hang as before.
The kernel version I used was 2.6.10-1.736_FC3
Ok, now I think I'm reproducing it. :) (The final "somefile"
attachment was vital to doing this, and your last "dmesg" helped too.)
Don, just so I can be sure that I'm hitting the same bug, I'd like you
do the following:
1. "mount /dev/hda2 /mnt/hda2 -t vfat"
2. "cat /proc/mounts | fgrep hda2"
3. Copy the output of step 2 and paste it into an additional comment
to this bug (that is, copy and paste the output rather than attaching
it). I think it should only be one line of text (or maybe two) -- it
should be pretty short.
Even if it's not the same bug, what I'm hitting at this point is still
a bug involving Unicode filenames on FAT partitions. (Not necessarily
FAT32 -- all FAT.)
/dev/hda2 /mnt/hda2 vfat rw,nodiratime,fmask=0022,dmask=0022 0 0
Hmmm.... If I mount my test disk image like that, then I don't get the
oops. However, what I am doing to get the oops (see my next
attachment/comment) is giving me one that's amazingly similar to yours.
Created attachment 109539 [details]
universal vfat oopsing kit ;)
This *should* allow other kernel developers to reproduce this oops.
Instructions for use:
1. zcat oops.144.gz > oops.144 (or some other method of decompressing)
2a. mount -o loop,ro,uni_xlate oops.144 /mnt/wherever
(use utf8 instead of uni_xlate if you don't want the kernel to oops)
3. (for example) ls /mnt/wherever/oopsoops, or find /mnt/wherever/oopsoops,
Right now I'm compiling a vanilla 2.6.10 kernel for my test box. Once that
finishes I will test that -- that way I will know whether I need to push this
Oops, typo, step "2a" should just be "2". And arguably I forgot this
0. Click (or otherwise select) the attachment download link and save
it as "oops.144.gz".
Sorry about that.
Do you need me to try anything else right now.
No, the instructions (and attachment) I just posted are for people who
have not seen this problem yet but who need to. For now (and maybe
until a fix is developed) there's nothing more you need to do.
I might have some more news later today, probably in the next few hours.
I can reproduce this bug on both 2.6.10 and 2.6.10-bk12, so I have now
filed an upstream bug report:
Kernel 2.6.10-1.741_FC3 just came out, and it should fix this problem.
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which
may contain a fix for your problem. Please update to this new kernel, and
report whether or not it fixes your problem.
If you have updated to Fedora Core 4 since this bug was opened, and the problem
still occurs with the latest updates for that release, please change the version
field of this bug to 'fc4'.
This bug has been automatically closed as part of a mass update.
It had been in NEEDINFO state since July 2005.
If this bug still exists in current errata kernels, please reopen this bug.
There are a large number of inactive bugs in the database, and this is the only
way to purge them.