Bug 587126 - f13-beta can't mount 4G USB memory stick (fat)
f13-beta can't mount 4G USB memory stick (fat)
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
13
x86_64 Linux
low Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-28 21:05 EDT by Luming Yu
Modified: 2013-08-05 21:47 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-06-27 11:57:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Luming Yu 2010-04-28 21:05:30 EDT
f13-beta can't mount 4G USB memory stick (fat)


# dmesg | tail
sd 6:0:0:0: [sdb] Mode Sense: 23 00 00 00
sd 6:0:0:0: [sdb] Assuming drive cache: write through
sd 6:0:0:0: [sdb] Assuming drive cache: write through
 sdb: sdb1
sd 6:0:0:0: [sdb] Assuming drive cache: write through
sd 6:0:0:0: [sdb] Attached SCSI removable disk
FAT: count of clusters too big (65526)
VFS: Can't find a valid FAT filesystem on dev sdb1.
FAT: count of clusters too big (65526)
VFS: Can't find a valid FAT filesystem on dev sdb1.
# fdisk /dev/sdb

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
        switch off the mode (command 'c') and change display units to
        sectors (command 'u').

Command (m for help): p

Disk /dev/sdb: 4009 MB, 4009754624 bytes
256 heads, 63 sectors/track, 485 cylinders
Units = cylinders of 16128 * 512 = 8257536 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

  Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *           1         261     2097152    6  FAT16
Partition 1 has different physical/logical endings:
    phys=(1023, 255, 63) logical=(260, 17, 16)
Comment 1 Luming Yu 2010-04-28 21:20:26 EDT

C:\>chkdsk f:
The type of the file system is FAT.
Volume Serial Number is 003B-6562
Windows is verifying files and folders...
File and folder verification is complete.
Windows has checked the file system and found no problems.

2,147,123,200 bytes total disk space.
      262,144 bytes in 3 files.
2,146,861,056 bytes available on disk.

       32,768 bytes in each allocation unit.
       65,525 total allocation units on disk.
       65,517 allocation units available on disk.

C:\>
Comment 2 Stanislav Ochotnicky 2010-04-29 05:49:00 EDT
Just walking by...but I noticed that chkdisk reports ~2GB space whereas you claim the USB is 4GB. You have formatted only one half of it?

If you can, try to fill up the USB in Windows and see how much you can stuff in there...
Comment 3 Luming Yu 2010-04-29 07:47:33 EDT
(In reply to comment #2)
> Just walking by...but I noticed that chkdisk reports ~2GB space whereas you
> claim the USB is 4GB. You have formatted only one half of it?

I got the USB from my friends who told me it's 4GB. I don't know who formatted it.

> If you can, try to fill up the USB in Windows and see how much you can stuff in
> there...    

xp sees 2GB too, and can mount it. I belielve it just can stuff 2GB ..
Comment 4 Stanislav Ochotnicky 2010-04-29 08:01:22 EDT
Well, there have been numerous fake usb keys floating around claiming bigger size than what is actually there. But this usually happens with bigger sizes...

Notice that fdisk thinks that this is 4GB key too:
> Disk /dev/sdb: 4009 MB, 4009754624 bytes

Try to run:

dd if=/dev/zero of=/dev/USB_KEY_DEV bs=8192

And see how much data it can copy there before bailing. That is the real size of the device. You could then create partition that would end before this barrier and use at least part of this usb key that is available for real.
Comment 5 Luming Yu 2010-04-29 11:14:17 EDT
(In reply to comment #4)
> Well, there have been numerous fake usb keys floating around claiming bigger
> size than what is actually there. But this usually happens with bigger sizes...
> 
> Notice that fdisk thinks that this is 4GB key too:
> > Disk /dev/sdb: 4009 MB, 4009754624 bytes
> 
> Try to run:
> 
> dd if=/dev/zero of=/dev/USB_KEY_DEV bs=8192


Would it overwrite the fat file system meta data ? 

> 
> And see how much data it can copy there before bailing. That is the real size
> of the device. You could then create partition that would end before this
> barrier and use at least part of this usb key that is available for real.
Comment 6 Stanislav Ochotnicky 2010-04-29 11:26:03 EDT
(In reply to comment #5)
> (In reply to comment #4)
> > Well, there have been numerous fake usb keys floating around claiming bigger
> > size than what is actually there. But this usually happens with bigger sizes...
> > 
> > Notice that fdisk thinks that this is 4GB key too:
> > > Disk /dev/sdb: 4009 MB, 4009754624 bytes
> > 
> > Try to run:
> > 
> > dd if=/dev/zero of=/dev/USB_KEY_DEV bs=8192
> 
> 
> Would it overwrite the fat file system meta data ? 

Not only that...it would completely wipe whole drive. I apologize for not warning you...back-up your data first obviously.
Comment 7 Luming Yu 2010-04-29 11:41:45 EDT
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > Well, there have been numerous fake usb keys floating around claiming bigger
> > > size than what is actually there. But this usually happens with bigger sizes...
> > > 
> > > Notice that fdisk thinks that this is 4GB key too:
> > > > Disk /dev/sdb: 4009 MB, 4009754624 bytes
> > > 
> > > Try to run:
> > > 
> > > dd if=/dev/zero of=/dev/USB_KEY_DEV bs=8192
> > 
> > 
> > Would it overwrite the fat file system meta data ? 
> 
> Not only that...it would completely wipe whole drive. I apologize for not
> warning you...back-up your data first obviously.    

then we would wipe the bug if I can't figure out how to build same file system on the memory stick.
Comment 8 Stanislav Ochotnicky 2010-04-29 12:05:13 EDT
> then we would wipe the bug if I can't figure out how to build same file system
> on the memory stick.    

If it's really a non-hw problem..yes. But you can also do reverse to backup you whole drive first:

dd if=/dev/USB_KEY_DEV of=/dev/key_backup bs=8192
Comment 9 Stanislav Ochotnicky 2010-04-29 12:06:15 EDT
eh...the "of" path is probably not in /dev/ :-) Put it in your home, or somewhere safe...
Comment 10 Jan Kratochvil 2010-04-29 12:22:47 EDT
(In reply to comment #4)
> dd if=/dev/zero of=/dev/USB_KEY_DEV bs=8192
(In reply to comment #8)
> dd if=/dev/USB_KEY_DEV of=/dev/key_backup bs=8192    

Why not just
  cat /dev/zero >/dev/USB_KEY_DEV
  cat /dev/USB_KEY_DEV >/tmp/key_backup
Linux kernel can handle block-unaligned accesses fine (contrary to some Unices).
Comment 11 Bug Zapper 2011-06-02 10:44:21 EDT
This message is a reminder that Fedora 13 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 13.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '13'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 13's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 13 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 12 Bug Zapper 2011-06-27 11:57:08 EDT
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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