# SD Card intermittently not recognized after reboot (CC100)

**URL:** <https://www.wago.community/t/sd-card-intermittently-not-recognized-after-reboot-cc100/1731>\
**Category:** Hardware and Linux\
**Tags:** linux, cc100\
**Created:** [April 3, 2025, 1:49pm UTC](https://www.wago.community/t/sd-card-intermittently-not-recognized-after-reboot-cc100/1731 "2025-04-03T13:49:18Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![Dr.Fix](https://sea2.discourse-cdn.com/flex016/user_avatar/www.wago.community/dr.fix/32/498_2.png) [@Dr.Fix](https://www.wago.community/u/Dr.Fix)\
**Post date:** [April 3, 2025, 1:49pm UTC](https://www.wago.community/t/sd-card-intermittently-not-recognized-after-reboot-cc100/1731/1 "2025-04-03T13:49:18Z")

</div>

Hi everyone,

I’m facing a recurring issue with the WAGO CC100 Edge Controller related to SD card detection after rebooting the system.

**Setup & steps taken:**

- Controller: WAGO CC100
- SD card formatted using the **Web-Based Management (WBM)** interface:  
`WBM > Mass Storage > Create New Filesystem on Memory Card`
- Initially, the SD card is recognized correctly, full capacity is shown – everything seems fine.
- `df -h` displays the SD card as expected
- `fdisk -ul` also shows the correct layout

**Issue:** After rebooting the controller (`reboot`), the SD card is **intermittently** not recognized correctly.  
Roughly 50% of the time, it doesn’t show up after boot.

**`dmesg | grep mmc` output shows:**

```auto
[0.998435] mmc0: new SD card at address d555
[1.004944] mmcblk0: mmc0:d555 SD032 30.6 MiB

```

→ It identifies the card, but only as **30.6 MiB** , even though it’s a 32GB card.

**`df -h` output shows:**

```auto
Filesystem Size Used Available Use% Mounted on
/dev/root 581.4M 187.8M 351.1M 35% /
devtmpfs 246.6M 12.0K 246.6M 0% /dev
none 247.1M 8.0K 247.1M 0% /tmp
none 247.1M 156.0K 247.0M 0% /media
none 4.0M 124.0K 3.9M 3% /var/log
none 247.1M 136.0K 247.0M 0% /var/run
none 247.1M 0 247.1M 0% /var/lock
none 247.1M 0 247.1M 0% /var/tmp
none 247.1M 0 247.1M 0% /sys/fs/cgroup
tmpfs 247.1M 168.0K 246.9M 0% /run
/dev/mmcblk1p2 16.0M 644.0K 15.3M 4% /boot/loader
/dev/mmcblk1p6 1.1G 184.4M 851.4M 18% /home
/dev/mmcblk1p4 6.7M 45.0K 6.1M 1% /settings
/dev/mmcblk1p3 6.7M 45.0K 6.1M 1% /log
none 247.1M 136.0K 247.0M 0% /var/run/netns
none 247.1M 156.0K 247.0M 0% /media/sd/docker

```

where `/media/sd/docker` usually should be mounted on /dev/mmcblk0p1.

Also, **`fdisk -ul` output shows:**

```auto
Disk /dev/mmcblk0: 30 MB, 32096256 bytes, 62688 sectors
979 cylinders, 4 heads, 16 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Disk /dev/mmcblk0 doesn't contain a valid partition table
Disk /dev/mmcblk1: 3728 MB, 3909091328 bytes, 7634944 sectors
473 cylinders, 256 heads, 63 sectors/track
Units: sectors of 1 * 512 = 512 bytes

Device Boot StartCHS EndCHS StartLBA EndLBA Sectors Size Id Type
/dev/mmcblk1p1 0,0,2 1023,255,63 1 7634943 7634943 3727M ee EFI GPT
Partition 1 has different physical/logical end:
     phys=(1023,255,63) logical=(473,101,37)

```

where I can find that `Disk /dev/mmcblk0` has issues with the partition table – issues that may have been caused during formatting via the WBM or the corresponding command:  
`/etc/config-tools/format_medium device=mmcblk0 volume-name=docker-sd fs-type=ext4`?

**Technical insight – format\_medium script behavior:**  
During formatting via the WBM or using the manual command  
`/etc/config-tools/format_medium device=mmcblk0 volume-name=docker-sd fs-type=ext4`,  
the script internally uses the following line to partition the device:

```auto
echo ",,${part_type},," | flock "$deviceName" sfdisk -f "$deviceName" > /dev/null 2>&1

```

Here’s what this does:

- `sfdisk` is used to write a **new partition table** to the device.
- `",,${part_type},,"` tells `sfdisk` to:
  - create **one partition** using the **entire available space** (no start or end sector specified),
  - with the partition type determined by the selected filesystem:
    - `"83"` for **ext4**
    - `"b"` for **FAT32**

- `flock` ensures that **no other process** is accessing the device during this operation.
- This partitioning step happens **after deleting any existing GPT or MBR** , and before formatting with `mkfs`.

This reinforces my suspicion that the issue may not lie in how the partition is created, but rather in how the system (CC100) picks it up during or after boot – especially given that GParted consistently shows everything as expected.

**What I’ve tried so far:**

- Multiple CC100 controllers
- Multiple SD cards (different delivery batches)
- Same issue: the card is either detected correctly or not – it’s inconsistent

**Additionally:** I’ve already tried the suggestions from [this community thread](https://www.wago.community/t/cc100-docker-daemon-issues-after-reboot/739), which mainly focuses on issues with the Docker daemon startup, related to the “delayed” SD card recognition:

- Set `timeout=20` (instead of 10) in **`/usr/local/bin/wago-automount`**
- Added `sleep 180` in **`/etc/init.d/dockerd`**

Unfortunately, this hasn’t helped – the issue persists.

**Extra observation:**  
When I take an SD card that was **not recognized properly** by the CC100 (or shows only 30.6 MiB and no partition), and plug it into another system and check it with **GParted** , I can see the **full capacity (32 GB)**. The partition is there, and it’s properly formatted as **ext4** – everything looks normal from an external system’s perspective.

**Important note:**  
We are **not** using the official WAGO-branded SD card.  
However, we have now provisioned over **300 CC100 controllers** with the same 32 GB micro SD cards and identical setup / identical setup procedure, and this issue has **only started appearing this week**.

**My questions:**

1. Why would the SD card sometimes be detected as only 30.6 MiB?
2. Any way to make the mount process more reliable during boot? We are using FW Version 04.01.10(23) - could this issue be fixed using a more recent FW Version?
3. Any tricks for formatting or automounting that might help?

Any help or insights would be greatly appreciated!

Best regards

---

<div class="post-metadata">

**Author:** ![WagoKurt](https://sea2.discourse-cdn.com/flex016/user_avatar/www.wago.community/wagokurt/32/11_2.png) [@WagoKurt](https://www.wago.community/u/WagoKurt)\
**Post date:** [April 3, 2025, 5:13pm UTC](https://www.wago.community/t/sd-card-intermittently-not-recognized-after-reboot-cc100/1731/2 "2025-04-03T17:13:31Z")

</div>

Hello  
Can you confirm the SD card is a high quality model (SanDisk for example). Some lower quality cards have been found to have quality issues.  
Curious, have you tried smaller cards, 16GB, 8GB etc?

---

<div class="post-metadata">

**Author:** ![Dr.Fix](https://sea2.discourse-cdn.com/flex016/user_avatar/www.wago.community/dr.fix/32/498_2.png) [@Dr.Fix](https://www.wago.community/u/Dr.Fix)\
**Post date:** [April 3, 2025, 5:37pm UTC](https://www.wago.community/t/sd-card-intermittently-not-recognized-after-reboot-cc100/1731/3 "2025-04-03T17:37:15Z")

</div>

Hi @WagoKurt, thanks for the reply.

Yes, I can confirm that. We use SanDisk cards purchased from a trusted retail shop. We still have some 16 GB cards (also SanDisk) lying around, and I’ll run another test with those tomorrow to see if things work better with them. I’d be surprised if that made a difference, since we’ve never had issues with the 32 GB version during many other provisioning processes — but I’ll give it a try just to be sure. I’ll share some feedback on that during the course of tomorrow.

My second approach would be to give the latest firmware (version 28) a try, in case the test with the 16 GB cards doesn’t help either. But if you have any further input, checks, or logs for me to look into, I’ll be more than happy to follow up on them.

---

<div class="post-metadata">

**Author:** ![WagoIcard](https://sea2.discourse-cdn.com/flex016/user_avatar/www.wago.community/wagoicard/32/1508_2.png) [@WagoIcard](https://www.wago.community/u/WagoIcard)\
**Post date:** [April 4, 2025, 8:10am UTC](https://www.wago.community/t/sd-card-intermittently-not-recognized-after-reboot-cc100/1731/4 "2025-04-04T08:10:10Z")

</div>

Hello, I think there is a problem when something is trying to use the SD card before it is mounted and so it create the folder SD instead of waiting for the link to be there.  
For myself I’ve made a symlink in the codesys folder:  
`ln -s /media/sd/ /home/codesys/PlcLogic/sd`  
if the SD card is not there the link will be broken and the process trying to use the SD card will return an error or will wait.

Maybe creating an equivalent link somewhere and use this instead of the media/sd will work better ?  
Just a suggestion. I haven’t tested this solution for your current problem.

---

<div class="post-metadata">

**Author:** ![Dr.Fix](https://sea2.discourse-cdn.com/flex016/user_avatar/www.wago.community/dr.fix/32/498_2.png) [@Dr.Fix](https://www.wago.community/u/Dr.Fix)\
**Post date:** [April 4, 2025, 1:29pm UTC](https://www.wago.community/t/sd-card-intermittently-not-recognized-after-reboot-cc100/1731/5 "2025-04-04T13:29:10Z")

</div>

@WagoKurt, today we tested another batch of SD cards. Also SanDisk, but this particular batch has been lying around here for a while. Interestingly, the setup worked reliably again with these cards – both 16 GB and 32 GB versions 🥳. The CC100 correctly detects the partitions, even after reboots. What exactly is different about the non-working cards (aside from the production batch) still remains a mystery to me – especially since they’re recognized just fine on other Linux systems (e.g., via GParted), just not on the CC100 🤔.

I’ll still give it a shot and see if I can get the currently problematic 32 GB cards to work with the newer FW version 28. I’ll probably be able to share some feedback on that next week. However, I suspect the root cause might indeed be related to those cards from that specific delivery batch. We’ve already ordered new ones and will test those as well.

@WagoIcard thanks for the hint regarding the symlink approach – I wouldn’t have thought of that myself so quickly. Definitely something worth trying. That said, I’m still unsure whether it would truly help in our specific case. We’re using `/media/sd` explicitly in combination with `/etc/docker/daemon.json` to offload Docker onto the SD card. Since our use case relies heavily on Docker environments, it’s critical that the containers start reliably. If implementing a custom retry/check mechanism is required merely to verify storage availability, the symlink may not effectively address the issue for the Docker daemon, as it depends directly on that mount point — and the symlink would simply be an additional layer which, in this case, would add more overhead than value. Still, I’ll definitely keep the idea in mind for other use cases – using a symlink could make a lot of sense when handling things directly within the (Docker) applications that require the file system.

---

<div class="post-metadata">

**Author:** ![Dr.Fix](https://sea2.discourse-cdn.com/flex016/user_avatar/www.wago.community/dr.fix/32/498_2.png) [@Dr.Fix](https://www.wago.community/u/Dr.Fix)\
**Post date:** [April 7, 2025, 10:09am UTC](https://www.wago.community/t/sd-card-intermittently-not-recognized-after-reboot-cc100/1731/6 "2025-04-07T10:09:57Z")

</div>

We received our new batch of SD cards today (both 32 GB and 16 GB) and immediately ran some additional setup tests. Interestingly, the issues we were experiencing no longer occur with the new cards.

> [@Dr.Fix](#):
>
> I’ll still give it a shot and see if I can get the currently problematic 32 GB cards to work with the newer FW version 28. I’ll probably be able to share some feedback on that next week. However, I suspect the root cause might indeed be related to those cards from that specific delivery batch. We’ve already ordered new ones and will test those as well.

Additionally, we ran one more test last Friday using FW version 28 and the older, problematic cards – unfortunately without success. It really seems like the issue was tied to that specific batch of SD cards, even though we still can’t quite explain what the root cause was.

Since everything is now working smoothly again, I’ll go ahead and mark this thread as **resolved** , as the problem appears to be less related to the CC100 itself and more to the SD cards.

Thanks to everyone who contributed and shared their insights!

---

<div class="post-metadata">

**Author:** ![WagoIcard](https://sea2.discourse-cdn.com/flex016/user_avatar/www.wago.community/wagoicard/32/1508_2.png) [@WagoIcard](https://www.wago.community/u/WagoIcard)\
**Post date:** [April 7, 2025, 11:58pm UTC](https://www.wago.community/t/sd-card-intermittently-not-recognized-after-reboot-cc100/1731/7 "2025-04-07T23:58:17Z")

</div>

Hello, if you can it would be interesting to see if the cad have some bad memory block which make its controller take longer time to enable it and put it online.

---

<div class="post-metadata">

**Author:** ![quenorha](https://sea2.discourse-cdn.com/flex016/user_avatar/www.wago.community/quenorha/32/429_2.png) [@quenorha](https://www.wago.community/u/quenorha)\
**Post date:** [April 8, 2025, 5:59am UTC](https://www.wago.community/t/sd-card-intermittently-not-recognized-after-reboot-cc100/1731/8 "2025-04-08T05:59:27Z")

</div>

It would be interesting to see if the SD cards you have support S.M.A.R.T feature

> [@How To get memory card life time expectancy](https://www.wago.community/t/how-to-get-memory-card-life-time-expectancy/1679):
>
> If you wish to get the life time expectancy of a WAGO memory card, here is a solution. 8Gb WAGO memory card support S.M.A.R.T (Self-Monitoring, Analysis and Reporting Technology), and thanks to a software tool from Swissbit, advanced diagnosis data can be read out, either with a computer software, or even with a small binary that you can install directly in the controller. ./sbdm-cli Swissbit Device Manager 1.2.4 Please wait while SBDM is scanning for devices... /dev/mmcblk0 ------------ …

---

<div class="post-metadata">

**Author:** ![WagoIcard](https://sea2.discourse-cdn.com/flex016/user_avatar/www.wago.community/wagoicard/32/1508_2.png) [@WagoIcard](https://www.wago.community/u/WagoIcard)\
**Post date:** [April 10, 2025, 12:05am UTC](https://www.wago.community/t/sd-card-intermittently-not-recognized-after-reboot-cc100/1731/9 "2025-04-10T00:05:09Z")

</div>

Indeed, but can we do this in the PLC (Like PFC200 or PFC300 ?)

---

<div class="post-metadata">

**Author:** ![Dr.Fix](https://sea2.discourse-cdn.com/flex016/user_avatar/www.wago.community/dr.fix/32/498_2.png) [@Dr.Fix](https://www.wago.community/u/Dr.Fix)\
**Post date:** [April 11, 2025, 12:01pm UTC](https://www.wago.community/t/sd-card-intermittently-not-recognized-after-reboot-cc100/1731/10 "2025-04-11T12:01:45Z")

</div>

I analyzed the SD cards using my Ubuntu machine and the “Disks” tool. Everything looks fine — no irregularities, errors, or damaged blocks were found.  
I also ran the two tools h2testw and Validrive on my Windows machine, again without any issues or warnings. Do you know / recommend other specific tools to check the blocks?

---

<div class="post-metadata">

**Author:** ![Dr.Fix](https://sea2.discourse-cdn.com/flex016/user_avatar/www.wago.community/dr.fix/32/498_2.png) [@Dr.Fix](https://www.wago.community/u/Dr.Fix)\
**Post date:** [April 11, 2025, 12:05pm UTC](https://www.wago.community/t/sd-card-intermittently-not-recognized-after-reboot-cc100/1731/11 "2025-04-11T12:05:32Z")

</div>

Unfortunately I wasn’t able to get the S.M.A.R.T. tool to run. On the CC100 I’m getting errors indicating that FUSE is missing.

Is it even possible to use the `sbdm-cli` binary directly on the CC100, or would I need to run it in a Docker container that includes the necessary libraries? I couldn’t get it running on other distros either (like Ubuntu) — though I assume it was designed specifically for WAGO devices?

Here’s what I tried:

```auto
curl -k -o sbdm-cli https://raw.githubusercontent.com/quenorha/sbdm-cli/refs/heads/main/sbdm-cli && chmod +x sbdm-cli
./sbdm-cli

```

Result:

```auto
dlopen(): error loading libfuse.so.2

AppImages require FUSE to run.
You might still be able to extract the contents of this AppImage
if you run it with the --appimage-extract option.
See https://github.com/AppImage/AppImageKit/wiki/FUSE
for more information

```

Running it with the additional parameter `--appimage-extract-and-run` will result in:

```auto
./sbdm-cli --appimage-extract-and-run
Swissbit Device Manager 1.2.4

Please wait while SBDM is scanning for devices...
libusb usb_find_busses failed: has usb_init() been called?
No supported disks found!

```

Any ideas or suggestions?

---

<div class="post-metadata">

**Author:** ![quenorha](https://sea2.discourse-cdn.com/flex016/user_avatar/www.wago.community/quenorha/32/429_2.png) [@quenorha](https://www.wago.community/u/quenorha)\
**Post date:** [April 11, 2025, 12:31pm UTC](https://www.wago.community/t/sd-card-intermittently-not-recognized-after-reboot-cc100/1731/12 "2025-04-11T12:31:38Z")

</div>

This is weird, it does work on my CC100.

Which CC100 is it ?  
Which Firmware version are you running ?

I used the latest, FW28.

Note that Swissbit also provide a S.M.A.R.T tool for Windows :

> **[Swissbit Device Manager - Swissbit](https://www.swissbit.com/en/support/swissbit-device-manager/)**
>
> The Swissbit management tool to analyze the usage of Swissbit SSDs and cards

---

<div class="post-metadata">

**Author:** ![Dr.Fix](https://sea2.discourse-cdn.com/flex016/user_avatar/www.wago.community/dr.fix/32/498_2.png) [@Dr.Fix](https://www.wago.community/u/Dr.Fix)\
**Post date:** [April 11, 2025, 3:31pm UTC](https://www.wago.community/t/sd-card-intermittently-not-recognized-after-reboot-cc100/1731/13 "2025-04-11T15:31:20Z")

</div>

We used a CC100 751-9301 with FW version 04.01.10(23). That version is already a bit outdated, so I’ve now also tried it with FW28 (the latest available firmware).

I’m getting the following output when running `./sbdm-cli`:

```auto
Swissbit Device Manager 1.2.4

Please wait while SBDM is scanning for devices...
libusb usb_find_busses failed: has usb_init() been called?
No supported disks found!

```

So, the FUSE error is gone — but the SD card (a standard SanDisk card) doesn’t seem to be _detected_, or maybe it’s just being marked as _unsupported_ by the tool?

Since I used an SD card from the new delivery batch, it currently seems to be recognized again – at least it shows up with `df -h`.

```auto
Filesystem Size Used Available Use% Mounted on
/dev/root 581.0M 344.1M 194.4M 64% /
[... omitted]
/dev/mmcblk0p1 29.1G 24.0K 27.6G 0% /media/docker-sd

```

My assumption is that the SD cards might simply not support S.M.A.R.T., but I’m wondering if the issue could also be related to `usb_init()` not being triggered correctly?

---

<div class="post-metadata">

**Author:** ![quenorha](https://sea2.discourse-cdn.com/flex016/user_avatar/www.wago.community/quenorha/32/429_2.png) [@quenorha](https://www.wago.community/u/quenorha)\
**Post date:** [April 22, 2025, 5:51am UTC](https://www.wago.community/t/sd-card-intermittently-not-recognized-after-reboot-cc100/1731/14 "2025-04-22T05:51:52Z")

</div>

Your assumption seems correct, this is the kind of result I get when I use a regular memory card not supporting S.M.A.R.T.
