[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#353400: marked as done (linux-image-2.6.12-1-686-smp: acorn.c's adfs_check_CUMANA can give a false positive on a vfat disk)



Your message dated Mon, 3 Apr 2006 20:34:02 -0700 (PDT)
with message-id <Pine.LNX.4.63.0604032028090.3430@bobcat>
and subject line acorn.c's adfs_check_CUMANA can give a false positive on a vfat disk
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: linux-image-2.6.12-1-686-smp
Version: 2.6.12-6
Severity: normal


I have a USB drive I just bought, and it didn't work when I plugged it
in.  mount complains:

mount -t vfat /dev/sda1 /mnt
mount: wrong fs type, bad option, bad superblock on /dev/sda1,
       or too many mounted file systems

dmesg says:

FAT: invalid media value (0xb9)
VFS: Can't find a valid FAT filesystem on dev sda1.

Google finds a lot of people who have had this problem, but nobody who
has tracked down the root cause.  dd'ing over the beginning of the
disk, repartitioning, and reformating works around the bug, but this
is not obvious.  This bug report explains why.  Hopefully this bug
will get fixed now, since it does not seem to be an uncommon problem.

The problem is that acorn.c:adfs_check_CUMANA, which is called from
check.c:check_partition before msdos.c:msdos_partition, thinks the
disk is an acorn disk.  The check method is naive, and has this
comment in it:

	/*
	 * Try Cumana style partitions - sector 6 contains ADFS boot block
	 * with pointer to next 'drive'.
	 *
	 * There are unknowns in this code - is the 'cylinder number' of the
	 * next partition relative to the start of this one - I'm assuming
	 * it is.
	 *
	 * Also, which ID did Cumana use?
	 *
	 * This is totally unfinished, and will require more work to get it
	 * going. Hence it is totally untested.
	 */

In the case of my disk, sector 6 contains
0,1,2,...,254,255,0,1,2,...,254,255.  It turns out that this sequence
of bytes passes the check for an ADFS boot block.  And for whatever
reason, it seems like some USB drive vendors put this pattern between
the partition table and the fat partition.  This causes linux not to
handle these USB drives properly.

Sure enough, modifying the last byte of block 6 to have 0 instead of
255 causes linux to see the drive perfectly.

(As a side note, if check_partition was named check_partition_table, I
would have found this a lot faster.)


This leads to the question of the fix.  Ideally, the adfs_check_CUMANA
method would be made a lot smarter about figuring out what's a Cumana
partition table.  However, this would require finding docs which
explain this format.  Google was not immediately helpful.

Moving acorn below msdos would also fix the problem, but check.c has
this comment right before the acorn checks:

	/*
	 * Now move on to formats that only have partition info at
	 * disk address 0xdc0.  Since these may also have stale
	 * PC/BIOS partition tables, they need to come before
	 * the msdos entry.
	 */

IMHO, if I had to choose between an ambiguity between an acorn disk
and an msdos disk, I'd choose the latter, because there are a heck of
a lot more vfat disks out there than acorn disks.

The last option which comes to mind is a hack, but would seem to solve
the immediate problem and be easy to implement.  If the block contains
the same contents that mine does, then -1 from the check function.
There is precedent for this sort of hack, in adfs_fs.h:

/*
 * Calculate the boot block checksum on an ADFS drive.  Note that this will
 * appear to be correct if the sector contains all zeros, so also check that
 * the disk size is non-zero!!!
 */

(Why this method is inlined in a header file is beyond me, but that's
a completely different issue.)

I have not tested this bug on a newer kernel, but I'd be very
surprised if it has been fixed, and should be easy to test by dd'ing
increasing bytes to sector 6 of your favorite USB drive.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.12-1-686-smp
Locale: LANG=en_US.ISO8859-1, LC_CTYPE=en_US.ISO8859-1 (charmap=ISO-8859-1)

Versions of packages linux-image-2.6.12-1-686-smp depends on:
ii  coreutils [fileutils]         5.2.1-2    The GNU core utilities
ii  initrd-tools                  0.1.82     tools to create initrd image for p
ii  module-init-tools             3.2-pre1-2 tools for managing Linux kernel mo

-- no debconf information
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.


--- End Message ---
--- Begin Message ---
Version: 2.6.16-5

The CONFIG_ACORN_PARTITION_CUMANA option is now disabled in official kernels, starting with today's upload of linux-2.6 2.6.16-5. That should take care of your problems.

Best regards,

Jurij Smakov                                        jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC

--- End Message ---

Reply to: