MNT Reform System Image Set my SD Cards to Read Only

MNT Reform
1

I’ve been using my Reform for several months, but all of a sudden it stopped booting up. After some troubleshooting I discovered that there was something wrong with the SD card it was booting from. The device itself seems to be set to Read Only. Not the partitions on the card, the actual drive itself. I can’t even dd to it.

sudo dd if=/dev/zero of=/dev/sdb
dd: failed to open '/dev/sdb': Read-only file system

I did some troubleshooting and attempted to set the drive back to read/write using both hdparm and blockdev.

sudo blockdev --setrw /dev/sdb
# Exits with code 0, indicating success
...
sudo hdparm -r0 /dev/sdb      

/dev/sdb:
 setting readonly to 0 (off)
 readonly      =  1 (on)
# Exits with code 0, indicating success

Neither worked. After replugging and remounting, the drive failed to become readable again. I also checked the physical read/write switch on the card, and I’ve tried two different SD card readers. The drive stayed read only.

Eventually I gave up and figured this was a hardware failure. I have had SD cards fail on me like this before. I backed up the contents of the card, bought a brand new one, and dd’d everything over to the new card. After transferring, the new drive was suddenly exhibiting the exact same behavior. Locked down to read only, unable to be unlocked. My MNT system image is apparently capable of bricking SD cards.

What the hell is going on here? Is there any way for me to restore my cursed image and/or SD cards? The laptop still boots with (a third) SD card that is just using a stock system image. I really just don’t want to go through the hassle of migrating everything, and I want to make sure that this doesn’t happen to me randomly in the future (or at least I can fix it without a complete system reset).

2

Just to confirm: you bought a brand new card, dd-ed your old system image to it and it shows up as read-only even in other sd-card readers?

3

There is a sysfs switch that can disable write access to SD cards. I wouldn’t know how dd-ing an image could affect it, but that would be the first thing I would check.

I don’t remember the exact path, but it’s somewhere in /sys/block.

4

You probably mean the CSD information of the card? You could try to run this and paste the output here:

$ cat /sys/block/mmcblkX/device/csd | xxd

Replace the X by the appropriate integer for your SD-card. The interesting part are the last two bytes before the newline. My output is:

00000000: 3430 3065 3030 3332 3562 3539 3030 3030  400e00325b590000
00000010: 6564 6338 3766 3830 3061 3430 3430 3030  edc87f800a404000
00000020: 0a                                       .

And the last 0x40 is binary 1000000 which translates to file format group 1 and temporary and permanent write protection 0 (off).

It is maybe also interesting to note, that:

  • the physical write protection switch on SD-cards is just a “suggestion” to the card reader – there are many readers which simply ignore it
  • sd-cards, when they become faulty can internally activate write-protection to avoid further damage
  • sometimes, sd-card readers get old and contacts have to be cleaned with IPA or just some strong air to make them behave properly again

I have a professor who’s expertise is in flash memory sitting right down my hallway in case anybody has more questions. :slight_smile:

1 Like
5

I was actually just thinking about /sys/block/mmcblkX/force_ro and /sys/block/mmcblkX/ro.

Not sure how those two flags relate to the CSD info.

(Edit: I think I just had the SD Card that came with the Reform die while I looked up those files… I/O errors… Speaking about coincidences…)