Bug 364365

After googling for "unknown partition table" it turns out that quite a few people are mislead to believe something is wrong with their media. A similar request as this one can be found at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463758

Where exactly have you seen the text "unknown partition table"?

Bug 299704 comment #3, Bug 300894 comment #0

So this is really a request to our kernel developers.

After taking a closer look it seems like initially this was the case as the kernel reported "unable to read partition table" (but which probably doesn't sound much better to users anyway) in the case of no partition table.

It seems like the upstream commit 57881dd9df40b76dc7fc6a0d13fd75f337accb32 (by suzuki@in.ibm.com on 2006-12-06) made this part unreachable.

No, my previous note was wrong. On a correct media with no partition table nothing is mentioned at all.

The message you are observing (investigated the mbrs of you from bug #299704) shows that there are the msdos label magic bytes (offset 510 and 511) set correctly, but on verifying if bootable indicator is set correctly (to 0 or 0x80) it only finds garbage at 0x1be.
So, it seems your mbr is not only without a partition table but also has a abnormal structure.

I verified (with multiple medias, formated via mkfs.vfat and from windows (vista)) and never got a "unknown partition table" message.

So, as those mbrs - besides the absent partition table - aren't regular ones this message is imho adequate.

As the message "unknown partition table" just references an absent partition table  it has nothing to do with "garbage at 0x1be" nor does it hint to that end.

If "garbage at 0x1be" is worth investigating, it should be worth it's own (error)message then.

The way you point it out makes the message even more obscure.

So why this should be "adequate" iyho is beyond my intellectual capacities.

Please come up with something reasonable.

Besides: all the media were formatted with (my copy of) Windows XP professional. So there might be some XP magic code here. Also XP will report a Diskette or MMC with partition table as "not formatted" and refuse to touch it.  

(In reply to comment #8 from Casual J. Programmer)
> As the message "unknown partition table" just references an absent partition
> table 

No, that is wrong. A plane absent partition table does not lead to a "unknown partition table" message.

> it has nothing to do with "garbage at 0x1be" nor does it hint to that
> end.

Of course the default logging isn't that detailed and in your case it definitly has to do with the unregular value at 0x1be.

> If "garbage at 0x1be" is worth investigating, it should be worth it's own
> (error)message then.

No, "garbage at 0x1be" is the point of failure for your special mbr, but "unknown partition table" is imho perfectly valid in that case. Your partition table _is unknown_, so why should it tell anything different.

> The way you point it out makes the message even more obscure.
> So why this should be "adequate" iyho is beyond my intellectual capacities.
> Please come up with something reasonable.

I hope the above made it mode clear.

> Also XP will report a
> Diskette or MMC with partition table as "not formatted" and refuse to touch it. 

XP also can cope with sd and mmc medias with and without a partition table on it.

But anyway, what is valid: if this is a general point of problem with medias formated via XP it should be detected and handled accordingly.
I will investigate if there is a general way to solve this.

Created attachment 197515 [details]
possible fix for detection of not partitioned fat medias

this is just a rough first try (but which is tested and works here without problems)

Ask lkml if the approach is acceptable.

Not sure what I am missing:

fs/partitions/msdos.c: In function ‘msdos_partition’:
fs/partitions/msdos.c:446: error: dereferencing pointer to incomplete type
fs/partitions/msdos.c:446: error: dereferencing pointer to incomplete type
fs/partitions/msdos.c:446: error: implicit declaration of function ‘FAT_VALID_MEDIA’
fs/partitions/msdos.c:446: error: dereferencing pointer to incomplete type
make[2]: *** [fs/partitions/msdos.o] Error 1
make[1]: *** [fs/partitions] Error 2
make: *** [fs] Error 2

	/*
	 * Now that the 55aa signature is present, this is probably
	 * either the boot sector of a FAT filesystem or a DOS-type
	 * partition table. Reject this in case the boot indicator
	 * is not 0 or 0x80.
	 */
	fb = (struct fat_boot_sector *) data;
446	if (fb->reserved && fb->fats && FAT_VALID_MEDIA(fb->media)) {
		printk("\n");
		put_dev_sector(sect);
		return 1;
	}

	p = (struct partition *) (data + 0x1be);
	for (slot = 1; slot <= 4; slot++, p++) {
		if (p->boot_ind != 0 && p->boot_ind != 0x80) {
			put_dev_sector(sect);
			return 0;
		}
	}

Seems like you didn't correctly apply my patch .. as most probably its first hunk (the include of linux/msdos_fs.h) is missing. At least that would directly explain the error.

Even when correctly applied there is a warning issued that a comparison would always be true. But that one is totally harmless (and also misleading). The used FAT_VALID_MEDIA macro contains a subexpression (x <= 0xFF, which here is always true as x is a unsigned 8bit var) that isn't really needed but also does no harm.

I already sent the patch upstream and am now waiting for feedback from there.

".. as most probably its first
hunk (the include of linux/msdos_fs.h) is missing."

How very true :-(

Created attachment 198218 [details]
patch v2

just for record.. this is the new version of the patch i did after some upstream discussions

btw this will only compile with mm kernel tree currently as it requires another patch fixing the the FAT_VALID_MEDIA macro there

commited patch v3 (besides a Acked-by: OGAWA Hirofumi and a small comment identical to v2) to cvs

(In reply to comment #19)
> commited patch v3 (besides a Acked-by: OGAWA Hirofumi and a small comment
> identical to v2) to cvs


Hi Frank,
I don't see your patch in the kernel version 2.6.28
linux-2.6.x\fs\partitions\msdos.c

Without the patch, I was seeing a very similar problem. Certain valid FAT formatted USB drives/media (Lexar, Kingston Traveldrives) were not being detected by Linux and were causing an "unknown partition table" message even though the media is valid (can be accessed via XP) and/or has no partition table. 

Has the patch either been approved, checked in or committed?

Thanks.

The patch has been approved and went into Andrew Mortons mm-tree. But i haven't tracked if it also went into linus' tree. Could well be it was missed. I haven't checked that.

Ok, i just checked linus git tree and found it. So it is in:
My patch is in commit 0607fd02587a6b4b086dc746d63123c1f284db68
from April 28th 2008.

commit 0607fd02587a6b4b086dc746d63123c1f284db68
Author: Frank Seidel <fseidel@suse.de>
Date:   Mon Apr 28 02:16:31 2008 -0700

    fat: detect media without partition table correctly

    I received a complaint that some FAT formated medias (e.g.  sd memory cards)
    trigger a "unknown partition table" message even though there is no partition
    table and they work correctly, while in general (when e.g.  formated with
    mkdosfs or even Windows Vista) this message is not shown.

    Currently this seems only to happen when the medias get formatted with Windows
    XP (and possibly Win 2000).  Then the boot indicator byte contains garbage
    (part of text message) and so do the other parts checked by msdos_paritition
    which then later triggers this message.

    References: novell bug #364365

    Most fat formatted media without partition table contains zeros in the boot
    indication and the other tested bytes and so falls through the checks in
    msdos_partition, leading it to return with 1 (all is fine).

    But some (e.g.  WinXP formatted) fat fomated medias don't use boot_ind and so
    the check fails and causes a "unkown partition table" warning eventhough there
    is none and everything would be fine.

    This additional check directly verifies if there is a fat formatted medium
    without a partition table.

    Signed-off-by: Frank Seidel <fseidel@suse.de>
    Cc: Andreas Dilger <adilger@sun.com>
    Acked-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
    Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
    Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>