필자는 이전 직장에서 ubuntu 16.04와 18.04를 배포본 또는 debootstrap을 통해서 생성된 rootfs를 이용하였다.
업무상 BSP(Board Support Package)일은 기본으로 깔고 가는지라 나름 이런저런 경험이 많은 편이긴 한데.. 이러한 파일시스템 생성툴이 바뀔때마다 한번씩 홍역을 치르고 있다.
필자는 직금 생각하기에 고전이었던 2.4, 2.6 시절에는 직접 파일시스템을 만들거나 또는 build-root를 이용해서 생성하였다. 그리고 근래에 이르러 i.MX6기반의 디바이스에서 사용할 rootfs(OpenEmbedded)를 위해 yocto를 이용하였고, 최근 3년전부터 Ubuntu를 위해 그리고 현재는 Debian을 위해서 debootstrap을 이용하여 이미지를 생성하고 있다.
결론을 먼저 이야기하고, 파일시스템 만드는 방식에 대한 종류별로 느낀점을 정리하였다.
1. 결론.
1) 처음부터 끝까지 한땀한땀 만든 루트파일 시스템
- 장점 : 최소한의 용량으로 리눅스 시스템을 부팅시킬 수 있다.
- 단점 : 많은 시행착오와 많은 시간이 소요된다.
2) build-root
- 장점 : 클릭으로 옵션만 선택해 주면 rootfs를 생성해 준다. 이후 부트로더와 커널만 합쳐주면 끝.
- 단점 : 선택할 옵션이 정말 많고, 의존관계로 수만은 반복작업을 해야한다.
3) yocto
- 장점 : 칩셋제조사들이 주로 이용하므로, 웬만하면 동작된다.
- 단점 : 옵션 하나 변경하기위해 빌드하는데 많은 시간과 저장공간이 소요되며, 세세한 설정등을 모두 넣기 힘들다.
- 팁 : 생성된 기폰 패키지 이외 추가적인 부분은 크로스 컴파일하여 재 포장 하여 사용하였다.
4) debootstrap
- 장점 : 우분투와 데비안을 이용한 rootfs 생성시 주로 사용한다. 사용법이 생각보다 간단하다.
- 단점 : 크게 단점은 없다. 다만 자료 찾기가 좀 힘들다.
사실 필자는 이러한 문제보다 장치에 있는 실행파일이 전원을 불시에 종료했을 때 파일이 손상되는 문제에 대한 고려를 더 많이 하게 되는 중이다. debon에 의해서 아예 프로세스가 분리된 경우라면 모르겠는데, 분리하기 전의 파일은 정전발생시 소실될 수 있는데, 이러한 문제는 결국 파일시스템과 관련이 있다. 고전리눅스에서는 램디스크를 이용하여 모두 램에 올려서 사용해서 오히려 NAND 배드로 인한 파손이 더 많았는데말이다. 최근에는 대부분 emmc로 바뀌어서 배드나 이런부분은 거의 없는데 반해 파일손상 문제는 다소 보이는 것 같다. 이는 부분적으로 ramdisk를 이용하여 처리하면 해결될 것으로 보인다.
이렇게 바꾸어 오면서 느낀점을 정리하면 다음과 같다.
1. 고전 리눅스 시절
KLDP와 KELP의 문서를 토대로 참고하여 파일시스템 구성요소를 하나씩 만들어 끼워 넣었다. 당시 ARM계열의 임베디드 시스템의 저장공간은 NOR 16MB와 32MB가 주를 이루고 있었으므로, 탑재되는 리눅스들도 최소화 하여 만들고, 램디스크를 최대한 활용해야 했다. 저장공간보다 램이 더 큰 시스템이 많았던 시절이다. 예를들면 램은 64MByte이고 NoR Flash는 16GByte인데 ramdisk를 만들면서 압축했다가, 부팅되면서 압축된 ramdisk이미지파일(플래시에 존재)를 메모리로 바로 올리면 32GByte를 할당하더라도 NoR플래시의 공간을 절약할 수 있다. 또한 RAM Disk에서 특정 디렉터리 예를들면, /root 디렉터리를 NoR 플래시를 마운트하여 공간 절약과 데이터 유지를 구현하는 방법이다.
어쨋든 이땐, 부트로더, 커널, 파일시스템 하나 만드는게 곤욕이었기에 (물론, 잘하는 분들은 금방 하셨겠지만..) 한번 생성된 이미지에 필요한 것만 추가하여 사용하였다. 이때 주로 사용했던 ARM프로세스는 xscale(PXA250/255)시리즈 이었다.
2. 고전리눅스의 환경변화 시절 (Build-Root)
일을 하다보니 고전시절에도 몇가지 툴을 이용하여 편리하게 파일시스템을 만들 수 있었다. 물론 반복작업은 많이하게되지만 잘 알지도 못하는 리눅스 루트 파일시스템을 만든다는게 어지간히도 싫었다. 회사를 다니면서 이런거 저런거 미리미리 해보다가 알게된 build-root 다행이 검색찬스를 이용할 수 있었던 시절이라 자료를 수집하고 적용하여 파일시스템을 만들던 시기이다. 이전과 다른점이라면 회사에서 만들었던 PXA255나 270에 Nand 플래시를 적용하던 시점이다. 그래서 조금 큰 용량의 파일시스템이 도덕적으로 허용될 만한 시점이었다. build-root를 사용하여 클릭하여 파일시스템을 생성할 수 있다면, 물론 당시에서 Windows CE나 이런 부분의 기본 BSP는 패키지 선택으로 생성이 가능했지만 말이다. 리눅스에서 그런 환경을 사용할 수 있다니 얼마나 감동적인가 말이다. 어쨋든 이 시절에는 NAND 128MB, 256BM ~ 1GByte 정도의 플래시 메모리와 128MByte정도의 RAM을 탑재한 시스템을 주로 이용하였다. 이젠 램보다 Flash의 용량이 더 커졌기에 조금 rootfs가 커지더라도 크게 문제가 없는 시절이 되었다.
다만, Build-Root를 사용하여 오류가 없이 정상적인 루트파일시스템이 생성되어도 죽거나, 엄청난 양의 오류메시지나, 부트 딜레이를 만나게 된다. 이러한 현상의 이유는 Build-Root의 옵션에 따른 문제가 대부분이었으며, 선택한 옵션 하나 차이에 여러 의존관계의 패키지를 직접 정확히 선택해 주어야 문제가 없이 동작 된다. 따라서, 운좋게 부팅되더라도 부팅하면서 보이는 수 많은 오류 메시지를 지우기 위해서 반복적인 선택과 생성 작업을 반복해 주어야 한다. 이 이전까지만 해도 임베디드 시스템에 SDL(Simple Directmedia Library), QTopia/Emmbedded를 올려서 GUI(QVFB)를 구현하던 시절인데, Build Root를 사용하면 손쉽게 GTK기반의 Xwindow를 이용할 수 있었다.
물론 이러한 rootfs도 버전이 거듭되며 올라간 이후로 의존관계도 어느정도 맞춰주었기에 이후 6410이나 PC110,PV210 프로세스를 사용하던 시절에는 좀더 편리해졌다. 웬만한 오류는 걷어주니까, 발생된 오류 메시지를 통해서 좀더 줄어든 반복작업만으로 사용가능한 정도의 루트 파일시스템을 생성할 수 있었다.
3. i.MX와 Yocto
필자가 i.MX6QP 를 이용한 양산 프로젝트를 진행할 때, NXP에서 제공해주는 Yocto 기반의 rootfs를 생성하기에 이르렀다. 테스트로 Build-Root를 이용하여 생성한 rootfs도 동작은 하지만, 양산 프로젝트에 서드파티로 생성된 rootfs를 사용하는건 아닌것 같고해서 Yocto에 대한 부분을 스터디하여 생성하였다. 그런데 당시 가상머신을 이용하던 필자에게 yocto는 좌절감을 주기에 충분했다. 프로젝트를 다운받아 빌드하고, 설정하고 빌드하고 추가 빌드하다가 꼬이면 지우고 새로빌드하고를 반복하다 어디서 꼬였는지 모르겠지만 빌드 자체가 안되는 상황도 벌어지고, 그래서 별도로 PC를 준비하여 rootfs 빌드에만 사용하여도, 상당히 느리다. 관련 패키지 다운로드하고 설정에 맞춰서 빌드하고 다운로드 하고 빌드하고의 작업이 지속적으로 발생되므로 느릴 수 밖에 없다. 그리고 가이드에 설명도 부족하고, 구매한 책에는 기본개념만 들어있고.. 사실 지금도 기억은 잘 나지 않는다. 그러다 다음회사에서는 i.MX8M계열의 AP를 이용하면서 Yocto로 사전테스트 후 최종 Ubuntu로 갈아 탔다.
4. i.MX와 Debootstrap
Yocto를 이용해 다운로드 받을 수 있는 패키지가 최근에 늘어난거 같은데.. 필자는 관심없다. 어쨋든 기본적으로 NXP에서 배포하는 BSP는 Opem Embedded를 이용한다. 커널도 뭐 근래꺼고, Window 시스템도 적용되어있고, 물론, 필요없으니 제거하겠지만 말이다. 그런데 이 Yocto 프로젝트 자체가 시스템 처리를 위한 CPU와 저장소의 용량 등 하드웨어적으로 너무 많이 먹는다. 따라서 정말정말 느려서, 회사에서 기분좋게 고가의 시스템을 제공해주지 않는이상 빌드하는데 멍때리는 시간이 더 길어지는 경우가 허다하다. 또한 빌드되다 중간에 오류나면 승질이 아주 그냥 죽여준다.
그리고 회사 제품 정책상 Ubuntu를 이용해야 되므로, debootstrap을 사용하게 된다. Yocto에 비하면 정말 가볍다. 생성된 이미지는 바로 확인이 가능할 정도로 필요한 것들만 받게된다. 것도 그럴것이 ubuntu에서 제공되는 기본적인 패키지등 이외에는 고려대상이 아니며 기 빌드된 데이터를 사용하기 때문이기도 하다. 다시말해, 다운로드와 설치로만 rootfs를 어느정도 생성할 수있다. 이를 이용하기 위해서는 가상 디바이스를 이용한다.
debootstrap을 이용하여 파일시스템을 생성할 경우 총 2가지의 과정을 거치는데, 1st stage에서 필요한 자료를 수집하고 2nd stage 에서는 수집된 자료를 생성된 가상 장치에서 설치한다. 또한 부족한 설정들은 2nd Stage이후 rootfs 폴더에 직접 추가함으로서 간단하게 루트파일시스템을 생성할 수 있다. 물론, 검색해보면 자료가 거의 없다는 것을 알수 있다. 별로 안쓰는건가? 이렇게 편한데...;;
결론적으로 파일시스템은 만드는 사람이 운영체제에서 지원되는 방법으로 알아서 생성하면된다. 다만 요즘처럼 시스템 리소스가 다양한 경우에는 굳이 어려운 방법을 쓸 필요가 있을까 싶다.
최근댓글