How to identify and manage an SD card in Linux using commands

If you work with Linux daily, sooner or later you're going to need to accurately identify an SD card or any other storage device: to format it, assemble it, clone a Raspberry Pi, make sector-by-sector copies with dd or simply to avoid accidentally deleting the hard drive. In UNIX-like systems, these devices are represented by paths such as /dev/sda, /dev/sdb1etc., a far cry from the classic C: or D: drives of Windows.

In addition to locating your SD card, it is essential know the hardware and software of your GNU/Linux system wellThis information includes details such as which kernel you're using, which modules are loaded, RAM specifications, PCI/USB cards, network configuration, and more. It's not only useful for diagnosing problems, but also for choosing the right software, asking for help in forums, and verifying that a device is indeed what the manufacturer claims, without having to open the computer and void the warranty.

How are SD cards and other disks named in Linux?

In Linux, disks and partitions are represented by special files in the directory /dev/The most common scheme nowadays is the /dev/sdXwhere each letter represents a block device (hard drives, SSDs, USB drives, SD cards viewed as disks, etc.).

A disc will appear as /dev/sda, /dev/sdb, /dev/sdc... depending on the order in which the kernel detects them. Their partitions are numbered below: /dev/sda1, /dev/sda2etc. This means that an SD card inserted into a USB reader is usually seen as something like /dev/sdb o /dev/sdc, with partitions /dev/sdb1, /dev/sdb2...

In a simple scenario, with no disks other than the card, a USB or external SD disk could end up being named as /dev/sda if it is the only blocking device present. In routers or other embedded Linux-based devices where you only connect a USB drive, that drive will generally be /dev/sda, with its first partition in /dev/sda1.

Keep in mind that These names may change depending on when you start up or connect/remove devicesThat's why many tools use more stable identifiers like the UUID of the partition, although for quick operations from the terminal it is normal to work with /dev/sdX.

Basic commands to locate the SD card in Linux

To identify a specific SD card without going crazy, the best approach is to combine several commands and pay attention to... capacity, device type, and mounting pointsThese are the most practical.

List all disks and partitions with fdisk

A classic for viewing block devices is fdisk -lYou need administrator privileges:

sudo fdisk -l

The output shows all disks (/dev/sda, /dev/sdb…) with his total size and partition tableSearching by capacity makes it quite easy to find Which one matches the SD card? (for example, 32 GB, 64 GB, etc.), and also check if it is compatible microSD cardsFrom there, you already know which device to point to in commands like dd if=/dev/sdX.

View connected storage devices

There are different utilities that help to List the connected storage hardwareeach with their own style:

• lsblk It displays disks and their partitions in a tree-like format with size and mount point.
• lsscsi It displays SCSI/SATA devices (hard drives, SSDs, optical drives), useful if your SD card reader identifies as SCSI. It is typically installed on Debian/Ubuntu with sudo apt install lsscsi and then run lsscsi.
• pydf It's a "vitamin-enhanced" version of df written in Python that shows disk space usage with colorsIt is installed with sudo apt install pydf and is used as pydf.
• hdparm It offers a multitude of options for viewing and adjusting disk parameters (hdparm /dev/sdb (for example). It should be used with care.

With these tools you can see at a glance What devices are available, their size, type, and whether they are mountedCombining this with the information from fdisk -l You'll hardly ever pick the wrong SD card.

Wildcards for quick exploration /dev/sdX

The Linux shell allows you to use wildcards for working on multiple files at onceAnd this is also very useful for exploring devices in /dev/Some basic patterns:

• * represents anything from no character to any sequence: ls /dev/sd* will list all SCSI/SATA/USB type disks (e.g.) /dev/sda, /dev/sda1, /dev/sdb, etc.).
• ? equivalent to a single character: ls /dev/sda? It will show /dev/sda plus a character, for example /dev/sda1 a /dev/sda7.
• [] define ranges: ls /dev/sda will list /dev/sda1 a /dev/sda5.
• denies a range: ls /dev/sda will list the partitions of sda whose numerical part is not between 1 and 5, for example /dev/sda6, /dev/sda7...
• {} groups patterns separated by commas: ls /dev/{sda*,sdb*} It will show everything that begins with sda o sdb.
• \ It is used to "escape" special characters, such as space, when creating directories or working with paths.

These wild cards are very handy when you need operate on multiple partitions or disks at the same timeFor example, to list, copy, or delete multiple devices related to your SD card.

Graphical tools for viewing disks and SD cards

If you don't feel like relying solely on the terminal, many distributions include graphical tools that clearly display storage devicesTwo of the most common ones are:

• Disks (GNOME Disks)In GNOME environments (and derivatives like Linux Mint Cinnamon), it comes by default or is easily installed from the software center. It displays each disk, its size, partitions, file system, label, and the exact route type /dev/sdXIt's ideal for quickly seeing which SD card you have.
• hard infoA very complete graphical utility for viewing hardware and system information (CPU, memory, PCI, USB, disks, temperature, etc.) and run small benchmarks.

Hardinfo is usually available in the repositories of most GNU/Linux distributions. You can install it from a graphical package manager (Software, Synaptic, etc.) or via the terminal, and launch it from the applications menu or with the command hardinfo.

The error may appear in some versions of Ubuntu “Failed to load module canberra-gtk-module” when starting the application. This is fixed by installing the corresponding package (for example) libcanberra-gtk-module), and that's it.

Within Hardinfo, information is organized into four main groups: Equipment, Devices, Network and BenchmarksTo locate an SD card, you'll be most interested in the sections on Devices and Storagewhere you'll see disks, controllers, and details like size and bus.

Commands to learn about the system and kernel modules

Often, identifying an SD card also involves Understanding how the kernel detects it and which modules are involvedThis is where some classic commands come into play.

Basic system and kernel information

To know which system you're dealing with, it's helpful to master a few short commands:

• Kernel version: uname -r o uname -a to see version, architecture and more details.
• System architecture: uname -m It tells you if your machine is x86_64, armv7letc., which is important when working with devices like Raspberry Pi.
• Distribution and versionIn many modern distributions, lsb_release -a or look /etc/os-release Give the distribution name, version, and codename.
• Current user: whoami it shows to you Which user are you running commands with?useful for knowing if you need sudo.
• Name of the team: hostname returns the system hostname.

To know what kernel modules are loaded at a given moment it is used lsmodThis is especially interesting if you're tinkering with storage-related modules, buses, or cards (e.g., SDHCI modules, bus controllers, etc.).

Working with modules: an example with Bluetooth

A typical management situation is wanting Test different parameters of a kernel module without rebootingFor example, the module bluetoothThe normal way to download it would be with:

sudo modprobe -r bluetooth

However, sometimes you'll get errors indicating that the module can't be downloaded because it's in use. This means that some The device or service is using that module.and the kernel doesn't release it. You need to locate what uses it (for example with lsmod o lsof) and stop the service or disconnect the device before attempting to reload the module with other parameters.

List hardware in detail: CPU, PCI, USB, RAM and more

Besides the discs, you often need know exactly what hardware you have to make sure that a card, graphics card, network or similar is what you say you bought.

General hardware: lshw y dmidecode

The command lshw This list lists absolutely all the hardware known to the system: CPU, memory, buses, PCI/USB devices, disks, etc. The output is long, so it is usually paginated:

sudo lshw | less

You can also request a more compact summary with options such as sudo lshw -shortwhich is more manageable when you just want See at a glance what devices are available.

Another powerful tool is dmidecode, which extracts information from the BIOS/UEFI DMI table: motherboard model, BIOS, memory, etc.Since the output is also extensive, it can be redirected to a file:

sudo dmidecode -q >> hardware.txt

Then you open hardware.txt with your favorite editor or a less and you check out what interests you.

PCI devices: locating a graphics or network card

To see what is connected to the PCI bus (graphics cards, network cards, controllers, etc.) you use lspciA typical example: you want to confirm that your brand new Is the external video card really the advertised model?But you don't want to open your PC because of the warranty. Just run:

lspci

or for more details:

lspci -v

and find the line corresponding to VGA compatible controller or similar, where you'll see the actual model and manufacturer as detected by the system. Additionally, if you need network information, you can use resources for know what network card you have and compare the data with what the system shows.

Keep in mind that in architectures like ARM or on Raspberry Pi-type boards, the command lspci often it doesn't even exist or returns very little, because Many of these machines do not use a traditional PCI bus as in x86, but rather different buses (for example, devices integrated into SoCs) that are managed differently. That's why the absence of lspci On a Raspberry Pi it's more than justified: there's simply no PCI bus to enumerate.

USB Devices

If your SD card is in a USB reader, it's very useful to see what the system detects on that bus. lsusb:

lsusb

All connected USB devices will appear there, including card readers, external drives, hubs… If you also want transfer photos to the SD card To free up space on another computer, combine this information with what they give you. fdisk -l y lsblk It will help you perfectly identify the specific SD card.

RAM and memory devices

To take a quick look at main memory, the command free -m It shows you the total amount of RAM, used, free, and swap in megabytes. It's useful for check if a heavyweight process (such as a dd (huge on your SD) is bursting the memory or if there is plenty of space.

How to find and understand the SD card mounting point

Many people get frustrated when they try to find the SD card from an application (e.g., RetroArch) and don't see one. unit C: or D: as in Windows. In Linux, everything hangs on a single directory tree, and SD cards or USB drives are mounted under paths such as /media, /mnt or similar.

Depending on the distribution, your desktop may automatically mount the SD card in something like this:

• /media/tu_usuario/NombreDeLaTarjeta
• /run/media/tu_usuario/etiqueta in some distributions

If you're using a graphical browser and don't see it directly, you can check it from the terminal with lsblk o df -h to locate where exactly is it mounted?Then you just need to point it there from the application (for example, in RetroArch, go to that path in "Load Content"). If you're interested in knowing if it's possible move an application to the SD card In other systems, that information can guide you on mounting limitations and permissions.

In some complex setups or chroot/emulators, the system can locate fairly deep paths, like /var/.local/...Although it may seem that "everything is buried 50 layers deep", it actually responds to how the runtime environment is encapsulatedIt is even possible that there are hidden directories (with names that begin with .) that are only visible when explicitly listed or when "show hidden files" is enabled. The strange behavior of not seeing .local when listing /var But writing it by hand could be due to file browser filters or permissions.

Monitor SD card copies and cloning with dd y pv

When you make sector-by-sector copies of your SD card, for example a clone of a damaged Raspberry Pi, it is very common to use commands like:

dd if=/dev/sdb of=/dev/sdc

The problem is that dd It does not show progress by default.So it seems like it's frozen, especially with large backups. Traditionally, this is fixed by launching dd in combination with pv (pipe viewer), which shows how much has been transferred, speed, percentage and estimated time.

But if you've already launched dd And since it's been copying for hours, it's not fun to interrupt it just to see the progress bar. That's where an option comes in... pv less known: -d It allows monitoring the file descriptor of a running process..

The typical procedure would be:

1. On another terminal, locate the process PID. dd with ps or similar.
2. Consult your file descriptors in /proc/PID/fd/ with a ls to see which descriptor corresponds to the input/output you are interested in (usually 0 is standard input, 1 is standard output and 2 is errors).
3. Run pv -d PID indicating the corresponding descriptor, so that pv will show you the read/write progress of dd which is already running.

This way you can see it in real time gigabytes copied, elapsed time, speed, percentage, and ETA without having to kill the original process, which is perfect for long operations on large SD cards.

PCMCIA, memory cards and SD cards in older systems

In older laptops and certain embedded systems, cards (including many memory cards) are managed through PCMCIAAlthough it is largely obsolete today, it remains relevant in older or industrial hardware where you can insert flash cards or SCSI/IDE adapters.

Demon cardmgr and file /var/run/stab

The demon cardmgr takes care of monitor PCMCIA socketsIt loads drivers when a card is inserted and runs user configuration scripts. It logs its actions in the system log and signals status changes with beeps (tone patterns that indicate whether the configuration was successful or unsuccessful).

For each socket, cardmgr guard device information in /var/run/stabAn example of content would be:

Socket 0: Adaptec APA-1460 SlimSCSI
0 scsi aha152x_cs 0 sda 8 0
0 scsi aha152x_cs 1 scd0 11 0
Socket 1: Serial or Modem Card
1 serial serial_cs 0 ttyS1 5 65

Each device line includes socket, device class, driver, instance, device name, and major/minor numbersIf your SD card is seen through a PCMCIA adapter as a SCSI disk, it will appear there as sda, sdb, etc.

Utilities cardctl y cardinfo

To check the status of a PCMCIA socket and its configuration, the following is used cardctlTypical commands:

• cardctl config: displays the socket configuration (voltages, I/O windows, etc.).
• cardctl ident: displays the identification information of the inserted card.
• cardctl suspend y cardctl resume: turn off/reactivate the card without downloading modules.
• cardctl resetTry resetting and reconfiguring the card.
• cardctl insert y cardctl ejectThey emulate physical insertion or removal, including loading/unloading drivers and activating/deactivating devices.

If you are in a graphical environment, cardinfo provides graphical view of the status of PCMCIA sockets and an interface for performing most actions of cardctlAgain, in older systems where the SD card travels through a PCMCIA adapter, these tools are key.

Configuration scripts and device classes

The PCMCIA system is based on device classes (network, SCSI, CD-ROM, disk, serial, memory, FTL, etc.) that are associated with scripts in /etc/pcmcia. For example: uterine

• Red: scripts network y network.opts, which configure interfaces such as eth0, routes, DNS, etc.
• SCSI: script scsi and file scsi.opts for SCSI disks, tapes and CD-ROMs.
• Conference proceedings: scripts memory y memory.opts for simple memory cards.
• FTL (Flash Translation Layer): ftl_cs y ftl.opts to use flash memory as block devices.
• ATA / IDE: ide_cs y ide.opts for ATA/IDE disks.

Each script receives a “device address” which identifies the scheme, socket, device type, and other useful data (for example, the MAC address in the case of network interfaces). Based on that address, the script decides How to mount, format, configure IPs, or manage the card.

Flash memory cards, FTL and ATA/IDE devices

In the PCMCIA and similar world, there are several types of memory cards and ways to present them to the system, closely related to how they are identified and assembled.

Simple memory cards and controller memory_cs

The controller memory_cs takes care of all “simple” memory cards and to provide direct access to the PCMCIA memory space. When loaded, it creates both character and block devices, which are used for raw access or for file systems.

Some older cards or static RAM do not have CIS (Card Information Structure)which is what is normally used to identify them. In those cases cardmgr It usually assumes it's a basic memory card and loads memory_csThe size is estimated using heuristics, but if that fails, you can specify it manually when doing dd o mkfs.

Flash memory with FTL

To use flash memory as if it were a "normal" disk, one uses a translation layer called FTL (Flash Translation Layer)The typical process is:

1. Format the flash region with ftl_format -i /dev/mem0c0c (for example), operating on the “raw” interface.
2. Once the FTL is created, treat it as a block device and create the file system: mke2fs /dev/ftl0c0, and then assemble it with mount -t ext2 /dev/ftl0c0 /mnt.

The names ftl0c0, ftl0c0p1etc. encode card number, region and partitionSome cards, such as the Intel 100 Series, reserve the first block for configuration information, and ftl_format He already takes that into account so as not to crush him.

There are also cards in a format Microsoft Flash File System (FFS)However, Linux does not currently support that format, so to use them fully it is usually necessary to reformat them.

ATA/IDE disks via PCMCIA

ATA/IDE drives connected via PCMCIA are managed with ide_cs and the kernel's normal IDE driver. The device address it receives ide.opts It includes schematic, socket, drive serial number, and optionally, partition.

As with SCSI, ide.opts It is executed first for the entire device and, if the variable is defined PARTSthen for each partition. This allows automatically mount certain partitions or add entries to /etc/fstab when an ATA/IDE disk or a compact card connected as IDE is inserted.

On some systems, these drives take longer to initialize than the PCMCIA specification allows. Starting with certain driver versions, ide_cs It tries to probe the device to give it boot space, but with older drivers it was necessary to play with options like unreset_delay when loading the module.

If you want to use an ATA/IDE CD-ROM drive, the kernel must be compiled with the corresponding support (CONFIG_BLK_DEV_IDECD), something that modern distributions have enabled by default.

CPU vulnerabilities: Checking for Meltdown on Linux

Beyond hard drives and SD cards, you might also be interested in Check if your processor is vulnerable to known flaws such as Meltdown. This vulnerability, which affected many processors of different architectures, was discovered in 2018, and recent kernels include mechanisms to report the state.

On Linux, you can check the status of Meltdown and other CPU vulnerabilities by looking at:

/sys/devices/system/cpu/vulnerabilities/

Inside you will find files like meltdown, spectre_v1etc. Showing the contents of meltdown with cat You'll see if the system is working. vulnerable, partially mitigated, or fully protected, along with the measures applied by the kernel.

With all this arsenal of commands (from fdisk -l, lsblk y lsusb to locate your SD card...even tools like Hardinfo, lshw or dmidecode to inventory hardware and PCMCIA, FTL, and ATA/IDE utilities on older systems), you can work with SD cards and other storage devices in Linux quite safely, always knowing which device is which, what it's called in /dev/ and what mount paths your system uses, avoiding surprises and making better use of all the information that the kernel makes available to you. Share this information and more users will know how to do it.