Bug 465753

kay, any comments on that?

Looks like an invalidly formatted FAT32. We expect the fsinfo sector to be valid, which isn't:
  fat.c: fat_size 0x77e
  fat.c: cluster_count 0x3be24
  fat.c: looking for FAT32
  util.c: get buffer off 0x400(1024), len 0x200
  fat.c: signature1: 0x00000000
  fat.c: signature2: 0x00000000

A valid mkdosfs formatted volume shows here:
  fat.c: fat_size 0xf4a
  fat.c: cluster_count 0x3d26b
  fat.c: looking for FAT32
  util.c: get buffer off 0x200(512), len 0x200
  fat.c: signature1: 0x52526141
  fat.c: signature2: 0x72724161
  fat.c: FAT32 signatures match

Which tool formatted the volume? Can you try to reformat it, and try again?

It was formatted with dosfstools 2.11:

mkfs -t vfat -F 32 -S 1024 /dev/sde1

The partition is not mountable if 512-byte sectors are used.

Reformatting yet again, with or without -F or -S, made no difference in the vol_id output.

Hmm, that is weird. I can do this on SUSE (there are no patches for dosfsutils):

  $ mkfs -t vfat -v -n lalala -F 32 -S 1024 /dev/sdc1
  mkfs.vfat 2.11 (12 Mar 2005)
  /dev/sdc1 has 32 heads and 62 sectors per track,
  logical sector size is 1024,
  using 0xf8 media descriptor, with 1003873 sectors;
  file system has 2 32-bit FATs and 8 sectors per cluster.
  FAT size is 490 sectors, and provides 125357 clusters.
  Volume ID is 48e9fa35, volume label lalala     .

  $ /lib/udev/vol_id /dev/sdc1
  ID_FS_USAGE=filesystem
  ID_FS_TYPE=vfat
  ID_FS_VERSION=FAT32
  ID_FS_UUID=48E9-F9E6
  ID_FS_UUID_ENC=48E9-F9E6
  ID_FS_LABEL=lalala
  ID_FS_LABEL_ENC=lalala

How large is your volume?

Do you have a 32 or 64 bit system?

Can you provide the output of "mkfs" with "-v"?

(In reply to comment #4)
> How large is your volume?

It's a 2GB SD card.

> Do you have a 32 or 64 bit system?

It's a 32-bit system:

uname -rm
2.6.26.3-14.fc8 i686

> Can you provide the output of "mkfs" with "-v"?

# mkfs -t vfat -v -F 32 -S 1024 /dev/sde1
mkfs.vfat 2.11 (12 Mar 2005)
/dev/sde1 has 62 heads and 62 sectors per track,
logical sector size is 1024,
using 0xf8 media descriptor, with 1964222 sectors;
file system has 2 32-bit FATs and 8 sectors per cluster.
FAT size is 959 sectors, and provides 245284 clusters.
Volume ID is 48ea078a, no volume label.

I downloaded:
  ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/dosfstools/

I unpacked the i386 binary:
  ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/dosfstools/dosfstools-2.11.i386.tar.gz

and mkdosfs still works fine here. Do you mind trying that, just to see if your Fedora mkdosfs is broken?

Or maybe, if that works on your box, try the current 3.0 version:
  ftp://fedora.bu.edu/development/i386/os/Packages/dosfstools-3.0.0-1.fc10.i386.rpm

(In reply to comment #6)
> ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/dosfstools/dosfstools-2.11.i386.tar.gz
> 
> and mkdosfs still works fine here. Do you mind trying that, just to see if your
> Fedora mkdosfs is broken?

[root@ignacio dosfstools-2.11]# sbin/mkfs.msdos -v -F 32 -S 1024 /dev/sde1
mkfs.msdos 2.11 (12 Mar 2005)
/dev/sde1 has 62 heads and 62 sectors per track,
logical sector size is 1024,
using 0xf8 media descriptor, with 1964222 sectors;
file system has 2 32-bit FATs and 8 sectors per cluster.
FAT size is 959 sectors, and provides 245284 clusters.
Volume ID is 48ea196b, no volume label.
[root@ignacio dosfstools-2.11]# /lib/udev/vol_id -t /dev/sde1
/dev/sde1: unknown volume type

> Or maybe, if that works on your box, try the current 3.0 version:
>  
> ftp://fedora.bu.edu/development/i386/os/Packages/dosfstools-3.0.0-1.fc10.i386.rpm

[root@ignacio dosfstools-3.0.0]# sbin/mkfs.msdos -v -F 32 -S 1024 /dev/sde1
mkfs.msdos 3.0.0 (28 Sep 2008)
/dev/sde1 has 62 heads and 62 sectors per track,
logical sector size is 1024,
using 0xf8 media descriptor, with 1964222 sectors;
file system has 2 32-bit FATs and 8 sectors per cluster.
FAT size is 959 sectors, and provides 245284 clusters.
Volume ID is 48ea19a6, no volume label.
[root@ignacio dosfstools-3.0.0]# /lib/udev/vol_id -t /dev/sde1
/dev/sde1: unknown volume type

Nothing.

Perhaps it would be pertinent to mention that blkid (e2fsprogs) retrieves the volume info just fine.

(In reply to comment #7)
> (In reply to comment #6)
> > ftp://ftp.uni-erlangen.de/pub/Linux/LOCAL/dosfstools/dosfstools-2.11.i386.tar.gz
> > 
> > and mkdosfs still works fine here. Do you mind trying that, just to see if your
> > Fedora mkdosfs is broken?
> Volume ID is 48ea196b, no volume label.
> [root@ignacio dosfstools-2.11]# /lib/udev/vol_id -t /dev/sde1

> /dev/sde1: unknown volume type
> 
> > Or maybe, if that works on your box, try the current 3.0 version:
> >  
> > ftp://fedora.bu.edu/development/i386/os/Packages/dosfstools-3.0.0-1.fc10.i386.rpm

> [root@ignacio dosfstools-3.0.0]# /lib/udev/vol_id -t /dev/sde1
> /dev/sde1: unknown volume type
> 
> Nothing.

Now it's getting interesting, we run the same binaries, but get different images? You can mount the created FAT volume and write to, right?
 
> Perhaps it would be pertinent to mention that blkid (e2fsprogs) retrieves the
> volume info just fine.

Yeah, sure, it never has a problem detecting "something" as a FAT volume. :)
  $ mkswap /dev/sdb1
  Setting up swapspace version 1, size = 1027960 kB
  no label, UUID=04496461-77f3-470a-9749-a49e70ab8668

  $ blkid /dev/sdb1
  /dev/sdb1: LABEL="lalila" UUID="48EA-0DCC" TYPE="vfat" 

  $ /lib/udev/vol_id /dev/sdb1
  ID_FS_USAGE=other
  ID_FS_TYPE=swap
  ID_FS_VERSION=2
  ID_FS_UUID=04496461-77f3-470a-9749-a49e70ab8668
  ID_FS_UUID_ENC=04496461-77f3-470a-9749-a49e70ab8668

how about adding an empty fs image as a compressed attachement? shouldn't be very big.

(In reply to comment #8)
> Now it's getting interesting, we run the same binaries, but get different
> images? You can mount the created FAT volume and write to, right?

# mount /dev/sde1 /mnt/loop
# echo foo > /mnt/loop/bar
# umount /dev/sde1
# mount /dev/sde1 /mnt/loop
# cat /mnt/loop/bar 
foo
# umount /dev/sde1
# mount /dev/sde1 /mnt/loop
# mount | grep sde1
/dev/sde1 on /mnt/loop type vfat (rw)

(In reply to comment #9)
> how about adding an empty fs image as a compressed attachement? shouldn't be
> very big.

Will https://bugzilla.redhat.com/attachment.cgi?id=319529 do, or should I pull a fresh one off?

We have already an image, that should be fine.

Hmm, let's try without the device, but a 2GB sparse file:
  $ dd if=/dev/zero of=2gb.img bs=1 seek=2147483648 count=1
  1+0 records in
  1+0 records out
  1 byte (1 B) copied, 0.000137866 s, 7.3 kB/s

  $ ls -lh 2gb.img
  -rw-r--r-- 1 root root 2.1G 2008-10-06 17:47 2gb.img

  $ mkfs.vfat 2gb.img
  mkfs.vfat 2.11 (12 Mar 2005)

  $ /lib/udev/vol_id 2gb.img
  ID_FS_USAGE=filesystem
  ID_FS_TYPE=vfat
  ID_FS_VERSION=FAT32
  ID_FS_UUID=48EA-32F4
  ID_FS_UUID_ENC=48EA-32F4

What does that do on your box?

Those commands result in pretty much the same results, except a different UUID and extra lines:
ID_FS_LABEL=
ID_FS_LABEL_ENC=
ID_FS_LABEL_SAFE=

At this point I'm thinking that this may be a UMS issue, even though I don't see any messages in the system log. Is there anyone we can call on to help diagnose the hardware?

Can you run vol_id on the exact same image you attached here?

(In reply to comment #13)
> Can you run vol_id on the exact same image you attached here?

sd.img: unknown volume type

So for some strange reason, mkdosfs creates this "invalid" image on your card but not on a simple file. I have no good idea what is going wrong here.

Can you copy a whole image to the card, just to try if applying the format to the card fails? Here is what gives you the exact same output for a file like you got for your card:

  $ dd if=/dev/zero of=2gb.img bs=1 seek=2011363327 count=1
  1+0 records in
  1+0 records out
  1 byte (1 B) copied, 0.000103016 s, 9.7 kB/s


  $ mkfs.vfat -v -F 32 -S 1024 2gb.img
  mkfs.vfat 2.11 (12 Mar 2005)
  2gb.img has 64 heads and 32 sectors per track,
  logical sector size is 1024,
  using 0xf8 media descriptor, with 1964222 sectors;
  file system has 2 32-bit FATs and 8 sectors per cluster.
  FAT size is 959 sectors, and provides 245284 clusters.
  Volume ID is 48ea7d79, no volume label.

The simply dd this file to the card, and try to mount it to see if it works, and run vol_id on it. Thanks!

Created attachment 319616 [details]
New image from SD after transfering image

Uh...

This is WEIRD...

I created the FS image and checked it with vol_id. All good.

Then I transferred it to the card and checked it. Failure.

Then I pulled it off and checked it. Failure.

First megabyte attached. I'm going to grab the other card I got at the same time and check that out.

Yeah, there seems something wrong with the reader, or the card.

While the image should have like the first 16kB filled with data, the rest zeros, the image you sent, has the entire first 64kb a repeating pattern of  "* ff ff ff ff ff ff ff ff ff f0 00 00 00 00 00 00 00 00 00 *", which might indicate a broken flash card, or the reader is going crazy.

If you:
  dd if=/dev/zero of=/dev/<card>

and fill the whole card with zeros, does:
  hexdump -C /dev/<card>

print something other than zeros?

Urk. LOTS of non-zeros. Including the old FAT. Alright, bad media. Thanks for helping me out here.