System architecture

Four concepts explain the JelinaOS architecture: dual systems, a read-only root, separate data storage, and cloud coordination. Together, they form the foundation for reliability, maintainability, and manageability.

Partition layout

JelinaOS uses a clear storage partition layout, with each partition serving a distinct purpose without interfering with the others. Partitions are identified by fixed labels that remain consistent across platforms. Regardless of the underlying device nodes (sda/nvme on x86 or mmcblk on ARM), the system locates partitions by name:

┌─────────────────────────────────────────────────────────────────────────────┐
│ jelina-boot     Boot partition: bootloader and environment variables         │
│ jelina-kernel-1 Kernel 1 (redundant pair with 2, read-only)                    │
│ jelina-kernel-2 Kernel 2                                                    │
│ jelina-system-1 System 1 (read-only, factory state)                           │
│ jelina-system-2 System 2                                                    │
│ jelina-data     Data partition: all user data and writes                     │
│ jelina-recv     Recovery partition: system repair and factory reset          │
└─────────────────────────────────────────────────────────────────────────────┘

• A/B partitions: Two complete copies of both the kernel and system provide mutual backup.
• Read-only mounting: System partitions are mounted read-only at runtime so programs cannot modify their contents.
• Separate data partition: All user data, configuration, and runtime writes are stored in the Data partition.

Boot sequence

JelinaOS follows the same boot logic regardless of the underlying hardware platform:

Hardware firmware → Bootloader → Select A/B partition → Load kernel → Assemble system → Start business applications
        │                │                │
Platform-specific  Platform-specific  Platform-independent; subsequent flow is identical on all platforms

1. Hardware firmware and the bootloader initialize the platform. Details vary by platform, but are transparent to users.
2. The bootloader reads the boot policy, selects partition A or B, and checks system health.
3. After the kernel starts, the system combines the read-only system partition and writable data partition into a unified runtime view.
4. System services and business applications start in sequence, bringing the device into operation.

System updates follow the same sequence: the new version is written to the standby partition, validated automatically after switching, and rolled back automatically on failure. Sites with limited bandwidth can also use incremental updates to transfer only the changes.

This process ensures that updates affect only the standby partition, leaving the current system running; validation occurs automatically at boot, with automatic switching on faults.

Data flow and isolation

During operation, internal data flows follow strict isolation rules:

        ┌────────────────────────────────────────────┐
        │ Application layer (containers / native apps)│
        └──────────────────────┬─────────────────────┘
                               │ Reads: read-only system
                               │ Writes: data partition
        ┌──────────────────────┴─────────────────────┐
        │ System layer (read-only, immutable)         │
        ├────────────────────────────────────────────┤
        │ Data partition (all user writes)            │
        └────────────────────────────────────────────┘

• Applications can read system content but cannot modify the underlying system.
• All write operations are redirected to the data partition, completely isolated from the system.
• A factory reset restores the system and user-written data to their factory state. Back up important data first.

Cloud coordination

Devices work with the JelinaCloud platform through the built-in device agent:

┌─────────────┐       Status reports / logs       ┌────────────────┐
│ Edge device │ ────────────────────────────────▶ │  JelinaCloud   │
│ JelinaOS    │ ◀──────────────────────────────── │ Cloud platform │
└─────────────┘    Updates / remote operations    └────────────────┘

• Upstream: Device status, runtime metrics, and logs are continuously reported for real-time cloud visibility.
• Downstream: System updates, application releases, and configuration policies are centrally orchestrated in the cloud.
• Secure channel: In production mode, devices communicate with the cloud only through encrypted channels; remote maintenance does not expose them to the public Internet.

Architecture at a glance

Layer	Components	Responsibility
Application	Containerized and native applications	Execute business logic
Runtime	Container runtime, service management, device agent	Application orchestration, system services, cloud coordination
System	Read-only system (Debian / Ubuntu / Kylin, etc.)	Provide a stable, immutable system foundation
Hardware	ARM64 (Allwinner / Rockchip / NXP i.MX), x86_64	Consistent adaptation across platforms

The result is a more secure system, more reliable updates, and simpler operations—the architectural goals of JelinaOS for industrial edge environments.