'우분투'에 해당되는 글 34건

Client OS: Ubuntu Desktop 14.04.1 LTS (amd64)

Host OS: Ubuntu Server 14.04 LTS (amd64)

우분투 데스크탑에서 원격 컴퓨터에 SSH로 로그인하면서 X윈도우를 통한 앱을 쓰려면 서버와 클라이언트 양쪽 모두 X11 forwarding 옵션을 켜야 한다.  서버 쪽에서는 /etc/ssh/sshd_config 파일에서 X11Forwarding yes 항목이 주석 없이 적혀 있어야 한다. 클라이언트 쪽에서는 간단하게 "-X" 옵션만 추가하면 되지만, 이 때 에러 메세지가 발생하는 경우가 있는데, 그 중에 다음과 같이 .Xauthority 파일에 접근을 하지 못하는 에러가 발생할 때가 있다.

일단 위와 같은 에러 메세지가 뜨더라도 SSH 로그인은 되기 때문에, /home/[로그인 사용자 계정]/.Xauthority 파일을 확인해 보니 권한이 600 (루트만 읽고 수정가능)으로 되어 있었다. 그래서 일단 이 파일의 권한을 모든 사용자가 읽고 쓸 수 있게 바꾸어 보았다.

다시 ssh -X로 로그인해 보니 위의 에러는 사라졌지만, 로그인 과정에서 잠시 멈춰 있다가 아래와 같은 에러 메세지를 보여 주면서 어쨌든 기본 SSH로 로그인은 되었다. 여전히 X윈도우 관련 어플리케이션은 실행되지 않았다.

이 경우에는 lock에 관여하는 .Xauthority-c, .Xauthority-l 파일들을 삭제하면 된다.

SSH 세션에서 빠져나온 후, 다시 ssh -X를 이용하여 로그인해 보면 에러 없이 로그인이 되고, X윈도우 앱들도 정상적으로 실행됨을 확인할 수 있다.

Host OS: Ubuntu 14.04.1 LTS (amd64)

Guest OS: Windows 10 (64-bit)

연구실 PC가 메모리가 넉넉한 편이라서(16GB) 가상 머신으로 윈도우를 시험삼아 돌려 보고 있는데, 이상하게 오랜만에 가상머신에 원격으로 접속하면 (원격 데스크탑 RDP 사용) 바탕화면이 뜨는데 상당히 오랜 시간이 걸린다. 정확히 재지 않았지만, 1분은 확실히 넘는 것 같다.

가상머신 구성은 다음과 같다:

• 가상 머신 관리는 QEMU KVM을 사용
• 윈도우 가상 머신에 CPU 2 Cores (물리적으로 2개, 쓰레드 기준으로 4개), 6GB 메모리, 180GB의 하드디스크를 할당
• 평소에 항상 PC를 켜 두고, 리눅스를 주로 사용하다가 몇 시간에 한 번씩 윈도우 가상 머신에 RDP로 연결(리미너 원격 클라이언트 또는 FreeRDP 사용)

확인해본 결과, 우분투는 기본적으로 물리적인 메모리에 상주하는 어플리케이션을 가급적이면 스왑 영역(가상 메모리 영역; 즉 하드디스크)에 옮겨 두려는 경향이 크다는 것을 알게 되었다. 그리고 그 경향을 조절하는 설정 변수가 Swappiness이다. 0부터 100 사이의 값 중에서 기본값이 60으로 되어 있다. 60이라는 숫자가 정량적으로 얼마만큼의 메모리 영역을 스왑 영역으로 보내는지는 확실하지 않지만, 경향성이 매우 높은 편에 속한다는 사실에는 이견이 없어 보인다.

인터넷에서 대부분의 우분투 사용자들이 개인 PC에서 우분투를 쓸 때 성능을 개선하기 위해서 가장 먼저 swappiness부터 조정한다는 것 또한 알 수 있었다. 설정 방법은 /etc/sysctl.conf 파일에 아래와 같이 한 줄을 추가하거나, 이미 있으면 숫자를 아래와 같이 조정한다:

인터넷에서는 보통 swappiness 값을 10 으로 권장하는 분위기이다. 실제로 나도 swappiness 값을 조정하고 나서 윈도우 가상 머신의 원격 데스크탑 접속 로딩 시간이 꽤 단축되는 것을 체감할 수 있었다. 하지만 여전히 몇 시간 후에 다시 접속하면 약 30초 가량의 딜레이가 발생하였다. 그래서 아예 vm.swappiness 값을 3으로 더욱 낮게 설정했더니, 그제서야 길어도 10초 이내로 바로 원격 데스크탑 화면이 나타났다.

개인적인 경험으로 볼 때, 물리적 메모리가 16GB이고 가상 머신을 한 개만 운용하고 있으며, 이외에 메모리를 많이 소비하는 다른 프로그램을 쓰지 않기 때문에 swappiness 값을 매우 낮게 줘도 앞으로 쓰는 데는 문제가 없을 것 같다.

하지만 근본적으로는 서버에서 가상 머신을 돌리는 것이 속도를 개선하는 가장 확실한 방법인 것 같다. 실제로 연구실에서 운용하는 24코어에 64GB 메모리, 5TB의 하드디스크를 갖고 있는 서버에서 동일한 스펙의 가상 머신을 돌리는 것이 개인 PC에서 돌릴 때에 비해 속도가 월등하게 빨랐다. 즉, 그래픽 측면의 이질감과 불편함(폰트 같은 것이 깔끔하게 표시되지 못하고, 게임을 실행하지 못하는 문제)만 감수할 수 있다면, 서버에서 가상 머신을 돌리는 것(결국 클라우드 환경)이 좋을 수밖에 없다.

아직 연구실에 오픈스택(OpenStack)을 적용하지는 못했는데 (당장 이 쪽으로 연구실 구성원 중에 연구주제가 있는 것은 아니고, 운영상의 목적만 있음), 서버 여러 대와 몇몇 잉여 데스크탑 본제들을 조합해서 클라우드 환경을 만들어서 돌려보고 싶다. 일단은 졸업이 급하니 졸업하고 나서 해 봐야겠다. ㅜㅜ

OS: Ubuntu 14.04 LTS

우분투 부팅 시 "waiting for network configuration"이라는 글자가 떠서 한동안 기다리는 경우가 있다.

ESC로 취소가 안되고, 1분 이상 걸리는 듯 하다.

이런 경우는 대체로 /etc/network/interfaces 파일에 있는 설정이 실제 하드웨어와 맞지 않거나, 설정이 잘못 입력되어 있어서 발생한다. 필자의 경우에는 우분투 데스크탑에 있는 네트워크 관리자(network-manager)를 쓰지 않고 직접 /etc/network/interfaces 파일을 설정하다 보니 생기는 문제였다.

실제 하드웨어와 맞지 않는다는 것의 의미는, USB 무선랜카드에 대한 설정을 interfaces 파일에 기록해 두었는데, 재부팅하는 순간에 그 USB 무선랜카드를 빼 놓아서 interfaces 파일에 입력된 인터페이스 이름(예: wlan0)을 찾을 수 없는 경우이다.

이 경우, USB 무선랜카드를 연결시킨 다음에 부팅하거나, 부팅하는 당시에 /etc/network/interfaces 파일에서 무선랜 관련 설정이 미리 주석처리 되어 있어야 한다.

그 외에는 링크(http://askubuntu.com/questions/213614/waiting-for-network-configuration-problem)에 의하면, 같은 물리적 인터페이스에 여러 IP를 할당하는 경우(eth:0 과 같이 설정)에 게이트웨이를 두 번 명시하는 경우에도 발생한다고 한다.

OS: Ubuntu 14.04.2 LTS (amd64)

VGA: AMD Radeon HD7850

우분투 소프트웨어 업데이트가 많이 밀려서(약 2-3주) 설치할 소프트웨어 패키지들이 합쳐서 290MB 넘게 있었고, 이것들을 한번에 업데이트시키고 나서 재부팅을 했더니, Unity 데스크탑에 로그인하지 못하는 문제가 생겼다. 정확히 설명하면, 사용자 계정을 선택하고 비밀번호를 입력하는 화면에서 로그인을 하면 진행되는 듯 하다가 화면이 한번 깜빡하고 나서 다시 로그인 화면으로 되돌아온다.

아마 Unity 데스크탑을 로드하는 과정에서 문제가 생겨서 튕긴 것 같았다. 그래서 대체용으로 설치해 두었던 Gnome session (fallback)으로 선택했더니 임시로 로그인은 할 수 있었으나, 각종 설정 창은 결국 Unity 데스크탑을 기반으로 되어 있어서 아무 설정도 변경할 수 없었다.

유력하게 예상되는 원인으로, AMD 그래픽 드라이버와 관련된 패키지(fglrx 종류)가 업데이트되면서 망가진 것이 아닐까 생각이 되었다. 예상대로 AskUbuntu에 찾아본 결과, 비슷한 문제가 많이 언급되고 있었다. 필자도 AMD 그래픽 카드를 제대로 활용해 보고 싶어서 PC에 fglrx를 설치했고, 아마 하드웨어 가속도 기본으로 사용하도록 되어 있었던 것으로 기억한다.

결국 AMD 그래픽카드를 제대로 활용하는 것을 포기하기로 결정하고, 아래와 같이 fglrx 관련 패키지를 모두 삭제하고 Unity를 재설치하고 나서야 해결이 되었다. (참고: http://askubuntu.com/questions/449845/problems-after-upgrading-to-14-04-only-background-and-pointer-after-login)

이전까지 윈도우를 PC의 메인 운영체제로 써 오다가 올 여름부터 우분투를 메인 운영체제로 써 보았는데, 이런 식으로 소프트웨어 업데이트 한번에 데스크탑 환경 설정이 망가져서 로그인을 못할 정도면 우분투에 대한 신뢰성을 가질 수가 없다. 리눅스에서 그나마 일반 사용자가 쓸만한 우분투라고 해도 이런 식이면 윈도우보다 좋은 OS라고는 도저히 말할 수 없을 것 같다. 결국 무료이면서 이정도 수준인 것이 도리어 훌륭하다고 평가하는 것이 정확한 것일까?

어쨌든 우분투에서 AMD 그래픽카드를 쓰는 것 자체가 고난인 것 같고, 그래픽카드에 상관없이 VGA 카드의 하드웨어 가속을 쓰는 것도 잔고장이 너무 많아서 차라리 안 쓰는 것이 정신건강에 좋을 지도 모르겠다. 다른 리눅스 배포판에 비해서도 유난히 Unity 데스크탑은 문제가 많은 것 같다. XRDP를 조합하는 원격 데스크탑에서도 제대로 실행되지 않고, 이번처럼 그래픽카드 하드웨어 가속 관련 문제가 생기면 아예 로드도 되지 못하는 것은 너무 취약한 문제점이다. 배포판을 바꿔야 할지 심각하게 고민해 봐야 할 것 같다. 하지만 한번 바꾸는 데 하루가 꼬박 걸릴 텐데, 졸업연구도 급한 마당에 언제 가능할지 고민이 된다...

OS: Ubuntu 14.04.2 LTS (amd64)

Chrome: 46.0.2490.71 (64-bit)

Graphics: AMD Radeon HD 7800 Series

우분투에서 크롬을 쓰다가 가끔 화면이 깜빡이면서 얼마 전에 보던 탭(페이지) 화면이 표시되는 현상이 나타났다.

같은 증상이 데비안 계열에서도 있는 듯해 보였고, 우분투에서 많이 나타났으며, 특히 AMD 그래픽카드를 쓰고 드라이버 설치를 통해서 하드웨어 가속을 사용하는 사용자들에게서 문제가 많이 나타났다. Nvidia 계열 그래픽 카드에서는 그런 문제가 많이 나타나는 것 같지는 않아 보였다. (물론 Nvidia 계열에서도 같은 증상을 호소하는 글이 2개 정도 보이기는 했다)

간단한 해결방법은 크롬의 하드웨어 가속 기능을 끄는 것인데, 하드웨어 가속을 안하는 만큼 손해보는 요소도 있으니까 근본적인 해결책은 아니다. 하지만 그럼에도 불구하고 웹 브라우징을 제대로 하지 못할 정도로 심각한 깜빡임 현상을 감수하는 것보다는 하드웨어 가속을 끄는 것이 정신 건강에 이롭다는 생각이 든다.

<크롬 하드웨어 가속 끄는 방법>

1. 주소창에 chrome://settings 입력해서, Settings (설정)에 들어간다.

2. 맨 아래쪽에 Show advanced settings... 링크를 클릭.

3. 또 아래쪽으로 내려가서 "Use hardware acceleration when available"에 표시된 체크를 해제한다.

4. 크롬을 restart 해야 된다는 안내가 나오는데, restart 글자를 누르면 크롬이 재시작된다.