Overlay file system

Partitions

Most PLCnext Control device have two data storage media types:

An internal flash memory
An SD card

Using an SD card is mandatory for some controllers, and for others it is optional or not possible at all. Check the user manual of your PLCnext Control for more information.

Each data storage medium is divided into one or more partitions.

The PLCnext firmware uses an Overlay File System (short: OverlayFS) to combine contents of a read-only partition with a read-write partition. The read-only partition is always stored in the internal flash memory of the controller. That partition contains the initial firmware and is updated upon each firmware update. In fact, this is a set of 3 partitions:

Active boot partition
The controller boots from the active boot partition.
Inactive boot partition
On delivery, the inactive boot partition is empty. During a firmware update the new firmware is copied into the inactive boot partition. When the copying process is completed, the inactive and the active partitions are swapping their roles. The firmware update is then finished by booting from the just updated partition. The then-inactive partition contains the formerly active firmware as a worst-case fallback (see the note box below).
Recovery partition
The recovery partition contains (a copy of) the firmware that has been installed to the controller during its manufacturing process. The recovery partition plays a role when performing a reset type 2 (see the Resetting section below).

Note: If the boot process failed five consecutive times then the inactive and the active boot partition will change their roles. This behavior has been implemented to keep the PLCnext Control device accessible even if the firmware update fails.

The behavior can also occur when the boot process is interrupted e.g. by power loss. In this case you will observe that the PLCnext Control boots with its previously installed firmware version. To prevent such unintended firmware downgrades, Phoenix Contact recommends that after a finally successful firmware update, the same firmware should be installed once again. This way both the active and the inactive boot partition will contain the same firmware version.

File handling

In an early phase of the boot process the read-only active boot partition is integrated with the read-write partition. The read-write partition is stored either at the external SD card or in a dedicated partition of the internal flash memory if no SD card is present. This integration affects the handling of files during operation of the controller as follows:

New files (not present in the read-only partition) are stored in the read-write partition.
Changed files are stored in the read-write partition. The initial file remains unchanged at the read-only partition. Access to the initial file is not intended.
Removed files are indicated as deleted in the read-write partition and can no longer be accessed. The initial file remains unchanged in the read-only partition.

This means besides its regular path, a file is also listed at one or two further paths in the file system (depending on your PLCnext Control model). These further paths indicate the partition used to store the file. Normally you neither recognize nor have to worry in which partition a certain file is stored because this is managed in the background by the OverlayFS. In rare cases it may be interesting which file is stored in the read-write partition. For these cases both partitions are mapped into the controller’s directory structure:

/media/rfs/ro is the root of the read-only partition. Files in this partition cannot be changed but may be read for information or comparison reasons. Files in this partition are replaced (respectively removed) during a firmware update.
/media/rfs/rw/upperdir is the root of the read-write partition, where new, changed and removed files are stored. Files in this partition are usually not changed during a firmware update. The OverlayFS integrates all files stored here into the root folder of the file system.
Note: After manipulating files in the upperdir folder, it is recommended to reboot the controller. Otherwise it is undetermined when these changes become active.

Example on read-only and read-write partitionExample on read-only and read-write partition

The NTP configuration is listed at /etc/ntp.conf. This file comes with the firmware and is therefore located at /media/rfs/ro/etc/ntp.conf. Once you have edited this file, the changed file will be located at /media/rfs/rw/upperdir/etc/ntp.conf. This file will be used when accessing /etc/ntp.conf. Even if you edit this file back to its initial content, this situation continues.

Note when changing firmware files:

Problems may occur when updating or downgrading the firmware. Let’s consider you have changed a file which comes with the firmware, and later you update the firmware with an updated content of this file. Then your changed file will remain in operation because the content updated by the firmware resides in the read-only partition, and the OverlayFS will prefer the file of the read-write partition.

For this reason it is generally recommended to never edit or remove files that are installed with the firmware. This also applies to changes by means of the operating system, which also includes that some Linux® commands like adduser implicitely write to files which are stored in the OverlayFS. That's why the default admin user has no permission to execute such commands.

If you run into trouble caused by changes in the upperdir folder as described above:

Try to remove the offending file(s) from the upperdir folder, and then restart the controller.
If this does not work (or if you cannot identify the offending files) perform a reset type 1.

Files on an SD card

In case the read-write partition is stored at the SD card, the configuration and project files can easily be transferred to another controller by removing the SD card from one controller and inserting it into another controller. Please note that licenses which are bound to the device are stored at the device. Licenses which are bound to a LIC SD card are stored at this SD card.

Security note: The SD card can be read with a conventional SD card reader at any time, and sensitive data on the SD card can be read by unauthorized persons.

Physically protect the SD card against unauthorized access.
Ensure that unauthorized persons do not have access to the SD card.

Utilization monitoring

The utilization of the read-write partition is monitored by the firmware. The utilzation is shown in the cockpit pages of PLCnext Engineer and WBM.

Furthermore the utilization is shown in IEC 61131‑3 system variables:

In case the utilization of the read-write partition exceeds 90 %, an Arp.Device.Interface.UserPartitionUsage.Critical notification (severity: Warning) is emitted. At the same time, the Arp.Device.Interface.DeviceInterface emits a message “Filesystem usage critical: 90 %” (severity: WARN) to the output.log.
In case the utilization is decreased to 85 % or less after that, another notification Arp.Device.Interface.UserPartitionUsage.Changed (severity: Info) is emitted.

Resetting a device

Reset type 1

All user-specific data in the read-write partition is deleted (settings, programs, users, etc.).
The following directories are cleared:
- /media/rfs/rw/upperdir
- /media/rfs/rw/work
↪ During the following boot process , for firmware files the initial versions on the read-only partition become active again.
From firmware 2023.0 LTS, the directories that are used for containers are also cleared:
- /media/rfs/rw/var
- /media/rfs/rw/data
Licenses installed on the device and bound to the device as well as the (de-)activation of SD card support are retained
(for RFC 4072S or BPC 9102S note the Known Issue below).
The current firmware version remains the same; the device restarts from the same partition and firmware release.

Note: Files that are stored outside the listed directories are not deleted during a reset type 1 nor type 2.
In case you need an complete reset to the delivery state, user data stored outside of the upperdir directory (e.g. OCI container images with pre-2023.0 LTS firmware) has to be deleted manually.

Reset type 2

All changes/deletions as with a reset type 1.
In addition, the firmware of the controller is reset.
Further steps have to be performed, depending on the device type!

Note: The current PLCnext Control device generations have a basically different approach:

The first generation of PLCnext Control devices contains a complete firmware on a separate recovery partition. Out of the box, the same release is placed on the active and the inactive boot partition. The release of that firmware depends on the production date of your hardware. That recovery partition cannot be updated in place. Therefore, after resetting the firmware by reset type 2 and booting from the recovered (initial) firmware, most commonly a firmware update is necessary.
The secure-by-default generation of PLCnext Control devices contains a complete firmware on the active boot partition when unpacked. But after performing a reset type 2 the controller boots into a small recovery system that allows for choosing a firmware release to be installed.

First generation of PLCnext Control devices

Valid with AXC F 1152, AXC F 2152, AXC F 3152, RFC 4072S, RFC 4072R, EPC 1502, EPC 1522, BPC 9102S

The firmware contained in the recovery partition is copied to the inactive boot partition. Thereafter, the inactive and active partitions change their roles, and the reset is finished by booting from the just activated partition that contains the recovered firmware. Note: Depending on the manufacturing date of your device, that recovered firmware may be much older than the one you had before resetting. For updating to a newer firmware, see Operating system: Firmware management.

Show an issue with reset type 2 on BPC 9102S or RFC 4072S Show an issue with reset type 2 on BPC 9102S or RFC 4072S

Known issue

Known for firmware versions from 2022.6 on RFC 4072S and BPC 9102S:

LIC SD cards are only supported from firmware release 2022.6 or newer. If you're using a LIC SD card with an RFC 4072S or BPC 9102S and performing a reset type 2, then the firmware version of the delivery state that is reactivated might not support the LIC SD card type. You first need to update to a firmware version ≥2022.6 that supports the LIC SD card. But because for these controllers an SD card is mandatory, updating the firmware is no longer possible then by means of the WBM.

In this case, proceed as follows:

Connect to the controller via an SFTP client, e.g. by means of WinSCP (see Connecting to the controller).
Upload a firmware container of a version ≥2022.6 to /var/volatile/tmp. This folder is located in the RAM of the controller and has about 4 GB of free memory.
Perform an update with the following command via SSH console:
rauc install /var/volatile/tmp/<updatecontainer>.raucb
↪ The update is executed and the LIC SD card will be active on restart.

Secure-by-default generation of PLCnext Control hardware devices

Valid with AXC F 1252 and upcoming device types

After a reset type 2 on a secure-by-default device, the controller reboots into a small recovery system that allows for choosing a different firmware release to be installed, or to reboot from the already preinstalled firmware. In case a different release is installed, the firmware on the active boot partition is updated and the device reboots again from there. After a reset type 2 the configuration steps have to be done again as if the controller was just taken out of the box. Find the description on how to perform a reset and how to commission the controller in the corresponding user manual to your device. Note: Once the controller is running again, the firmware should be updated again with the same release, so the inactive boot partition will contain the same firmware for a fallback.

Virtual PLCnext Control

For a Virtual PLCnext Control no reset type 2 is possible because no boot partition is present in the container-based controller. For "resetting" a Virtual PLCnext Control, the mounted volumes must be erased and the container needs to be reinstalled.

Means of resetting

Resetting via...		Reset type 1	Reset type 2
Hardware element	You can reset your device via specific operating elements at the hardware (e.g., a reset button on the housing or in an operating display). Find the description on how to perform a reset in the corresponding user manual to your device.	yes	yes
Linux® script	A shell script is available in the controller's file system under /usr/sbin/. When calling the script, you specify the desired reset type; e.g., `sudo recover-plcnext 1` for reset type 1. In the /usr/sbin/ directory you will also find symbolic links with the respective product designation in the name; e.g., `recover-axcf2152 1` for reset type 1 of a PLCnext Control AXC F 2152.	yes	yes
PLCnext Engineer	In the Cockpit editor of in PLCnext Engineer, a reset can be executed with this button:	yes	no
Web-based Management	From firmware versions 2023.0 LTS to 2024.6, a reset type 1 can be executed via the WBM cockpit. From firmware version 2025.0 or newer, a reset type 1 can be executed via the WBM 2: Navigate to the System → Device Maintenance page and scroll down to the Device section.	yes	no