Next Stop - Ihcblog!

Some creations and thoughts sharing | sub site:ihc.im

0%

Using an SD Card with Bad Blocks on a Development Board

This article also has a Chinese version.

The Raspberry Pi has already ruined three of my SD cards. Although I was able to directly contact SanDisk and Samsung customer service on two occasions, where they replaced the SD cards unconditionally adhering to the warranty terms.

However, SD (TF) cards can’t endure many write cycles. Depending on the type of flash memory cells, MLC (Multi-Level Cell) has a longer life expectancy than TLC (Triple-Level Cell) chips. Cheaper SD cards generally use TLC chips, which can only withstand a few thousand write/erase cycles. Typical Linux systems frequently delete and write a large amount of log data during use, which means that SD cards cannot be used reliably for a long period.

This time I tried to boot up the board with a damaged SD card using some unusual methods.

Repairing Damaged Files

Recently, my Orange Pi One was not functioning properly, and upon connecting via UART, I discovered that the kernel loaded fine but the SSH service could not start due to missing files.

Without an SD card reader, I attempted to repair the EXT4 partition data using a rooted Android phone:

  • Remove the password by writing passwd -d root into /etc/rc.local

  • After rebooting, connect via TTL cable and log in, then create the necessary files for the SSH service

The board worked fine after another reboot.

However, the board crashed again when rebooted the next day. This indicates that there was a substantial amount of corrupted data.

Skipping Bad Blocks to Write Data

I was using a 32GB SD card, but the actual data written to it frequently did not exceed 8GB. So, by skipping the initial 8GB, we can avoid the damaged data blocks.

Here, I used Armbian. After downloading the image, I opened it with WinHex and saw that the first block was the MBR data. After reading the partition data, I found there was only one data partition (block8192 - block1826816). The data from block1 - block8191 appeared to be the Bootloader.

I directly skipped the first 8GB and changed the start of the partition in the MBR table from block8192 to block16777216. Then, I used dd if=armbian.img of=/dev/sdb bs=512 count=8192 to write the MBR data and Bootloader to the SD card. After that, all that was needed was to write the partition data: dd if=armbian.img of=/dev/sdb bs=512 count=1818624 skip=8192 seek=16777216.

The board booted normally after inserting the card.

Minimizing Write Operations

Mount /tmp, /var/log, etc. to RAM

Disable the SWAP partition or SWAP file and mount tmpfs partitions. Edit the /etc/fstab file to add noatime to the partitions to avoid disk writes when updating file modification times.

1
2
3
4
none        /var/run        tmpfs   size=1M,noatime         0 0
none /var/log tmpfs size=1M,noatime 0 0
none /var/tmp tmpfs size=1M,noatime 0 0
none /tmp tmpfs size=1M,noatime 0 0

Using overlayfs

Refer to the Armbian documentation:

1
2
3
apt-get install overlayroot
echo 'overlayroot="tmpfs"' >> /etc/overlayroot.conf
reboot

When you need to save modifications:

1
overlayroot-chroot

Welcome to my other publishing channels