::: Dragon Tail :::

Kernel 패닉시 떨어지는 Taint 에대해서..

2010-08-06T17:54:36+09:00

Taint 가 뭐냐면... 뭐 단어는 구글단어장에서 찾아!!! 일단 Kernel 패닉등이 일어나면 코어에 혹은 로그에 관련 로그가 찍히는데, 거기보면 Pid: 15652, comm: scopeux Tainted: P 2.6.9-89.ELsmp 이런게 남는다. 여기에 있는 Tainted다. 대략 정리해보자면 이 상태를 찍어주는 Flag 의 종류는 레드햇의 경우 총 7개가 있다.. (소스보기 귀찮아서 그냥 매뉴얼만 봤다.. 디테일하게 묻진 말자 :P ) 1. P: Proprietary License 를 갖고있는 모듈이 문제를 일으켰다는 내용으로 독점적 라이센스를 뜻한다. 즉 써드파티따위에서 GNU 나 GPL 아래 있는 모듈이 아닌 자체제작된 모둘이라는 것으로 source 코드에 대한 지원이 불가능함을 뜻한다. 즉 일단 써드파티 모듈부터 까고 봐야 한다는거지! 2. G: 잘 안나오는녀석이긴한데, 이건 말 그대로 GPL 에 영향에 있는 공개된 모듈에서 문제가 됬다는 것이다. P 의 반대로 생각하면 된다. 이경우엔 리눅스 커널 개발자가 알아서 해줄지도 모른다 :) 3. F: 강제로 로드된 모듈에서 결국 문제가 발생되어버렸다 라는 뜻으로, insmod 나 modprobe 의 -f 옵션으로 강제 로드된 모듈에서 버전 정보등의 검사를 하는 도중 커널에 문제를 일으켰다는 내용으로 보면 된다. 4. R: 커널이 운영되고 있는 중에, 그리고 사용중인 모듈인데 강제로 (rmmod -f 옵션) Unload 시켰을때 발생하는 플래그이다.. 결국 뻘짓거리 하지말고 정상적으로 사용하라는 것... 5. S: SMP 커널을 사용할때 CPU 할당 관련 문제시 발생하는 플래그이다. 6. M : MCE ( Machine Check Exception ) 에서 일으키는 문제에 대한 플래그로, CPU 온도가 높다던가, 메모리 뱅크 및 슬롯이 잘못됬을때 하드웨어에서 감지하고 일으키는 문제에 대한 플래그. 7. B: Bad Page State 를 뜻하는 것으로, 리눅스가상메모리(virtual memory) 에서 잘못된 부분을 감지했을때 사용되는 플래그이다. 보통 RAM 또는 메모리 캐쉬의 문제시 발생되곤 한단다.. 자...7개다.. kernel Document 보면 사실 한 3개쯤 더 있는데, 난 7개만 썼다.. 왜? 오래된 문서를 보고 정리한거고, 커널문서에서는 tainted 에 대한 비트수만 나와있지 뭐라고 찍히는지는 안나아욌어서다... 짜증나게 깊이 묻지 말자... :) 대략 tainted 에서 뜨는 내용만 보고도 어디를 조져야 할지 나온다. 좀 이런것좀 보면서 일하잔 말이다! ㅠㅠ 어만 리눅스만 자꾸 잡아대려고 하지 말고! 근데 나 이거 열심히 쓰고 봤더니 예전에 내가 정리해서 쓰지 않았던가 라는 데자뷰현상이!!!! 블로그 뒤지다보면 간간히 예전에 썼다 생각했는데 없는것들이 있다... 뭐지.. 나 해킹당하나 머릿속 해킹... :(

글 전체보기

아이퐁! 레댓계열에서 USB 테더링하기! (fedora11 이상)

2010-08-04T16:51:58+09:00

오랜만에 글이다... 좆같은 세상 좆같은 한국 IT 특히 모사! 너넨 그따구로 할꺼면 직접 개발해서 써라 너낼 위해서 한쪼가리 날려주는 테더링이라는 (전혀상관없..쿨럭...웅~?) 글이다. 레댓계열 물론 엄밀히말하자면 GCC 가 4.4.4 대로 올라갈 수 있는 녀석들 얘기니까 페도라10 이하 (10포함이다) 는 고민좀 해보시고! 11 이상이면 가능할것 같아........ 자 따라해 보라고.. 부면말하지만 블루투쓰가 아닌 USB 케이블 이용이다! 가장 중요한건 git 야... 니미 시붕, RHEL 5의 update 4 이하에선, git 사용이 거지같더라 ㅡ.,ㅡ Glibc 관련 라이브러리들 때문이지만 ㅠㅠ 명심해 둬.. 5.5 는 모르겠는데, 잘... RHEL6 (물론아직베타) 에선 git 로 가져오는 것들 잘되더라.. 물론 내가 쓰는것은 페도라 위주고, RHEL 에서 구지 아이폰 테더링 할필요 없으니까... (회사가 조낸 힘들게 하니까 아이폰에 써버를 꽂으려고 하는거다..그런덴 때려쳐라..헉 이런 개드립을 ㅠㅠ) mirr4u@~ ]# yum install libimobiledevice libimobiledevice-devel git gcc -y ... 생략 Done mirr4u@~ ]# git clone git://github.com/dgiagio/ipheth.git mirr4u@~ ]# cd ipheth/ipheth-pair mirr4u@~ ]# make mirr4u@~ ]# sudo make install mirr4u@~ ]# cd ../ipheth-driver/ mirr4u@~ ]# sudo make install mirr4u@~ ]# modprobe ipheth 또 중요한게 뭔줄 아냐?? NetworkManager 패키지이다.. 레드햇에서도 일종의 계륵인 녀석인데, 어쩔수 없다. 블루투스가 더 거지같다... 인식도 잘 못하고, Blueman 쓰면 블루맨자체가 충돌나서 뻗는경우가 많다. 그냥 왠만해선 기본설치 되니, NetworkManager 를 실행 혹은 재실행 시키자. 그르면!!!!! iPhone 관련된 네트워크를 잡거나 보여준다... 괜춤하고 잘 된다. 이런건 정말 느그들이 애플이 정말 괜찮다 생각하면 페도라 자체에는 포함해야 하지 않겠냐?? git 권장하지말고! 젠투도 아닌것들이.. yum 레포로 넣으라고!! 좀!!! 추가로! 안드로이드도 조낸 까대거나 실헝하지만 말고! 무선 AP 자체적으로 만들어 주는 거! RHEL 에도 넣고 페도라에도 쉽게 넣게 만들어 주라고! ㅡ,.ㅡ 얼마나 좋아! 다들 테더링하고 다들 무선AP 찾고, 다들 그딴식으로 노가다하고 돈 때려 줘야돼?? 좀 각성하자 형이 길어져서 그만한다 졸려 ㅡ,.ㅡ 스윗드림해라 ! :)

글 전체보기

ABRT 사용하기

2010-05-27T01:24:03+09:00

일전에 잠깐 소개했던 ABRT 에 대한 핸들링을 좀 간략하게 적어볼까 한다. 일차적으로 CLI 를 이용한 쉘에서의 분석이다. 일단 abrt 는 커널 2.6.30 이후부터 (정확하겐 모르겠다) 즉, RHEL6 에서 기본 크래쉬 관리 도구로 사용되는, 자동 버그 리포팅 툴이다. 이것은 큰 기능은 없지만, 어플리케이션 뿐만아닌, 커널 레벨의 모든 크래쉬를 감지, 코어파일을 생성하여 일련번호를 할당하여 관리할 수 있게 한다. 물론 이걸 이용해 분석도 할 수 있고, 간단하게 bugzilla 등에 리포팅 할 수 도 있다. 이것에 대한 얘기는 총 세개의 글로 나누어 설명할 예정이다. abrt 의 사용을 위해서는 abrtd 라는 데몬이 실행되야 하며, 특정 커널 이후로는 필수 실행데몬이다. cli (쉘) 에서의 명령어는 abrt-cli 로, 간단하게 몇가지 옵션위주로 설명하겠다. [mirr@Mirr Document]$abrt-cli --get-list 0. UID : 500 UUID : 7934db0508363522625da8ef236db612fa7af2d3 Package : gnome-terminal-2.28.2-1.fc12 Executable : /usr/bin/gnome-terminal Crash Time : 2010년 04월 16일 (금) 오후 12시 14분 35초 Crash Count: 1 1. UID : 500 UUID : 4d66c3c61860827f892facad0e7e38e878ac97c5 Package : gnome-screensaver-2.28.3-1.fc12 Executable : /usr/libexec/gnome-screensaver/slideshow Crash Time : 2010년 05월 02일 (일) 오후 09시 54분 24초 Crash Count: 3 ................................... ............중략 ............... 7. UID : 500 UUID : 23ab4764de849a8166e74e0a1a51f5b7052d47e6 Package : abrt-gui-1.0.9-2.fc12 Executable : /usr/bin/abrt-applet Crash Time : 2010년 05월 08일 (토) 오후 05시 41분 32초 Crash Count: 1 8. UID : 500 UUID : f5694f7625c378966ade0589333c19fd13f74e07 Package : compiz-0.8.2-24.fc12 Executable : /usr/bin/compiz Crash Time : 2010년 05월 12일 (수) 오전 09시 09분 43초 Crash Count: 1 9. UID : 500 UUID : c90bebaca19d364eef0c133f742478731cf9f1a1 Package : twitux-0.69-4.fc12 Executable : /usr/bin/twitux Crash Time : 2010년 05월 24일 (월) 오전 09시 38분 26초 Crash Count: 1 10. UID : 500 UUID : f04092400057d11de3876cce9246844aa663ee43 Package : firefox-3.5.9-2.fc12 Executable : /usr/lib/firefox-3.5/firefox Crash Time : 2010년 05월 26일 (수) 오전 10시 04분 40초 Crash Count: 1 보다시피 0번부터 발생되고, 감지된 모든 크래쉬를 쭉 나열해 준다. 유저레벨에서도 사용이 가능한점이 특징이다라고 할 수 있고, 루트의 경우 커널크래쉬 혹은 커널 워닝 레벨까지 보여준다 (와우~) 직관적이므로 설명이 깊이는 필요없을거라 생각하지만.. 일단 프로그램이 실행된 UID, 그리고 프로그램 코어 발생을 구분해주는 UUID, 문제 유발 프로그램의 패키지, 실행파일, Crash 발생 시간, 그리고 Crash 횟수이다. 자 이제 리스트를 받았으면 내용을 봐야지.. [mirr@Mirr Document]$ abrt-cli --report `UUID` 또는 @Number` >! crash '@0' is not in database >! Can't find crash with id @0 in database 뭐 이런식으로 뜨면서 Stack Backtrace 장면이 펼쳐진다. 나오는건 중략하고 대략 vi 명령어 모드로 볼 수 있으며, 나오는건 역시 :q 나 :q! 를 사용하면 빠져나오고, 다음과 같이 버그 리포팅을 묻는다. No changes were detected in the report. Report using Bugzilla? [y/N]: n Skipping... Report using Logger? [y/N]: n Skipping... Crash reported via 0 plugins (0 errors) 매우 간단하지 않는가? 여기서 중요한건 코어에서 뽑을 수 있는 로그.. 즉, Backtrace 부분이 손쉽게 보여진다는 점으로, 이것들만 버그질라등에서 검색해도 많은 힌트를 얻을 수 있다. 버그질라에 보고하기 위해서는 계정이 필요하다. 이제 ABRT 를 이용하여, 손쉽게 버그를 핸들링 및 리포팅 하자. 두번째 장에서는 GUI 로 다뤄 볼 예정이다. PS : 스프링놋흐에서 좀 더 자세히 작성될 예정이다.

글 전체보기

RHEL6 on System Z10 의 abrt 내용 - 2

2010-05-27T00:44:42+09:00

이번에는 어플리케이션 레벨 크래쉬 발생. [root@linux04 ~]# abrt-cli --get-list 0. UID : 0 UUID : de784294dea27f567470a83867ac5faf9c95dc30 Package : groff-1.18.1.4-19.el6 Executable : /usr/bin/grotty Crash Time : Wed May 26 23:56:54 2010 Crash Count: 1 [root@linux04 ~]# abrt-cli --report de784294dea27f567470a83867ac5faf9c95dc30 [New Thread 4700] Core was generated by `grotty -c'. Program terminated with signal 11, Segmentation fault. \#0 0x0000000080005b9a in ?? () Thread 1 (Thread 4700): \#0 0x0000000080005b9a in ?? () No symbol table info available. \#1 0x00000000800020ce in ?? () No symbol table info available. \#2 0x0000004c97126894 in __libc_start_main () from /lib64/libc.so.6 No symbol table info available. \#3 0x0000000080001cc2 in ?? () No symbol table info available. From To Syms Read Shared Object Library 0x0000004c9764e68c 0x0000004c976d7604 Yes (*) /usr/lib64/libstdc++.so.6 0x0000004c972eb9c4 0x0000004c97336780 Yes (*) /lib64/libm.so.6 0x0000004c9759b40c 0x0000004c975a678c Yes (*) /lib64/libgcc_s.so.1 0x0000004c971265a0 0x0000004c97265720 Yes (*) /lib64/libc.so.6 0x0000004c970dcc30 0x0000004c970f6fc8 Yes (*) /lib/ld64.so.1 0x000002000000a4dc 0x000002000000b268 Yes (*) /usr/lib64/gconv/ISO8859-1.so (*): Shared library is missing debugging information. $1 = 0x0 No symbol table is loaded. Use the "file" command. r0 0x1 1 r1 0x200000001 8589934593 r2 0x6a8 1704 r3 0x4c00000000 326417514496 r4 0x80005b82 2147507074 r5 0x8002bfb0 2147663792 r6 0x1 1 r7 0x3fffff6d2e8 4398045909736 r8 0x3fffff6d2bc 4398045909692 r9 0x80016690 2147575440 r10 0x80014428 2147566632 r11 0x8002c870 2147666032 r12 0x80016688 2147575432 r13 0x8000f160 2147545440 r14 0x80005b82 2147507074 r15 0x3fffff6d1f0 4398045909488 pc 0x80005b9a 0x80005b9a cc 0x2 2 No function contains program counter for selected frame. Debuginfo absent: 158419a490e305a8ddabf2ce33236f8bed265d25 Debuginfo absent: 1e56dbdcd1da368cc506da6fd5491c81d82467db Debuginfo absent: 2bacaa9b9da7c46647164b2443001be21bca87bf Debuginfo absent: 4d07a20699ca445734708864b04dbef0e01ef1c0 Debuginfo absent: 825b439d8dafc782938c6093a2fb617b1163a180 Debuginfo absent: 88d0c4c627334edfe4b1a80efc5d6dd8354e8ef8 Debuginfo absent: e2bee819f0a836d0ee2bc1b2beac53413b5179f9 이건 debuginfo 를 가지고 코어덤프를 gdb 등으로 Trace 해야 할것 같은데 지금은 귀찮고... 일단 흥미로우니 책갈피식으로 꽂아놓는다...

글 전체보기

RHEL6 on System Z10 의 abrt 내용 - 1

2010-05-27T00:33:27+09:00

abrt 에 보니 몇개씩 쌓여있다... 대략 베타라서 그런것 같고 뭐 찾아지는건 좀 다른내용이긴 하지만, 비슷할것 같고 해결중인것으로 보여진다...아님말고 (무책임 먼산~ ;p) ------------[ cut here ]------------ WARNING: at fs/sysfs/dir.c:491 sysfs_add_one+0xf4/0x160() (Tainted: G W ) sysfs: cannot create duplicate filename '/devices/qeth/0.0.0700/ipa_takeover' Modules linked in: qeth_l3(U) ipv6(U) qeth(U) qdio(U) vmur(U) ccwgroup(U) ext4(U) mbcache(U) jbd2(U) dasd_diag_mod(U) dasd_eckd_mod(U) dasd_mod(U) dm_mod(U) [last unloaded: scsi_wait_scan] CPU: 0 Tainted: G W 2.6.32-25.el6.s390x #1 Process ccw_init (pid: 825, task: 00000000023150b0, ksp: 000000003d3bf9d0) 000000003d3bfb78 000000003d3bfaf8 0000000000000002 0000000000000000 000000003d3bfb98 000000003d3bfb10 000000003d3bfb10 00000000004a8b8c 000000000001ffff 00000000007b3254 0000000000000000 000000003d3bff18 000000000000000d 000000000000000c 000000003d3bfb68 0000000000000000 0000000000000000 00000000001052f0 000000003d3bfaf8 000000003d3bfb38 Call Trace: ([<00000000001051f0>] show_trace+0xe8/0x138) [<0000000000144f3c>] warn_slowpath_common+0x80/0x98 [<0000000000144fc2>] warn_slowpath_fmt+0x5e/0x68 [<00000000002bc988>] sysfs_add_one+0xf4/0x160 [<00000000002bd2ca>] create_dir+0x6a/0xe0 [<00000000002bef32>] internal_create_group+0x5e/0x1e8 [<000003c001a52282>] qeth_l3_create_device_attributes+0x5a/0x108 [qeth_l3] [<000003c001a4ad08>] qeth_l3_probe_device+0x40/0x80 [qeth_l3] [<000003c00164097e>] qeth_dev_layer2_store+0xfe/0x114 [qeth] [<00000000002bb52c>] sysfs_write_file+0xe0/0x194 [<0000000000240270>] vfs_write+0xa0/0x1a0 [<0000000000240472>] SyS_write+0x5a/0xac [<0000000000118256>] sysc_noemu+0x10/0x16 [<0000004c971fea9c>] 0x4c971fea9c https://bugzilla.redhat.com/show_bug.cgi?id=468755 여기보면 RHEL5 버젼에서 비스무리한 경우가 있긴 한데 이건 뭐 할당이 안된거고, 여기선 왠지 모르겠지만 중복되었기때문에 난 문제인듯한데, 리부팅마다 남겨진것 같다. 동일한 내용인데 주소와 ccw_init PID 만 변하고 계속 새로 카운트 되기 때문에 그렇게 생각 되는데, 몇번 #CP 모드에서 빠져나오는 부분 관련하여 여러번의 시행착오가 있었는데, 관련된것 같긴하지만... 좀 더 zLinux 에 대한 공부가 필요하다.

글 전체보기

LWN 기사중 LFCS 관련 기사 -2-

2010-05-24T00:08:14+09:00

아까 노인들만 늘어난다(?) 라는 내용 외에 또 한가지 흥미로웠던것! 바로 구글과 안드로이드다! ( IBM 관련 대화들도 있긴한데 개발관련 된 부분들과 10주년 키노트 관련부분이라 그냥 패스한다.. ) Chris DiBona ( Google's Open Source Program Manager ) 의 대화가 있는데, 한동안 구글은 오픈소스 개발자들의 블랙홀이라는 비난을 받을 만큼 오픈소스 개발자들을 자꾸 대리고가서는 감옥에 가둬놓고 다른일은 전혀 못하게 착취를 시키곤 했는데(응~?) 크리스는(크리스맞나?) 구글이 오픈소스에 기여하는 점이 얼마나 많은지 설명하며 비난아닌, 상을 받아야 한다고 주장했었다고 한다. (뭐 code.google 에 있는 3만개 이상의 코드들이라든가, 지들이 내는 패치 뭐 기타 등등등 ) 재밌는건 내용 대충 보면 구글진영의 발언은 분노만 샀다는점 ㅎㅎ 안드로이드에 관해서 그는 upstream 에 merge 를 위해 그 과정과 온갖 관심들을 즐겁게 견딜 수 있을 만한 매조히즘을 갖고 있는 매조키스트 개발자가 없어서 어쩔 수 없다라고 한 발언이 있었다. 즉, 메인라인에 안드로이드를 포함하기 위해서 복잡한 메인라인 머지 작업과, 리뷰어들의 비난, 패치요청에 대한 작업을 구글 내부에서 막거나 규제하고 있진 않지만, 그것 자체에 대한 부담을 이겨내고 선뜻 나서서 진행하는 사람이 전혀 없다는 점....(이점은 예전기사들 보면 잘 나와있다 나중에 정리함 할까..) 즉, 당분간은 구글이 직접 나서서 커널 메인라인에 포함되는 일은 어렵고, 하고싶지 않다는 얘기 ;( (예전에 욕 대지게 먹고 메인라인에서 쫒겨났었.... :P ) 어쨋든 그 발언을 비롯하여 비난을 샀으면 샀지 그가 생각했던 만큼의 칭찬과 찬사는 얻어가지 못해 실패한 발언이였다고 전하고 있으며, 정말 흥미롭고도 너무 부럽게도, 이 성공적이지 못한 발언커버를 위해 세션 참석자 전원에게 "Nexus One" 을 주었다는 것!!!!!!! (ㅠㅠ 이런데 가고싶다 가고싶다 젠장 영어 ㅠㅠ ) 이것으로 많은 비난의 소리를 잠재울 수 있었더라는 얘기가 있다 :) 이것으로 충분히 만족스러운것 아닌가!!! 핸드폰을 그냥 막 뿌려줄 수 있을 정도의 배포!! 구글사마 ㅠㅠ 세션 후 조나단 코뱃 (기자다) 이 따로 안드로이드 커널 개발자들을 만났고, 이들의 얘기는 크리스의 말과는 달랐다고 한다. 이들은 여느 임베디드개발자와 동일 하였으며, "우리나라" 에서 역시 "흔히들" 말하는 식으로, "언제나 상품 개발 주기는 짧고, 시간은 부족하기때문에, 커널 메인라인에 merge 를 할 엄두가 없다" 라고 했다는 것이다. 안드로이드 커널 개발자들은 점점 외톨이가 되어 가며, 그것이 그들을 좌절시킨다고 기사에서 전하고 있다. 조나단은 이 기사를 통해 안드로이드 커널 개발자들이 모든 리눅스 커뮤니티에서 그들과 소통하려고 하였던 모든 요구들을 잘 들어왔고 충분히 이해하고 있다고 말하며, 이번 기회를 통해 그들의 참여를 너그럽게 충분히 도와줘야 하는 시점이라고 말하고 있다. 우리 회사에서도 현재 안드로이드 개발을 열심히 연구중이곤 한데, 그들중에 실제 커널 개발 및 리눅스 커널에 대해서 얼마나 깊은 기여의식과 관심이 있을지 모르겠다.... 아마 "우리나라" 에서 "흔히들" 말하는 시간이 없고, 상품개발 주기가 짧다는 말은, 외국에서 쓰는 말과는 다르지 않을까 싶다. 우리나라는 마인드와, 기본기를 충실히 닦아가려는 자세부터 고쳐먹어야 할 것이다. ;( 난 아직 안드로이드 커널에 대해서 이렇다할 입장은 표명 할 수 없다. (잘 모르기에 ㅠㅠ ) 사실 MeeGo 가 더 땡긴다 :P PS : 고작 한개 기사 정리하는데 주말을 다 보냈다.. 정말 세상과, 시간, 그리고 우주는 끊임없이 팽창해 가고 있고, 나에게 주어진 삶이라는 시간은 계속 타들어가는 촛불과 같다. 그리고 나라는 그 촛불이 꺼질 시기는 온 몸이 다 타들어간 뒤이다. 다음 기회때는 TSC (Time Stamp Counter) 나 SLEB 에 관해서 (좀 간단한편이라 ㅠㅠ) 얘기해 보도록 하겠다.. 그럼 모두들 스윗쥬림 (Sweet Dream~)

글 전체보기

LWN 기사중 LFCS 관련 기사 -1-

2010-05-24T00:19:09+09:00

그동안 LWN에 흥미로운 기사들이 무쟈게 떴었는데, 귀차니즘과 먹고사니즘때문에 계속 헤드라인정도만 확인하고 시간이 흘러버렸었다.. 지금 아직 번역중인것도 있고, 번역은 완료 했는데, 내용정리가 안되있는것들 몇가지 있긴하지만, 차츰차츰 올릴 예정이고, 일단 지금은 샌프란시스코에서 열린 LFCS 에 관한 기사이다. 뭐 왜 흥미로웠냐면, Graybeards (내용 상 의미로하자면 노땅이라고 해야 할려나 ㅠㅠ) 에 관한 부분인데, 사실 현인이나 고수, 고참파일럿을 뜻하는 단어인데, 기사내용에 의하면 요즘 커널 개발자들의 새로운 피가 수혈되지 않아 어찌 해결해야 할지에 대한토론이다. 링크를 걸었기 때문에 보면 재밌을 것이라고 생각한다 :) 대략 결론만 요약하자면 커널 개발자의 노령화가 진행되고 있는것 같아 보이지만 실재론 그렇지 않다는 것. 매 커널 릴리즈 주기마다 1000명 이상의 개발자들이 참여하게 되며, 그 중의 상당 부분이 처음으로 릴리즈에 공헌 (constribution) 하는 사람들로, 그중 약 20%정도는 페이에 상관 없이 스스로, 그리고 취미로 contribution 을 즐기는 사람이라고 말하며, 오히려 contributor 중 일부는 다른 프로젝트에 참여하게 하는것이 차라리 나을 것이라는 얘기까지 돌고있을 정도로 많은 개발자들이 충원되어 발전하고 있다는 것이다. 내가 알기로도, 단순한 패치를 올리고 리뷰하는 코더들은 물론 릴리즈까지 직접 관여하여 각 부분별 프로젝트에 참여하고 있는 개발자들이 너무나도 많아 커널 릴리즈 속도가 엄청 빨라진걸로 알고 있는데.. 여기 새로운 커널 개발자들이 너무 없다라고 했던 링크된 기사에서 새로운 피가 수혈되지 않는 이유가 있다. ( http://www.jfplayhouse.com/2010/04/why-linux-is-not-attracting-young.html ) 링크에 의하면 신선한 피들의 수혈이 안되는 이유로 Linux 가 이미 기업소속개발자 들의 주도로 발전되고 있으며, 이로 인해 개인이 취미로 활동하는 부분들에서 얻을 수 있는 만족감이 크지 않다는 것이다. 이거 우리나라에서 쓴건가 라는 생각을 할정도로 재밌는 기사였다 :) 하지만 난 좀 다른 이유로 본다. 메인라인 커널 커뮤니티에서는 대부분 각각의 분야가 있다. 서로가 각각 맡은 분야에 집중하다 보면 충분한 만족할 수 있다고 생각한다. 실재로 난 아직 커널 메인라인에 기여할 만큼 코드를 리뷰하거나 패치하지 않고 있고 실력도 안된다. 오픈소스 경험이라고는 골랑 vsftpd 와 tar, apache 에 아주아주 소소한 그것도 메일 보냈으나, 필요없을것 같아 포함하진 않겠으나 감사하다 따위의 메일정도만 받아 봤을 뿐... 개인별로 어느 정도의 기여를 해야만 자신이 그 프로젝트에 참여하고 있으며, 자랑스럽다고 느낄 수 있을지 모르겠지만, 그 메일 조차 나에게는 감격이였으니까..... 하지만 반면에, 이미 돈을 받으며 메인라인에 참여하고 있는 풀타임 개발자들의 비중이 대하고 중요하다는 것은 사실이고, 전체적으로 따져 보았을 때 필요한 부분이기 때문에 Linux 가 더 발전되고 퍼져나가는 것이라고도 생각한다. (왠지 내가 그냥 뿌듯 ㅠㅠ) 리눅스 개발의 진입장벽에 대한 또 다른 시각도 있었다. 커널 코어 개발자들의 경험치가 높아지는 반면 더 복잡한 코드가 포함되고 있다는 내용... 이로 인해 커널 개발의 진입장벽이 덩달아 높아지고, 그로 인해 코드 유지보수 역시 계속되서 어려워질 것이라는 이슈가 있다. 사실 개발자가 없는 이유를 들자면 난 이 말에 손을 들어 공감한다. 지금 리눅스 커널은 예전 한참 공부했던.. 시작하던때와 완벽하게 달라졌다. feature 및 모듈들은 계속 증가하고, 변화하며 제거되고 있으며, IT 산업자체의 흐름에도 맞추어 가야 하기 때문에, 쉽게 말해 짜바리들은 꺼져 가 되는 것이다. "너 커널 개발 참여하고 싶으면 이거부터 알고와..." 라고 해서 조낸 공부하다보면 이미 커널은 저~~ 멀리 달아나있다. 당장 어디서부터 시작해야 할 지 모를 정도로 멀리 와버린 것이다. "응 나 그냥 무작정 걷다보니 지구를 얼마나 돌았는지 모르겠네..선그어논거 있으니 쭉 그거 따라오면서 몇바퀴 돌았는지 세어보면 알꺼야" 라는.... 몇년 전가지 커널 책들은 아직도 한참 옛날 커널들에 맞추어진 책들만 쏟아져 나왔었고, 현재 변화된 커널에 맞는 개발에 대한 양서를 찾기란 매우 어려운 상황이 되어버렸다. ( 심지어 시스템엔지니어를 위한 서적들은 아직도 레드햇 9계열이다 !!! ) 무엇보다 이 커널 변화동안의 갭을 채워줄 훌륭한 서적들이 절대적으로 부족하다는 점... 물론 참여하기 위해 외국놈들에게 마구 물어보면 git 와 kernel source 에 있는 주석들 그리고 문서들을 이용하면 충분하다고 답해주고, 실제로 투덜대며 보면 잘되있다라는 게 요즘 그나마 다행이라는 점이다 ㅠㅠ 요즘은 또한 커널개발 책들도 괜찮은 것들이 보이긴 한다.. 모 고객사 커널레벨 이슈로 인해 커널에 대한 관심을 깊히 가지게 된 뒤로 계속 행동하진 못하고 있지만, 이번 기회에 정말로 최대한 참여해 봐야 겠다는 생각을 할 수 있었다. 일단 커널 공부를 위한 계획을 세워야 하고, 어떻게 어디서부터 시작해야 할지를 정해야 겠지.... ( 어디 사부라도 있으면 정말 도시락 쌓들고 당기면서 배우고 싶은 심정 ㅠㅠ ) 나도 나름 커널개발의 젊은(응~?) 피 가 될 수 있을까... 도전해 볼 과제다..(응?)

글 전체보기

z/VM 에서 Guest OS 로 콘솔(?) 접속하는법

2010-05-25T22:29:35+09:00

#CP disc 로 연결을 끊어야 Guest OS 가 계속 Running 된다. (위의 경우 x3270 연결이 종료된다.) 그리고 다시 붙고 싶을때 'CP READ' 였다능... 다시 붙으면 기본적으로 Guest 콘솔이 활성화 된다. #cp set run on #cp terminal CONMODE 3270 로 터미널 모드를 맞춰주는 것도 필요하다. 또한 ipl 로 다른 모드들로 넘어갈 경우에는 VM 이 그냥 내려간다... 방법 없는듯 :) 내려갔을때 Guest 를 띄우는 방법은 "#CP IPL D000" D000 은 DASD 의 이름으로, Guest 가 설치되어 있는 것을 불러온다는 의미인가 보다. (vdev ) 이걸 몰라서 그냥 'IPL CSM SHUTDOWN' 을 때렸더니 z/VM 이 내려간듯...

글 전체보기

RHEL6 on System Z 사용기 (1)

2010-05-20T13:42:54+09:00

으악. 이것저것 뭐해볼까 생각하다 '엔티' 형 말대로 워크로드 처리량이 뛰어나다는데 부하나걸어봐! 라는 걸 따라서 stress 테스트를 결정했다. 일전에 포모사의 사람잡기(응~?) 시스템 관련 이슈 해결할때 사용되었던 "stress" !!! 초반에 가볍게 cpu 2, vm 8개, 각 vm (process) 메모리 사이즈 128M, 3600초 동안 계속 유지 로 걸었더니 CPU 로드등의 부하가 90 ~ 100% 치면서 메모리도 마구 소진되고 하면서 좀 버벅되나 싶었는데, 잠깐이였을 뿐, 로우멤이나 메모리 소진 및 리클레임이 아주아주 원할하게 잘 순환하고 있었다. 몇분 돌리다 으흠.. RHEL 6 성능인거 아냐? 라는 생각에 조건을 더 걸어볼 요량으로 중단....그리고 이제 vm 32개 Memory 256M 3600초 동안 계속 유지시켰다. nmon 이라는 막강한 모니터링 툴로 보는데, 이게 갑자기 뚝.......멈춘거다... 로드에버리지 안찍히고, nmon 모니터링 시간 안흐르고, 접속도 안되고..... 한 십여분 대기하다가 설마 Z가 뻗은건 아니겠쥐~ 라는 생각에 다시 콘솔 접속.... 이상이 없다..... 여기서 GuestOS 를 죽일 생각으로 명령어 찾아보던중 shutdown 이라는 명령을 발견! 아무 생각없이 'IPL CMS SHUTDOWN' 을 과감하게 때려줬 아뿔싸..갑자기 콘솔 연결이 끊긴다...... 자세히 커맨드 설명을 봤더니 젠장 z/VM 셧다운 명령이다 ㅠㅠ 박부장님 죄송합니다 ㅠㅠ 텨텨 =3=33

글 전체보기

RHEL6 on System Z !!

2010-05-20T13:41:54+09:00

우연찮게 트위터를 통해 준희과장 다리로 IBM zLinux 팀 박부장님과 연이 닿았다... 그리곤 우연찮게 System Z 에 RHEL6 를 올리는 기회를 얻게 되었다!!!! (감사합니다 :] ) 일단 처음 접해보는 x3270 에뮬레이터는 참으로 당황스러운 모습이였는데, 명령어를 전혀! 하나도 모르겠다는 것이였다!!! 박부장님이 올려주신 System Z 관련 문서들은 오로지 영어! 일단 z/VM 에 대한 개념에 대해서 잘 알지 못하고 있던 전혀 모르고 구경만 살짝 했던 터라 꼼꼼히 읽어보기 시작했는데...역시 가장 도움이 되었던 것은 "SLES on System Z" 와 "RedHAT Cookbook" !! 대량 CP 와 IPL 그리고 CSM 에 대해서 파악은 되었는데 대체 이 커맨드들을 어떻게 쎃야할지를 모르겠더란.. 다행인 것은 이미 기존에 올라가 있는 SLES10 설치용 boot 이미지와 kernel, parameter 파일들의 내용이 매우 도움이 되었다는것... 하지만 이제부터 문제 시작... 첫번째 문제.. 일단 RHEL6 의 설치용 부트이미지와 커널이미지등을 업로드 시켜야 하는데, ftp 를 통해 업로드 하려고 봤더니 용량이 부족하단다.... '안타깝지만 SLES관련 파일들을 지워야 할것 같은데.......rm? del? rem? remove? delete? 어찌지워?' 라는 고민만 몇시간째 했다..다행이 고객사인 P사 에 같이 지원하는 P시리즈 엔지니어분께서 IBM infomation Center 에 보면 Command Reference 등 잘 설명되어 있고 검색도 편하니 이용해 보라신다. "오맙소사 완전 감사합니다." 하고 보니 정말 커맨드 레퍼런스가 쭉 있다.... 속으로 쾌재를 외치며 'IPL CSM' 란 명령을 통해 z/VM 로 진입...'l' 명령을 통해 파일리스트 확인 후, 'erase SLES10 img', 'erase SLES10 parm', 'erase SLES10 initrd' 등을 순차적으로 입력하여 SLES 의 흔적들을 지워버린뒤, ftp 로 RHEL6 설치용 파일들을 다운받았다. 설치에 필요한 필수파일은 일단 'kernel.img', 'initrd.img', 'generic.prm' 파일.. 여기서 난 실행 파일인 'redhat.exec' 파일을 같이 받았다. 이미 설치될 스토리지등은 할당이 되어있던 상황이기때문에, 바로 REDHAT EXEC 실행 이런 제길 안된다.... 여기서 두번째 문제에 봉착!!! 답답한 마음에 집으로 달려와서 다시 해보았다... 한가지 놓친게 있었는데, 그것은 바로 ftp 를 통해 다운받을때 선택해야하는 모드... (박부장님 힌트) parameter 파일의 경우 텍스트이기때문에 asc 로 받아야 정상적인게다... 'type generic.parm' 을 봤더니 텍스트가 다 깨져있었다.... 부랴부랴 다시 받았으나 역시 설치모드로 들어가질 않는다... 다시 찬찬히 파라메터 파일과 실행파일을 뜯어본다... 아하...CSM 관련 컨피그파일이 있어야 수월하게 작성하겠구나... 라는 생각을 하게되었고, RedHAT CookBook 의 컨피그파일을 참조하여 RHEL6.conf 파일을 만든다... 그리고 다음과 같이 파라메터 파일을 수정(추가) 해 준다. 'CSMCONFFILE=rhel6.conf vnc vncpassword=lnx4vm' 자 이제 다시 redhat.exec 실행이다. 몇가지 컨피그파일에서 빠져있는 부분들을 물어보며 (IP 등) 아주 스무쓰하게, 그리고도 아주 감탄스럽게도 리눅스 설치모드가 부팅된다. 여기서 ftp 및 cd 등 설치용 미디어를 설치해주고 설치진행될 언어를 선택해 주면 아나콘다가 뜬다!!! 이때부터는 vnc로 접속하면 된다 :) 그런데 또 한가지 문제!! vnc 가 뜨다가 중간에 죽는다... 콘솔에 뿌려지는 debug 관련 메시지.. 아무래도 아나콘다 쪽 문제인것 같은데...그냥 원래 설치하던데로 텍스트로 설치하자 아까 파라메터 파일을 다시 열어 vnc 부분을 text 로 바꿔주면 간단하다. 쭈~~~욱 된다......지만 역시 중간에 또 debug 라고 뜨면서 98%정도에서 뻗었다. selinux-policy-target 인가 뭔가 RPM 에서 멈췄다... glibc 관련 에러를 뿜으며... 이건 분명히 아나콘다 문제야... 라고 생각하며 다시 반복... 설치 완료!! 이제 이걸로 뭐하지??? PS : 생전 처음 System Z 를 직접 만저보았다... 단순히 설치까지만이였지만 x3270 이라는 에뮬레이터를 직접 사용해본것도, Mainframe 의 z/VM 를 이용해 Linux 를 올려 볼 수 있던 것도, 왠지 지금처럼 지쳐있는 나에게 굉장한 활력이 되었던 것 같다.... 감사합니다 박부장님 :)

글 전체보기