-
Notifications
You must be signed in to change notification settings - Fork 1
A B Slot Model
Full detail lives in docs/A_B_SLOT_MODEL.md — this page is the short version.
The Nebula Pad holds two complete, independent boot slots on the same eMMC:
| Partition | Contents | Slot |
|---|---|---|
mmcblk0p5 / p7
|
Stock kernel / rootfs | Slot 1 (stock, 8MiB / 500MB) |
mmcblk0p6 / p8
|
Custom kernel / rootfs | Slot 2 (custom, same sizes) |
mmcblk0p1 |
OTA boot marker | 1MB, shared |
mmcblk0p9 |
rootfs_data (/overlay) |
Shared, not duplicated — 300MB ext4 |
mmcblk0p10 |
userdata (/usr/data) |
Shared, not duplicated — ~6GB ext4 |
p9/p10 are the same physical partitions no matter which slot is active — stock and custom just
use their own subdirectories, so switching slots never exposes or wipes the other side's data.
Two different tools flip the boot marker, depending which OS you're on — that's on purpose, not an inconsistency:
| Tool | Side | How it works |
|---|---|---|
write_ota_marker() in /etc/ota_marker.sh
|
Custom (NebulaOS's own) | Takes an explicit target |
local_set_next_boot_device() in /etc/ota_bin/ota_local_method.sh
|
Stock (Creality's own) | Toggles — flips to whichever side you're not on |
Automatic rollback: the moment a custom boot starts, it resets the marker back to stock. Only
once Moonraker reports klippy_state == "ready" does it flip the marker forward again. One thing
to know: this protection is itself part of the new image's boot sequence, so if the kernel never
gets far enough to run it, it can't help you — that's the one real edge case we haven't tested
directly.
scripts/flash-spare-slot.sh is the safety-hardened flasher — always targets slot 2, refuses if the
target matches whatever's currently running (a real incident taught us to add that check), and
verifies the write with an MD5 read-back. It doesn't flip the marker itself — that's a separate,
deliberate step.
See also: Developer Install From Stock, Developer Recovery.
Building
Install / update / recover
Reference