This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 129966 - accessing fat32 windows disk oopses
accessing fat32 windows disk oopses
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Jones
:
: 121957 133919 (view as bug list)
Depends On:
Blocks: FC3Target FC4Target
  Show dependency treegraph
 
Reported: 2004-08-15 19:19 EDT by Don Hardaway
Modified: 2015-01-04 17:08 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-02 20:25:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
dmesg log (12.57 KB, text/plain)
2004-08-28 12:38 EDT, Don Hardaway
no flags Details
screen snapshot while list a vfat directory with CJK fonts in filenames (1.65 KB, text/plain)
2004-10-02 00:29 EDT, Ling Li
no flags Details
Konqueror driven vfat oops accessing dir with unicode pathname (5.53 KB, text/plain)
2004-11-23 10:52 EST, Jeff Pitman
no flags Details
here you go--somefile as you requested (37 bytes, text/plain)
2005-01-07 16:46 EST, Don Hardaway
no flags Details
Here you go (3.04 KB, text/plain)
2005-01-08 13:16 EST, Don Hardaway
no flags Details
Here you go (3.05 KB, text/plain)
2005-01-08 14:46 EST, Don Hardaway
no flags Details
copy of dmesg after hang (15.31 KB, text/plain)
2005-01-09 10:08 EST, Don Hardaway
no flags Details
universal vfat oopsing kit ;) (6.74 KB, application/x-gzip)
2005-01-09 15:25 EST, Barry K. Nathan
no flags Details

  None (edit)
Description Don Hardaway 2004-08-15 19:19:40 EDT
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:
Comment 1 Don Hardaway 2004-08-27 20:06:53 EDT
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??
Comment 2 Don Hardaway 2004-08-28 12:38:28 EDT
Created attachment 103207 [details]
dmesg log
Comment 3 Don Hardaway 2004-09-04 14:21:38 EDT
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.
Comment 4 Ling Li 2004-09-13 20:25:55 EDT
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.
Comment 5 Alexander Larsson 2004-10-01 04:41:07 EDT
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.
Comment 6 Don Hardaway 2004-10-01 06:20:07 EDT
I can access the fat32 from the command line also. It just will not
open directories using the gui approach.
Comment 7 Ling Li 2004-10-02 00:05:18 EDT
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.
Comment 8 Ling Li 2004-10-02 00:29:57 EDT
Created attachment 104661 [details]
screen snapshot while list a vfat directory with CJK fonts in filenames
Comment 9 Alexander Larsson 2004-10-04 03:39:48 EDT
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?
Comment 10 Don Hardaway 2004-10-04 08:16:55 EDT
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.
Comment 11 Alexander Larsson 2004-10-04 09:15:57 EDT
I bet thats related to some udev change. I've seen it mentioned on the
lists.
Comment 12 Alexander Larsson 2004-10-04 09:16:52 EDT
*** Bug 133919 has been marked as a duplicate of this bug. ***
Comment 13 Ling Li 2004-10-05 04:37:17 EDT
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.
Comment 14 Don Hardaway 2004-10-05 06:09:21 EDT
/dev/hda2   /media/idedisk    vfat noauto,user,exec,managed


Here is mine.
Comment 15 Alexander Larsson 2004-10-05 07:49:46 EDT
*** Bug 121957 has been marked as a duplicate of this bug. ***
Comment 16 Alexander Larsson 2004-10-05 07:52:24 EDT
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.
Comment 17 Don Hardaway 2004-10-08 12:38:31 EDT
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.
Comment 18 Rodger Wang 2004-10-08 21:31:35 EDT
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.
Comment 19 Don Hardaway 2004-10-19 11:50:59 EDT
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).
Comment 20 Ling Li 2004-10-31 01:59:57 EST
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.
Comment 21 Ling Li 2004-10-31 17:20:50 EST
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.
Comment 22 Wendell Fields 2004-11-14 17:30:42 EST
This is definitely a problem here too.
Comment 23 Don Hardaway 2004-11-14 19:18:59 EST
I have core 3 now with all updates and still have the problem.
Comment 24 Keith Wong 2004-11-20 21:16:16 EST
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
Comment 25 Jeff Pitman 2004-11-23 10:48:09 EST
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. 
 
Comment 26 Jeff Pitman 2004-11-23 10:52:02 EST
Created attachment 107306 [details]
Konqueror driven vfat oops accessing dir with unicode pathname
Comment 27 Jeff Pitman 2004-11-23 11:23:54 EST
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 
 
Comment 28 Jeff Pitman 2004-11-23 19:16:25 EST
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! 
Comment 29 Mark Huang 2004-12-12 01:56:29 EST
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 30 Jungshik Shin 2005-01-07 03:35:10 EST
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)
Comment 31 Nicolas Mailhot 2005-01-07 08:32:35 EST
A lot of people will prefer 850 to 437 anyway, so kicking 437 out of
the default config is good
Comment 32 Barry K. Nathan 2005-01-07 09:49:25 EST
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
Comment 33 Barry K. Nathan 2005-01-07 10:59:41 EST
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/
Comment 34 Barry K. Nathan 2005-01-07 16:09:50 EST
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...
Comment 35 Don Hardaway 2005-01-07 16:46:18 EST
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 ~]#
Comment 36 Barry K. Nathan 2005-01-07 17:26:20 EST
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.
Comment 37 Don Hardaway 2005-01-07 18:27:44 EST
It does not crash from the command line---only when using gui
Comment 38 Barry K. Nathan 2005-01-08 06:47:52 EST
Don, does running "find /mnt/hda2" crash or hang, or does it
successfully run?
Comment 39 Don Hardaway 2005-01-08 08:44:53 EST
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.
Comment 40 Don Hardaway 2005-01-08 08:46:44 EST
Sorry -- the mount instead was: mount /dev/hda2 /mnt/hda2 -t vfat
Comment 41 Barry K. Nathan 2005-01-08 09:37:24 EST
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.
Comment 42 Don Hardaway 2005-01-08 12:03:34 EST
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?
Comment 43 Barry K. Nathan 2005-01-08 12:25:04 EST
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.
Comment 44 Don Hardaway 2005-01-08 13:16:10 EST
Created attachment 109515 [details]
Here you go

Here is the somefile result.
Comment 45 Barry K. Nathan 2005-01-08 13:28:54 EST
Thank you! I'm looking at this now.
Comment 46 Barry K. Nathan 2005-01-08 14:11:22 EST
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.
Comment 47 Don Hardaway 2005-01-08 14:46:05 EST
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.
Comment 48 Barry K. Nathan 2005-01-08 17:25:06 EST
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.)
Comment 49 Don Hardaway 2005-01-08 17:32:34 EST
2.6.9-1.724_FC3 plus I have updated all other files.
Comment 50 Barry K. Nathan 2005-01-08 18:00:17 EST
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).
Comment 51 Don Hardaway 2005-01-09 10:08:38 EST
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
Comment 52 Barry K. Nathan 2005-01-09 13:16:27 EST
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.)
Comment 53 Don Hardaway 2005-01-09 14:11:49 EST
/dev/hda2 /mnt/hda2 vfat rw,nodiratime,fmask=0022,dmask=0022 0 0
Comment 54 Barry K. Nathan 2005-01-09 15:19:20 EST
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.
Comment 55 Barry K. Nathan 2005-01-09 15:25:49 EST
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.
Comment 56 Barry K. Nathan 2005-01-09 15:30:27 EST
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.
Comment 57 Don Hardaway 2005-01-09 15:48:43 EST
Do you need me to try anything else right now.
Comment 58 Barry K. Nathan 2005-01-09 16:33:46 EST
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.
Comment 59 Barry K. Nathan 2005-01-09 17:51:24 EST
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
Comment 60 Barry K. Nathan 2005-01-14 06:55:54 EST
Kernel 2.6.10-1.741_FC3 just came out, and it should fix this problem.
Comment 61 Dave Jones 2005-07-15 15:44:14 EDT
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.
Comment 62 Dave Jones 2005-10-02 20:25:44 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.