5

I try to mount a SDHC card under GNU/Linux. Unlike what happens usually, /var/log/syslog doesn't mention sdb1, just:

Jul 26 16:07:53 xvii kernel: [  159.404842] scsi 6:0:0:0: Direct-Access     Singim   SD Card   MMC/SD 1.4F PQ: 0 ANSI: 0 CCS
Jul 26 16:07:53 xvii kernel: [  159.405115] sd 6:0:0:0: Attached scsi generic sg2 type 0
Jul 26 16:08:01 xvii kernel: [  168.239600] sd 6:0:0:0: [sdb] Attached SCSI removable disk

Moreover fdisk -l /dev/sdb outputs nothing. What should I do?

EDIT (2014-07-27): I could have this SD card again, and it seems to be faulty. Yesterday, I was trying it via a USB card reader. Today, I've tried it directly by putting it in the SD slot of my laptop, and I got thousands of I/O errors:

Jul 27 11:56:35 xvii kernel: [ 8091.317234] mmc0: new high speed SDHC card at address 1234
Jul 27 11:56:35 xvii kernel: [ 8091.317477] mmcblk0: mmc0:1234 SA04G 3.68 GiB
Jul 27 11:56:35 xvii kernel: [ 8091.320119] mmc0: Got data interrupt 0x00200000 even though no data operation was in progress.
Jul 27 11:56:35 xvii kernel: [ 8091.322277] mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0xb00
Jul 27 11:56:35 xvii kernel: [ 8091.322289] mmcblk0: retrying using single block read
Jul 27 11:56:35 xvii kernel: [ 8091.324862] mmcblk0: error -84 transferring data, sector 0, nr 8, cmd response 0x900, card status 0x0
Jul 27 11:56:35 xvii kernel: [ 8091.324872] end_request: I/O error, dev mmcblk0, sector 0
Jul 27 11:56:35 xvii kernel: [ 8091.326398] mmcblk0: error -84 transferring data, sector 1, nr 7, cmd response 0x900, card status 0x0
Jul 27 11:56:35 xvii kernel: [ 8091.326405] end_request: I/O error, dev mmcblk0, sector 1
Jul 27 11:56:35 xvii kernel: [ 8091.329056] mmcblk0: error -84 transferring data, sector 2, nr 6, cmd response 0x900, card status 0x0
[...]

and gdisk -l didn't find any partition table, and lsblk output about the card:

mmcblk0                  179:0    0   3.7G  0 disk

A bit later I tried again, and the card was recognized:

Jul 27 12:08:00 xvii kernel: [ 8776.617712] mmc0: new high speed SDHC card at address 1234
Jul 27 12:08:00 xvii kernel: [ 8776.618117] mmcblk0: mmc0:1234 SA04G 3.68 GiB
Jul 27 12:08:00 xvii kernel: [ 8776.620324]  mmcblk0: p1

and I could mount it: /dev/mmcblk0p1 on /media/mmc type vfat (rw,nosuid,nodev,noexec,noatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=utf8,shortname=mixed,errors=remount-ro,user=vinc17)

gdisk -l /dev/mmcblk0 found only a MBR partition table, but the second partition table overlaps the last partition.

vinc17
  • 12,174
  • Can you verify the SD card works on another system? Is there any partition scheme on it (maybe GPT, fdisk only works for MBR)? You can try reading the first bytes with hexdump and see if they are all 0. – groxxda Jul 26 '14 at 14:56
  • You should mount /dev/sdb /path/to/mount. If you want partitions, make some, but it will likely be destructive to whatever is on the disk already if anything. – mikeserv Jul 26 '14 at 14:57
  • what does file -s /dev/sdb output? – phemmer Jul 26 '14 at 17:06
  • @mikeserv Mounting /dev/sdb gives an error message (IIRC, a file system can't be found). I had also tried with -t vfat, but this didn't work either. – vinc17 Jul 26 '14 at 18:23
  • @Groxxda The SD card isn't recognized either by Mac OS X. It is currently being tried on a TV and it is recognized by it. Well, only 4 photos can be currently found. – vinc17 Jul 26 '14 at 18:25
  • @vinc17 - I completely missed the tv bit until just now. You might have better luck with linux - the tv is probably running some embedded linux anyway - but you will need to ensure you have the correct filesystem module loaded in memory to recognize it. I'm almost certain there is no partition table on the card at all and it is wholly formatted with a single filesystem. You can probably find out by googling the tv's make and model and finding a manual on it. – mikeserv Jul 26 '14 at 22:59
  • 1
    @mikeserv Actually I think that for the TV, the card was used via the camera (from which the SD card came) and a USB cable. I didn't follow this closely, but in such a case, I suppose that this may be very different (e.g. if a protocol like MTP is used). As you said, the card is probably wholly formatted with a single filesystem, otherwise I would have got at least sdb1. And that's why I said "without a partition" in the title. – vinc17 Jul 27 '14 at 00:19
  • @vinc17 - that's a good point, but maybe do that same thing with the camera. Still, most cameras will just understand and use fat filesystems. Can you mount other fats? – mikeserv Jul 27 '14 at 00:44
  • Though maybe if the camera is configured to only serve pictures over usb it would use its own proprietary format and screw allowing it to mount. If thats the case then i think you might wanna try plugging it into your computer. A lot of times that stuff just works and youll get the camera instantly, else you might need to install v4l2. – mikeserv Jul 27 '14 at 01:53
  • @mikeserv Yes, this may be the problem. I don't have the SD card any longer. The camera plugged into a Mac OS X computer with the USB cable was recognized (but not the SD card alone). I didn't try the USB cable on my laptop. – vinc17 Jul 27 '14 at 08:20
  • @mikeserv See new information. In short, the card is faulty, with occasional I/O errors. Also, using a USB card reader hides such errors. – vinc17 Jul 27 '14 at 10:45

1 Answers1

4

The link /dev/$disk points to the whole of a block device, but, on a partitioned disk without unallocated space, the only part which isn't also represented in /dev/$disk[num] is the first 2kb-4mb or so - $disk's partition table. It's just some information written to the raw device in a format that the firmware and/or OS can read. Different systems interpret it in different ways and for different reasons. I will cover three.

  • On BIOS systems this table is written in the MBR master boot record format so the firmware can figure out where to find the bootable executable. It reads the partition table because in order to boot BIOS reads in the first 512 bytes of the partition the table marks with the bootable flag and executes it. Those 512 bytes usually contain a bootloader (like grub or lilo on a lot of linux systems) that then chainloads another executable (such as the linux kernel) located on a partition formatted with a filesystem the loader understands.

  • On EFI systems and/or BIOS systems with newer kernels this partition table can be a GPT GUID partition table format. EFI firmware understands the FAT filesystem and so it looks for the partition the table describes with the EFI system partition flag, mounts it as FAT, and attempts to execute the path stored in its Boot0000-{GUID} NVRAM variable. This is essentially the same task that BIOS bootloaders are designed to do, and, so long as the executable you wish to load can be interpreted by the firmware (such as most Linux kernels since v. 3.3), obviates their use. EFI firmware is a little more sophisticated.

After boot, if a partition table is present and the kernel understands it, /dev/${disk}1 is mapped to the 4mb+ offset and ends where the partition table says it does. Partitions really are just arbitrary logical dividers like:

start of disk | partition table | partition 1 | ... and so on | end of disk

Though I suppose it could also be:

s.o.d. | p.t. | --- unallocated raw space --- | partition 1 | ... | e.o.d.

It all depends on the layout you define in the partition table - which you can do with tools like fdisk for MBR formats or gdisk for GPT formats.

  • The firmware needs a partition table for the boot device, but the kernel needs one for any subdivided block device on which you wish it to recognize a filesystem. If a disk is partitioned, without the table the kernel would not locate superblocks in a disk scan. It reads the partition table and maps those offsets to links in /dev/$disk[num]. At the start of each partition it looks for the superblock. It's just a few kb of data (if that) that tells the kernel what type of filesystem it is. A robust filesystem will distribute backups of its superblock throughout its partition. If the partition does not contain a readable superblock which the kernel understands the kernel will not recognize a filesystem there at all.

In any case, the point is you don't really need these tables on any disk that need not ever be interpreted by firmware - like on disks from which you don't boot (which is also the only workable GPT+BIOS case) - and on which you want only a single filesystem. /dev/$disk can be formatted in whole with any filesystem you like. You can mkfs.fat /dev/$disk all day if you want - and probably Windows will anyway as it generally does for device types it marks with the removable flag.

In other words, it is entirely possible to put a filesystem superblock at the head of a disk rather than a partition table, in which case, provided the kernel understands the filesystem, you can:

mount /dev/$disk /path/to/mount/point

But if you want partitions and they are not already there then you need to create them - meaning write a table mapping their locations to the head of the disk - with tools like fdisk or gdisk as mentioned.

All of this together leaves me to suggest that your problem is one in these three:

  • your disk has no partition table and no filesystem

    • It was recently wiped, never used, or is otherwise corrupt.

  • your disk's partition table is not recognized by your os kernel

    • BIOS and EFI are not the only firmware types. This is especially true in the mobile/embedded realm where an SDHC card could be especially useful, though many such devices use layers of less-sophisticated filesystems that blur the lines between a filesystem and a partition table.

  • your disk has no partition table and is formatted with a filesystem not recognized by your os kernel

After rereading your comment above I'm fairly certain it is the latter case. I recommend you get a manual on that tv, try to find out if you can get whatever filesystem it is using loaded as a kernel module in a desktop linux and mount the disk there.

mikeserv
  • 58,310
  • I can't test the card any longer, but this could help if the problem occurs again in the future. Thus upvoted. FYI, the kernel is a 3.11.10 and /proc/filesystems gives the following supported dev-filesystems: ext2, ext3, ext4, fuseblk. However this list doesn't seem to be exhaustive since I can mount vfat partitions with mount without doing anything else special. It appears that mount can also recognize filesystems and the kernel would auto-load the module. Unfortunately, I don't know what it tried. Next time I should use the --verbose option in case it gives interesting information. – vinc17 Jul 27 '14 at 00:22
  • 1
    @vinc17 - yeah, those modules are loaded by udev when it detects a disk. It calls on libblkid (same libs used by mount and friends) to read the superblock and then loads the appropriate modules automatically. You might want to try doing lsblk (it's one of those friends). – mikeserv Jul 27 '14 at 00:28
  • 1
    The fact that the filesystem is neither recognized by Linux nor by Mac OS X but supported by the camera is strange. I now think that the partition table may exist but is corrupted to a point that it cannot be recognized as a partition table. Perhaps the camera doesn't care e.g. if it can deal with only a single partition and a single fs. But computers do care. – vinc17 Jul 27 '14 at 08:04
  • 1
    @vinc17 - one way to check is to dd off the first 2kb to a file image somewhere - in case you want to restore - then dd /dev/zero over the head of the disk. Still, if the camera was reading it at all, I don't personally think it's the case. I think it might be though that the camera uses one of those less-sophisticated filesystems I alluded to that usually work by reading each file straight out in a stream - like a bunch of pipes catted over the disk. – mikeserv Jul 27 '14 at 08:20