IOT2050 Root Password Reset on Industrial OS: mel-setup Recovery

IOT2050 Root Password Reset on Industrial OS: mel-setup Recovery Procedure

The Siemens SIMATIC IOT2050 is an industrial edge gateway built around a TI AM65x SoC (ARM Cortex-A53). When shipped with the pre-installed Industrial OS image on the internal eMMC of the IOT2050 Advanced variant, the device boots into a first-setup wizard (mel-setup) that configures the host name, IP address, locale, time zone, and—critically—the system administrator account. Operators who later attempt to escalate privileges via su find that the standard non-root-to-root escalation does not succeed because the Industrial OS strips the setuid bit from /bin/su and instead routes all privilege operations through sudo, using the credentials of the user that was defined during the wizard. If that user was not granted administrator rights, the result is a true lockout. This article documents the root cause, the precise recovery sequence using sudo mel-setup, and the configuration practices that prevent recurrence on single units and fleets.

1. Hardware and Firmware Identification

Before performing any password reset, confirm the exact variant and firmware of the unit. The IOT2050 ships in two hardware configurations that diverge in storage, recovery options, and processor:

The active firmware and Industrial OS version can be read from the local console or SSH session:

cat /etc/os-release
cat /etc/iot2050-release 2>/dev/null || echo "not an Industrial OS image"
uname -r

The expected output of the second command on a Siemens Industrial OS image is a banner string containing the build date and the meta-iot2050 layer revision. The Yocto baseline for current Industrial OS images is Kirkstone (Yocto 4.0) with the Linux kernel 5.10 long-term branch. Record the kernel version and Yocto revision before attempting any reset, because re-running mel-setup on a non-Industrial-OS image (for example, a vanilla Debian rootfs you flashed yourself) will not re-create the wizard; it will simply report command not found.

2. Problem Description: Locked-Out Root Account

The typical lockout sequence reported by field engineers matches the following pattern:

1. The IOT2050 Advanced is powered on for the first time, connected to a display via DisplayPort and to a USB keyboard.
2. The bootloader (U-Boot) reads the eMMC and launches the Industrial OS kernel with the rootfs mounted from /dev/mmcblk0p2.
3. systemd brings up the serial-getty on ttyS0 and the graphical first-setup wizard (mel-setup) on the DisplayPort output.
4. The wizard prompts for: host name, network configuration (DHCP or static), language, keyboard layout, time zone, and a primary user account with password.
5. During user creation the wizard also asks: Grant administrator privileges (sudo) to this user? The default is Yes. If the operator selects No, the user is created without /etc/sudoers membership and the root account is simultaneously locked.
6. After reboot the operator logs in as the configured user. Typing su prompts for a root password; the password set during the wizard for the user is rejected because the wizard never collected a separate root password—only a user password.

Symptom matrix:

3. Root Cause Analysis

The Industrial OS image follows Debian conventions for account handling but adds a Siemens-specific hardening profile applied by the meta-iot2050 Yocto layer. The hardening profile performs three relevant actions during first boot:

1. Forces the operator to define at least one non-root user through the wizard; the wizard cannot be skipped with Ctrl+C without aborting the entire boot sequence.
2. Locks the root account with passwd -l root unless the wizard is explicitly told to keep it enabled.
3. Installs the configured user into the sudo group only if the Grant administrator privileges prompt was answered with Yes.

The net effect is that an operator who declines sudo rights ends up with neither a usable root login nor a usable sudo path—a true lockout. The only escape valve shipped in the image is the wizard itself, which can be re-invoked to correct the configuration.

The hardening is documented in the upstream meta-iot2050 layer on GitHub. Per the project README, the default username shipped by the layer is root and the operator is required to change the default password upon first login. The Siemens Industrial OS image, however, replaces that single-step prompt with the full graphical mel-setup wizard to align with operator-facing usability, and the wizard itself does not offer a separate set root password field—it only offers to enable or disable the root account and to grant or deny sudo to the new user.

4. Recovery Procedure: Re-running mel-setup

The recovery procedure requires a working sudo path. If sudo is not available because the configured user was denied administrator rights, recover sudo first by re-running the wizard. Two paths are documented below; Path A is the documented Siemens procedure and Path B is the fallback used when sudo itself is broken or unreachable.

4.1 Path A: Standard Recovery (sudo available)

1. Connect to the IOT2050 via serial console (115200 8N1 on the RJ45-to-USB Siemens service cable, 6ES7648-1A series) or via SSH on the address assigned during the wizard.
2. Log in with the configured non-root user.
3. Verify sudo rights: sudo -n true && echo OK || echo NO_SUDO — if the response is OK, proceed to step 4. If the response is NO_SUDO, jump to Path B.
4. Re-open the first-setup wizard: sudo mel-setup
5. The wizard re-launches in console (TTY) mode when no display is attached. Navigate with Tab and the arrow keys. Select User Configuration from the menu.
6. Re-enable the root account by selecting Enable root account and providing a new root password. The password must satisfy the PAM strength policy shipped in the image (minimum length, mixed character classes).
7. If the user still does not have sudo rights, also enable Grant administrator privileges to <user>.
8. Select Apply. The wizard writes /etc/passwd, /etc/shadow, and /etc/sudoers.d/<user>, then prompts for reboot. Decline the reboot if you intend to validate first.
9. Validate from the existing shell: sudo -i whoami should print root; su -c whoami root should prompt for the new root password and print root.
10. If validation passes, reboot: sudo reboot

4.2 Path B: Recovery when sudo is denied or unreachable

If Path A returns user is not in the sudoers file, the user cannot recover the system from the running rootfs without external media. Use one of the following methods:

1. Method B1 — Live USB stick with chroot:
   1. Power down the IOT2050 Advanced.
   2. Insert a USB stick containing a bootable Debian ARM64 live image or the Siemens example image from the Siemens Industry Online Support portal.
   3. Press DEL during U-Boot to enter the boot menu. Select the USB stick. The example image's U-Boot script accepts bootcmd_usb0.
   4. After booting, mount the eMMC rootfs:

      mkdir -p /mnt/emmc
      mount /dev/mmcblk0p2 /mnt/emmc
      mount /dev/mmcblk0p1 /mnt/emmc/boot

   5. Bind-mount pseudo filesystems and chroot:

      mount -t proc /proc /mnt/emmc/proc
      mount -t sysfs /sys /mnt/emmc/sys
      mount -o bind /dev /mnt/emmc/dev
      chroot /mnt/emmc /bin/bash

   6. Inside the chroot, unlock root and reset the password:

      passwd -u root
      passwd root

   7. Optionally re-grant the user sudo rights by adding the user to the sudo group: usermod -aG sudo <username>
   8. Exit the chroot, unmount, and reboot from eMMC:

      exit
      umount /mnt/emmc/{proc,sys,dev,boot,}
      reboot

2. Method B2 — Re-flash the Industrial OS image:
   1. Download the latest Industrial OS image for the IOT2050 from the Siemens support portal. Verify the SHA-256 checksum against the value published on the support page.
   2. Write the image to a microSD card with dd or with the Siemens-provided IOT2050-Flash-Tool on a Windows host.
   3. Insert the SD card, power on while holding the recovery button (SW2 on the Advanced carrier board) until the status LED blinks amber.
   4. The IOT2050 writes the image to the eMMC and reboots into a fresh wizard. This is destructive: any application data, certificates, and OPC UA server configurations are erased.

5. Default Credential Reference

The default account matrix for IOT2050 images is summarised below. Use this table when triaging a recovered unit that may have been reverted to a factory state.

Per the meta-iot2050 README, the layer's default account convention is username root with mandatory first-login password change, and the image is installed on the eMMC for IOT2050 Advanced only. The Siemens Industrial OS overrides that convention by launching the mel-setup wizard; the example image preserves the upstream convention.

6. mel-setup Wizard Reference

The mel-setup binary lives at /usr/sbin/mel-setup on the Industrial OS image and is implemented as a Python dialog that consumes the python3-dialog (whiptail/newt) backend. The wizard writes its state file to /var/lib/iot2050/setup/state.json; deleting this file forces the wizard to re-run on the next boot even after a successful first setup.

The wizard can be invoked in non-interactive (scripted) mode for fleet deployments:

sudo mel-setup --batch --hostname iot-edge-01 \
  --user admin --password 'StrongP@ss1!' \
  --grant-sudo --enable-root --root-password 'R00tP@ss!' \
  --tz Europe/Berlin --locale en_US.UTF-8

The --batch flag suppresses the dialogs and writes the configuration atomically. Always run batch mode through a serial console or systemd journal capture; if --batch fails (for example, due to a password-policy violation), the wizard exits with code 3 and leaves the previous configuration intact.

7. Sudo vs su on the Industrial OS

The Industrial OS image is built on a Debian package set with the sudo package pinned to the LTS release (currently 1.9.x). The image strips the setuid bit from /bin/su as a hardening measure; this is why su returns Authentication failure even when the operator knows the password of a different account. The rationale, per the meta-iot2050 security policy, is to force all privilege escalation through the audited sudo path and to keep a tamper-evident record in /var/log/auth.log.

Operator equivalents:

To re-enable su (against Siemens recommendation) for an air-gapped lab unit:

sudo chmod u+s /bin/su
sudo pam-auth-update --enable su

Undo with sudo chmod u-s /bin/su before returning the unit to production. Leaving the setuid bit in place violates the Siemens security baseline and may be flagged by the SIMATIC Automation Tool security audit.

8. SSH and Serial Console Hardening

After resetting the root password, harden remote access. The Industrial OS image ships with OpenSSH 9.x and enforces the following defaults:

• PasswordAuthentication: enabled on all interfaces
• PermitRootLogin: prohibit-password (key-based root login only)
• AllowUsers: not set (any user can SSH in)
• X11Forwarding: no

Recommended hardening for a production IOT2050:

sudo systemctl edit ssh
# Add:
[Service]
Restart=on-failure

sudo tee /etc/ssh/sshd_config.d/99-iot2050-hardening.conf <<EOF
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
AllowUsers admin
MaxAuthTries 3
LoginGraceTime 30
EOF
sudo systemctl reload ssh

Generate a 4096-bit RSA key on the operator workstation and install it into ~/.ssh/authorized_keys for the admin user before disabling password authentication. A factory reset that wipes /home will also wipe the authorized keys file; keep an offline copy.

9. Verification Checklist

Run this checklist after every password reset or sudo-rights change. A check that fails indicates either a stale state file or a PAM stack regression introduced by a package upgrade.

1. Login as the admin user over SSH: ssh admin@<iot2050-ip>
2. Confirm shell prompt is non-root: whoami should print admin
3. Escalate via sudo: sudo whoami should print root
4. Read release info: cat /etc/os-release | grep PRETTY
5. Confirm mel-setup state file: sudo jq .root_enabled /var/lib/iot2050/setup/state.json should return true
6. Confirm sudo group membership: sudo getent group sudo should contain admin
7. Test serial console login (if the unit is rack-mounted): connect at 115200 8N1, log in as admin.
8. Test forced reboot and re-login: sudo reboot; verify the wizard does not re-launch.

If the wizard re-launches, the state file has been deleted or corrupted. Restore it from a backup or re-run sudo mel-setup and complete every screen.

10. Preventive Configuration for Fleet Rollout

For multi-unit deployments, avoid the lockout class entirely by adopting these defaults in the roll-out procedure:

• Always answer Yes to Grant administrator privileges.
• Keep root login disabled and rely on sudo for all administrative operations.
• Provision the admin user via the SSH public key shipped in a configuration tarball rather than via the wizard password field.
• Centralise sudo logging by pointing /etc/sudoers.d/00-logging at a remote syslog target.
• Lock the /var/lib/iot2050/setup directory after the wizard succeeds: sudo chattr +i /var/lib/iot2050/setup/state.json — this prevents accidental re-invocation of the wizard during automated bootstrap scripts.

11. Related Error Conditions

Other root-related failure modes that look superficially similar to the lockout described above but have different remedies:

12. Standards and Documentation Cross-References

The credential handling and password policy of the Industrial OS image align with IEC 62443-3-3 SR 1.1 (Identification and Authentication) and SR 1.5 (Access Management). The hardening profile is described in the Siemens SIMATIC IOT2050 Operating Instructions manual (available on the Siemens Industry Online Support portal under product family SIMATIC IOT2050) and in the meta-iot2050 layer documentation. When integrating the IOT2050 into a SIMATIC PCS 7 or TIA Portal project, align the S7-1500 CPU password policy with the gateway policy to avoid operator confusion when the same engineer accesses both.

FAQ