안드로이드 / 라즈베리파이 부팅 실패를 100% 해결하는 디버깅 패치
0. Overview
많은 개발자들은 '브링업'이란 개발 업무를 맡고 있습니다. 이 과정에서 다음과 같은 어려움을 많이 겪습니다.
* 보드 브링업을 하다 보니 컴퓨터의 시작 화면까지 보이지 않는다.
* 부팅 과정에서 출력하는 화면이 계속 출력된다.
이런 이슈를 겪은 적이 있나요? 보통 이런 상황을 겪으면 굉장히 답답하고 짜증이 납니다. 그 이유는 무엇일까요?
* 뭔가 문제가 생겨서 부팅이 안되는 상황인데 그 원인을 파악하기 어렵기 때문입니다.
달리 말씀을 드리면 정확히 어디에 문제가 생겨서 부팅이 안되는지 알 수 없기 때문입니다. 이번 포스팅에서는 이런 상황에서 사용하면 아주 유용한 커널 패치를 소개합니다.
1. 아이디어
안드로이드나 라즈비안 타겟 부팅 과정에서 init이나 systemd 프로세스가 *.rc나 *.sh 셸 스크립트를 실행하면서 각종 서비스나 프로세스를 초기화합니다. 하지만 리눅스 커널 입장에서는 위 레이어에 안드로이드나 라즈비안 혹은 우분투가 돌아가는지 모릅니다. 이를 다음과 같이 요약해 볼까요?
"유저 공간에서 프로세스나 스레드 생성 요청이 오면 이를 생성한다."
"'실행 파일'을 실행할 때 커널은 말 그대로 실행시켜준다."
만약 안드로이드에서 각종 서비스를 실행할 때 커널은 이를 어떻게 처리할까요?
* /system/bin/sh 파일 처럼 실행할 뿐입니다.
2. 커널 패치
서론이 길었는데, 먼저 커널 패치 코드를 소개합니다.
패치 코드의 내용은 실행 파일과 실행 파일에 적용되는 아규먼트 옵션을 커널 로그로 출력해주는 것입니다.
1.2 커널 로그 확인
커밋을 반영하고 커널 로그를 받아보면 아래와 같은 시그니처를 볼 수 있습니다. 참고로 아래 로그는 안드로이드 디바이스에서 받았습니다.
그렇다면 위 로그를 어떻게 해석할까요? 한 가지 예를 들겠습니다.
[ 385.662491 / 01-01 06:15:00.929][5] [exec:servicemanager-562] exec_file: /system/bin/servicemanager, arg: [/system/bin/servicemanager]
서비스 매니저가 실행됐다는 정보입니다. arg는 파일을 실행할 때의 아규먼트다.
이번에 다른 로그를 봅시다.
[ 400.060155 / 01-01 06:15:14.839][4] [exec:init.rpi_device.crash-1144] exec_file: /vendor/bin/init.rpi_device.crashdata.sh, arg: [/vendor/bin/sh]
'/vendor/bin/init.rpi_device.crashdata.sh' 셸 스크립트를 init.rpi_device.crash.sh 스크립트가 실행한다.
부팅하고 난 다음에 다음 시그니처도 확인할 수 있습니다.
[ 442.944003 / 07-30 05:19:25.069][3] [exec:crash_dump64-4141] exec_file: /system/bin/crash_dump64, arg: [crash_dump64]
유저 공간에서 Tombstone이 떨어졌다는 사실을 알 수 있습니다.
다음은 가장 흥미로운 로그입니다.
[ 450.178083 / 07-30 05:19:32.299][2] [exec:sh-4946] exec_file: /system/bin/sh, arg: [/system/bin/sh]
[ 450.224563 / 07-30 05:19:32.349][7] [exec:dmesg-4946] exec_file: /system/bin/dmesg, arg: [dmesg]
위 로그는 다음 명령어를 실행했다는 사실을 알려줍니다.
adb shell dmesg > kernel_log.c
3. 결론
이 패치를 적용하면 커널 로그를 통해 임베디드 리눅스의 어떤 배포판(안드로이드, 라즈비안)이던 부팅 과정을 확인할 수 있습니다.
출처 : Austin Kim님 블로그