안녕하세요~

Bulldozer 입니다.

제 블로그에 있던 글들을 하나씩 관심도 끌어올리기 용으로 퍼오다가...

사실 이 글은 가져오려 하지 않았었습니다.

2번 항목 때문이었는데요...

사실상

테그라크나 스피드모드를 사용하는 분들 중

원낸드 모드 유저나 외장패치 혼용 유저가 아닌 경우는...

패치를 해제하지 않고 그냥 펌업을 해도 됩니다...

단, 다시 동일한 file system 으로의 적용이 가능한 커널이 해당 펌버전에 맞게 배포가 되어져 있다면...

얼마 전, rfs 변환을 안하고 펌업을 하셔서 메모리가 0mb 가 나왔다고 하시는 분께

그냥 테그라크 커널 올리라고 알려드렸더니 쪽지로 원리를 물으시더군요...

그래서 지금 퍼온 글인 지난 3월에 적었던 이 글을 링크 해드리고 간략하게 설명 드린적이 있었습니다.

그래도 정말 trouble shooting 에 자신있는 분이 아니면 그냥 다 해제하고 펌 올리는게 좋겠죠~^^

오래 전에 적었던 글이지만...

조금이라도 문제 발생 원인이나 해결의 원리를 그냥 적용법 보다는 알고 싶으신 분들께는 참고할 만한 정도는

된다고 생각이 들어서 퍼옵니다.

역시나 이번 글도 반말이죠...

제 블로그에 개인적으로 아는 내용을 정리한 것 뿐인 글이니까요~^^;

글 읽어주신 모든 분들 행복하시고 즐거운 하루 보내세요~^^

==================================

얼마 전에 주로 정보를 얻는 스마트폰 커뮤니티인 맛클의 서버가 다운되어
오랜만에 네이버 까페에 로그인을 한 후 정보들을 훑어 보게 되었다.

그런데 대부분의 강좌란에 있는 글들은...
무조건적인 방법들을 정도라고 생각하며 강좌에 올려져있었다, 또 그 방법을 이용하여 사람들은
벽-돌이나 무한부팅을 대부분 해결하고 있었다. 기본적인 원인과 해결법에 대해 이해하지 못하고 있는 듯한데
간단한 적용법만을 적어놓고 있는게 전부인 글들을 보고 짧게 강좌란에 그것보다는 근본적인 원인과 간단한 해결법에
대해서 하나의 글만을 적기만 했다. 사실 괜히 글을 적는게 아닌가 싶었지만...
짧은 글 하나를 올렸는데, 댓글들에 자세한 강좌를 적어달라고 하는 글도 있었다.
처음에 블로그 공지나 여러 글 중간 중간에도 적었지만, 강좌나 뭐 이런쪽에는 전혀 관심이 없다.
그리고 강좌를 적을 정도로 뭔가를 아주 깊숙히 알지도 못한다.
강좌를 적으려면 하나의 주제에 대해 큰 뿌리를 이해하는걸 넘어서, 그 잔 뿌리들까지 모두 이해를 해야만 진정한
강좌가 만들어 진다고 생각한다. 안드로이드의 여러가지 주제에 대해 사실 큰 뿌리들은 공부를 통해 알게 되었지만...
그 가지가지, 그 잔 뿌리들까지 공부를 하지도 못했고, 하기도 힘들다. 지금 강좌를 적는다는건 주제넘은 짓같이 느껴진다.
사실 간단히 Trouble shooting 법을 안다고 해서 강좌를 적는다는 것도 웃기는 일이다.
Trouble shooting 법을 적으려면 적용법이 아니라, 그 문제되는 이유와 원리를 설명하고 해결법이 왜 해결법으로 사용될 수
있는지를 분석하여 강좌를 올려야하는데... 그 경우의 수도 너무나 많고, 하나 하나 다 원인분석을 하기도 힘들다.

Trouble shooting 에 대해서는 좀 더 자세한 원리를 알게된 이후에 적으려 했으나...
네이버 까페의 강좌들을 보고 자극제가 되어 그냥 지금 내가 알고 있는것들이라도, 하나 하나 적어볼 생각이다.
역시나 이번 글도 누군가가 읽기를 위해 적는 글이 아니며, 단지 내가 알고있는걸 정리하는 글일 뿐이다.

1. Theme file 적용 오류로 인한 무한부팅에 대한 Trouble shooting
루팅을 한 후 주로 두가지의 작업을 한다.
패치의 적용, 테마파일의 적용이다. 이 중 theme file 의 잘못된 적용으로 인해 무한부팅의 결과를 초래하는 경우가 많다.
theme file 이란
/system/framework 와 /system/app 내부에 있는 file 들 중 눈에 보여지는 theme 부분을 담당하고 있는 file 들이다.
file 의 교체를 통해서 스마트폰을 꾸밀 수 있게 되는것이다.
무한부팅이 발생하는 주된 원인은
/system 내의 용량이 충분하지 못해서 원하는 theme file 이 충분히 복사가 되지 않은 상태에서 재부팅을 한 경우가 해당한다.
/system/app 내부의 file 이 잘못 복사된 경우는 주로 무한 부팅이 아니라, 무한 강종이 발생하게 된다.
해당 application 의 실행에 관련된 요류가 발생하는 것이다.
하지만, /system/framework 내부의 file 이 잘못 복사된 경우는 무한 부팅이 발생한다.
무한 부팅, 무한 강종이 발생한다고 해서 결코 공장초기화를 하는것은 해결책이 아니다.
공장초기화는 /data, /dbdata, /cache patition 을 초기화 시키는 것이다.
문제가 발생된 부분은 /system 부분인데, 엉뚱한 부분을 초기화 시키게 되는 것이다.
본인이 사용하고 있는 패치가 tegrak onenand patch 가 아니라면 factoryfs.rfs 를 tar 압축한 file 을
odin 으로 flash 시키면, /system 영역이 순정으로 돌아오게 되므로 해결이 된다.
이때, 본인의 firmware build no 와 맞는 factoryfs.rfs 를 선택해야한다.
factoryfs.rfs 는 /system 을 정보를 포함하고 있는 rfs file 이다.
좀더 고급 해결법으로는 adb tool 을 이용하는 방법이 있다.
custom kernel 중 바로 su 권한으로 recovery mode 접속이 되는 경우가 아니라면
맛클의 자양이라는 개발자의 홈페이지인 자양이네에서 rsu 라는 file 을 받아서 recovery mode 에서 su 권한을
얻어야 한다. rsu 는 /system/bin 에 밀어 넣어야 한다. 물론 chmod 로 권한 부여를 해줘야한다.
adb push 교체할 apk 교체당할 apk 를 써주면 경로대로 apk 가 교체되게 된다.
이때, 당연히 /system 은 rw 로 romount 되어 있어야한다.
아니면 adb push 로 /sdcard 영역에 교체할 apk 를 먼저 넣어두고, adb shell 접속 후 cp 혹은 cat 으로
원하는 곳의 apk 를 교체해 주면 된다. 당연히 /sdcard 영역을 미리 mount 시켜줘야 한다.
recovery mode 에서는 기본적으로 /system 만 mount 가 된 상태이다. 그러므로
/system 은 rw 로 remount 를 시키고, 나머지 필요한 영역은 mount 를 잡아줘야지만 된다.

2. Custom kernel 의 patch 를 풀지않고, firmware update 로 인한 Trouble shooting
이 부분에서는 firmware update 의 영역과 file system 에 대한 이해가 필요하다.
우리가 firmware update 를 한다는 것은
factoryfs.rfs, modem.bin, zImage 를 교체하는 것이다.
factoryfs.rfs 는 /system 영역의 정보를 가지고 있는 file 이며,
modem.bin 은 통신을 담당하고 있는 정보를 가지고 있는 file 이며,
zImage 은 우리가 흔히 이야기 하는 kernel, 즉 운영체제에 해당하는 file 이다.
그리고 우리가 사용하는 대부분의 custom kernel patch 의 경우는 file system 을 교체하는 것이다.
만약 /data partition 을 rfs -> ext4 로 file system 을 변경하여 custom 화 하여 사용하고 있었다가 firmware update 를 했다면,
새롭게 update 된 zImage 에서는 /data partition 을 mount 를 시킬 수가 없다. ext4.ko module 도 없고, insmod 도
실행이 안될것이며, mount 가 되지를 않는것이다. 이렇게 되는 경우가 firmware update 후 install memory 가 0mb 가 되는
것이다. 이 경우에는 일단 /data 의 정보가 사라진게 아니다. 단지 정보는 있으나 mount 를 시키지를 못하고 있는것이다.
지금 /data 에 적용되어 있는 file system 을 지원할 수 있는 kernel 로 mount 를 시켜주면 된다.
/dbdatd, /cache, /system 모두 위의 /data 와 같은 개념이다. 물론 /system 의 경우는 firmware update 를 하면서
factoryfs.rfs 로 인해서 file system 이 원래의 상태로 돌아와 있을것이다.
설치가능 memory 가 0mb 가 나왔을 때는 file system 을 지원하는 kernel 로 복구를 진행한 후 정식적으로 patch 해제를 통해
file system 을 원래의 file system 으로 바꾸고 다시 zImage 만을 씌워주면 되는 것이다.
결코, 0mb 가 나왔다고 해서 공초 + 펌웨어 업그레이드를 할 필요가 없다.

3. Movinand 포멧...
movinand 포멧에 대해 정확히 이해를 해야할 듯하다.
물론 이 부분에 있어서는 아직 잘 모르는 부분도 있지만, 아는데로만 적으면 아래와 같다.
cache.rfs, dbdata.rfs, movinand.mst, param.lfs 로 구성된다.
여기에 zImage, factoryfs.rfs, modem.bin 의 firmware 부분을 같이 첨부해서 tar 압축을 한것이, 통용되고 있는
Galaxy S 의 movinand 포멧 file 이다.
cache.rfs, dbdata.rfs 는 해당 영역을 깔끔히 wipe 시켜버리는 것이다.
movinand.mst 는 movinand 부분인 /dev/block/mmcblk0p1, /mmcblk0p2 를 깜끔히 wipe 시키는 것이다.
param.lfs 는 jpg file 의 집합체로, 경우에 따라 자체적으로 나타내어 주는 jpg file 들을 교체시키는 것이다.
위와 같은 file 들을 용도에 따라 사용하는 것이 현명하다.
무조건 movinand tar file 을 odin 으로 flash 시키면 불 필요하게 모든 영역이 초기화 되므로,
원하는 file 만을 tar 압축하여 odin 으로 flash 시키면 효과를 얻을 수 있다.
그리고 movinand 포멧을 할 경우라면 결코 공장초기화를 선행할 필요가 없다.
네이버 까페에서 해결법으로 공초 + 모비낸드 라는 강좌글을 본적이 있다.
사실 쓸대 없는 짓이다.
공초란 /data, /dbdata, /cache 영역을 초기화 시킨다.
모비낸드 포멧이란 /data, /dbdata, /cache, /system, kernel, /sdcard 등을 초기화 시킨다.
(/system 은 factoryfs.rfs 포함 시, kernel 은 zImage 포함 시)
모비낸드 포멧 자체가 공장초기화에서 이루어지는 초기화 영역을 포함한다는 것이다.
할것 같으면 모비낸드 포멧만 하면 된다.

4. Patch 혼용 사용으로 인한 문제에 대한 Trouble shooting
내장과 외장 패치를 병행하여 사용하다 문제가 생기는 경우는 해결하기가 쉽지 않다.
일단 내장, 외장 어느부분에서 문제가 생겼는지를 확인하고, 본인이 외장패치를 통해 심링크 혹은 바인딩을 한 부분이
해결법과 관련이 되는지를 확인해야 한다.
/system 영역을 복구해야 하는데 ln 이 되어 있거나, /data 영역을 복구해야 하는데 /disk 로 모두 ln 심링크가 되어 있거나
하는 복잡한 상황이 오게된다.
그리고 경우에 따라서는 외장으로 심링크를 시켜놓았던 file 이 링크가 깨지는 경우도 발생한다.
그래서 일단 문제가 생기면 가장 먼저 외장패치를 어떻게 해서든 해제를 시켜야 한다.
무한 부팅이 되었는데 어떻게 외장패치를 해제 시키느냐고 생각하기 쉽다.
당연히 recovery mode 에서 adb tool 을 이용하여 patch 가 손쉽게 적용하고 있는 linux 명령어를 직접 입력하여
수작업으로 복구를 해줘야한다.
ln 복구의 경우는 다시 ln 을 /data/app 과 /disk/app 을 걸어준다던지,
bind 를 적용안되게 해서 부팅을 유도하고 싶다면 /etc/init.d/*. 를 rm -f 하거나 playlogos1 을 순정으로 돌린다던지의
방법들이 존재한다.
하지만 결코 쉽지 않다. 사실상 그래서 application 을 이용한 외장패치 보다는 script 를 이용한 외장패치가
더 합리적이라고 생각한다. application 을 이용하는 경우는 해결하기가 쉽지 않다. 해제의 모든 과정을 직접 쳐야한다.
하지만 script 를 이용한 외장패치의 경우는 /sdcard 를 mount 시키고, 원하는 영역을 모두 mount 시킨다음
/sdcard/*.sh 를 실행시켜서 패치해제의 절차를 밟을 수 있기 때문이다.
경우의 수가 너무 많아서, 이보다 더 여러가지의 경우를 적기가 쉽지 않다.
나중에 직접 문제가 생겨서 복구를 했을 시에 발생되는 사례들만을 추가적으로 적어 넣어야겠다.

그리고 가장 좋은 방법은 항상 백업을 해놓는 것이다.
주로 사용하는 custom kernel 들은 backup * restore 기능을 제공한다.
voodoo 와 speedmod 의 경우는 /sdcard/clockworkmod/backup 에 날짜별로 백업 시에 저장이되며,
tegrak 의 경우는 /sdcard/tegrak/backup 에 최신의 백업 data 가 저장이 된다.
custom kernel 의 backup & restore 기능은 모든것을 백업 시점으로 돌려버리기 때문에
본인이 원하는 시점의 백업을 보관해 두는 것이 좋다.

이 외에 또 어떠한 경우가 존재하는지는 지금은 잘 생각이 나지 않는다.
사실 적용 전에 복구법을 모두 숙지하고 시도를 하기 때문에 벽-돌이나 무한부팅을 경험한 것이 4번 정도이며,
1번을 제외하고는 그냥 adb 로 주로 해결을 했었다. 1번은 movinand 포멧을 했으며, 그때에는 공초와 movinand 에 대해
잘 몰라서 공초 + movinand 포멧을 했다.

앞으로 겪는 문제들이 있다면 이 글에 추가적으로 적을 생각이며, adb tool 의 활용에 대해서는 자세히 적지 않았는데
그 이유는 adb tool 활용에 대해 별도로 글을 저을 생각이기 때문이다.
그 때 trouble shooting 에 대한 부분도 한번 더 adb tool 활용에 대해 적을 생각이다.

그리고 지금 android service 에 대해 공부를 하려하는데...
시간이 충분하지를 못하다. application 구동과 관련된 여러가지 사항에 대해 서적을 참고하며 정리를 해야하는데
회사 업무가 바빠지다보니... OTL...
앞으로는 블로그에 글을 적는것도 지금보다는 훨씬 뜸 해질듯 하다.

==================

지난번에 올렸던 Android booting process 에 관한 글을 같이 읽으시면

조금은 도움이 될듯 하네요.

http://matcl.com/index.php?mid=usrkn&document_srl=3938976

음...

보통 이렇게 약간 복잡한 내용의 글은 인기가 없던데... ^^;;

암튼...

필요하신 분들께 도움되는 글이 되기를 바랍니다.