gentoo 설치 후기

저는 대충 2010년 초반부터 gentoo를 사용했습니다. 저의 경우에 호기심도 있었고 주위에 수퍼 유저가 있었습니다. 성능을 더 잘 활용하게 되리라는 확신은 있었는데, 지나고 보니 매 패키지 업데이트가 컴파일이고, 업데이트를 두 달이라도 거르고 나면 한 번씩 할 때마다 의존관계가 깨지는 경우가 너무나도 허다해서 최소한 매 주 업데이트를 합니다. 그러다 보니 사실 전체적으로 머신에 주는 로드는 결코 더 적지 않은 것 같습니다.

그보다는 시작하게 된 이유가 그 수퍼 유저가 준 make.conf 파일과 .config 파일이 있었기 때문입니다. 후자는 다들 아시다시피 커널 컴파일 옵션입니다. 전자는 gentoo 고유의 설정 파일인데, 거칠게 보면 패키지를 빌드할 때, 어떤 기능을 넣고 무엇을 뺄 것인지 결정하거나, 제 하드웨어에 어떤 기능이 있는지 컴파일러와 패키지 매니저에게 알려줍니다.

다른 대부분의 배포판 (여기에 최소한 데비안 계열, 레드햇 계열은 다 들어갑니다)에선 그렇게 할 필요가 없죠. 여기는 패키지를 배포하는 사람이 이런 설정을 다 하고 빌드를 해서, 실행 파일과 런타임 설정 파일 등을 배포합니다. Gentoo는 이 빌드를 사용자의 머신에서 합니다. 그때 사용자는 설정을 유연하게 가져갈 수 있고요.

설정이 유연한 만큼 지시도 보다 디테일합니다. 그러다 보니 경험이 없으면 하기 힘들죠. 전 다행히 이 working configuration을 수퍼 유저에게서 받았습니다.

2. 그렇게 시작했는데 처음에는 괜찮더군요. 무엇보다 리눅스를 대하는 제 태도를 많이 바꿨습니다. 교육용으로는 꽤 훌륭했습니다.

전에는, 예컨대, sftp 서버가 동작하지 않는다면, 그냥 구글/네이버 검색해서 포스팅에 나오는 거 의미도 모르고 따라해 보다가 안 되면 시스템을 재설치하는 수준이었습니다. Gentoo를 쓸 무렵에는 모든 문제에 대해 소위 trouble shooting을 하게 되더군요. 먼저 어디가 문제인지 이해하고, 그 토픽에 대해 최소한 아주 높은 추상 수준에서 이해하고, 문서도 읽어 보고요. 따라 하더라도 각각의 라인이 뭘 의미하고 뭘 시도하는지 이해하도록 노력하게 되었습니다. 하다 보니 이런 접근이 얼핏 시간이 더 걸리는 것 같아도 결국은 효율성이 더 높다는 것도 배우게 되었습니다.

3. 이를테면, 새 랩탑에 gentoo 설치했더니 touchpad가 안 잡히더군요. 다행인 건 우분투에서는 잡혔습니다. 그러니까 제 경우에는 우분투는 되고 gentoo는 안 되는 이유를 찾아내어야 했습니다. touchpad (synaptics)가 안 된다고 검색해 보면, i8042.nomux=1를 커널 부트 옵션에 넣으라는 포스팅이 많이 나옵니다. 이전 같으면 그런 거 그냥 따라 해보다가 안 되면 포기하든가 했을 텐데, gentoo를 쓰게 되면서부터 이렇게는 안/못 하게 되더군요.

4. 우선은 gentoo에서 장비가 어느 수준에서 인식되지 않는지 보는 게 좋을 것 같은데, 제가 그럴 능력은 되지 않았습니다. input 장비는 X 서버에서 관리할 테니까 X 서버가 인식하는지 보고, 그냥 lsmod를 통해 로드 된 드라이버 (이 경우도 장비 모듈이 커널의 일부라면 lsmod에는 안 보이는 걸로 압니다)를 우분투와 비교해 보려고 했습니다. libinput이나 xinput 같은 툴로 보니 인식이 안 되더군요. lsmod를 보니 우분투는 hid_touchpad라거나 hid_i2c 같은 커널 모듈이 보이는데 젠투는 없었습니다.

위의 두 개는 generic option인 것 같고, 선택을 해줬는데 로드가 되진 않더군요. 그러니까 아마 이 generic 모듈이 N가지 서로 다른 장비 표준을 지원하는 것일 수도 있지만 혹은 그 아래 장비별 커널 모듈/컴포넌트을 사용해서 인터페이스만 구현해주는 것일 수도 있겠다는 생각이 들었습니다.

그래서 디바이스 커널 컴포넌트/드라이버의 의존관계 전체를 루트까지 볼 수 있는 뭔가가 없는지 찾아보니 udevadm -a가 비슷한 일을 하는 것 같습니다. 그걸로 보니 제 장비 드라이버 자체는 SYNA3926:00 어쩌고 하는 기괴한 이름이더군요. 이를테면, Logitec 어쩌고 하면 로지텍 장비를 커널 옵션에서 찾아 모조리 켜줄 텐데, 저런 이름으로는 커널 옵션으로 검색이 되지 않았습니다.

그게 generic한 장비 드라이버 (hid_touchpad 같은)들을 parent로 갖고 있고, 그 위로 좀 올라가니 이제 장비 드라이버 이름에 회사 이름이 몇 개 나왔습니다. 무슨 i2c_designware 어쩌고 synopsys 어쩌고랑 intel-lpss라고 되어 있더군요.

그걸 보니 혹시 제 장비 드라이버가 enable되지 않은 이유가 그 위쪽 체인 어딘가를 커널 옵션에서 포함시켜 주지 않아서였을 것 같았습니다. 이름이 인식 가능한 intel-lpss 이런 것들을 전부 찾아서 모듈로 컴파일 해주고 다시 부팅하니까 마침내 되더군요.

5. 이번엔 또 ibus-hangul이 되지 않습니다. 이런 경우도 10년 전 같았으면 구글, 네이버 (한글 자료니까요) 검색 열심히 해보고 따라 하다 안 되면 포기하고 다른 한글 입력기를 설치 시도했을 겁니다. 그러다 짜증나면 밀고 다른 배포판을 깔거나요.

저도 귀찮기도 하고 해서 version을 낮춰서 빌드해 보기도 하고 ibus-tables를 설치해 보기도 하고 했는데 소용이 없더군요.

그래서 어쩔 수 없이 에러 메시지를 읽기 시작했습니다. ibus-hangul-setup이라고, 설정 프로그램이 crash 하더군요. core dump를 합니다. 이 프로그램은 이걸 좀 고쳐야 될 것 같긴 합니다. 있어야 될 게 없으면 나이스한 에러를 내고 곱게 죽어야지 core dump를 남기는 건 좀 그런 것 같습니다.

어쨌든 죽기 전에 남긴 메시지를 보니 org.freedesktop.ibus.engine.hangul 어쩌고가 register 되지 않았다고 합니다. 뭐라는 건지는 잘 모르겠는데, 뭔가 freedesktop 이라는 모종의 매니저에 ibus engine이 뭘 등록해 줬어야 했는데 실패한 것 같습니다.

그래서 이번에는 ibus-hangul 패키지 빌드/설치 메시지를 읽어보니 뭔가 gnome2 시절에 쓰던 script/function이 gnome3에서 지원이 안 되서 fail했지만 critical이 아니어서 지나간 것 같더군요.

이번엔 ibus-hangul 패키지가 설치한 할 파일 리스트를 들여다 보았습니다. 배포판마다 이런 명령어가 있습니다. 그랬더니 org.freedesktop.* 어쩌고 하는 파일이 /usr/share/glib-2에 있고 파일의 확장자가 gchema.xml이더군요. 그 폴더에 가보니 그런 것들이 잔뜩 있었습니다. 이걸로 뭘 하는지 구글 검색을 좀 해봤더니 그 폴더 안에 무슨 데이터베이스 파일이 있고, glib-compile-schema로 xml들을 한꺼번에 컴파일해서 넣어주는 것 같습니다. 제 생각엔 아마 ibus-hangul이 설치할 때 이 커맨드를 실행했어야 하는데, 위에서 뭔가 실패하다 보니 이 커맨드가 실행되지 않은 채로 설치가 끝난 것 같더군요. 수동으로 그 명령어를 한 번 실행했더니 ibus-hangul-setup도 되고 정상적으로 한글이 나오게 되었습니다.

6. 2, 3년간 이런 식으로 리눅스를 설치, 사용하는 게 교육적으로 상당히 도움이 되는 것 같기는 합니다. 그런데 그 한계 효용도 체감하는 게 사실이고, 7년, 8년씩 이런 일을 하는 게 무슨 의미가 있나 싶어지더군요. 이 시점에 몇 시간을 소모했는데 제가 얻은 건 한글이 되고 터치패드가 반응하는 멀쩡한 랩탑이거든요.

7. 그런데 또 다른 배포판으로 가자니 유연성 때문에 버리기가 힘듭니다. 다른 배포판에서는 맘대로 안 되는 일, gentoo에서는 쉽게 되었는데 다른 배포판에서는 어렵게 되는 일도 흔하진 않지만 적당히 있습니다.