A/B systems and switching

A/B systems are the core of JelinaOS reliability: the kernel and system each have two complete copies, one used at runtime while updates write to the other. This page describes routine operations involving the two systems.

View the current boot partition

jelina-info

Check the current boot partition, A or B, and system health in the output. The device always runs one system while the other serves as backup.

How system switching works

Currently running System A
        │
        ▼ Write update to System B
        ▼ Automatically switch to B after reboot
        ▼ Boot verification passes → Continue running B
        │
        ▼ Verification fails → Automatically roll back to A (business unaffected)

• Switching is automatic and requires no manual intervention.
• Both system copies back each other up and remain in their factory state.
• All runtime user writes go to the data partition, independently of switching.

Updates and rollback

Normal updates

1. Initiate a system update.
2. The update writes to the standby partition while the device keeps running.
3. After reboot, the device switches to the new system and validates it automatically.

Rollback

If a new version has problems and must be rolled back:

1. Specify the previous version through the update mechanism.
2. The system switches back to the original partition and validates it.
3. The device resumes normal operation.

You can also roll back manually through system rollback services. Root/kernel rollback takes effect after reboot; application area rollback takes effect immediately:

systemctl restart jelina-rollback@root     # Roll back the system partition; takes effect after reboot
systemctl restart jelina-rollback@kernel   # Roll back the kernel partition; takes effect after reboot
systemctl restart jelina-rollback@app      # Roll back the application area; takes effect immediately
systemctl restart jelina-rollback@adv      # Roll back the component area; takes effect immediately

Before rollback, the system checks that actual mounts match configuration to prevent repeated operations.

Boot count and staged recovery

The system tracks boot status using bootcount for staged automatic recovery:

• The count increases at each boot and resets automatically after a successful normal startup.
• If boot fails due to a crash, power loss, or watchdog restart, the count continues increasing.
• After consecutive failures, recovery starts automatically: first attempting recovery boot, then rolling back the system and kernel partitions in sequence if failures continue.
• After successful recovery, normal boot resumes and the count resets.

This mechanism ensures that neither upgrades nor faults trap the device in a reboot loop, allowing it to return automatically to a usable state.

Boot validation

At every boot, the system validates the current partition:

• Validation passes: Start the system normally.
• Validation fails: Try the other system automatically to ensure a usable state.

This provides reliable startup and recovery for unattended deployments.

Common questions

How can I check which partition is running? Run jelina-info to view boot partition information.

Are the two partitions synchronized? No. Both systems maintain their own factory state. User data is centralized in the data partition, while version relationships are maintained through system updates.

Can I select a boot partition manually? Manual selection is unnecessary in normal use because the system manages it automatically. For special maintenance, use the platform’s boot management capabilities. Rockchip provides jelina-rk-bootctl; consult command help for usage.