overlayroot vs A/B 업데이트, 임베디드에서 무엇을 고르나

overlayroot는 Ubuntu의 cloud-initramfs-tools 계열 패키지로, initramfs 단계에서 하위 루트를 읽기 전용으로 두고 그 위에 쓰기 가능한 overlay(대개 tmpfs) 를 올립니다. A/B 업데이트는 루트 파일시스템을 두 슬롯(또는 그 이상) 으로 두고, 비활성 슬롯에 이미지를 쓴 뒤 부트로더가 전환·롤백하는 원자적 시스템 업데이트 모델입니다. RAUC·Mender·SWUpdate 문서가 말하는 dual-bank / redundant slot이 여기에 해당합니다.

이 글은 루트 파일시스템 보호·업데이트 전략만 다룹니다. Device Tree Overlay(.dtbo) 적용 확인·심볼 디버그는 별도 주제입니다. 보드 실화·가격은 넣지 않으며, Ubuntu overlayroot 패키지·manpage와 A/B OTA 공개 문서(RAUC basics, U-Boot A/B 흐름)를 기준으로 합니다.

각각의 실패 모드는?

한 줄 답: overlayroot의 전형적 실패는 “쓰였다고 믿은 변경이 재부팅 후 사라지거나, 영구 쓰기가 lower를 깨뜨리는 것” 이고, A/B의 전형적 실패는 “비활성 슬롯 기록·부트 전환·헬스 확인 중 한 단계가 깨져 롤백되거나 부트 선택이 꼬이는 것” 입니다.

overlayroot 쪽

문서·패키지 동작상 핵심은 다음과 같습니다.

휘발성 upper — overlayroot="tmpfs"이면 런타임 쓰기는 upper(tmpfs)에만 쌓입니다. 재부팅하면 upper가 비워지고 lower(원래 루트)는 그대로입니다. “설정이 저장됐다”고 착각하면 실패처럼 보입니다.
영구 변경 경로 — lower를 바꾸려면 overlayroot-chroot(하위 FS를 쓰기 가능하게 remount한 뒤 chroot) 또는 lower 마운트 경로를 직접 수정하는 식의 명시적 절차가 필요합니다. 여기서 전원 차단·불완전 쓰기가 나면 보호하려던 그 이미지가 손상될 수 있습니다.
initramfs 전제 — overlayroot는 초기 사용자 공간(initramfs) 훅으로 동작합니다. initrd 없이 부팅하면 설정이 있어도 overlay가 안 올라갑니다. (클라우드 이미지의 initrd-less 부팅 등이 대표 함정으로 알려져 있습니다.)
설정 계층 — /etc/overlayroot.conf와 이를 덮는 /etc/overlayroot.local.conf, 그리고 커널 커맨드라인의 비활성 옵션 등을 혼동하면 “켜 둔 줄 알았는데 RW 루트” 상태가 납니다.
보호 범위 ≠ 업데이트 원자성 — 런타임 변조·실수 쓰기를 줄이는 데는 강하지만, 실패한 시스템 이미지 교체를 이전 슬롯으로 자동 되돌리는 메커니즘은 아닙니다.

A/B 쪽

Bootlin의 U-Boot A/B 설명과 RAUC basics가 공통으로 짚는 실패 지점은 다음과 같습니다.

비활성 슬롯 기록 실패 — 플래시/검증이 실패하면 현재(활성) 슬롯을 유지하는 것이 정상입니다. “업데이트 앱이 실패했다”로 끝나는 경우가 많습니다.
기록은 됐지만 부팅 실패 — 새 슬롯으로 전환한 뒤 커널 panic·watchdog 리셋·헬스 체크 실패가 나면, 부트로더의 bootcount / bootlimit / altbootcmd(또는 RAUC mark-good/mark-bad와 연동된 선택 로직)로 이전 슬롯으로 폴백해야 합니다. 이 고리가 없으면 “벽돌에 가까운” 상태가 됩니다.
부트로더 환경 손상 — 슬롯 지시 변수(bootpart, upgrade_available 등 구현체별 이름)가 깨지면 어느 파티션이 활성인지 사용자 공간과 부트로더가 어긋납니다.
저장 공간·레이아웃 — 대칭 A/B는 루트 용량을 대략 두 배 씁니다. 파티션 크기 불일치·잘못된 slot class 매핑은 “설치는 됐는데 부팅 슬롯이 아님”으로 나타납니다.
mark-good을 안 함 — 새 이미지가 떠도 사용자가 status mark-good류를 커밋하지 않으면, 다음 리부트에서 다시 실패로 간주되어 롤백될 수 있습니다.

구분	overlayroot	A/B 슬롯
보호 대상	런타임 쓰기·실수로 lower 오염	실패한 시스템 이미지 교체
실패 시 기본 모습	재부팅 후 변경 소실 / lower 손상(영구 쓰기 실수)	활성 슬롯 유지 또는 이전 슬롯 롤백
전제	initramfs + overlay 설정	이중(이상) 슬롯 + 부트로더 연동

OTA와 맞물림은?

한 줄 답: A/B는 OTA를 위해 설계된 슬롯 전환 모델이고, overlayroot는 OTA 프레임워크가 아니라 런타임 루트 보호 계층입니다. 둘을 같은 “업데이트 방식”으로 놓으면 선택 기준이 흐려집니다.

overlayroot와 OTA

필드에서 apt upgrade로 upper에만 쌓인 패키지 변경은 재부팅 후 사라집니다(tmpfs upper).
실제 이미지 갱신은 lower를 고치는 일(오프라인 리플래시, overlayroot-chroot 안에서의 패키지/이미지 작업, 공장 이미지 재배포)에 가깝습니다. 그 경로는 원자적 롤백 슬롯을 기본으로 주지 않습니다.
따라서 “항상 연결·원격으로 안전하게 루트를 갈아끼워야 하는 제품”의 주 전략으로 overlayroot만 고르기는 어렵습니다. 키오스크·데모·변조 방지처럼 루트는 거의 안 바꾸고 런타임만 버리고 싶은 쪽에 맞습니다.

A/B와 OTA

공개 문서상 공통 흐름은 대략 다음과 같습니다.

비활성 슬롯에 번들/이미지 기록·서명 검증
부트로더에 “다음 부팅은 새 슬롯” 표시
재부팅 후 헬스 확인 → 성공 시 commit(mark-good), 실패 시 폴백
(선택) 델타·스트리밍·아티팩트 저장소 등 프레임워크별 확장

RAUC는 슬롯 클래스·그룹·부트 확인을 시스템 설정으로 묶고, Mender/SWUpdate도 U-Boot 환경 변수와 맞물리는 dual rootfs 패턴을 전제로 합니다. OTA 요구사항(서명, 중단 후 복구, 플릿 보고)이 있으면 A/B(또는 동등한 리던던트 슬롯) 쪽이 문서와 도구 생태계에 맞습니다.

함께 쓰는가?

개념적으로 읽기 전용으로 배포된 슬롯 위에 일시 overlay를 두는 제품도 있으나, 그때도 어느 슬롯이 활성인지·실패한 업데이트를 되돌리는지는 A/B(또는 동등 메커니즘)가 담당합니다. overlayroot만으로 A/B의 롤백을 대체하지는 마십시오.

개발 이미지에선?

한 줄 답: 개발·실험 이미지는 쓰기 가능한 단일 루트(또는 overlayroot 비활성)가 기본에 가깝고, 생산·필드 이미지는 업데이트 정책에 따라 overlayroot 보호 또는 A/B 슬롯을 켭니다.

실무 선택 기준(문서가 가리키는 역할에 맞춘 정리):

패키지·디버그·로그를 디스크에 남겨야 할 때 — overlayroot tmpfs는 재부팅마다 지웁니다. 개발 이미지에서는 overlayroot=disabled(커널 커맨드라인) 또는 설정 비활성으로 일반 RW 루트를 쓰는 편이 문서상 우회 경로와 일치합니다.
필드와 동일한 보호를 재현할 때 — 스테이징에서만 overlayroot="tmpfs"를 켜 보고, 영구 변경은 overlayroot-chroot로 연습합니다. “개발용으로 lower를 자주 고친다”면 오버레이 켜 둔 채 작업 비용이 큽니다.
OTA 파이프라인을 검증할 때 — 개발 보드라도 두 슬롯 + 부트로더 변수 + mark-good/bad를 갖춘 이미지가 필요합니다. 단일 파티션 개발 이미지로는 A/B 실패 모드(롤백·bootcount)를 재현하기 어렵습니다.
저장 공간이 빠듯한 프로토타입 — 대칭 A/B는 용량을 두 배로 씁니다. 초기 프로토타입은 단일 루트로 기능을 맞춘 뒤, 제품화 단계에서 슬롯을 넣는 순서가 흔합니다. (비대칭·rescue 레이아웃은 RAUC 등이 별도로 설명합니다.)
목표 한 줄로 고르기
- “실수로 루트를 망가뜨리지 않게” → overlayroot(또는 squashfs+overlay 등 동등 RO 루트)
- “원격으로 시스템을 갈아끼우고 실패 시 이전으로” → A/B OTA
- “둘 다” → 슬롯 단위 원자 업데이트 + (선택) 런타임 RO/overlay. DT overlay 디버그와는 무관합니다.

마무리

overlayroot는 initramfs에서 lower를 RO로 두고 upper에 쓰기를 모아 런타임 오염을 줄이는 Ubuntu 쪽 수단입니다. A/B는 이중 슬롯과 부트로더·헬스 확인으로 시스템 이미지 OTA의 실패를 이전 슬롯으로 되돌리는 모델입니다. 실패 모드·OTA 맞물림·개발 이미지 쓰기 요구를 먼저 적고 고르면, Device Tree Overlay 이슈와 혼동하지 않고 루트 전략을 나눌 수 있습니다.