Request for comments, A/B update system

Signed-off-by: sohrab <behdanisohrab@gmail.com>

rfcs/0000-2025-06-01-ab-update-system.md

@@ -0,0 +1,160 @@
+# RFC: ParchLinux A/B Update System
+
+**Author:** Parch Linux Development Team
+**Status:** Draft
+**Version:** 0.1
+**Date:** 2025-06-01
+
+---
+
+## Title: A/B Partition-Based Update System for Parch Linux
+
+### Abstract
+
+This document proposes an A/B (dual-slot) update mechanism for Parch Linux aimed at improving system reliability, reducing update-related downtime, and enabling atomic system upgrades. The A/B update system maintains two bootable system partitions (A and B), where one can be updated while the other remains operational. On successful update, the system switches to the new slot; if the new slot fails, the system rolls back to the previous known-good partition.
+
+---
+
+## 1. Motivation
+
+Traditional Linux update mechanisms (such as `pacman -Syu`) perform in-place updates. This approach can lead to broken systems if the update process is interrupted, packages conflict, or improper configurations are introduced. For mobile and embedded use cases—especially those targeted by Parch Linux—it is essential to:
+
+* Ensure safe and atomic system updates
+* Provide automatic rollback on failure
+* Support offline and staged updates
+* Improve user confidence and minimize recovery interventions
+
+---
+
+## 2. Scope
+
+This RFC defines the architecture, tools, and policy for implementing A/B updates in Parch Linux. It applies to immutable system partitions and is compatible with both mobile (Parch Mobile) and desktop variants.
+
+---
+
+## 3. Design Overview
+
+### 3.1 Partition Layout
+
+* **System\_A**: Primary system slot
+* **System\_B**: Secondary system slot
+* **Boot**: Common bootloader and kernel partition
+* **Data**: User data, persistent and shared between slots
+* **State**: Stores update metadata, active slot flags, and rollback counters
+
+### 3.2 Slot Metadata
+
+Metadata is managed in `/boot/loader/entries` or `/etc/parch-ab-state.json`:
+
+```json
+{
+      "active_slot": "A",
+        "boot_successful": true,
+          "rollback_attempts": 0,
+            "last_update": "2025-06-01T00:00:00Z"
+}
+```
+
+### 3.3 Update Process
+
+1. **Determine inactive slot** (e.g., B if currently booted from A)
+2. **Download & install system image** to the inactive slot
+3. **Mark slot as pending** in bootloader configuration
+4. **Reboot into new slot**
+5. On successful boot, mark as active and successful
+6. On failure, automatically rollback to previous slot
+
+---
+
+## 4. Tooling
+
+### 4.1 `parch-ab-update`
+
+CLI tool to manage A/B system updates.
+
+#### Features:
+
+* Detect active/inactive slot
+* Perform updates using images or delta patches
+* Validate installation
+* Configure boot flags
+* Support integration with pacman hooks or systemd units
+
+### 4.2 Systemd Integration
+
+* `systemd-update-check.service`: Periodic update checks
+* `systemd-ab-boot-check.service`: Validate new slot post-boot
+* `systemd-ab-rollback.service`: Automatically trigger rollback if system is unbootable
+
+---
+
+## 5. Bootloader Support
+
+#### Supported bootloaders:
+
+* **systemd-boot** (recommended)
+* **GRUB** (with custom scripting)
+* **U-Boot** (for embedded/mobile)
+
+Bootloader must support:
+
+* Slot-aware entries
+* Automatic fallback to previous slot
+* Update-safe boot counter (optional)
+
+---
+
+## 6. Update Image Format
+
+Updates can be:
+
+* Full rootfs images (`.img.zst`)
+* OSTree-style delta snapshots (future scope)
+* Compressed tarballs with metadata (`.tar.zst` + `update.json`)
+
+---
+
+## 7. Benefits
+
+* **Atomicity**: Entire rootfs is replaced, no partial updates
+* **Resilience**: Update errors never affect the running system
+* **Rollback**: Fully automated with no user intervention
+* **Fast deployment**: Ideal for mobile and embedded devices
+
+---
+
+## 8. Limitations
+
+* Requires dual storage slots; not feasible on small disks
+* Doubling of system partition size
+* App and system state decoupling needed (flatpak, /home persistence)
+
+---
+
+## 9. Future Work
+
+* Integration with Flatpak, Snap for user apps
+* Secure Boot validation for both slots
+* GUI front-end (`parch-ab-gui`) for end users
+* Support for delta updates and rsync-style patching
+
+---
+
+## 10. Conclusion
+
+Introducing A/B updates to Parch Linux will increase system reliability and make updates more robust—especially on mobile and low-touch systems. With proper bootloader support and system tooling, this method is practical, safe, and user-friendly.
+
+---
+
+## 11. References
+
+* Android A/B Updates: [https://source.android.com/docs/core/ota/ab](https://source.android.com/docs/core/ota/ab)
+* ChromeOS Update System: [https://chromium.googlesource.com/chromiumos/platform/update\_engine/](https://chromium.googlesource.com/chromiumos/platform/update_engine/)
+* OSTree Documentation: [https://ostree.readthedocs.io/en/latest/](https://ostree.readthedocs.io/en/latest/)
+* systemd Boot Loader Specification: [https://systemd.io/BOOT\_LOADER\_SPECIFICATION/](https://systemd.io/BOOT_LOADER_SPECIFICATION/)
+* GRUB Configuration: [https://www.gnu.org/software/grub/manual/grub/html\_node/Booting.html](https://www.gnu.org/software/grub/manual/grub/html_node/Booting.html)
+* U-Boot Bootloader: [https://u-boot.readthedocs.io/en/latest/](https://u-boot.readthedocs.io/en/latest/)
+* Arch Wiki on System Maintenance: [https://wiki.archlinux.org/title/System\_maintenance](https://wiki.archlinux.org/title/System_maintenance)
+* Flatpak Overview: [https://docs.flatpak.org/en/latest/](https://docs.flatpak.org/en/latest/)
+* Snapcraft Update Management: [https://snapcraft.io/docs/keeping-snaps-up-to-date](https://snapcraft.io/docs/keeping-snaps-up-to-date)
+}