FS#12982 - partition table unsupported (and bugfully ignored) on sansa clip+ microsd card

Attached to Project: Rockbox
Opened by Andrew Engelbrecht (sudoman) - Tuesday, 03 June 2014, 05:46 GMT
Task Type Bugs
Category Operating System/Drivers
Status Unconfirmed
Assigned To No-one
Operating System Sansa Clip+
Severity Low
Priority Normal
Reported Version Release 3.13
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


if i format the clip+'s microsd card to contain a DOS partition table, then the vfat formatted partition is not recognized.

if i format the sd card with a vfat fs starting at the first block, then the fs is recognized by rockbox.

** if i then reformat the sd card with a partition table like above, then the second fs i created is still recognized by rockbox, even though the first 512 bytes or so have been clobbered. the result is that rb and my laptop see different fs structures, and clobber each other's metadata, causing corrupt file systems.

the work-around is to dd if=/dev/zero the beginning of the sd card and format without partitions.

i kindly request that rb support dos, or some other, partition table, and maybe that rb doesn't mount fs'es which appear to be clobbered by a partition table. one problem with this change is that some people may be using a clobbered fs without knowing. with such a patch, they could end up seeing a corrupt fs instead.

i don't consider this very high priority. thanks for the awesome firmware! :-)
This task depends upon

Comment by Frank Gevaerts (fg) - Tuesday, 03 June 2014, 08:05 GMT
Do you have a dump from (the beginning of) a block device where you see this?
Comment by Andrew Engelbrecht (sudoman) - Tuesday, 03 June 2014, 14:58 GMT
here you go, the first 20 MB. in /dev/sdc1 is a a text file. in rockbox, we see the rockbox manual for the device.

i made the partition table with fdisk on debian sid:

Device Boot Start End Blocks Id System
/dev/sdc1 8192 62333951 31162880 83 Linux

i had also tried starting the partition at 2048, but that didn't help.
Comment by Frank Gevaerts (fg) - Thursday, 05 June 2014, 22:17 GMT

As far as I can figure it out, that first sector is actually both a valid MBR with partition table *and* a FAT bootsector.

What happens is that rockbox looks for a partition table, and checks if there's a FAT partition in there. If we find one, we mount it, and everyone's happy. If we don't find one, we try mounting the disk as a partitionless device.

In your case, you don't have any FAT partition on the device (83 is for various linux filesystems, not for FAT), so rockbox tries the second way. There are still enough leftovers from that FAT filesystem for that to work.

We could probably use a bit more sanity checking here.
Comment by Andrew Engelbrecht (sudoman) - Friday, 06 June 2014, 00:46 GMT
oohh.. i see. the dual validity thing is pretty weird...

i thought that 83 (linux) referred to the system used to create the partition, and was in many cases meaningless. fdisk sets that value by default. i think the difference in behavior i saw is likely because the kernel linux (or mount) may check the header of the partition contents (at least given the "system id"s i've tried), and determines the fs type from that header.

for now, i'll be using the 0x0b (W95 FAT32) system id. i think that allowing other system ids should be relatively harmless. if there was a partitionless fs under an unrecognized partition and fs, then using the underlying one in any significant way would lead to fs corruption issues. therefore allowing other system ids shouldn't hurt many users, as there likely aren't many people with just a few very small files on devices with that kind of layering. also, they would quickly run into the problems of files not showing up on both systems.

if other system ids should be ignored, then it would make sense to mention the importance of setting it, on the sansa faq and various other wiki pages. i did a lot of searching of the wiki to find info on partitioning methods. i remembered that i got ipod partitioning to work in the past, but the suggestion there is to download a pre-made partition table for each size of the device.

thanks for looking into this! rb is, and continues to be amazing. :-)