Choosing microSD for a Linux SBC Boot Drive: What to Test Beyond A2
- An A2 mark describes card performance under defined conditions; it does not establish boot compatibility or application speed on a particular board.
- Separate image/bootloader detection, Linux root-filesystem mounting and application startup when diagnosing a failure.
- Use the exact board, software image and card configuration for repeated boot, update and recovery tests before purchasing a batch.
A2 is a useful screening mark for a microSD card that will run an operating system, but the purchase decision depends on the board and its workload. Verify that the exact single-board computer (SBC) boots the intended image, starts the application on time, handles updates and recovers within the project's limits. A fast result in a PC reader does not establish any of those outcomes on the target host.
The SD Association describes A2 as at least 4,000 random-read IOPS, 2,000 random-write IOPS and 10 MB/s sustained sequential performance under its specified conditions. It also describes command queuing and cache features associated with A2 and the host support needed to benefit from them. These are class criteria, not a guarantee of a given Linux boot time, endurance or compatibility. Our speed-class explanation covers the markings themselves.
The A2 figures are measured under defined SD test conditions with suitable equipment and a capable host. They are not predicted results from a customer's everyday PC and ordinary card reader: that reader and its host may not support the A2 features or reproduce the test setup. Record the actual reader and host used for any comparison, then measure the boot and application workload on the target SBC.
Check the board before comparing cards
Obtain the board maker's boot-media and host-interface documentation. Record the exact board revision, firmware or bootloader version, supported card capacity family, intended OS image and any host features relevant to A2. If host support is undocumented, mark it unknown and validate the candidate on the board. A card's own logo does not show which features a particular host uses.
Raspberry Pi documents different 4 KB random I/O results for its official A2 card on Pi 4 and Pi 5, alongside different interfaces. This is an example of host-dependent results for one documented product; it is not a benchmark for other cards or SBCs. Raspberry Pi also documents microSD as common boot media and recommends writing and verifying an OS image with Imager. Other boards can use different image preparation, boot order and storage paths, so follow their own manuals. In particular, the Raspberry Pi OS FAT boot partition is a Raspberry Pi implementation detail, not a universal Linux SBC layout.
Find the stage where boot or startup fails
“The card will not boot” can describe different failures. Capture the diagnostic output the board actually provides and note the last successful stage:
| Stage | Evidence to collect | Question to answer |
|---|---|---|
| Image preparation and early boot | Image identity and verification result; bootloader or board diagnostic messages. | Was the intended image written correctly, and did the board find the required boot files or data? |
| Kernel and root filesystem | Kernel messages, detected storage device and mount errors if exposed. | Did Linux detect the card and mount the intended root filesystem? |
| Services and application | Service logs, application-ready time and I/O errors. | Did the OS boot but the application stall, time out or fail to write? |
The available logs vary by board. A missing serial message alone does not prove a card fault; boot settings, power and image preparation may need investigation. Compare a known-working card and the candidate under the same board, power supply, firmware and image before assigning the cause.
Run the actual operating tasks
Use dedicated test cards with copies of the production image. Set pass limits from the device's job: how quickly must it become ready, what update window is allowed, how much data may be lost after interruption, and what temperature and duty cycle matter? There is no universal boot-time or random-IOPS threshold for all Linux SBCs.
| Test on the target board | Record and judge |
|---|---|
| Image write and verification | Exact image version/hash, write method, verification result and first boot. |
| Repeated cold starts and software reboots | Successful starts, time to application ready, last stage on any failure and relevant log entries. |
| Small-file and application work | Package or database tasks, logging rate, response time and errors during the real concurrent workload. |
| Update or maintenance event | Time and free space required, continuing application behavior and recovery if interrupted. |
| Higher planned fill level | Remaining free space, task latency and whether the application still meets its own limit. |
| Planned power interruption on test equipment | What data was acknowledged before the cut, what survives, filesystem state and time to useful operation after restart. |
| Required environment | Board and card operation within the application's stated temperature and power conditions. |
A controlled power-cut test on backed-up test media can reveal a recovery problem. It cannot prove that all uncommitted data will survive every future interruption. Define what the application must retain and compare observed results with that requirement. Do not run destructive benchmarks on the only copy of an OS or customer data.
Hand procurement a reproducible configuration
Record the approved board and firmware, OS/image checksum, card model and capacity, available revision or lot identifiers, test conditions, application write volume, target life and acceptance results. Specify which changes require a new sample and repeat test; a label or capacity alone does not reproduce the configuration that passed. If a card or host attribute cannot be identified, state the gap rather than inventing it.
For a quote request or OEM discussion, provide the board's card-slot specification, image size, expected write workload, environment and sample-test criteria. Kalstor can discuss a candidate microSD configuration against those inputs; the board owner must verify boot, application behavior and release acceptance on the actual system.
References
We publish measured usable capacity and define trial-batch verification against the quoted product and agreed test scope.