Android 버전만으로 이미지 구성을 단정하지 않습니다
옛 설명에서 “boot.img 안에는 커널과 ramdisk가 들어 있습니다”라고 읽었다면, 그 기기가 어느 Android 버전으로 출시됐는지 먼저 확인해야 합니다. Android 12의 GKI 구성에서는 generic ramdisk가 boot 이미지에 들어갑니다. Android 13으로 출시하는 기기는 이를 init_boot로 분리합니다. 기존 커널 구성을 유지하며 업그레이드하는 기기는 예외가 있으므로 OS의 현재 버전 숫자만으로 파티션을 추측하면 안 됩니다. AOSP generic boot 구성
| 이미지 | 담는 대표 내용 | 오해하기 쉬운 점 |
|---|---|---|
boot | GKI kernel, header와 해당 형식의 정보 | 모든 버전에서 generic ramdisk가 함께 있는 것은 아닙니다. |
init_boot | Android 13 출시 기기의 generic ramdisk | vendor 전용 드라이버 전체를 넣는 공간이라는 뜻이 아닙니다. |
vendor_boot | vendor ramdisk, DTB 등 보드 관련 정보 | header v4의 ramdisk fragment 구조 등 버전 차이를 확인합니다. |
vbmeta | 검증에 사용하는 서명·descriptor 등 메타데이터 | 여기에서 커널 명령이 실행되는 것이 아닙니다. |
super | dynamic partition의 공간과 메타데이터 | 하나의 일반 파일 시스템으로 통째로 마운트하는 대상과 다릅니다. |
header의 version은 이미지 형식의 버전입니다. kernel release와 같지 않습니다. GKI 인증용 boot_signature와 제품의 AVB 검증 서명도 역할이 다릅니다. boot header 형식 vendor_boot 구성
부트로더의 적재와 init의 마운트는 다른 단계입니다
- 부트로더
선택한 slot의 이미지와 검증 정보를 읽고 필요한 커널·ramdisk·DTB를 RAM에 배치합니다.
커널 진입 조건에 맞춰 실행을 넘깁니다.
- Linux 커널
CPU·메모리·드라이버를 초기화하고 초기 사용자 공간의 init을 실행합니다.
PID 1의 사용자 공간 실행이 시작됩니다.
- first-stage init
필요한 초기 모듈·장치와 fstab 정보를 바탕으로 초기 마운트를 수행합니다.
SELinux 설정 등 부팅 단계가 이어집니다.
- second-stage init
rc의 action과 service를 처리해 Android 서비스를 시작합니다.
화살표는 부팅 단계의 진행입니다. 부트로더가 init.rc의 service를 직접 실행하거나 system_server가 커널을 시작한다는 뜻이 아닙니다.
그림은 세부 분기를 생략한 구조 설명입니다. recovery, A/B 여부, vendor ramdisk 구성에 따라 경로가 달라집니다. 커널의 일반적인 initramfs 동작과 Android의 init 정책을 구분해서 읽어야 합니다. Linux 초기 사용자 공간 Android init의 action과 service
bootargs·bootconfig·property는 같은 저장소가 아닙니다
| 위치 | 읽는 쪽 | 예 |
|---|---|---|
| 커널 command line | 커널과 이를 참고하는 사용자 공간 | console=, root= 등 커널 파라미터 |
| bootconfig | 커널의 bootconfig 처리 및 Android init | Android 12 이후의 androidboot 관련 정보 전달 구성 |
| Android system property | property API를 사용하는 프로세스 | ro.boot.* 등 init이 부팅 정보를 반영한 속성 |
부트로더 변수 하나를 바꾸었다고 실행 중인 Android property가 즉시 바뀌는 것은 아닙니다. 부트로더가 실제 전달한 데이터, 커널이 받은 값, init이 만든 property를 순서대로 확인해야 합니다. 명령 줄과 bootconfig에 같은 의미의 값이 있으면 해당 버전의 init이 무엇을 읽는지도 확인합니다. AOSP bootconfig 전달
cat /proc/cmdline
cat /proc/bootconfig
getprop ro.boot.slot_suffix
getprop ro.boot.verifiedbootstate첫 두 명령은 커널이 노출한 부팅 정보를 읽고, 뒤 두 명령은 Android property를 읽습니다. /proc/bootconfig의 존재와 내용은 커널 설정·부팅 방식에 따라 달라집니다. 출력이 없다는 이유만으로 곧바로 부트로더 오류라고 단정하지 않습니다.
실패한 단계에서 증거를 찾습니다
| 관찰 | 우선 확인할 것 |
|---|---|
| 커널 첫 로그도 나오지 않습니다. | 부트로더의 검증 결과, 이미지 header와 적재 주소, DTB 선택, 콘솔 설정을 확인합니다. |
| 커널은 시작하지만 root를 못 찾습니다. | 초기 ramdisk·저장장치 드라이버·fstab·해당 slot의 파티션 구성을 확인합니다. |
| init은 실행됐지만 특정 서비스가 없습니다. | rc의 import·trigger·class·disabled 설정과 SELinux 거부를 확인합니다. |
| 예전 unpack 도구가 이미지를 읽지 못합니다. | 이미지 손상에 앞서 header v3/v4와 vendor ramdisk fragment를 지원하는 도구인지 확인합니다. |
오래된 LK/aboot의 boot image 분석은 그 구현을 이해하는 데 유효합니다. 그 구조를 최근 GKI 이미지의 전체 규칙으로 확장하지 않는 것이 핵심입니다.