Siemens IOT2000 First Boot: Fixing Slow PuTTY Console via SD Resize

The SIMATIC IOT2020 and IOT2040 are industrial IoT gateways designed by Siemens for edge-of-network data acquisition, MQTT/OPC UA bridging, and protocol conversion between field-level devices and higher-level cloud or SCADA systems. On first power-up from a freshly flashed microSD card, the device executes a one-time filesystem expansion that can render the serial console (and any PuTTY session attached to it) effectively unresponsive for several minutes. This article documents the root cause, the hardware-level diagnostic indicators, the verified recovery procedure, and the configuration steps that follow once the console becomes responsive.

1. Problem Summary

Symptom: After writing the Siemens IOT2000 example image (or any custom Yocto image built with the siemens/meta-iot2000 BSP layer) to a microSD card and applying power, a PuTTY serial session opened at 115200 8N1 on the debug UART (X10 on IOT2020, X11 on IOT2040) is either:

• Extremely slow to the point of unusability (multi-second latency per keystroke)
• Freezes on the boot banner before the login prompt
• Never reaches the iot2000setup console menu for IP configuration

Affected platforms: SIMATIC IOT2020 (6ES7647-0AA00-0YA2), SIMATIC IOT2040 (6ES7647-0AA00-1YA2), and all hardware revisions shipped with the Quark (IOT2020) or ARM Cortex-A8 (IOT2040) SoC.

Affected software: Siemens IOT2000 Example Image up to and including V2.4.0, V2.5.0, V2.6.3, and V3.x, as well as any custom image inheriting the iot2000-init systemd unit that performs the on-first-boot partition resize.

2. Root Cause: On-First-Boot SD Card Resize

The shipped Siemens IOT2000 example images do not pre-expand the root filesystem to fill the entire microSD card. The image file (.wic or .img) is built against a fixed size, typically 1 GB or 2 GB, but the user's microSD card is almost always larger (8 GB, 16 GB, 32 GB). To make the remainder of the card available to the OS, the iot2000-init service (or, on older images, the resize2fs_once script) performs a one-shot automatic resize of the second partition on first boot.

The resize is performed by resize2fs on the ext4 root partition and is gated by a sentinel file such as /var/lib/iot2000/resized or, in older builds, the absence of /.resized. The I/O workload generated by resize2fs on a large card (especially a slow Class 4 microSD) saturates the SD bus and the single-core Quark / Cortex-A8 CPU. Because the UART driver shares interrupt priorities with the MMC subsystem on the IOT2020 platform, the console output stalls while the kernel waits for the MMC I/O to complete. On the IOT2040, the bottleneck is largely CPU-bound: the resize dominates the scheduler and starves the getty that drives the TTY.

The result is a console that appears frozen or pathologically slow. There is no kernel panic and no fault condition; the system is simply busy doing housekeeping.

3. Diagnostic Indicators

Before assuming hardware or image corruption, validate the resize state using the indicators below. These are derived from the stock meta-iot2000 Yocto layer (https://github.com/siemens/meta-iot2000/) recipes and verified against field deployments.

Estimated resize duration by card size, observed on stock Example Image 2.6.3 with the default systemd-resize2fs service:

If the LED pattern above persists beyond 30 minutes, the resize has failed and recovery steps in Section 6 must be applied.

4. Pre-Flight Checklist

Confirm the following before concluding that the console slowness is normal first-boot behavior:

1. Image source. Verify whether the card was flashed with the official Siemens Example Image (recommended for first deployment) or a custom image. Custom images must inherit meta-iot2000 and the iot2000-init service to participate in the resize sequence. See siemens/meta-iot2000 for the supported recipes.
2. Image version. Note the version. The field report references Example Image 2.4.0. Newer images (2.6.3, 3.x) include a faster resize path and updated iot2000setup.
3. PuTTY configuration. Serial line = the COM port of the USB-to-UART bridge (FTDI on most IOT2040 dev kits), speed = 115200, data bits = 8, stop bits = 1, parity = none, flow control = none. Disable "local echo" and "local line editing."
4. Power supply. The IOT2000 expects 9 - 36 V DC on the X1 power connector. Under-voltage on a marginal bench supply can stall the SD controller mid-resize.
5. microSD card health. Cheap or counterfeit cards can fail mid-resize, leaving the filesystem in an inconsistent state. Use a name-brand card from a controlled lot.

5. Recovery Procedure (Recommended Path)

The most reliable fix reported in field deployments and consistent with Siemens guidance is to wait for the resize to complete. The PuTTY session does not need to be closed; it will become responsive again as soon as the iot2000-init service exits.

5.1 Wait for the SD LED to settle

1. Leave PuTTY connected at 115200 8N1.
2. Observe the microSD activity LED on the IOT2000. While the LED is solid green or blinking rapidly, the resize is in progress.
3. When the LED goes dark (or blinks only on shell I/O), the resize is finished. The next kernel log lines on the console will announce the new filesystem size, e.g.:
   [ 6.124879] EXT4-fs (mmcblk0p2): resized filesystem to 7581740 (4k) blocks
4. Press Enter. The login prompt should appear immediately. Default credentials for the Example Image are root / root.

5.2 Confirm the resize completed

After logging in, verify that the root partition now spans the full card:

root@iot2000:~# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk0p2  7.2G  1.1G  5.8G  16% /

Also confirm the sentinel file is in place so the resize is not retried on the next boot:

root@iot2000:~# ls -l /var/lib/iot2000/resized 2>/dev/null \
   || ls -l /.resized 2>/dev/null \
   || echo "Sentinel missing - resize will re-run"

6. Fallback: Re-Flash the microSD Card

If the resize never completes (LED solid for more than 30 minutes) or the filesystem is left inconsistent, re-flash the image. This is the recovery that the field engineer should default to when in doubt.

1. Power down the IOT2000 and remove the microSD card.
2. On a Linux host, write the image with dd or with balenaEtcher (Windows / macOS). Example:
   $ sudo dd if=iot2000-example-image-v2.6.3.wic of=/dev/sdX bs=4M status=progress conv=fsync
3. Re-insert the card, apply power, and observe the LED as in Section 5.1.
4. If the problem reproduces with multiple cards, reflash the card completely (not just overlay-write) to clear partition table artifacts.

7. Configuring Network Access with iot2000setup

Once the console is responsive, configure the network. The Example Image provides the iot2000setup TUI tool, which is the supported way to set the IP address, hostname, DNS, and proxy for first-time commissioning. If the TUI is unreachable, the issue is still the resize; complete Sections 5 or 6 first.

root@iot2000:~# iot2000setup

The tool exposes the following menu items on Example Image 2.4.0 and later:

To set a static IP without the TUI (useful for scripted provisioning), edit /etc/systemd/network/eth0.network directly:

[Match]
Name=eth0

[Network]
Address=192.168.0.100/24
Gateway=192.168.0.1
DNS=192.168.0.1

Then restart the network:

root@iot2000:~# systemctl restart systemd-networkd
root@iot2000:~# ip addr show eth0

8. Firmware and Image Management

The Siemens IOT2000 Example Images are shipped as .wic files that include a complete partition layout: a small boot partition, a recovery partition (used by the on-board updater to revert to factory image), and the main ext4 root partition. The default user on the Example Image is root with password root; change this before connecting the device to a production network.

For custom images, use the siemens/meta-iot2000 Yocto BSP layer. This layer is the canonical source of:

• Kernel configurations for the IOT2020 (Quark) and IOT2040 (ARM)
• The iot2000-init first-boot service that triggers the resize
• The iot2000setup TUI source
• U-Boot and GRUB recipes for the IOT2040, and bootloader recipes for the IOT2020
• Machine configurations: iot2020 and iot2040

To build a custom image, clone the layer and the matching meta-intel or meta-ti BSP into a Yocto workspace, then run:

$ source oe-init-build-env build-iot2040
$ bitbake iot2000-example-image

The resulting .wic in tmp/deploy/images/iot2040/ is the artifact to flash to the microSD card.

9. Verification Checklist After Recovery

Run the following checks once the console is responsive to confirm the device is in a fully commissioned state:

1. Filesystem size. df -h / reports the expected total size of the microSD card minus the boot and recovery partitions.
2. Network connectivity. ip addr show eth0 shows the configured IP and link state UP. ping -c3 192.168.0.1 reaches the gateway.
3. DNS. getent hosts siemens.com resolves if a name server is configured.
4. Time. date returns a sane value. If not, set it with date -s "2024-05-20 12:00:00" or enable NTP via systemd-timesyncd.
5. iot2000setup accessible. Launch the TUI; it should render within one second.
6. Web interface (if enabled). The Example Image from 2.5.0 onward includes Node-RED on port 1880. Navigate to http://<ip>/ for the portal.

10. Troubleshooting Matrix

11. Field-Proven Tips

• Always deploy with an industrial-grade microSD (e.g. Swissbit, ATP, Apacer) rather than consumer cards. The IOT2000 lacks a wear-leveling controller of its own, and a card rated for embedded use will outlast a consumer card by an order of magnitude.
• If you need to shorten the first-boot delay for production staging, pre-expand the root partition on the host before flashing. Use growpart + resize2fs on the .wic, or build the image with IMAGE_ROOTFS_EXTRA_SPACE = "0" and the correct IMAGE_SIZE in your Yocto config.
• Disable the resize service entirely if your image is built at the final size. Remove iot2000-init from SYSTEMD_SERVICE in the image recipe, or set RESIZE_ROOTFS = "0".
• For headless deployments, configure the network in /etc/systemd/network/eth0.network on the host before flashing, so the device is reachable on the network immediately after first boot and the slow console is not in the critical path.
• Document the default password change as part of the commissioning checklist. The root/root default is published and must be replaced before the device touches any production segment.

12. Summary

A sluggish or unresponsive PuTTY console on a freshly flashed Siemens IOT2000 is almost always the on-first-boot resize2fs expanding the root partition. The microSD activity LED is the canonical indicator: solid or fast-blink green means "resize in progress, leave the device alone." The default recovery is to wait, verify the LED transition, and confirm with df -h. If the LED never settles within 30 minutes, re-flash the card with a known-good image. Once the console is responsive, use iot2000setup or a direct edit of the systemd-networkd configuration to bring the device onto the plant network.