0

Alternative way to earn the bounty: Show me how to store a file system like ext4 (a FS which can store large files, I don't really need all of the good stuff ext4 provides for this use case) in many small files (< 4 GiB) stored on a (working) FAT-formatted partition.

I have an SD card (adverties as 64 GB but other than usual storage media has less than that (it has 63'416'827'904 Byte)) and an SD slot on my laptop (an Acer Aspire VN7-591G-70CY). The SD card worked with my previous laptop without problems and is formatted with ext4.

I tried sudo modprobe -r r852; sudo modprobe -r sdhci_pci; sudo modprobe r852; sudo modprobe sdhci_pci which helped others but did nothing for me.

The SD card works with an SD card to USB adapter. When using this adapter the SD card is /dev/sdb and the single partition on it is /dev/sdb1. When I put it into the SD card slot it is /dev/mmcblk0 and its partition is /dev/mmcblk0p1.

When I enter the SD card into the slot, nautilus says:

Error mounting /dev/mmcblk0p1 at /media/christoph/e07d3be4-bd85-4eb2-9205-d6638ab37704: Command-line `mount -t "ext4" -o "uhelper=udisks2,nodev,nosuid" "/dev/mmcblk0p1" "/media/christoph/e07d3be4-bd85-4eb2-9205-d6638ab37704"' exited with non-zero exit status 32: mount: wrong fs type, bad option, bad superblock on /dev/mmcblk0p1, missing codepage or helper program, or other error

   In some cases useful info is found in syslog - try
   dmesg | tail or so.

Mounting it manually results in pretty much the same error message:

mount: wrong fs type, bad option, bad superblock on /dev/mmcblk0p1, missing codepage or helper program, or other error

   In some cases useful info is found in syslog - try
   dmesg | tail or so.

Now the weird part is that dd doesn't seem to work in either case. I copied the first 100 MiB of each /dev/sdb, /dev/sdb1, /dev/mmcblk0 and /dev/mmcblk0p1 and earlier this day even got matching sha256-sums.

They now don't match any more but are very similar in the way that except for a little bit in the beginning almost exclusively consist of zero bytes even though the SD card is almost entirely full (and filled with compressed and encrypted data, so there shouldn't me many zero bytes).

So I replaced every instance of 4 consecutive zero bytes in $mmcblk0 (the copies I made via dd are named exactly the same as the devices but I but a dollar sign before the name so they can be differentiated) with plain nothingness in a hex editor and ended up with files just being 129.4 kB for r$sdb (the 'r' is for 'reduced' / 'replaced') and 312.7 kB for r$mmcblk0 instead of being 104.9 MB each.

r$sdb has a mount point stated in the beginning (and I have no idea why). It really is the mount point the SD card was mounted on. Then comes randomly seeming data with a lot of repetitions, followed by a whole lot of FF bytes, followed by actual names of files saved on the SD card, followed by a little more randomly seeming data but not much.

About the fist 1600 Byte in r$mmcblk0 are exactly the same as in r$sdb (this includes the mount point even though the SD card couldn't be mounted while in the slot). Then comes randomly seeming data with a lot of repetitions but with big blocks made from printable characters including file paths, followed by FF bytes, followed by exactly the same as the ending of r$sdb (actual names of files saved on the SD card, followed by a little more randomly seeming data but not much).

Can you help me to resolve the problem and maybe tell me why dd outputs this weird data?

I figured out how to make it work with FAT myself. I ran apt-get install nfs-common, rebooted and now FAT is working. Unfortunately, FAT is a shitty file system which doesn't support loads of stuff and I need file many GB in size which aren't supported by FAT. So I cannot use the SD card with FAT at all.

If I format the partition with ext4, the same error as previously occurs. For FAT everything seems fine.

Is there a command to make it work for ext4 as well?

$ sudo fdisk -l

Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 2D8D2D1D-B17D-4F86-ACD1-743E6B376EFE

Device          Start        End    Sectors   Size Type
/dev/sda1        2048    1230847    1228800   600M Windows recovery environment
/dev/sda2     1230848    1845247     614400   300M EFI System
/dev/sda3     1845248    2107391     262144   128M Microsoft reserved
/dev/sda4  1716043776 1920843775  204800000  97.7G Microsoft basic data
/dev/sda5  1920843776 1953523711   32679936  15.6G Windows recovery environment
/dev/sda6     2107392   36923391   34816000  16.6G Linux swap
/dev/sda7    36923392 1716043775 1679120384 800.7G Linux filesystem

Partition table entries are not in disk order.
Disk /dev/mmcblk0: 59.1 GiB, 63416827904 bytes, 123860992 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xd69abc36

Device         Boot Start       End   Sectors  Size Id Type
/dev/mmcblk0p1       2048 123860991 123858944 59.1G 83 Linux

Disk /dev/mapper/cryptswap1: 16.6 GiB, 17825267712 bytes, 34814976 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

 

$ lspci
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor DRAM Controller (rev 06)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller (rev 06)
00:02.0 VGA compatible controller: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller (rev 06)
00:03.0 Audio device: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor HD Audio Controller (rev 06)
00:14.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI (rev 05)
00:16.0 Communication controller: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #3 (rev d5)
00:1c.3 PCI bridge: Intel Corporation 8 Series/C220 Series Chipset Family PCI Express Root Port #4 (rev d5)
00:1d.0 USB controller: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation HM86 Express LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 8 Series/C220 Series Chipset Family 6-port SATA Controller 1 [AHCI mode] (rev 05)
00:1f.3 SMBus: Intel Corporation 8 Series/C220 Series Chipset Family SMBus Controller (rev 05)
01:00.0 3D controller: NVIDIA Corporation GM107M [GeForce GTX 860M] (rev a2)
07:00.0 Network controller: Intel Corporation Wireless 7265 (rev 48)
08:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0c)

I think that the last part of the output of dmesg is interesting:

[10106.153215] mmc0: new ultra high speed SDR50 SDXC card at address 59b4
[10106.153349] mmcblk0: mmc0:59b4 SD    59.0 GiB 
[10106.158564]  mmcblk0: unknown partition table
[10109.748018]  mmcblk0: p1
[10110.393758] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
[10111.098030] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
[10111.862596] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
[10111.862610] EXT4-fs (mmcblk0p1): Magic mismatch, very weird!
[10201.953257] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
[10202.553754] mmcblk0: error -110 sending stop command, original cmd response 0x900, card status 0x900
[10202.555661] EXT4-fs (mmcblk0p1): ext4_check_descriptors: Checksum for group 48 failed (26727!=0)
[10202.555664] EXT4-fs (mmcblk0p1): group descriptors corrupted!
Improve this question
16
  • Why not ntfs then?
    – daltonfury42
    Jul 4, 2015 at 19:53
  • Also, what partition table do you use? Try changing it.
    – daltonfury42
    Jul 4, 2015 at 20:28
  • @daltonfury42 I tried ntfs but it also doesn't work. Right after formatting the partition to ntfs, GParted shows me a warning symbol on the partition and when I right-click the partition and select "Information", the error message says: Unable to read the contents of this file system! Because of this some operations may be unavailable. The cause might be a missing software package. The following list of software packages is required for ntfs file system support: ntfsprogs / ntfs-3g. Package ntfs-3g is installed, ntfsprogs has no installation candidate (is superseded by ntfs-3g?).
    – UTF-8
    Jul 4, 2015 at 20:33
  • askubuntu.com/questions/512461/… Quote: "The ntfsprogs package was renamed to ntfs-3g in Ubuntu 13.04."
    – UTF-8
    Jul 4, 2015 at 20:40
  • yeah, I was wrong, from it's manpage, "The ntfsprogs are part of the ntfs-3g package"
    – daltonfury42
    Jul 4, 2015 at 20:42

3 Answers 3

Reset to default
1

In my opinion, your SD Card Reader is failing. There is a very high probability of data loss. FAT is working probably because it has less error checking features, but that doesn't mean no errors! Use FAT with extreme caution. Take backups if you will be storing important data. Or rather, don't store important data, or simply use the USB Card Reader. That being said,

Try repairing your SD card which is a standard procedure:

sudo e2fsck -f -C 0 /dev/mmcblk0p1

e2fsck is the linux utility to repair ext based filesystems. Anyways, I don't expect it to work.

So, as another answer suggests, the card reader might not support such a large drive. But the fact that FAT works indicates that it is possible, with the added possibility of getting screwed up.

These are things you can try, but I don't know if they will work: Partition it into two, or even four drives if it will suit you, and then go forward with ext4. Or how about creating a smaller partition and leaving the rest as free space? You could give it a try.

Finally, since FAT works, (remember, probably because it does little error checking) exFAT could meet your requirements of storing file sizes greater than 4 GB. See how to do it here.

Improve this answer
3
  • I'll try this command after I gave NTFS a try. How would making smaller partitions help? Why does the card reader even care about partitions in the first place? I'd expect a card reader to just read what's on the SD card, whether there are partitions according to some kind of partition table or whether there is something else on the card (like the whole thing being full of random data, not organized in partitions).
    – UTF-8
    Jul 4, 2015 at 20:38
  • Ok, I'll try to explain it for the last time. The card is not broken. Every cardreader has a built-in controller that is hardwired to do things. Pretty much like a regular hard drive. If you could insert another platter in it to extend the capacity it would not recognize it because it is not hardwired to do so. Similarly if you insert a card in the cardreader of a size that it is not hardwired for it will not recognize it. However the cardreader can read partition tables and sees that there are more sectors defined than it can find so it starts throwing I/O errors.
    – wie5Ooma
    Jul 4, 2015 at 23:56
  • @wie5Ooma, if you are right, and it is doing as it is supposed to do, then why does it work with FAT?
    – daltonfury42
    Jul 5, 2015 at 4:55
0

I believe the problem is caused by the fact that this particular SD cardreader is unable to read SD cards that have a 64 GB capacity while the other one in your previous laptop apparently can read such cards. Not all card readers have the same specifications. When you buy a card reader it is stated in the documentation what the biggest capacity is that the reader can handle. When it sits already in a laptop you'll have to figure it out what it can handle. Currently the limit is usually 32 GB. Unfortunately you can't change this property.

Improve this answer
4
  • But then, why the partitions even be figured out? GParted can even tell me space is used and how much is unused. Btw.: I now figured out that useful data comes after the very nothing-saying beginning. It just so happened that the beginning is just that boring, probably because there all inodes are saved and the partition held very few (like very few) files. 3874816 inods with each taking 256 bye means ~967 MiB taken up by inodes. Given that I only read the fist 100 MiB it had to be expected that this would happen. But the question remains: Why can I read data in the first place?
    – UTF-8
    Jul 1, 2015 at 17:38
  • You 'lost' an amount of space because the metadata of the filesystem uses it so your observation regarding the inodes sounds valid. It works the same way for a regular hard drive. How did you test it with GParted? Was the card in the cardreader or in the SD to USB adapter?
    – wie5Ooma
    Jul 1, 2015 at 21:05
  • I simply opened GParted and switched to the SD card while it was in the SD card slot of the laptop (no adapter).
    – UTF-8
    Jul 2, 2015 at 0:21
  • 1
    cards larger than 32GB are called SDXC (instead of SDHC or SD), for eXtended capacity. This calls for a different type of reader, for arbitrary and historic reasons. Apparently you have an SDHC reader installed. I can advise you to get a 32GB card if you want it to work with your laptop. Or use a USB card reader (you seem to have one lying around).
    – Maarten Klop
    Jul 6, 2015 at 15:12
0

Considering the new information you've added to the question I've a different approach for you.

In GParted format the partition on the card as ext4. Then create a mountpoint. Let's assume this is sd. So you do:
mkdir -p /media/sd.
Then to mount it you do:
mount -t ext4 -O noatime,nodiratime /dev/mmcblk0p1 /media/sd.
The second command above is supposed to be on one line. Probably you have to prepend these commands with sudo. You can also use the flags in the second command in /etc/fstab.

Improve this answer
8
  • I tried mounting it manually from the beginning (see original question). Even when stating the file system type in the mount command, the error message remains the same: $ sudo mount -t ext4 -O noatime,nodiratime /dev/mmcblk0p1 /media/sd mount: wrong fs type, bad option, bad superblock on /dev/mmcblk0p1, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so.
    – UTF-8
    Jul 3, 2015 at 23:02
  • This suggests the card is not formatted as ext4. Are you really sure it is ext4? The mount procedure described certainly works.
    – wie5Ooma
    Jul 3, 2015 at 23:05
  • I know that the command is correct. I have used it many times to mount various media over several years. I created a new partition table and then a new partition on the SD card several times. (Using GPareted.) The whole thing that dd doesn't put out correct data doesn't make any sense at all.
    – UTF-8
    Jul 3, 2015 at 23:09
  • I added new information to the bottom of the answer.
    – UTF-8
    Jul 3, 2015 at 23:09
  • This means that there's something wrong with the partition table, which means the card is about to give up or it can mean that the cardreader thinks there's something wrong with the card which efectively means the cardreader is malfunctioning. Do both readers give this result?
    – wie5Ooma
    Jul 3, 2015 at 23:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .