Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have an MBR formatted sd card and when connect to a Linux machine (xubuntu 12.04) it can mount a partition and parse the file system (as can GParted). However, when I try to read the MBR from the device using dd it gives me a bunch of spurious data.

Could anyone shed any light into how Linux/GParted is able to read and make sense of the MBR when dd isn't able to read the MBR. Do they use different methods to get at the data? I.E not open(), read()

DD command is:

dd if=/dev/sdb of=mbr.bin bs=512 count=1

DD output is:

1+0 records in
1+0 records out
512 bytes transferred in 0.000786 secs (651345 bytes/sec)

mbr.bin dump with hexdump -C mbr.bin is:

00000000  04 16 41 53 4d 49 2d 53  44 03 00 00 00 00 16 f1  |..ASMI-SD.......|
00000010  00 7f 00 32 1f 5b 80 00  36 db bf bf 96 c0 00 01  |...2.[..6.......|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000030  6f 00 00 10 00 00 02 2e  00 00 00 00 00 00 00 00  |o...............|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200
share|improve this question
    
What output does dd give? –  qdii May 12 '13 at 15:59
    
what do you mean by dd is unable to read the data ? –  qdii May 12 '13 at 16:15
    
the first 512 bytes should be an MBR containing a partition table but clearly that is not the case –  Tom Booth May 12 '13 at 16:15
    
hmm. maybe because you don’t use one? The magic with GPT is the Partition Table which replaces the MBR (but the MBR can be preserved in order for boot loaders that expect one to keep working). –  qdii May 12 '13 at 16:17
1  
What's the output of fdisk -lu /dev/sdb, gdisk -l /dev/sdb and grep sdb /proc/partitions? –  Stephane Chazelas May 12 '13 at 20:50
show 3 more comments

2 Answers

I would try using the sfdisk command as opposed to dd. For example:

$ sudo sfdisk -d /dev/sda > /tmp/mbr_using_sfdisk.bin
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.

Now looking at mbr_using_sfdisk.bin reveals what you're looking for:

$ more /tmp/mbr_using_sfdisk.bin
# partition table of /dev/sda
unit: sectors

/dev/sda1 : start=     2048, size=  2457600, Id= 7, bootable
/dev/sda2 : start=  2459648, size=314765312, Id= 7
/dev/sda3 : start=956291072, size= 20480000, Id= 7
/dev/sda4 : start=317224960, size=639066112, Id= 5
/dev/sda5 : start=317227008, size=  1024000, Id=83
/dev/sda6 : start=318253056, size=638038016, Id=8e

So why can't I see the partition table using dd?

I'm not entirely sure why but I did come across this trick that shows you how to see the partition tables in your mbr.bin using the file command.

For example:

$ sudo dd if=/dev/sda bs=512 count=1 of=mbr.bin
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000184924 s, 2.8 MB/s

$ file mbr.bin 
mbr.bin: x86 boot sector; GRand Unified Bootloader, stage1 version 0x3, boot drive 0x80, 1st sector stage2 0x12f0c26a, GRUB version 0.94; 
partition 1: ID=0x7, active, starthead 32, startsector 2048, 2457600 sectors; 
partition 2: ID=0x7, starthead 162, startsector 2459648, 314765312 sectors;
partition 3: ID=0x7, starthead 239, startsector 956291072, 20480000 sectors;
partition 4: ID=0x5, starthead 239, startsector 317224960, 639066112 sectors, code offset 0x48

References

share|improve this answer
    
Why should anyone use hexdump for the (plain text) output of sfdisk -d /dev/sda? –  Hauke Laging May 12 '13 at 18:01
    
That's a great point, I hadn't noticed it was plain text. I'll fix it in the answer 8-). –  slm May 12 '13 at 18:03
add comment

The card does not have a Master Boot Record (MBR). If it had your hexdump would have given you at least one partition entry at offset 0x1C0 and 55aa at the end.

Not all partition tables lay out data in the first 512 bytes. The spurious data you see is SID and CSD register of (a / the) SD card. But from the looks of it it is not the correct data for the card (unless it is an old 1 MiB 2001 model.)

First 16 bytes are:

CID Register:
----------------------------------------------------------------------------
Manufacturer ID       (MID): 04               => (Transcend)
OEM/Application ID    (OID): 16 41            =  ?A
Product name          (PNM): 53 4d 49 2d 53   =  SMI-S
Product revision      (PRV): 44               =  0100 0100 => 4.4
Product serial number (PSN): 03 00 00 00
reserved               (-) : 00 >> 4          = 0000b
Manufacturing date    (MDT): (00 & 0x0f)|0x16 = 0001b,0110b => 2000+1,6=> Jun 2001
CRC7 checksum         (CRC): 1f >> 1          = 120
always 1               (1) : 1f & 1           = 1

Next 16 bytes (at least part of it):

CSD Register:
----------------------------------------------------------------------------
CSD Structure        (CSD_STRUCTURE): 00 >> 6  = 00b => CSD Version 1.0
reserved                         (-): 00 & 3f  = 00 0000b
Data read access time 1       (TAAC): 7f = 1111b => time val 8.0, 111b => 7=10ms
Data read access time 2       (NSAC): 00
Max. data transfer rate (TRAN_SPEED): 32 = 0110,010 time val 2.5, 2=10Mbit/s 25MHz
Card command classes           (CCC): 1f << 4 | 5b >> 4 = 0x1f5

...
Device size (C_SIZE) : (0x80 & 0x03) << 0xa | 00h | 36 >> 6 : 0

Max. read  current @VDD min (VDD_R_CURR_MIN) : 110 => 60mA
Max. read  current @VDD max (VDD_R_CURR_MAX) : 110 => 80mA
Max. write current @VDD min (VDD_W_CURR_MIN) : 110 => 60mA
Max. write current @VDD max (VDD_W_CURR_MAX) : 110 => 80mA
Device size multiplier         (C_SIZE_MULT) : 111 => 2^(7 + 2) = 512
Erase single block enable     (ERASE_BLK_EN) : 0
Erase sector size              (SECTOR_SIZE) : 1111111 => 127 + 1 = 128
Write protect group size       (WP_GRP_SIZE) : 0111111 =>  63 + 1 = 64

MULT      = 2^(C_SIZE_MULT + 2)  = 2^(7 + 2) = 512
BLOCKNR   = (C_SIZE + 1) * MULT  = 1 * 512   = 512
BLOCK_LEN = 2^READ_BL_LEN        = 2^11      = 2048

memory capacity = 
BLOCKNR * BLOCK_LEN = 512 * 2048 = 1048576 bytes = 1024 KiB = 1 MiB

Also the CRC7 check for CSD register is wrong. It could be old data left from a past time.

Those registers and more can be queried from the card directly by various commands. This is done by module drivers, card hubs etc.


Would be interesting to see what you find by the commands given by Stephane Chazelas, slm etc.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.