Bug 465753

Summary: Failure of vol_id to retrieve info abot a SD card
Product: [Fedora] Fedora Reporter: Ignacio Vazquez-Abrams <ivazqueznet>
Component: udevAssignee: Harald Hoyer <harald>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: medium    
Version: 8CC: harald, kay.sievers
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-10-07 04:42:34 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Attachments:
Description Flags
First megabyte of the partition on the SD card
none
New image from SD after transfering image none

Description Ignacio Vazquez-Abrams 2008-10-06 05:05:05 EDT
Created attachment 319529 [details]
First megabyte of the partition on the SD card

Description of problem:
Using vol_id to retrieve information about the first partition of a 2GB Secure Digital card fails with "unknown volume type". The card is plugged into a UMS reader, and the partition being checked is formatted vfat with 32-bit FATs and 1024-byte sectors.

Version-Release number of selected component (if applicable):
udev 118, udev 127

How reproducible:
Every time

Steps to Reproduce:
1. Run /lib/udev/vol_id against a SD card in a UMS reader (mine, preferably)
2. Note failure
  
Actual results:
"unknown volume type"

Expected results:
Info about the SD card

Additional info:
strace shows that the card is being read, it just isn't being processed properly. I have attached the first megabyte of the data in the partition.
Comment 1 Harald Hoyer 2008-10-06 05:08:49 EDT
kay, any comments on that?
Comment 2 Kay Sievers 2008-10-06 06:17:07 EDT
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?
Comment 3 Ignacio Vazquez-Abrams 2008-10-06 07:20:55 EDT
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.
Comment 4 Kay Sievers 2008-10-06 07:49:11 EDT
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"?
Comment 5 Ignacio Vazquez-Abrams 2008-10-06 08:43:01 EDT
(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.
Comment 6 Kay Sievers 2008-10-06 09:43:04 EDT
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
Comment 7 Ignacio Vazquez-Abrams 2008-10-06 10:02:34 EDT
(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.
Comment 8 Kay Sievers 2008-10-06 10:44:47 EDT
(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
Comment 9 Harald Hoyer 2008-10-06 11:04:25 EDT
how about adding an empty fs image as a compressed attachement? shouldn't be very big.
Comment 10 Ignacio Vazquez-Abrams 2008-10-06 11:17:30 EDT
(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?
Comment 11 Kay Sievers 2008-10-06 11:49:40 EDT
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?
Comment 12 Ignacio Vazquez-Abrams 2008-10-06 12:02:41 EDT
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?
Comment 13 Kay Sievers 2008-10-06 12:25:17 EDT
Can you run vol_id on the exact same image you attached here?
Comment 14 Ignacio Vazquez-Abrams 2008-10-06 12:42:42 EDT
(In reply to comment #13)
> Can you run vol_id on the exact same image you attached here?

sd.img: unknown volume type
Comment 15 Kay Sievers 2008-10-06 17:08:17 EDT
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!
Comment 16 Ignacio Vazquez-Abrams 2008-10-07 01:33:50 EDT
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.
Comment 17 Kay Sievers 2008-10-07 02:42:10 EDT
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?
Comment 18 Ignacio Vazquez-Abrams 2008-10-07 04:42:34 EDT
Urk. LOTS of non-zeros. Including the old FAT. Alright, bad media. Thanks for helping me out here.