From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040706 Firefox/0.9.1 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): kernel-2.6.7-1.517 How reproducible: Always Steps to Reproduce: 1.mount /dev/hda2 /mnt/hda2 -t vfat -o,rw,umask=2220 2.click open the hda2 foler under /mnt 3. Actual Results: hangs and never opens the folder Expected Results: it would open and display the contents of the folder Additional info:
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] dmesg log
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 lists.
*** 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 converted. 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. Keith
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: http://translate.google.com/translate?hl=en&sl=ja&u=http://bbs.fedora.jp/read.php%3FFID%3D3%26TID%3D90&prev=/search%3Fq%3Duni16_to_x8%2B2.6%26hl%3Den%26lr%3D%26ie%3DUTF-8%26safe%3Dactive%26sa%3DG I use Chinese myself. Options for autofs: usb -fstype=auto,user,uid=jeff,gid=win,umask=000 :/dev/sda1 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 http://lxr.linux.no/ident?v=2.6.8.1;i=uni2char 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 names, 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: iocharset=value Character set to use for converting between 8 bit characters and 16 bit Unicode characters. The default is iso8859-1. Long 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 without oopses. 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: CONFIG_NLS_CODEPAGE_437=y
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? http://people.redhat.com/davej/kernels/Fedora/FC3/
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 [root@localhost ~]#
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 successfully run?
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". Thanks.
Ok, 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 What now?
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 Thank you.
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: http://people.redhat.com/davej/kernels/Fedora/FC3/ 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, or... 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 issue upstream.
Oops, typo, step "2a" should just be "2". And arguably I forgot this step too: 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: http://bugme.osdl.org/show_bug.cgi?id=4013
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'. Thank you.
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. Thank you.