Troubleshooting TF Card Partitions: Third Partition Not Detected

TF card third partitions often fail to appear because the kernel does not automatically rescan block devices after partition table changes, or because the filesystem type is incompatible with standard mount tools. You can resolve this by manually triggering a device scan using partprobe or writing to the rescan sysfs entry, verifying the partition with blkid, and ensuring the correct driver loads for the specific filesystem format.

Understanding Block Device Detection in Linux

When you modify partitions on a TransFlash (TF) card, also known as an SD card, the Linux kernel creates a block device node, typically named /dev/mmcblk0 for internal slots or /dev/mmcblk1 for external readers. The first partition is usually /dev/mmcblk0p1. If you create a third partition, it should theoretically become /dev/mmcblk0p3. However, the kernel may cache the old partition table state. This caching prevents the system from recognizing new partitions until a rescan event occurs. This issue is distinct from general partitioning errors. It is a hardware abstraction layer problem where the OS sees the physical device but fails to update its logical view of the storage layout. Unlike hard drives which have persistent controllers that handle metadata updates, TF cards rely on the host controller to interpret the partition table stored in the boot sector. If the partition table is valid but the kernel cache is stale, the third partition remains invisible to user-space applications. For more context on how Linux handles these low-level storage structures, you might find our guide on Partitions on a TF Card: A Guide to Linux Partitioning and Filesystems helpful. It details the fundamental differences between MBR and GPT tables and how they interact with ARM-based single-board computers like the Raspberry Pi, which are common users of TF cards.

Rescanning the Block Device

The most effective way to force the kernel to re-read the partition table is to trigger a rescan of the underlying block device. There are two primary methods for achieving this, depending on your system configuration and permissions. The first method involves using the partprobe utility. This command instructs the kernel to reload partition tables for all block devices without requiring a reboot. Run the following command in your terminal:

sudo partprobe /dev/mmcblk0

If partprobe is not available or fails to detect the change, you must write directly to the sysfs interface. This method interacts with the kernel driver directly. Identify your device name (e.g., mmcblk0) and execute:

echo 1 | sudo tee /sys/block/mmcblk0/device/rescan

After executing either command, verify that the new partition has appeared by listing the devices again:

ls -l /dev/mmcblk0*

You should now see entries for p1, p2, and p3. If the third partition still does not appear, check if the partition table type is supported. Older kernels or minimal distributions may not support GPT partition tables on removable media without explicit loading of additional modules. In such cases, converting the partition table to Master Boot Record (MBR) format using fdisk or parted may be necessary.

Verifying Filesystem Compatibility

Once the kernel detects the partition node, the next step is to ensure the filesystem within that partition is readable. A common error is assuming that a partition exists simply because the block device node is present. The partition might contain an unknown or unsupported filesystem, causing mount attempts to fail silently or with cryptic errors. Use blkid to inspect the partition attributes. This tool reads the superblock information and identifies the UUID and filesystem type. Avoid using deprecated commands like file -s, which may provide misleading results regarding the actual filesystem structure.

sudo blkid /dev/mmcblk0p3

The output should resemble:

/dev/mmcblk0p3: UUID="..." TYPE="ext4"

If the TYPE field is empty or shows unknown, the partition may be corrupted or formatted with a non-Linux filesystem. If you recently updated partition UUIDs on other drives, you might encounter similar issues with mount APIs. Refer to our article on Failed Mount API: Filesystems with Updated Partition UUIDs in Linux for troubleshooting steps related to UUID mismatches and fstab configurations. Ensure that the appropriate filesystem module is loaded. For ext4, the ext4 module should be active. You can check this with:

lsmod | grep ext4

If the module is missing, load it manually:

sudo modprobe ext4

Then attempt to mount the partition to a temporary directory:

sudo mkdir -p /mnt/test
sudo mount /dev/mmcblk0p3 /mnt/test

If the mount succeeds, the issue was purely a detection or module loading problem. If it fails, check the kernel log for specific I/O errors:

dmesg | tail -n 20

Look for messages indicating "I/O error" or "bad superblock," which suggest physical corruption or a mismatched filesystem type.

Common Pitfalls and Best Practices

When working with TF cards, always use reliable partitioning tools. fdisk and parted are standard choices, but ensure you select the correct target device. Writing to the wrong device, such as /dev/sda instead of /dev/mmcblk0, can destroy data on other drives. Always double-check device names using lsblk before making changes. Additionally, avoid unplugging the TF card while the system is actively writing to it. This can leave the partition table in an inconsistent state, leading to detection failures. If you suspect corruption, run a filesystem check using fsck on the unmounted partition. Finally, consider the limitations of the card reader itself. Some cheap USB card readers do not support large partitions or specific filesystem types. If the third partition is large (e.g., over 32GB), ensure your reader supports SDXC standards. Testing different readers can help isolate whether the issue lies with the card or the host interface.

Frequently Asked Questions

Why does lsblk show the device but not the partitions?

This indicates that the kernel has detected the physical block device but has not updated its internal partition table cache. You need to trigger a rescan using partprobe or by writing to the sysfs rescan file to make the partition nodes visible.

Can I use fdisk to fix a missing third partition?

No, fdisk modifies the partition table structure itself. If the partition table is correct but the OS doesn't see it, running fdisk will not help and may corrupt data. Use rescan commands first; only use fdisk if you need to recreate or repair the table layout.

What should I do if blkid returns no output for the partition?

If blkid returns nothing, the partition likely contains no recognized filesystem signature. This could mean the partition is raw/unformatted, or the filesystem is corrupted. You may need to format the partition with a compatible filesystem like ext4 or FAT32 using mkfs.ext4.

Does the kernel version affect TF card partition detection?

Yes, older kernels may have limited support for GPT partition tables on removable media or lack certain drivers for newer SD card controllers. Updating your kernel or loading specific modules via modprobe can resolve detection issues on legacy systems.

How do I prevent this issue when creating new partitions?

Always run sync after writing partition tables to ensure data is flushed to the card. Immediately follow up with partprobe or a manual rescan to refresh the kernel's view. Avoid removing the card until the system confirms the new nodes exist in /dev/.