Linux Programmer

인텔 랩탑의 발열 제어를 위한 쓰로틀 프로그램 - ThrottleStop

sunyzero — Sun, 19 Apr 2026 23:37:57 +0900

삼성 갤럭시북3에는 인텔 13세대 i5 1340p CPU가 있는데 발열이 높아서 종종 스로틀링에 걸리는 문제가 있다. 원인은 4.6GHz나 되는 터보 기능 때문인데, 4GHz 근처만 가도 순식간에 80도를 찍어버린다. 그러고는 CPU 보호를 위해 속도가 1GHz 수준으로 훅 떨어져서 랙이 걸리는 것처럼 느려진다. 실제로 크롬으로 유튜브를 보면서 간단한 빌드 작업만 실행해도 순식간에 뜨거워졌다가 스로틀링으로 버벅거린다. 이 문제를 해결하려면 삼성에서 제공하는 최대 속도로 쿨러팬을 작동시키면 해결되는데, 그러면 팬 소음이 어마무시해서 짜증이 난다. 차라리 적당한 클럭(2GHz 언저리)로 작동되면 순간 속도는 느려지지만, 발열 문제도 해결되고 순간 끊김도 줄어들텐데 왜 이런 기능은 없을까 고민하게 되었다. 마침 본인은 리눅스에서는 온도에 따라 클록 속도를 제한하는 프로그램을 만들어서 잘 사용중이었다. 그리고 윈도11도 쉬울 것 같았으나... 큰 오산이고 평택이었다. ㅠㅠ

1. 윈도11의 엉망진창 발열관리

윈도11은 CPU의 발열을 관리하기 위해 작동 클록(Hz)을 운영체제에서 제어하는게 매우 어렵다는 것을 알게 되었다. 알고 싶지 않았지만 프로그램을 개발하면서 알게된 불편한 진실이었다. 아예 불가능한 것은 아니지만 윈11은 너무 극단적으로 클록이 내려가거나 혹은 제대로 작동하지 않았다. 어떤 사람은 제어판 설정에서 "프로세서 최대 성능"을 99%로 하면 부스트가 꺼져서 발열 제어가 된다고 하지만, 이렇게 했더니 아예 평소에도 boost기능이 꺼져서 클록이 너무 낮아지고, 속도가 너무 느려졌다.

본인은 원래는 Fedora Linux를 주로 사용한다. 그리고 리눅스는 커널에서 CPU클럭 속도를 쉽게 제어할 수 있는 방법을 제공하는데, 바로 /sys/devices/system/cpu/cpu번호/cpufreq/scaling_max_freq 파일에 최대 클록을 넣어서 즉시 적용하는 것이다. CPU 온도도 hwmon 센서로부터 읽으면 쉽다. 그래서 본인은 hwmon을 몇 초마다 읽어서 scaling_max_freq를 자동으로 조정하는 프로그램을 Rust로 작성했었고, 이를 daemon 서비스로 만들어서 systemd에 서비스 등록을 해뒀다. 이로 인해 본인이 사용하는 리눅스 랩탑 시스템은 CPU 온도에 따라 자동으로 CPU clock을 올리거나 낮추게 되어있다. 랩탑 뿐만 아니라 미니PC에도 이 프로그램을 사용중인데 아주 쾌적한 편이다. 아래는 이 프로그램의 web dashboard이다.

CPU Thermal Throttler - Fedora Linux 43

위 CPU Thermal Throttler 프로그램을 만들었던 경험을 되살려, 비슷한 기능을 윈11에서도 만들려고 했다. 하지만 결론부터 말하면 완전히 실패했다. 윈도는 레지스트리를 고치던 뭔 짓을 하던 스로틀링이 엉망으로 작동했다. 물론 내가 윈도 프로그래밍에 전문가가 아니라서 그럴 수도 있다. 하여튼 결국 실패하고, 기존에 이런 기능을 제공하는 프로그램이 있는지 조사했더니, 보통 2가지를 많이 추천하는 것 같았다. 참고로 아래 기능은 모두 Intel CPU에서만 작동한다. AMD는 이런 기능을 제공하는 프로그램이 있는지는 잘 모르겠다.

Intel XTU - Extreme Tuning Utility [1]
TechPowerUp의 ThrottleStop [2]

우선 Intel XTU는 기능은 제대로 작동했지만 뭔가 어설펐다. 삼성 시스템 설정에서 제공하는 놈과 충돌이 나는건지, 아니면 애초에 그렇게 만들어졌는지 모르겠으나, 자주 설정이 풀렸다. 매번 실행해서 apply 버튼을 누르는 것도 짜증이 났다. 결국 두번째인 ThrottleStop을 설치했는데, 이 녀석은 매우 잘 작동했다.

2. ThrottleStop 설정

ThrottleStop은 유명한 테크 사이트인 TechPowerUp에서 제작한 것으로 믿을 수 있는 프로그램인데, GUI는 좀 구린 편이고, 사용법도 구린 편이다. 그래서 여기서는 사용법을 조금 설명하도록 한다. 먼저 프로그램 다운로드 받고 설치 후 실행해보자. 다운로드 링크는 검색해도 알 수 있을테고, 귀찮으면 맨아래 참조 부분에 링크를 넣어두었다. 이런 프로그램은 항상 공식 사이트에서 받는걸 추천한다. 안그러면 해킹툴이 설치될 가능성이 있다.[2]

ThrottleStop and TPL configuration

ThrottleStop을 설치하고 실행하면 위 그림에서 좌측 같은 모양이 나오는데, 여기서 "Speed Shift EPP"를 켜져 있는지 확인한다. 그리고 TPL로 쓰여진 버튼을 누르면 우측 그림같은 모양이 나타난다.

2.1. MSR Power Limit Controls, PROCHOT Offset 설정

우측 그림을 확대해보면 아래와 같은데, 주의깊게 봐야 하는 것은 Long Power PL1, Short Power PL2, PROCHOT Offset 부분이다.

ThrottleStop PL1, PL2, PROCHOT Offset

참고로 MSR Power Limit쪽에 PL1, PL2는 15, 28을 넣었는데 이건 각각 다음과 같다.

PL1	지속적인 성능을 낼때 사용하는 전력량. 일반적인 사용에서 쓸 전력값이다. 기본적으로 28W였는데, 이 정도의 전력을 사용하면 온도가 곧잘 튀었다. 1340p에서는 보통 15W 정도로 설정하면 좋다는 글이 있어서 그걸 참고했다.
PL2	짧은 시간 부스트를 낼때 사용할 전력량으로 기본값이 60W였나 그런데, 이 상태는 너무 온도가 빠르게 올랐다. 대충 28 혹은 30W 정도를 주니까 크게 온도가 튀지 않았다. 물론 부스트 성능은 떨어졌지만, 그렇다고 무지막지하게 느려진 것은 아니였다.

PROCHOT Offset은 최대 허용온도에서 몇도를 내릴 것인지를 묻는 것이다. Intel i5-1340p는 섭씨 100도가 기본값인데, 위 그림처럼 40을 넣으면 100-40=60도가 된다. 그리고 뒤에 Lock 부분을 클릭해주면 다른 프로그램이 이 값을 수정하더라도 ThrottleStop이 이 값을 다시 강제로 바꾼다고 한다. 즉 값을 고정시켜주는 기능이다.

이렇게 설정하고 나와서 SAVE를 누르면 앞서 그림처럼 PROCHOT 온도가 60도로 보이게 된다. 이게 바로 변경되는게 아니라, 프로그램을 재실행하면 그때서야 변경된다. 그래도 변경이 안되면 재부팅을 권장한다. 윈11은 뻑하면 재부팅하는게 가장 속편하다.

2.2. 기타 옵션

Options를 눌러서 몇가지 옵션을 지정해두면 편리하다.

ThrottleStop Options

위와 같이 "Start Minimized"로 시작하면서 창을 작게 만들어서 트레이로 보내면 편리하다. 그리고 "Minimize on Close"를 하면 닫는 버튼을 눌러도 프로그램이 죽지 않고 트레이 아이콘 모양으로 내려간다.

그런데 시스템 부팅시 자동으로 이 프로그램을 실행해주는 기능이 없다. 그래서 따로 수동으로 등록하는 기능을 만들어줘야 한다.

2.3. 작업 스케줄러 등록

먼저 "작업 스케줄러" 프로그램을 실행한다. 그러면 아래와 같이 프로그램이 보이는데, 순서대로 진행한다.

작업스케줄러에 TrottleStop 등록

"작업 만들기"로 새로운 작업을 만들고, 이름에는 ThrottleStop을 넣어두자. 그리고 "가장 높은 수전의 권한으로 실행"을 체크해두고, 트리거 탭으로 이동한다.

작업스케줄러에 TrottleStop등록 - 트리거

트리거는 언제 실행할 것인지를 결정하는데, 로그온 할 때, 모든 사용자로 설정해두면 된다. 그리고 확인을 누른다.

그 다음에는 3번째 탭인 "동작" 부분을 선택한다.

작업스케줄러에 ThrottleStop등록 - 동작

동작을 선택하고 "새로 만들기"를 눌러서 동작 속성을 위와 같이 만들어준다. 프로그램 스크립트는 "찾아보기"로 설치된 디렉토리를 찾아서 선택해주면 된다. 본인은 "C:\opt\ThrottleStop_9.7.3-beta\ThrottleStop.exe"에 설치했기에 저런 경로가 나온다. 그리고나서 시작 위치는 디렉토리를 적어주면 된다. 본인은 설치한 디렉토리인 "C:\opt\ThrottleStop_9.7.3-beta"를 넣어주었다. 오타를 내지 않도록 조심하자. 여기까지 했으면 마지막에 완료를 눌러주면 된다.

제대로 작업 스케줄러가 작동하는지 재부팅을 해보자. 트레이 아이콘 있는 곳에 "I" 그림이 있는 빨간 아이콘이 생기면 성공이다. 그리고 커서를 그 위에 가져가면 CPU온도와 사용량 %, MHz 등등이 보일 것이다.

3. 결론

Microsoft Windows 11에서 CPU 온도가 높아져서 빈번한 스로틀링을 막으려면 ThrottleStop 외에는 별다른 방법이 없는 것 같다. 문제는 이렇게 하면 CPU 성능의 최대값이 고정되기 때문에 충분히 냉각이 되는 환경에서도 클록 속도를 높이기는 어렵다. 이게 가장 큰 단점이다. 다만 비즈니스 랩탑의 경우는 온도가 높아지는 것보다는 이게 더 나은 것 같다.

그리고 왠만하면 리눅스를 사용하는게 장기적으로는 정신건강에 더 이로운 것 같다. 개인적으로 윈11에서 CPU 스로틀링하는 프로그램을 만들려고 삽질하는데 일주일을 허비했고, 인텔 XTU, ThrottleStop을 세팅하고 이것저것 테스트하는데 하루를 꼬박 소비했다. 그러나 실제 대부분의 작업은 리눅스를 계속 쓰고 있다. 윈도11은 진짜 가끔 문서 작업할 때를 제외하고는 안쓰는게 함정이라고나 할까? 그리고 이번에 윈11은 쓰다보니 쓸수록 욕만 나오는 운영체제다. 진짜 윈11은 엉망진창이다.

[1] Intel XTU, https://www.intel.co.kr/content/www/kr/ko/download/17881/intel-extreme-tuning-utility-intel-xtu.html

[2] TechPowerUp - ThrottleStop Downaload, https://www.techpowerup.com/download/techpowerup-throttlestop/

히스토리

2026.04.19 글 작성

GMKtec K12 바이오스 업데이트, CPU 팬 속도 설정

sunyzero — Mon, 2 Mar 2026 00:24:59 +0900

GMKtec의 K12 미니PC는 CPU 팬을 자동으로 설정해두면 정지 후 기동을 반복하면서 끼리릭 거리는 소리가 난다. 그래서 매뉴얼로 팬속도를 40%에 놓고 사용했는데, 이게 평상시에는 괜찮지만 작업을 걸어서 온도가 올라가면 40%로는 CPU 온도가 떨어지지 않고 과열되는 문제가 발생했다. 처음에는 그냥 포기하고 부하를 거는 작업은 다른 PC에서 했는데, GMKtec에 불만이 많이 접수되었는지 25년 12월경에 K12 BIOS가 업데이트되었고, 여기서는 PWM을 이용해서 가변으로 설정할 수 있게 되었다. 따라서 이 글에서는 BIOS를 업데이트하는 방법과 CPU팬을 어떻게 설정하는지를 살펴보겠다. (참고로 기존 BIOS는 버전이 1.07이었고 새롭게 올라온 BIOS는 2.02이다.)

주의할 점은 BIOS 업데이트는 항상 위험이 있을 수 있다. 특히 업데이트 과정에서 전원이 끊어지면 문제가 생길 수 있기 때문에 조심해서 진행해야 한다. 만일 어린아이나 고양이가 갑자기 뛰어들어 전원을 건드릴 수 있다면 큰일이 발생할 수 있다. 어떤 이는 문제가 생겨도 계속 전원을 인가해두면 비상 바이오스로 롤백되는 기능이 있다고 하는데, 확실하지는 않다. BIOS 업데이트는 항상 벽돌이 될 가능성을 내포하고 있다는 점만 명심하면 된다. 물론 바이오스 업데이트로 인해 벽돌이 되는 경우는 굉장히 드물기 때문에 크게 겁먹지 않아도 된다.

0. 준비과정

바이오스 업데이트에 앞서 혹시나 보안 프로그램이나 각종 이상한 프로그램으로 오류가 생길 수 있으니, 구라제거기로 미리 제거해두자. 만일 구라제거기에서 각종 쓸데없는 보안 프로그램을 제거했다면 꼭 재부팅을 해야만 한다. 구라제거기 사용법은 인터넷에 많이 존재하기 때문에 여기서 특별히 설명하지는 않는다.

1. GMKtect K12 바이오스 다운로드

GMKtec에서는 google drive에서 BIOS 파일을 제공한다. 이에 대한 정보는 dcinside 에 누군가가 써놓은 글이 검색되어 그 링크에서 찾아보았다.[1]

K12 BIOS 다운로드 링크는 다음과 같다.

https://drive.google.com/drive/folders/1rBz_8buFkmM5fHLtw54H-LbkwA0bdGPS?spm=..page_2054333.page_detail_1.1

이 글을 쓰는 시점에서 GMKtec K12의 BIOS 버전은 2가지가 제공되는데 2.02와 2.03이다. 2.02는 2025년 12월 16일자 바이오스이고, 2.03은 2026년 1월 8일자이다. 현재 업데이트에 성공한 대부분의 글을 보면 2.02로 작업했으므로 본인도 2.03보다는 명확한 후기가 있는 2.02로 업데이트 했다. 각 바이오스 파일 이름은 다음과 같다.

GMKtec K12 BIOS 2.02 = AKB52-02_GMK_SW2.02_255_20251216.zip
GMKtec K12 BIOS 2.03 = AKB52-02_GMK_BIOS2.03_EC2.02_255_20260108.zip

참고로 BIOS 2.03은 EC FW는 여전히 2.02이다. EC 펌웨어 쪽은 별로 수정할게 없었던 것 같으니 Fan 설정에는 변화가 없을 것 같다. 아무튼 AKB52-02_GMK_SW2.02_255_20251216.zip 를 다운로드한 뒤에 적당한 곳에 압축을 풀어놓자. 본인은 C:\work 디렉토리를 만들고 여기에 압축을 풀어놓았다.

2. GMKtec K12 바이오스 업데이트

압축을 풀면 Afu_WinFlash라는 하위 디렉토리가 보이고, 여기에 AKB52-02_BIOS_WinFlash.bat 라는 배치 실행파일이 보인다. 이 배치 실행파일을 관리자 권한으로 실행해주면 된다. 즉 아래 그림처럼 마우스 오른버튼 메뉴에서 관리자 권한으로 실행한다. 다시 말하지만 혹시라도 인터넷 뱅킹이나 정부 사이트 접속을 위해 보안 프로그램이 설치되어있다면 꼭 구라제거기로 제거하고 재부팅 후 이 작업을 하도록 하자. 보안 프로그램이 있다면 민감한 작업은 실패할 가능성이 있으니 조심해야 한다. 그리고 업데이트 중에는 다른 프로그램을 모두 닫아주고 오직 이 작업만 하도록 해야 한다.

GMKtec K12 BIOS update batch script

실행이 되면 CMD창이 열리면서 업데이트가 진행된다. 업데이트 중에는 모든 작업이 멈추기 때문에 그대로 두면 된다. 해당 업데이트 과정은 꽤 길게 진행되어서 10여분 넘게 걸린 것 같다.

GMKtec K12 BIOS update batch script

그대로 두면 모든 작업이 완료되고 자동으로 재부팅되는데, 이후 BIOS 설정으로 진입해서 F9를 누르고 Default 설정을 불러와야 한다. (보통 바이오스 업데이트 후에는 항상 Default 설정으로 되돌리고나서 설정하는 것이 좋다. 간혹 자동으로 디폴트 설정으로 돌아가는 경우도 많으나 수동으로도 꼭 디폴트를 불러오는 것이 좋다.)

만일 바이오스 업데이트 후 Del키나 F7를 눌렀는데도 윈도로 다시 들어왔다면 관리자 권한으로 명령어 창(cmd.exe)이나 powershell 실행후 아래 명령어를 치면 바이오스로 진입을 할 수 있게 해준다.

shutdown /r /fw /t 0

참고로 Boot 메뉴에서 Fast boot가 Enabled로 되어있으면 바이오스 진입이 어려운 경우가 있다. 따라서 바이오스를 자주 들락달락해야 한다면 Fast boot 기능을 Disabled로 설정하자.

3. GMKtec K12 바이오스 설정법

BIOS로 들어왔다면 Advanced의 "Hardware Monitor" 메뉴로 들어간다. 그러면 아래 그림처럼 CPU Fan setting과 System Fan setting을 할 수 있게 된다. 기본값은 Automatic Mode로 되어있을텐데, 아래처럼 Manual PWM Mode로 변경하고 아래와 같은 값으로 설정해주면 된다. 이에 대한 자세한 설정 매뉴얼은 GMKtec 웹사이트에 설명되어있으니 각주를 참고하자[2].

GMKtec K12 BIOS 2.02 - Hardware Monitor

Manual PWM Mode 팬 설정은 5개의 항목이 있으며, 다음과 같다.

항목	설명
Fan Off temperature limit	이 온도에 도달하면 Fan은 멈춘다.
Fan start temperature limit	이 온도 이상이면 Fan은 작동을 시작한다.
Fan full Speed tempature limit	이 온도에 도달하면 Fan은 최고 속도로 작동한다.
Fan Start PWM	팬이 작동할때 기본 속도 퍼센티지다. 즉 Fan start tempature limit에서 시작할때 속도를 의미.
PWM SLOPE SETTING	아마도 PWM 성능을 몇 퍼센트씩 올리거나 줄일 것인지를 의미하는 것 같다. 확실치 않다.

여기서 중요한 항목은 3개이며 Fan start temperature limit, Fan full Speed tempature limit, Fan Start PWM이다. 특히 Fan Off temperature limit 와 Fan start temperature limit는 같은 값으로 세팅하면 된다. 솔직히 왜 둘을 나눠놨는지는 잘 모르겠다. 두 항목을 다른 값으로 넣으면 이상한 현상을 일으켰다. 예를 들어 45, 40도로 세팅하면 43도 되었을 때 Off온도인 45의 영향을 받아서인지 start temperature limit가 40도여도 실제로는 팬이 돌지 않았다. 따라서 무조건 이 2개의 값은 동일하게 맞춰주는게 좋다고 생각된다.

Fan start PWM은 Fan start temperature limit 온도 이상일 때 fan이 가동을 시작하는데, 초기 속도로 최대 성능의 백분율이다. 즉 20이면 최대 성능의 20%로 작동하는 것이다. 만일 해당 팬의 최대 성능시 RPM이 2000이라면 20%일때 400RPM으로 작동을 시작하라는 뜻이다.

3.1. 매뉴얼 PWM 모드 설정 예시

예를 들어 아래와 같이 설정했다고 가정하자.

fan_start_temperature_limit = 30
fan_full_speed_temperature_litmit = 80
fan_start_pwm = 20

위 경우에는 섭씨30도(fan_start_temperature_limit)가 되면 fan이 돌기 시작하고, 최대 성능의 20%(fan_start_pwm)로 작동한다. 그러다가 섭씨50도가 되었다면 fan_start_temperature_limit보다 20도가 증가한 것인데 fan_full_speed_temperature_litmit - fan_start_temperature_limit = 50이므로, 20도의 증가는 가용 속도의 40%를 증가시키는 것이 된다. 그런데 초기값이 fan_start_pwm = 20%이므로 추가할 수 있는 가용 속도는 80%이며, 다시 80%의 40%를 증가시키는 것이므로 +32%가 된다. 따라서 CPU온도가 50가 되면 위 설정에서는 fan 최대 성능의 52% RPM으로 작동된다. 문제는 이런 공식을 적용하는게 직관적이지 않기 때문에 이를 자동 계산해주는 python code를 하나 작성했다.

3.2. GMKtec K12 팬 속도 계산 파이썬 코드

이 코드는 python으로 작성되어있으므로 적당한 파이썬 파일로 저장하고 실행하면 된다. 사용법은 코드 아랫쪽의 calculate_fan_metrics 를 호출하는 부분을 보면 된다.

def calculate_fan_metrics(start_temp, full_temp, start_pwm, ref_temp=0, ref_rpm=0):
    """
    start_temp: 팬 가동 시작 온도
    full_temp: 팬 최대 속도 도달 온도
    start_pwm: 시작 시 PWM (%)
    ref_temp: 기준 온도 (0 입력 시 RPM 계산 무시, RPM정보가 없는 경우 0을 입력)
    ref_rpm: 기준 온도에서의 RPM (0 입력 시 RPM 계산 무시, RPM정보가 없는 경우 0을 입력)
    """
    
    # 1. 온도 범위 및 가용 PWM 범위 계산
    temp_range = full_temp - start_temp
    available_pwm_range = 100 - start_pwm
    
    # RPM 계산 가능 여부 확인
    calculate_rpm = ref_temp > 0 and ref_rpm > 0
    max_rpm = 0
    
    if calculate_rpm:
        # 기준 온도에서의 PWM % 계산
        ref_temp_increase_ratio = (ref_temp - start_temp) / temp_range
        ref_pwm_percent = start_pwm + (available_pwm_range * ref_temp_increase_ratio)
        
        # 최대 RPM (100% 성능) 유추 공식
        # $$Max\ RPM = \frac{Reference\ RPM \times 100}{Reference\ PWM\%}$$
        max_rpm = (ref_rpm * 100) / ref_pwm_percent
        
        print(f"--- 분석 결과 (RPM 포함) ---")
        print(f"유추된 최대 성능(100%) RPM: {max_rpm:.0f} RPM\n")
    else:
        print(f"--- 분석 결과 (PWM 전용) ---")
        print(f"기준 RPM 정보가 없어 온도별 %만 계산합니다.\n")
    
    # 2. 결과 출력 헤더 구성
    header = f"{'단계':<4} | {'온도 (°C)':<10} | {'팬 속도 (%)':<12}"
    if calculate_rpm:
        header += f" | {'RPM (추산)':<10}"
    
    print(header)
    print("-" * (len(header) + 2))
    
    # 3. 데이터 계산 및 출력
    for i in range(6):
        ratio = i / 5
        current_temp = start_temp + (temp_range * ratio)
        current_pwm = start_pwm + (available_pwm_range * ratio)
        
        row = f"{i:<6} | {current_temp:<12.1f} | {current_pwm:<13.1f}%"
        
        if calculate_rpm:
            current_rpm = max_rpm * (current_pwm / 100)
            row += f" | {current_rpm:<10.0f}"
            
        print(row)

# --- 실행 예시 1: CPU fan. 41도 값 측정 ---
print("[CPU Fan]")
calculate_fan_metrics(30, 80, 20, 41, 1342)

print("\n" + "="*50 + "\n")

# --- 실행 예시 2: System fan 설정. 41도 값 측정 ---
print("[System Fan]")
calculate_fan_metrics(40, 80, 30, 41, 604)

위 코드에서 맨 아래에 calculate_fan_metrics 함수가 핵심인데, 인수는 fan start temperature, fan full temperature, start PWM 과 뒤에는 측정된 온도값을 넣으면 RPM 퍼센티지와 RPM속도를 추측해서 알려준다. 위 그림파일처럼 본인이 사용하는 CPU fan과 System fan 설정을 아래는 실행 결과이다.

$ ./gmk_k12_bios_pwm_settings.py
[CPU Fan]
--- 분석 결과 (RPM 포함) ---
유추된 최대 성능(100%) RPM: 3569 RPM

단계   | 온도 (°C)    | 팬 속도 (%)     | RPM (추산)
-----------------------------------------------
0      | 30.0         | 20.0         % | 714
1      | 40.0         | 36.0         % | 1285
2      | 50.0         | 52.0         % | 1856
3      | 60.0         | 68.0         % | 2427
4      | 70.0         | 84.0         % | 2998
5      | 80.0         | 100.0        % | 3569

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

[System Fan]
--- 분석 결과 (RPM 포함) ---
유추된 최대 성능(100%) RPM: 1902 RPM

단계   | 온도 (°C)    | 팬 속도 (%)     | RPM (추산)
-----------------------------------------------
0      | 40.0         | 30.0         % | 571
1      | 48.0         | 44.0         % | 837
2      | 56.0         | 58.0         % | 1103
3      | 64.0         | 72.0         % | 1370
4      | 72.0         | 86.0         % | 1636
5      | 80.0         | 100.0        % | 1902

즉 본인과 같이 설정하면 대락 어느 정도로 RPM이 작동하는 유추할 수 있을 것이다. CPU fan의 Start PWM을 40%로 상향시킨뒤 측정해보면 아래와 같이 값이 달라진다. 원래 PWM이 그렇게 칼처럼 정확한 것은 아니기 때문에 프로그램이 보여주는 값은 그냥 대략적으로만 유추하면 될 것 같다. 보통 전압이 높을때 오히려 제대로 된 값을 보여주므로 아마도 CPU 팬은 최대 4000~5000 RPM 사이의 제품이 아닌가 생각된다.

# calculate_fan_metrics(30, 80, 40, 39, 2065) # Start PWM 40%에서는 39도, 2065 RPM이 측정되었다.
[CPU Fan]
--- 분석 결과 (RPM 포함) ---
유추된 최대 성능(100%) RPM: 4065 RPM

단계   | 온도 (°C)    | 팬 속도 (%)     | RPM (추산)
-----------------------------------------------
0      | 30.0         | 40.0         % | 1626
1      | 40.0         | 52.0         % | 2114
2      | 50.0         | 64.0         % | 2602
3      | 60.0         | 76.0         % | 3089
4      | 70.0         | 88.0         % | 3577
5      | 80.0         | 100.0        % | 4065

4. 결론

바이오스 업데이트 후 Manual PWM Mode를 적절하게 설정하면 아주 쾌적하게 사용할 수 있다. 그리고 참고로 2000 RPM이 넘어가면 소음이 조금 거슬릴 정도로 커진다.

[1] GMKtec 바이오스 및 소프트웨어 링크 모음, https://gall.dcinside.com/mgallery/board/view/?id=minipc&no=262

[2] GMKtec K12 팬 설정법, https://www.gmktec.com/pages/k12-fan-speed-setting-modification-operation-guide?spm=..product_ee8b6354-4815-4f89-a502-a6fdf86ce1a9.product_description_1.1

[3] GMKtec K12 spec, https://www.gmktec.com/products/gmktec-k12-amd-ryzen%E2%84%A2-7-h-255-mini-pc

히스토리

2026.03.01 첫 릴리즈

mobaXterm에서 한글 타이핑시 "응답 없음"으로 죽는 문제

sunyzero — Mon, 23 Feb 2026 21:07:50 +0900

ssh접속을 위해 mobaXterm을 쓰다보면 한영 전환을 하거나 한글 타이핑을 하면 "응답 없음" 상태로 변하면서 프로세스가 죽는 문제가 생기곤 했다. 특히 한글을 타이핑하다가 오타가 발생해서 백스페이스로 자음이나 모음을 지울때 종종 발생했다. 그래서 mobaXterm 한글이 죽는 이유를 찾다보니 마이크로소프트가 IME(Input Method Editor)를 2가지를 가지고 있다는 것을 알았습니다. 그리고 최신의 IME(TSF방식)이 구형 프레임워크나 개발툴로 개발된 애플리케이션과 종종 충돌을 일으킨다는 것도 알게되었다.

1. 해결 방법

우선 해결 방법을 먼저 말하자면 설정에서 "시간 및 언어", "언어 및 지역", "옵션", "Microsoft 입력기" 메뉴에서 "이전 버전의 Microsoft IME"를 켬(on)으로 해두면 된다. 문제는 이 옵션이 꽤 깊숙한 곳에 있어서 찾아가는게 좀 어렵다. 그래서 찾아가는 방법을 한땀한땀 보여주도록 하겠다.

먼저 "설정"을 실행하고, "시간 및 언어" 메뉴를 선택한다. 그리고 아래 그림처럼 "한국어"의 점3개를 눌러서 "언어 옵션"을 선택한다.

윈11설정, 시간 및 언어, 언어 및 지역

언어 옵션을 선택해서 들어가면 아랫쪽에 키보드 메뉴가 있다. 여기서 아래 그림처럼 "Microsoft 입력기"라는 것을 찾고, 점3개를 눌러서 "키보드 옵션"을 선택한다.

한국어, 키보드, Microsoft 입력기

키보드 옵션을 선택해서 들어가면 하단에 호환성 부분에 "이전 버전의 Microsoft IME"를 켬(on)으로 설정하면 끝난다.

키보드 옵션, 호환성, 이전 버전의 Microsoft IME

이렇게 한 뒤에 되도록이면 재부팅을 하는 것을 권장한다. 애초에 이런 설정이 필요없도록 하려면 tabby 같은 ssh client를 사용하는 것도 괜찮다. 다만 개인적으로는 mobaXterm이 더 편해서 이걸 주로 사용하는 편이다. 그리고 깨알 지식으로 mobaXterm을 사용할 때는 리가처 폰트(ligature font)를 사용하면 이상하게 화면 스크롤 속도가 느려진다. 따라서 되도록이면 ligature 글꼴 대신 일반 글꼴을 사용하는 것을 권장한다.

2. 기술적 배경 지식

왜 이런 문제가 생겼는지 알기 위해서는 IME의 변화에 대해서 알아야만 한다. 마이크로소프트는 XP에서 TSF(Text Services Framework)라는 새로운 IME를 도입했다. 그리고 윈도10이나 윈도11에는 구형 IME인 IMM32와 신형 IME인 TSF가 둘다 설치되고, 기본값으로는 TSF로 작동한다는 점이다.

TSF의 특징은 비동기로 작동한다는 특징이 있다. 따라서 타이핑을 하는 것을 버퍼에 채워두었다가 완성시키거나 혹은 음성 변환이나 여러가지 기능이 있는데, 이게 기능을 추가하다보니 어느 시점부터 옛날 시스템과 뭔가 안맞는게 생겼던 것 같다. 게다가 mobaXterm은 델파이(Delphi)라고 굉장히 옛날 개발툴로 만들어지다보니 TSF와는 잘 맞지 않는 부분이 있는 것 같다. 그럼에도 불구하고 영어권은 큰 문제가 없어 보인다. 한글이나 중국 번체, 일어 한문등이 가장 큰 문제가 되는것 같은데, 이들 문자들의 특징은 여러 타이핑을 조합해서 하나의 문자가 생기는 케이스가 있다는 점이다. 영어는 hello를 칠때 h를 치면 즉각 h를 표시하면 그만이지만, 한글로 "헬로"를 타이핑하려면 "ㅎ + ㅔ + ㄹ" 까지 쳐야 "헬" 글자 1개가 완성된다. 여기서 ㅎ 다음에 "ㅔ" 대신에 "ㅐ"를 잘못 타이핑했다면 backspace로 지울때 현재까지 완성된 "해"를 지우는게 아니라 딱 "ㅐ"만 지우고, "ㅎ" 자음은 남겨야 하는데, 이런 부분이 오류를 만드는 원인이 되는 것 같다. 게다가 TSF가 비동기식이라 어떤 경우에는 잘 작동하지만, 어떤 경우에는 비동기 이벤트를 놓쳐서 "응답 없음"오류를 만드는 것 같다.

물론 2026년을 기준으로 보면 대부분의 개발툴들은 TSF를 제대로 지원하는 경우가 많아서 큰 문제는 안되지만, 앞서 언급한 델파이나 아니면 cygwin, Qt을 이용하는 시스템에서는 문제가 종종 생기는 것 같다. 결국 문제가 생기는 애플리케이션을 주로 쓴다면 결국 TSF를 버리고 "이전 버전의 Microsoft IME"인 IMM32를 쓰는 수 밖에 없어 보인다. (마소가 근본적인 문제를 고쳐서 TSF를 쓸때도 문제없게 해주면 좋겠지만, 솔직히 기대도 안한다. 왜냐하면 지금 윈11은 툭하면 업데이트 버그가 쏟아지기 때문이다. 사소한 버그도 해결 못하는 것을 보면 윈도 개발팀의 프로그래밍 능력이 수준 이하라고 생각된다.)

게다가 TSF를 쓰면 성능도 좋아진다고는 하지만 솔직히 요새 시스템에서 TSF를 써서 얻는 성능적 이점은 쥐꼬리의 털조각 1개만큼도 안되는 수준이라, 성능적 이점은 사실상 없다. 다만 TSF는 한자를 더 많이 지원하는 장점이 있다고 하는데, 요새 한자를 병용하거나 한자를 타이핑하는 경우는 드물기 때문에 큰 메리트가 없어 보인다.

결론적으로 mobaXterm을 쓸때는 TSF를 쓰지 않고 IMM32를 쓰도록 "이전 버전의 Microsoft IME"를 설정하도록 하자.

히스토리

2026.02.23 릴리즈

LargeSystemCache 설정에 대한 오해 (윈11, 윈10 최적화)

sunyzero — Fri, 23 Jan 2026 19:52:55 +0900

윈도11 최적화 팁 중에 LargeSystemCache와 DisablePagingExecutive가 있는데, 이건 옛날에나 쓰던 방식이고, SSD를 사용하는 최근 2010년 이후의 시스템에는 오히려 문제가 되기 때문에 쓰면 안되는 설정이다. 하지만 여러 곳에서 잘못된 정보가 유통되기에 이 글을 쓰게 되었다. 실제로 주변인이 이걸 설정해서 PC와 랩탑이 이상 작동하는 문제가 있었고, 고쳐준 다음에 쓴 글이다.

1. 역사적 배경 (알아둬도 큰 쓸모는 없지만...)

LargeSystemCache와 DisablePagingExecutive 설정은 과거 HDD라고 불리는 하드 디스크를 장착한 십수년전 시스템에서 사용되던 설정으로서, 커널이라고 불리는 시스템 코어 부분이 사용하는 메모리 영역을 큰 값으로 확보해서 시스템 영역을 메모리에 상주시키는 효과가 있었다. 그렇다면 왜 시스템 영역을 메모리에 상주되는 기능이 있는지 살펴봐야 한다. 이를 위해 우린 스왑 영역에 대해서 조금 알아둬야만한다.

우선 램은 프로그램이 실행되기 위에서 디스크에 있는 정보를 읽어서 올려두는 주 메모리 공간(main memory)이다. 모든 프로그램은 램을 사용한다는 사실부터 기억해두자.

2000년대 중반만 하더라도 인터넷 열풍으로 PC 시장이 빠르게 성장했는데, 그에 비해 메모리(RAM) 용량은 발전이 더뎌서 1GB정도 밖에 안되는 경우가 많았다. 2026년 기준으로 보면 PC의 램 최소사양이 8~16GB이고, 게임을 하는 사람은 보통 32GB를 쓰는 것에 비하면 1GB는 엄청 작은 값이었다. 따라서 Windows에서는 여러 프로그램을 원활하게 실행하기 위해 최대한 램을 아껴써야만 했다. 이를 위해 스왑 영역을 사용하는 기법이 도입되었는데, 이는 OS(운영체제)론을 배운 학생이라면 다 알것이다. 혹시나 모르는 사람을 위해 설명하자면, 운영체제가 메모리 부족을 해결하기 위해 디스크의 특정 영역에 메모리 공간의 일부를 이동(copy and remove)시켰다가 나중에 필요할때 다시 메모리로 가져오는 기법이다. 이렇게 하면 RAM이 1GB여도 2GB인 것처럼 뻥튀기를 할 수 있었다. 운영체제론에서는 이때 사용되는 디스크 공간을 스왑공간(swap space)이라고 부르는데, 윈도에서는 페이지 파일(pagefile) 이라고 다르게 부르며 실제 위치는 C:\pagefile.sys 에 만들어지는 경우가 많다.[1]

참고로 메모리의 영역을 pagefile로 이동시키는 과정을 스왑 아웃(swap out)이라고 부르고, 반대로 pagefile에서 RAM으로 이동하는 과정을 스왑 인(swap in)이라고 부른다. 아래 그림을 보면 이해가 쉬울 것이다.

Windows, Swap Out, Swap In (Gemini 생성)

그런데 스왑 아웃이나 스왑 인에는 심각한 문제가 있다. 그건 바로 딜레이가 발생한다는 점이다. 어떤 프로그램을 수행하려고 하는데, 필요한 램 공간이 500MB정도 부족하다고 가정하자. 그럼 운영체제는 최소 500MB 이상의 메모리를 확보하기 위해 메모리 일부분을 디스크로 복사하는 과정, 즉 swap out이 발생한다. 문제는 500MB이상의 데이터를 디스크로 복사하는 과정에서 심각한 딜레이가 발생한다는 점이다(당시 하드 디스크의 속도는 대체로 초당 50~100MB수준 이었다). 따라서 500MB이상의 메모리를 swap out하려면 최소 6~10초 정도는 딜레이가 생길 것이다. 그런데 프로그램 실행시 이 정도 딜레이가 발생하면 악영향을 줄 것이다. 그렇다면 딜레이를 줄이기 위해 어떤 방법이 있을까? 그건 바로 미리미리 복사하던지, 아니면 메모리를 비워서 빈 메모리 공간을 만들어두는 것이다.

그런데 이렇게 미리 공간을 확보하는 것이 효과가 좋은 원인을 생각해보면 HDD(하드 디스크)의 복사 속도가 매우 느렸기 때문에 발생하는 딜레이였다. 그리고 공간을 확보하기 위해 디스크를 자주 쓰거나 읽게되면 디스크로부터 데이터를 주로 많이 읽어들이는 데이터베이스나 서버들은 악영향이 생긴다. 그래서 메모리를 미리 확보하는 기법은 반대로 커널의 응답속도가 떨어뜨리는 문제가 생긴다. 그래서 주변 장치를 많이 사용하거나 혹은 커널이 대용량 데이터를 처리하는 경우에 반대로 커널(시스템) 영역이 디스크로 swap out되지 않도록 하는 기능이 필요해진 것이었다. 이를 돕는 기능이 바로 LargeSystemCache, DisablePagingExecutive 라 부르는 것이었다. 두가지 기능에 대해서는 아래에 표로 정리해두었다.

LargeSystemCache

대용량 캐시를 사용하도록 하여, 커널이 파일을 읽거나 메모리 영역을 사용 할 때 캐싱을 최대한 하도록 하는 기법이다. 즉 빈 공간을 남기지 말고 최대한 파일을 위한 캐시로 쓰게 한다. 윈도 서버에서 데이터베이스나 네트워크 서비스를 사용할 때 반응 속도를 올리는데 도움이 되던 설정이다. 게임이나 문서 작업을 하는 일반인들에게는 필요가 없는 설정이다.[2]

DisablePagingExecutive

커널이 사용하는 영역의 메모리나 디바이스 메모리를 swap out을 하지 않고 메인 메모리에 유지하도록 하는 것이다. 위와 마찬가지로 윈도 시스템의 반응 속도를 올려주는 장점이 있었다. 혹은 디바이스 장치를 개발하는 경우에 주로 사용한다. [3]

이들은 위에 정리한대로 메인 메모리(RAM)를 소모해서 윈도 시스템 자체의 서비스와 장치들의 반응 속도를 올리는게 핵심 목적이므로 주소 Windows Server에서 사용되는 기능이었다. 물론 개인용 PC에서 사용하던 Windows 7 (2009년)이나 Windows 8 (2012년)에는 4GB이상의 메모리를 가지고 있고, HDD 디스크를 사용하던 경우에는 이 설정이 효과가 있는 경우가 많았었다. 문제는 2010년대 중반에는 SSD가 대거 보급되었고, 8GB이상의 대용량 메모리를 가진 시스템이 늘어나면서 해당 설정이 무의미해졌다는 점이다. 지금 대부분의 시스템들은 보통 16GB이상의 메모리를 가지고 있고, 고성능의 SSD를 가지고 있기에 전혀 쓸 이유가 없는 기능이다.

호랑이 담배 피우던 시절에 쓰는 PC설정 (Gemini 생성)

그럼에도 불구하고 이 설정을 하면 빨라진다는 호랑이 담배피던 시절 괴담이 늘어나고 있는데, Win10이나 Win11에서 LargeSystemCache나 DisablePagingExecutive 를 설정해봐야 효과도 없고, 도리어 시스템을 불안정하게 만드는 경우도 많다. 특히 랩탑(노트북)은 이 설정을 켜면 절전모드에서 깨어날때 문제가 생기거나 몇몇 블루투스나 와이파이 장치들이 문제를 일으키기도 한다. PC 데스크탑에서는 랩탑보다는 안정적이지만 간혹 USB 장치나 PCIe 장치가 문제를 일으킬 수도 있다. 따라서 현재는 쓰면 안되는 기능이다. 그러면 이 기능을 어떻게 켜고 끄는지 살펴보자.

2. LargeSystemCache, DisablePagingExecutive 끄기

혹시라도 이 설정을 켠 사람들은 아래 방법으로 끄면 된다. 먼저 regedit를 실행해서 레지스트리 편집을 시행한다.

LargeSystemCache와 DisablePagingExecutive 설정

여기서 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management 설정으로 이동하면 LargeSystemCache나 DisablePagingExecutive 설정이 보일 것이다. 이 값들은 on하는 것이 1이고, off하는 것이 0이다. 당연히 default값은 off인 0이다. 이 2가지 설정 값이 1이라면 0으로 수정하면 된다.

혹시 이 값을 설정한 뒤에 페이징 파일(pagefile)을 0바이트로 설정했다면 원상복구하는 것을 추천한다. 원복을 위해서는 다음과 같이 sysdm.cpl 프로그램에 설정하는 것이 편하다. 먼저 Win + R 키를 누르면 나타나는 좌측 하단 입력창에 sysdm.cpl 을 타이핑해서 실행한다. 그리고 "고급" 탭에 "성능" 설정을 눌러서 "성능 옵션" 창을 띄운다. 여기서 다시 "고급" 탭으로 이동해서 "가상 메모리"의 변경 버튼을 누르면 아래 그림처럼 가상 메모리 설정을 볼 수 있다. 가상메모리 설정을 "시스템이 관리하는 크기"로 설정하면 원상복구가 된다. 간혹 가상메모리 크기를 고정값으로 "사용자 지정 크기" 로 16GB로 해두는게 좋다는 글도 있는데, 다 십수년전 옛날 설정 이야기다. 2026년 기준으로 보면 쓸데없는 설정이다.

sysdm.cpl의 성능옵션, 가상 메모리 설정

윈도10이나 윈도11은 옛날처럼 최적화 하는 기법이 대부분 작동하지 않는다. 오히려 요새 최적화 기법은 발열이 심각한 몇몇 랩탑의 CPU나 올인원 PC들의 CPU 성능을 80% 정도로 낮추는 기능이 유용하고, 알림을 꺼서 최적화 하는 정도만 제대로 쓸모가 있다. 그 외에는 그냥 디폴트 값을 쓰는게 좋다. 괜히 만져서 더 느려지거나 문제가 생길 수 있으니 주의하도록 하자.

그러나 굳이 꼭 쓰고 싶다면 위에 레지스트리를 고쳐서 LargeSystemCache 정도만 쓰는 것을 추천한다. 간혹 엄청난 문서 파일들을 작업하거나 동영상 같은 것을 편집하는 경우에는 아주 조금 유용할 수는 있을 듯 하다.

레퍼런스

[1] 페이징 파일 소개, Microsoft Learn, https://learn.microsoft.com/ko-kr/troubleshoot/windows-client/performance/introduction-to-the-page-file?source=recommendations

[2] LargeSystemCache에 대한 설명, https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc784562(v=ws.10)

[3] DisablePagingExecutive 에 대한 설명, https://learn.microsoft.com/en-us/windows-hardware/test/wpt/wpr-command-line-options

히스토리

2026.01.23 문서를 처음으로 작성

Virtualbox의 설치 오류 (업그레이드 오류)

sunyzero — Sun, 28 Dec 2025 20:28:22 +0900

Virtualbox를 업그레이드 하는 경우 이상하게 오류가 잘 발생한다. 이런 경우 십중팔구는 driver 문제이다. 기존 버전을 제거하고 새롭게 설치하는 경우라고 하더라도 아래와 같은 화면을 본다면 거의 99% drv 문제인 경우이다.

Virtualbox : Installation failed Error: Fatal error during installation.

이런 경우에는 재부팅하고 다시 시도하면 되는 경우도 있지만, 안되는 경우에는 다음과 같은 방법으로 시스템에 남겨진 드라이버 정보를 삭제하면 대부분 성공한다.

1. 관리자 권한으로 powershell 실행

먼저 관리자 권한으로 powershell을 실행한다. 꼭 파워쉘로 실행해야 한다. Windows11이라면 "<Win + X>"키를 눌러서 "터미널(관리자)"로 실행하면 빠르다. 혹은 "윈도우 키"를 누르고 powershell을 치면 "관리자로 실행" 혹은 "Run as Administrator"라는 메뉴로 실행해도 된다.

<Ctrl-X>의 메뉴

2. pnputil 명령 사용

관리자 권한으로 powershell을 실행한 뒤에는 다음과 같이 pnputil 명령어와 Select-String을 이용해서 vbox 이름이 들어간 driver를 볼 수 있다.

pnputil /enum-drivers | Select-String -Pattern "vbox" -Context 1,0

아래는 위 명령의 실행 예시이다. 결과를 보면 oem2.inf, oem11.inf, oem26.inf 의 드라이버 정보가 담긴 oem.inf 파일이 3개 보인다. oem inf 파일의 갯수는 조금 다를 수도 있다. 하여간 이들이 보인다는 것은 시스템에 Oracle Virtualbox 쓰레기 잔재들이 남아있는 것이다.

PS C:\Users\SYKIM> pnputil /enum-drivers | Select-String -Pattern "vbox" -Context 1,0

  게시된 이름:     oem2.inf
> 원래 이름:      vboxsup.inf
  게시된 이름:     oem11.inf
> 원래 이름:      vboxusb.inf
  게시된 이름:     oem26.inf
> 원래 이름:      vboxusbmon.inf

이들을 제거하기 위해 pnputil /delete-driver oem2.inf /uninstall /force 처럼 수동으로 일일히 명령을 내려도 되지만, 그러면 너무 귀찮아진다. 따라서 powershell script 명령으로 한방에 해결할 수 있다. 아래 코드를 복사해서 powershell 관리자 모드에서 명령하면 끝난다.

pnputil /enum-drivers | Select-String "Published Name|Original Name" -Context 1,0 | ForEach-Object { if ($_ -match "Published Name") { $pub=($_.Line -split ":\s+")[1].Trim() }; if ($_ -match "Original Name" -and $_.Line -match "vbox") { pnputil /delete-driver $pub /uninstall /force } }

복붙이 어려운 분들을 위해서 아래에 다시 한번 적어두도록 하겠다. 친절하게 어디를 복붙해야 하는지 yellow색으로 색칠해두었다.

pnputil /enum-drivers | Select-String "Published Name|Original Name" -Context 1,0 | ForEach-Object { if ($_ -match "Published Name") { $pub=($_.Line -split ":\s+")[1].Trim() }; if ($_ -match "Original Name" -and $_.Line -match "vbox") { pnputil /delete-driver $pub /uninstall /force } }

실행한 뒤에는 앞서 확인했던 pnputil /enum-drivers | Select-String -Pattern "vbox" -Context 1,0 명령으로 다시 한번 목록이 나오는지 확인한다. 아무것도 나오는게 없다면 재부팅 후에 다시 설치를 시도하면 된다.

3. 잡담

오라클 버추얼박스는 이상하게 설치, 삭제도 잘 안되고 사용 중에 자잘한 오류도 드럽게 많다. 아니 버전이 7.x까지 왔는데도 이런 기초적인 에러가 발생한다는 것은 개발진의 프로그래밍 능력이 심각하게 떨어지는게 아닌가 의심된다. 강의하러 갔다가 vbox 설치나 업그레이드 때문에 수강하는 분들 랩탑에서 에러 발생하면 진짜 당황스럽다. 얼마전에는 이거 잡다가 시간을 거의 1시간 넘게 허비한 적도 있다.

Vbox, 넌 좀 맞자~

히스토리

2025-12-28 릴리즈.

Upgrade to Rocky Linux 10 (로키리눅스10 업그레이드)

sunyzero — Mon, 15 Dec 2025 00:50:52 +0900

지난 7월 Rocky Linux 10이 출시되었다.[1] 하지만 로키리눅스는 오피셜한 업그레이드 방법을 제공하지 않기 때문에 약간 편법으로 업그레이드를 해야한다. 오리지널 레퍼런스는 reddit에 올라온 "RHEL 10 upgrade from 9.6"이다.[2] 하지만 원문에 몇 가지 자잘한 버그가 있어서 본인이 약간 수정했다. 그리고 자동화를 위해 bash script도 작성했다. 우선 오류를 수정한 원문을 요약, 정리하면 다음과 같다.

How to Upgrade Rocky Linux 9 to Rocky Linux 10

Note: All commands require root user privileges.

Step 0: Ensure you have root user access for all commands.

Step 1: Enable the fastestmirror=1 option. This setting directs new package installations to the fastest available mirror site, saving time during the upgrade process.

Step 2: Clear any versionlock settings if they exist. This is especially important if versionlock was used to prevent kernel or other critical component updates for service stability. The upgrade will fail if versionlock restrictions remain in place, so they must be removed.

Step 3: Install the Rocky Linux 10 packages on your system: rocky-gpg-keys, rocky-release, and rocky-repos.

Step 4: If the rocky-repos package maintains old repository files pointing to Rocky Linux 9's GPG keys, errors will occur. Find and overwrite any *.rpmnew files in the /etc/yum.repos.d/ directory.

Step 5: Install Rocky Linux 10 using the command: dnf distro-sync

Step 6: If you use the rpmfusion nonfree repository, the old EL9 version may remain on your system. Remove the outdated version and reinstall the Rocky Linux 10 version.

Step 6a: Reboot the system after completing Step 6.

Step 7: Re-enable the fastestmirror=1 option. This setting is removed during the reinstallation process and must be reconfigured.

Step 8: Clean all temporary files using: dnf clean all

Step 9: Remove any remaining EL9 (old version) files. Use the command: rpm -e $(rpm -qa | grep '.el9.') 2>&1 | grep 'is needed by' | awk '{print $1}' to identify packages with dependencies. For packages with unresolvable dependencies, verify if they can be updated; otherwise, force remove them.

Step 10: Rebuild the rpm database.

There are two bash scripts for automation, written below. If the first script completes successfully, reboot the system and then run the second script.

업그레이드 자동화 bash script

위 프로세스를 자동화 하는 bash 스크립트는 다음과 같다. 스크립트 파일은 2개이며 첫번째 스크립트가 성공하면 재부팅한 뒤에 두번째 스크립트를 실행하면 된다.

Upgrade to Rocky Linux 10

업그레이드 bash script 1

첫번째 스크립트는 Rocky Linux 9.x 에서 10.1로 업그레이드하는 스크립트이다. 본인이 작업하거나 서비스하는 서버, 컨설팅해주는 회사의 서버는 9.4와 9.6이었는데 해당 스크립트로 업그레이드에 성공하였다. 그래도 만일 실행 오류가 있다면 적절하게 AI에게 물어서 해결하도록 하면 될 것이다. 아마도 gemini, claude, copilot, chatGPT 등에 물어보면 아주 잘 대답해 줄 것이다. 참고로 docker-ce나 nvidia-driver의 업그레이드 문제는 뒤에 적어두었다.

이 스크립트는 최대한 안전 코드를 넣어서 root 유저가 아니면 실행이 안되고, Rocky Linux 버전도 확인해서 9.x가 아니라면 작동하지 않도록 해두었다. 만일 업그레이드를 이미 한 뒤에 재실행하면 버전 체킹 때문에 실행이 중지될 것이다.

#!/bin/bash
ROCKY_VER_SOURCE=9
ROCKY_VER=10.1
REPO_URL="https://mirror.kakao.com/linux/rocky/${ROCKY_VER}/BaseOS/x86_64/os/Packages/r/"
PKGS_FILENAME=(
    rocky-gpg-keys-10.1-1.2.el10.noarch.rpm
    rocky-release-10.1-1.2.el10.noarch.rpm
    rocky-repos-10.1-1.2.el10.noarch.rpm
    )

PKGS_URL=(
    "${PKGS_FILENAME[@]/#/$REPO_URL}"
    )

check_el10_packages() {
    local installed_count=0

    for pkg_file in "${PKGS_FILENAME[@]}"; do
        # .rpm을 제거하여 패키지명 추출
        local pkg_name="${pkg_file%.rpm}"

        # rpm -q로 설치 여부 확인
        if rpm -q "$pkg_name" > /dev/null 2>&1; then
            ((installed_count++))
        fi
    done

    # 1개 이상 EL10 프로그램이 설치되어 있으면 return 0
    if [ $installed_count -gt 0 ]; then
        return 0
    else
        return 1
    fi
}

echo "Before you proceeding with the upgrade tasks below, you must first perform an update and reboot."
echo "If you have already done so, press Enter. If you still need to update and reboot, press Control-C to stop."
echo "** To update and reboot as root, run the following command:"
echo ""
echo "       dnf -y update && dnf clean all && reboot"
read

echo "[II-0] Checking user privilege level."
echo "       This script requires root privileges. The script will exit with an error if run by a non-root user."
if [ $UID -ne 0 ]; then
    echo "[EE] Insufficient privileges : You must be root"
    exit 1
fi

echo "[II-1] Checking the distribution and version."
if [ ! -f /etc/rocky-release ]; then
    echo "[EE-1] It dosen't seem to be Rocky Linux. Please check the /etc/os-release and /etc/rocky-release files."
    echo "* Exit with error."
    exit 1
fi
echo "       Rocky Linux has been dectected."

# Resume 상황인지 판단한다. 특히 rock-repos 설치에서 GPG-Key로 에러가 발생하는 경우를 감지해서 버전 체킹을 건너뛰도록 한다.
check_el10_packages
if [ $? -ne 0 ]; then
    # 첫 설치라면 현재 Rocky Linux version이 9.x인지 체킹을 한다.
    echo "       Now let me check if the distrobution versio is ${ROCKY_VER_SOURCE}.x."
    DIST_VERSION=$(grep "^VERSION_ID=" /etc/os-release | cut -d'=' -f2 | tr -d '"')
    DIST_VERSION_MAJOR=$(echo $DIST_VERSION | cut -d'.' -f1)
    if [ "$DIST_VERSION_MAJOR" = "${ROCKY_VER_SOURCE}" ]; then
	    echo "      Rocky Linux ${ROCKY_VER_SOURCE}.x detected. Upgrade requirements are met."
    else
	    echo "[EE-1] Your Rocky Linux version is not ${ROCKY_VER_SOURCE}.x (current: $DIST_VERSION)"
	    echo "* Exit with error."
	    exit 1
    fi
else
    echo "      => Resuming - Skipping version checking."
fi

echo "[II-2] Checking dnf option : fastestmirror"
if ! grep -q '^fastestmirror=1' /etc/dnf/dnf.conf; then
    set -e
    dnf config-manager --setopt fastestmirror=1 --save
    set +e
fi

echo "[II-3] Checking dnf versionlock setting"
if dnf list installed | grep dnf-plugin-versionlock; then
	echo "  => clear versionlock setting if needed"
	set -e
	dnf versionlock clear
	set +e
else
	echo "  => This step can be skipped if you don't use the versionlock feature."
fi

echo "***************************************************************************"
echo "*** Warning: DO NOT STOP or TERMINATE THE PROCESS UNTIL IT IS COMPLETE. ***"
echo "***************************************************************************"

echo "[II-4] Install prerequisite packages before distro-sync to RockyLinux ${ROCKY_VER}"
echo "    => ${PKGS_URL[@]}"
dnf -y install ${PKGS_URL[@]}
RESCODE=$?
if [ $RESCODE -ne 0 ]; then
	echo "[EE-4] ERROR : dnf -y install ${PKGS_URL[@]}"
	exit $RESCODE
fi
rm -rf /usr/share/redhat-logos

# rocky-repos가 EL9의 GPG-KEY를 가진 옛날 버전의 rocky.repo를 그대로 보존하고 
# 새로운 rocky.repo (EL10용)을 rpmnew로 백업하는 문제를 해결하기 위해
# 파일을 찾아서 변경하는 단계를 추가하도록 한다.
echo "       Rename /etc/yum.repos.d/*.repo.rpmnew to *.repo"
REPO_DIR="/etc/yum.repos.d"
# .rpmnew 파일이 존재하는지 확인
if ls $REPO_DIR/*.repo.rpmnew 1> /dev/null 2>&1; then
    echo "      Processing repository files in $REPO_DIR"

    # .rpmnew 파일들을 찾아서 처리
    for rpmnew_file in $REPO_DIR/*.repo.rpmnew; do
        # 파일명에서 .rpmnew를 제거하여 기본 파일명 추출
        base_file="${rpmnew_file%.rpmnew}"
        repo_file="$base_file"
        rpmold_file="$base_file.rpmold"

        echo "      * Repository file: $(basename $repo_file)"

        # 기존 .repo 파일을 .rpmold로 변경
        if [ -f "$repo_file" ]; then
            mv "$repo_file" "$rpmold_file"
            echo "      * Backup: $(basename $repo_file) -> $(basename $rpmold_file)"
        fi

        # .rpmnew 파일을 .repo로 변경
        if [ -f "$rpmnew_file" ]; then
            mv "$rpmnew_file" "$repo_file"
            echo "      * Renamed: $(basename $rpmnew_file) -> $(basename $repo_file)"
        fi
    done
else
    echo " ***** Skipped if no .rpmnew files found in ${REPO_DIR}. *****"
fi

echo "[II-5] DNF distro-sync to ${ROCKY_VER}"
set -e
dnf -y --disablerepo="*" --enablerepo=baseos --enablerepo=appstream --enablerepo=extras --releasever=${ROCKY_VER} --allowerasing --skip-broken --setopt=deltarpm=false distro-sync
set +e

echo "[II-6] Checking rpmfusion nonfree repository"
RPMFUSION_URL='https://mirrors.rpmfusion.org/nonfree/el/rpmfusion-nonfree-release-10.noarch.rpm'
PKGNAME_RPMFUSION_NONFREE=$(rpm -qa 'rpmfusion*' | grep nonfree)
if [ ! -z $PKGNAME_RPMFUSION_NONFREE ]; then
	set -e
    rpm -e --nodeps $PKGNAME_RPMFUSION_NONFREE && dnf -y install ${RPMFUSION_URL}
	set +e
fi

echo "[Step1] Exit with success. The system needs to be rebooted."
echo ""
echo "If the graphical environmnt dose not work after reboot, please reinstall the dbus-daemon package."
echo "* To install the package as root, run the following the command:"
echo ""
echo "          dnf -y install dbus-daemon"

첫번째 스크립트가 성공했다면 "[Step1] Exit with success. The system needs to be rebooted" 가 보일 것이다. 재부팅을 해주면 된다.

업그레이드 bash script 2

재부팅이 완료되면 uname -a 명령으로 커널 버전에 el10 이 포함되어있는지 확인하자. 그리고나서 2번째 bash script를 실행하자. 이 스크립트는 남아있는 el9 구버전 패키지들을 청소해주는 기능을 가지고 있다. 두번째 스크립트도 root 권한으로 실행해야 하며, non-root로 실행하거나 버전오류가 있다면 실행이 중지되는 안전 코드가 들어있다.

#!/bin/bash
export LANG=en_US.UTF-8
set -o pipefail
typeset -i n_retry
ROCKY_VER=10.1

echo "[II-0] Checking user privilege level."
echo "       This script requires root privileges. The script will exit with an error if run by a non-root user."
if [ $UID -ne 0 ]; then
    echo "[EE] Insufficient privileges: You must be root."
    exit 1
fi

echo "[II-1] Checking the distribution and version."
DIST_VERSION=$(grep "^VERSION_ID=" /etc/os-release | cut -d'=' -f2 | tr -d '"')
if [ "$DIST_VERSION" = "${ROCKY_VER}" ]; then
    echo "      Rocky Linux ${DIST_VERSION} detected"
else
    echo "[EE-1] Your Rocky Linux version is not ${ROCKY_VER}.x (current: $DIST_VERSION)"
    echo "* Exit with error."
    exit 1
fi

echo "[II-2] Checking dnf option : fastestmirror"
if ! grep -q '^fastestmirror=1' /etc/dnf/dnf.conf; then
    set -e
    dnf config-manager --setopt fastestmirror=1 --save
    set +e
fi

echo "[II-3] Clean all"
dnf clean all

printf "[II-4] Trying to remove all 'el9(Enterprise Linux 9)' packages...\n"
while true; do
    let n_retry++
    failed_deps_file=$(rpm -e $(rpm -qa | grep '.el9.') 2>&1 | grep 'is needed by' | awk '{print $1}' | head -n1)
    rescode=$?
    if [ $rescode -eq 0 ] || [ -z $failed_deps_file ]; then
        printf "       (%03d) Successfully removed all 'el9' packages.\n" $n_retry
        break
    fi 

    # 해당 파일을 제공하는 패키지 찾기 (pkg_fullname = version을 포함한 이름, pkg_nameonly = only name)
    printf "       (%03d) Checking dependency...\n" $n_retry
    printf "       (%03d) $failed_deps_file <= This file causes a dependency conflict during package removal.\n" $n_retry
    pkg_fullname=$(rpm -qf $failed_deps_file)
    pkg_nameonly=$(rpm -qf $failed_deps_file --queryformat "%{NAME}")
    printf "       (%03d) $pkg_fullname     <= The pakcage containing the file ($failed_deps_file)\n" $n_retry
    echo   "         => Attempting update the package(${pkg_nameonly}); if failed, will delete."

    # dnf로 업데이트 시도 후 업데이트 되면 el9 패키지 삭제
    dnf -y update $pkg_nameonly
    rescode=$?
    if [ $rescode -eq 0 ]; then
        printf "       (%03d) Updated $pkg_nameonly via dnf.\n" $n_retry
    else
        printf "       (%03d) dnf failed; forcing package removal via rpm.\n" $n_retry
	rpm -e --nodeps $pkg_fullname
    fi
done

echo "[II-5] Update all"
dnf -y update

printf "[II-6] (%03d) REBUILD Package DB.\n" $n_retry
rpm --rebuilddb
echo "[Step2] Exit with success."

2번째 스크립트까지 실행이 완료되면 Rocky Linux 10.1로 업그레이드 완전히 되었을 것이다.

Rocky Linux 10 주의점

Rocky Linux 10에서 크게 변경된 점을 몇 가지 소개하도록 한다.

1) 터미널 소프트웨어 변경

X윈도의 터미널 기본 프로그램이 gnome-terminal에서 ptyxis로 변경되었다. 따라서 단축키로 gnome-terminal을 실행하는 경우에는 단축키를 수정해야만 한다. 또한 새창을 띄울 때는 ptyxis --new-windows; 로 옵션을 추가해서 명령해야 한다. 그렇지 않으면 기존 터미널 창이 있다면 새로운 창을 실행하지 않게 된다.

2) docker-ce 재설치

docker-ce를 사용중이라면 기존 패키지를 삭제 후 재설치가 필요하다. 기존 시스템에서 작동중이던 docker container나 image들은 docker-ce를 삭제해도 잠깐 중지되었다가 재실행될 뿐 사라지거나 하지는 않는다. docker-ce의 설치 방법은 공식 사이트의 RHEL 10 설치 부분을 참고하면 된다. [3] 하지만 이것도 귀찮은 분들을 위해 아래에 적어두도록 하겠다. 그냥 copy해서 root로 명령내리면 된다.

dnf -y remove docker-ce && dnf -y config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo && dnf -y install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin && systemctl enable --now docker

3) nvidia 드라이버 재설치

nvidia 드라이버를 사용하는 경우에는 약간의 수고를 해야 한다. 만일 cuda가 포함된 nvidia official driver의 경우에는 Rocky Linux 9.x의 경우 dnf module 기능을 사용했을텐데, 이 기능은 Rocky Linux 10에서 deprecated되었다. 따라서 nvidia module를 완전 제거한 뒤에 다시 설치해야 한다. 아래와 같이 명령해서 제거하고, 재설치한다.

먼저 dnf module list;로 설치된 모듈을 확인한다. 아래와 같이 nvidia-driver가 보인다면 module 설치된 경우이다.

# dnf module list 
WARNING: modularity is deprecated, and functionality will be removed in a future release of DNF5.
Last metadata expiration check: 0:01:06 ago on Thu 27 Nov 2025 08:40:19 PM KST.
@modulefailsafe
Name              Stream               Profiles                 Summary                                  
nvidia-driver     latest-dkms [e]      default [i], fm, ks      Nvidia driver for latest-dkms branch     

Hint: [d]efault, [e]nabled, [x]disabled, [i]nstalled

nvidia-driver module 삭제를 위해 아래와 같이 dnf module reset nvidia; 명령을 사용한다.

# dnf module reset nvidia-driver
WARNING: modularity is deprecated, and functionality will be removed in a future release of DNF5.
Last metadata expiration check: 0:03:41 ago on Thu 27 Nov 2025 08:40:19 PM KST.
Dependencies resolved.
=========================================================================================================
 Package                 Architecture           Version                    Repository               Size
=========================================================================================================
Resetting modules:
 nvidia-driver                                                                                          

Transaction Summary
=========================================================================================================

Is this ok [y/N]: y
Complete!

# dnf module list
WARNING: modularity is deprecated, and functionality will be removed in a future release of DNF5.
Last metadata expiration check: 0:03:49 ago on Thu 27 Nov 2025 08:40:19 PM KST.

.... 이제 dnf module list에 아무것도 나오지 않아야 한다 ....

설치된 구형 cuda 패키지도 삭제하기 위해 dnf -y remove '*nvidia*'; 명령을 실행해야 한다.

# dnf -y remove '*nvidia*'
Dependencies resolved.
=========================================================================================================
 Package                            Arch        Version                    Repository               Size
=========================================================================================================
Removing:
 libnvidia-container-tools          x86_64      1.18.0-1                   @cuda-rhel9-x86_64      108 k
 libnvidia-container1               x86_64      1.18.0-1                   @cuda-rhel9-x86_64      3.1 M
 nvidia-container-toolkit           x86_64      1.18.0-1                   @cuda-rhel9-x86_64      4.4 M
 nvidia-container-toolkit-base      x86_64      1.18.0-1                   @cuda-rhel9-x86_64       24 M
 nvidia-gpu-firmware                noarch      20251008-15.8.el10_0       @appstream              101 M

Transaction Summary
=========================================================================================================
Remove  5 Packages
...생략...

이제 epel-release (저장소)을 설치해주고, nvidia 저장소 추가후 nvidia-driver를 설치하면 된다. 명령어는 dnf -y install epel-release && dnf config-manager --add-repo http://developer.download.nvidia.com/compute/cuda/repos/rhel10/$(uname -m)/cuda-rhel10.repo && dnf -y install nvidia-driver; 이다.

# dnf -y install epel-release && dnf config-manager --add-repo http://developer.download.nvidia.com/compute/cuda/repos/rhel10/$(uname -m)/cuda-rhel10.repo && dnf -y install nvidia-driver;
Last metadata expiration check: 0:05:05 ago on Thu 27 Nov 2025 08:40:19 PM KST.
Dependencies resolved.
=========================================================================================================
 Package                      Architecture Version                        Repository                Size
=========================================================================================================
Installing:
 nvidia-driver                x86_64       3:580.105.08-1.el10            cuda-rhel10-x86_64       4.6 M
Installing dependencies:
 cuda-driver-devel-13-0       x86_64       13.0.96-1                      cuda-rhel10-x86_64        45 k
 dkms                         noarch       3.3.0-1.el10_1                 epel                      89 k
 egl-gbm                      x86_64       2:1.1.2.1-1.el10_1             epel                      21 k
 egl-wayland                  x86_64       1.1.20-2.el10_1                epel                      45 k
 egl-x11                      x86_64       1.0.3-1.el10_1                 epel                      55 k
 kernel-devel-matched         x86_64       6.12.0-124.8.1.el10_1          appstream                1.4 M
 kmod-nvidia-open-dkms        noarch       3:580.105.08-1.el10            cuda-rhel10-x86_64        16 M
 libglvnd-egl                 x86_64       1:1.7.0-7.el10                 appstream                 36 k
 libglvnd-gles                x86_64       1:1.7.0-7.el10                 appstream                 30 k
 libglvnd-opengl              x86_64       1:1.7.0-7.el10                 appstream                 38 k
 libnvidia-gpucomp            x86_64       3:580.105.08-1.el10            cuda-rhel10-x86_64        19 M
 libnvidia-ml                 x86_64       3:580.105.08-1.el10            cuda-rhel10-x86_64       670 k
 libvdpau                     x86_64       1.5-8.el10                     appstream                 17 k
 libwayland-client            x86_64       1.23.1-1.el10                  appstream                 33 k
 mesa-libEGL                  x86_64       25.0.7-6.el10_1                appstream                131 k
 mesa-vulkan-drivers          x86_64       25.0.7-6.el10_1                appstream                 17 M
 nvidia-driver-libs           x86_64       3:580.105.08-1.el10            cuda-rhel10-x86_64       144 M
 nvidia-kmod-common           noarch       3:580.105.08-1.el10            cuda-rhel10-x86_64        72 M
 nvidia-modprobe              x86_64       3:580.105.08-1.el10            cuda-rhel10-x86_64        30 k
 vulkan-loader                x86_64       1.4.313.0-1.el10               appstream                153 k

Transaction Summary
=========================================================================================================
Install  21 Packages

Total download size: 276 M
Installed size: 841 M
...생략...

간혹 gdm 화면 (로그인 화면)만 나오고 X 윈도 로그인이 제대로 작동하지 않는다면 dbus-daemon 문제가 대부분이므로 dnf -y install dbus-daemon; 명령으로 설치 해준다. 혹은 기존에 설치되어있다면 dnf -y reinstall dbus-daemon; 으로 재설치 해준다.

# dnf -y reinstall dbus-daemon

레퍼런스

[1] Rocky Linux 10.0 Available now, https://rockylinux.org/ko-KR/news/rocky-linux-10-0-ga-release

Rocky Linux 10.0 Available Now

Rocky Linux 10.0 Available Now By Neil Hanlon, Infrastructure Lead and Alexia Stein, Community Lead We are pleased to announce the general availabilit...

rockylinux.org

[2] RHEL10 upgrade from 9.6?, https://www.reddit.com/r/RockyLinux/comments/1l9gxdh/rhel_10_upgrade_from_96/

[3] Install Docker Engine on RHEL, https://docs.docker.com/engine/install/rhel/

RockyLinux9의 X윈도우 GDM 오류 : 아, 뭔가 문제가 생겼습니다

sunyzero — Sat, 29 Nov 2025 13:47:48 +0900

Rocky Linux 9 리눅스에서 X.org 에러로 인해 "아, 뭔가 문제가 생겼습니다. 문제가 발생했지만 복구하지 못했습니다. 시스템 관리자에게 문의하십시오" 메시지가 나온 경우를 에러 처리 하는 방법이다.

일전에 강의를 하다가 실습 이미지를 가지고 이것저것 해보는 수강자 분이 갑자기 X윈도가 안된다고 했다. 그래서 고쳐드렸는데, 에러를 찾아내면서 해결하는 과정을 보시더니, 다른 프로그램의 오류나 충돌도 이런 해결 방식을 사용할 수 있냐고 질문하시길래, 100% 같은 방법은 아니지만 얼추 비슷하게 할 수 있다고 말씀드렸다. 이렇게 문제를 해결하는 방법에 대해 더 자세히 알기를 원하셨지만 부족한 강의 시간 때문에 따로 과외를 해드릴 수는 없었고, 여기에 블로그 글로 남겨서 읽을 수 있게 해드리겠다고 하였다. 이 글은 당시 과정을 재현하기 위해 Virtualbox에 RockyLinux9을 설치하고 같은 오류를 만든 후 그림 및 로그를 캡쳐하였다.

1. 에러 상태

에러 상태는 어느 날 갑자기 X윈도우 로그인을 담당하는 GDM(GNOME Display Manager)가 화면을 띄우지 못하고 아래처럼 에러를 뱉어내는 상황이다. 어제 수업까지는 잘 되었다고 하는데, 당일 아침에 와서 실습용 컴퓨터를 켜니까 저렇게 에러가 발생했다고 하였다.

Rocky Linux 9 GDM error : 아, 뭔가 문제가 생겼습니다.

그런데 이와 별개로 "아, 뭔가 문제가 생겼습니다"라는 메시지가 너무 귀엽지 않은가? 시스템 언어가 English인 경우에는 "Oh no! Something has gone wrong. A problem has occurred and the system can't recover. Please log out and try again."이라고 표시된다. 해석이 좀 엉망이긴 한데, 이건 기계 번역이라서 그럴 것이다.

2. 해결 방법을 모색

모든 프로그램의 문제를 해결하기 위해서는 최우선적으로 log 메시지를 살펴봐야 한다. 일반적으로 로그 메시지는 journalctl로 보거나 아니면 개별적으로 해당 프로세스가 남기는 log 파일이 있다면 그것을 살펴본다. 로그가 하나도 나오지 않는 시스템이라면 strace 같은 것으로 추적하는 방법을 실행하면서 함수가 error로 리턴하는 경우를 살펴보면 된다.

이 작업은 root의 권한을 필요로 하기 때문에 su - 로 변경하던가, 아니면 sudoers를 잡아놨다면 sudo로 명령한다. 여기서는 su - 로 root 유저로 변경한 것을 간주하여 명령하도록 한다.

2.1. X window의 로그 살펴보기

Rocky Linux 9에서는 startx 명령어를 사용해서 수동으로 X window를 실행할 수 있다. 기존에 X 윈도우가 띄워져 있으면 에러가 발생할 수 있기 때문에 default target을 multi-user.target으로 바꾸고 수동으로 startx를 해야만 한다. default target을 변경하는 명령은 아래와 같다.

systemctl isolate multi-user.target

위 명령을 성공한 뒤에, startx를 실행했더니 아래처럼 실패가 발생한다. 아래 그림은 관련 화면을 캡쳐한 것이다.

Rocky Linux 9 : systemctl isolate multi-user.target; startx;

로그 파일의 위치는 /var/log/Xorg.0.log로 보인다. X server가 종료되는 것을 확인 후 해당 위치를 가서 확인해본다. (종료되지 않는다면 강제로 Ctrl-C를 눌러 종료한다)

Rocky Linux 9 : Xorg.0.log 파일

X 서버 로그는 information은 (II)로 표시하고, 에러는 (EE)로 표시한다. 따라서 (EE)문자열을 검색하면 빠르게 에러 위치를 찾을 수 있다. 위 그림에서 에러 위치에 AIGLX error: dlopen of /usr/lib64/dri/swrast_dri.so failed (/usr/lib64/dri/swrast_dri.so: undefined symbol: amdgpu_cs_ctx_stable_pstate) 으로 표시된 것을 볼 수 있다.

여기서 undefined symbol은 ABI가 깨진 것이다. 아마도 개발자가 함수명을 변경했을 것으로 보인다. 그러나 swrast_dri.so가 문제는 아니다. 반대로 swrast_dri.so에서 amdgpu_cs_ctx_stable_pstate를 호출하는 대상이 되는 shared object를 찾아야 한다. 그리고 해당 so를 업데이트해주는 것이 맞는데, 이걸 찾기 위해 역으로 호출하는 관계를 찾아야 한다.

2.2. rpm으로 오류의 원인 파일 찾기

패키지 관리툴인 rpm 명령의 query 옵션으로 /usr/lib64/dri/swrast_dri.so가 어느 패키지에 속한 파일인지 역추적해본다.

Rocky Linux 9 : mesa-dri-drivers의 swrast_dri.so 파일

패키지 이름은 mesa-dri-drivers 이다. 이 패키지가 언제 변경되었는지 추적하기 위해 dnf history를 통해 살펴본다. 해당 패키지의 이력은 history id 1은 설치될 때이고, history id 26번은 bcc-tools를 설치할 때 업데이트 되었다.

Rocky Linux 9 : dnf history mesa-dri-drivers

자세한 트랜잭션을 보기 위해 26번 ID를 살펴보자. mesa-dri-drivers-21.3.4-2.el9.x86_64에서 mesa-dri-drivers-22.3.0-2.el9.x86_64로 업데이트 된 것을 알 수 있다.

Rocky Linux 9 : dnf history : bcc-tools

dnf history info 26은 dnf install bcc-tools 명령을 의미하고, dependency에 의해mesa-dri-drivers가 upgrade 된 것을 볼 수 있다. 보기 쉽게 위 그림에는 노란색 화살표로 표시해두었다.

아래는 rpm -qR로 디펜던시도 확인해 보았다. 명령어가 길어서 아래에 history를 적어 두었다. 출력되는 명령어 순서는 괘념치 말자. 사실 이미 여기서 직감적으로 libdrm_amdgpu.so.1 가 범인인 것을 알 수 있었다. 왜냐하면 shared object가 호출하는 함수이름이 amdgpu_cs_ctx_stable_pstate이므로 amdgpu라는 단어가 들어갈 가능성이 높았기 때문이다. 설상가상으로 libdrm_amdgpu.so.1 파일이 등장하니까 금방 확인이 가능했다. 따라서 rpm -qf <library PATH>/libdrm_amdgpu.so.1으로 바로 찾을 수 있지만, 여기서는 직감보다는 좀 더 제너럴한 방법으로 해결 방법을 찾아가는 것을 살펴볼 것이다.

Rocky Linux 9 : rpm query

ldd swrast_dri.so 명령어로 링킹된 shared object 파일을 조사해보면 다음과 같이 볼 수 있다. 사실 안해봐도 되지만 뭐든지 2중, 3중으로 확인하는 것이 좋다.

Rocky Linux 9 : ldd swrast_dri.so

2.3. ltrace로 추적하기

리눅스에는 프로그램의 실행을 추적하기 위해서 strace, ltrace를 제공한다. 이 2가지 툴은 개발자나 관리자에게 거의 필수적으로 배워야 하는 툴이다. strace는 system call tracer이고, ltrace는 library call tracer이다. 여기서는 사용자 라이브러리 함수인 amdgpu_cs_ctx_stable_pstate가 문제이므로 ltrace를 사용한다.

ltrace로 startx의 실제 실행 파일인 xinit가 실행될 때를 추적해보자. shared object는 메모리를 할당하는 과정이 포함되므로 malloc-free를 추적하면 쉽다. 사용된 옵션은 아래와 같다.

-s <string length>	string length 기본값이 32라서 argument가 긴 경우 짤릴 수 있다. 보통 128~256을 많이 사용한다.
-o <file>	화면 출력이 아닌 지정된 file 출력으로 변경한다.
-S	library call뿐만 아니라 system call도 같이 출력한다.
-f	fork를 follow한다.

Rocky Linux 9 : ltrace 명령어 실행

ltrace로 xinit를 추적한 뒤에 출력 파일인 ltrace_xinit.txt를 열어서 추적하다보면 dlopen하는 부분에서 swrast_dir.so를 여는 부분을 찾을 수 있다. 그리고 swrast_dir.so를 open한 뒤에 어느 순간에 amdgpu_cs_ctx_stable_pstate를 호출하다가 undefined symbol 오류를 내는 부분이 나올 것으로 예측할 수 있을 것이다.

파일을 오픈하는 함수는 openat이므로 openat@SYS를 찾으면 된다. 아래 그림에 표시해 두었다.

Rocky Linux 9 : ltrace 명령어 로그 : openat@SYS 검색

위 그림에서 openat@SYS을 살펴보면 각각 오픈하는 so(shared object) 파일들이 libglapi.so libdrm_radeon.so, libdrm_amdgpu.so, libelf.so등으로 보인다. 여기서 libelf.so는 시스템에서 기본으로 사용하는 shared object이므로 범인이 아니다. 참고로 2171 openat@SYS(AT_FDCWD, "/lib64/libdrm_amdgpu.so.1"을 오픈하는 것을 볼 수 있는데, 직후 _dl_catch_exception 익셉션은 그냥 발생하는 것이므로 에러가 아니다. 그러면 이제 원인이 된 라이브러리 목록을 알았으니 하나하나 찾아가면 된다.

찾는 방법은 심볼 이름들로 찾으면 되는데, static library는 nm으로 찾지만 so는 readelf -s (-s옵션은 --syms로 심볼을 본다는 뜻)으로 찾는다. 따라서 여기서는 readelf를 사용한다.

그런데 symbol name이 길면 [...]으로 축약되어 출력된다. 그냥 볼 때는 별 상관이 없지만 자세한 심볼 이름이 필요한 경우는 민폐다. 따라서 -W (--wide) 옵션으로 symbol의 fullname을 보는 경우가 많다.

Rocky Linux 9 : readelf libdrm_amdgpu.so.1

위와 같은 방법을 쓰다보면 amdgpu_cs_... 어쩌구가 있는 라이브러리인 libdrm_amdgpu.so.1을 찾을 수 있다. 그리고 rpm -qf로 해당 파일이 어느 패키지에 속해있는지 추적해보면 libdrm 인 것을 알 수 있다.

Rocky Linux 9 : rpm -qf /lib64/libdrm_amdgpu.so.1

이제 dnf update libdrm 으로 문제를 일으킨 패키지를 업데이트 해주자.(간접 의존성이 있어서 자동 업데이트가 안된 것이므로 이렇게 수동으로 업데이트하면 된다.)

dnf update libdrm

업데이트가 완료된 뒤에는 다시 graphical.target으로 돌아가야 한다. systemctl 명령어를 아래와 같이 사용한다. (재부팅해도 되지만 사실 재부팅을 안하고 해결하는 것이 제일 좋은 방식이다. 실제 서버나 워크스테이션은 정말 최후의 상황에만 재부팅을 한다. 시스템 관리자나 개발자는 재부팅 없이 문제를 해결하는 방법을 찾아야만 한다.)

systemctl isolate graphical.target

이제 제대로 작동하게 될 것이다. 위와 같은 경우는 흔하지는 않지만 간혹 시스템에서 발생되는 문제이다. 모든 패키지가 의존성이 완벽하지 않아서 A패키지가 의존성에 의해 B를 추가 업그레이드 했는데, 다른 패키지인 X가 Y를 의존하고, 하필이면 Y가 B의 기능을 사용하는 관계라면 어떻게 될까? 이런 경우 B의 ABI가 변경된 경우, 즉 위와 같이 symbol name이나 argument가 변경되었다면 이를 인지하지 못한 X, Y를 호출하면서 오류가 발생한다. 이런 경우 Y를 업그레이드 해주면 되지만, 그걸 찾아내려면 위와 같이 하나하나 찾아내야 한다. 이렇게 indirect한 하위 의존성은 복잡한 패키지 구조에서는 찾기 힘들 때가 있다.

물론 모든 패키지를 다 업데이트하면 해결되는 경우도 있지만, 안정성 때문에 security에 관련된 최소한의 업데이트만 하는 경우가 많기 때문에 핀셋처럼 딱 찾아내는 방법도 알아둬야만 한다. 위 예시는 그런 경우를 찾아내는 방법이다.

이제 libdrm를 업데이트 한 뒤에 /lib64 디렉터리로 이동해서 readelf로 해당 심볼을 제대로 찾아 낼 수 있다.

Rocky Linux 9 : readelf libdrm_amdgpu.so.1 ❘ grep amdgpu_cs_ctx_stable_pstate

2.4. 원인과 결과

나중에 알게되었는데, 이 강의말고 이전 강의에 bpf를 이용한 시스템 문제 해결, 튜닝 수업이 있었는데, 해당 강의 자료 PDF가 들어있는 디렉토리를 수강자분께서 보고 관심이 생겨서 쉬는 시간에 실습하셨다고 했다. 그래서 bcc-tools를 설치했다가 의존성에 의해 mesa-dri-drivers가 업데이트 되어 발생한 문제였다. (원래 수강자분이 듣던 강의는 bash shell programming이라서 bcc-tools를 쓸 일이 없으므로 설치할 일도 없었다.) 궁금증이 원인이었는데, 수강자분은 딴짓해서 죄송하다고 했지만, 사실 이렇게 궁금증이 많아서 이것저것 해보는 분들이 나중에 대성하는 경향이 있어서 오히려 기운을 복돋아 드렸다. 나중에 높은 사람이거나 유명한 사람이 되면 나를 좀 이끌어 달라고... -_-;;

3. LD_DEBUG를 사용하는 방법(꼼수)

이건 팁이면서 다른 방식의 해결법이다. 사실 이 방법이 더 쉽다. startx 실행시 아래처럼 LD_DEBUG=libs를 주고 실행하면 아래와 같은 출력을 볼 수 있다. 이 기능은 모든 CLI 명령어에 쓸 수 있다. 예를 들어 ls에 붙이면 ls가 호출하는 라이브러리를 모두 볼 수 있다.

LD_DEBUG=libs startx

LD_DEBUG=libs startx의 실행 결과는 아래 그림과 같다. 여기서 find library부분에 어떤 라이브러리를 참조하는지 나오는데, swrast_dri.so가 참조되기 전에 가져온 라이브러리 파일 경로를 보면 된다. 여기서 보이는 파일은 libglapi.so, libdrm_radeon.so libdrm_amdgpu.so, libelf.so, libxcd-dri3.so뿐이다. 이들만 readelf, rpm -qf, dnf history 로 조사해보면 금방 오류를 확인할 수 있다. 이 방법은 약간 꼼수에 가깝지만 실력자들이 많이 사용하는 기능이다.

LD_DEBUG=libs 사용 방법

LD_DEBUG에는 libs 말고도 reloc, files, bindings, unused 등등... 다양한 기능이 있으므로 높은 수준의 개발자나 admin 기법을 배우고자 한다면 꼭 살펴보도록 하자. 이런 고급 꼼수 기법은 아무나 가르쳐주는 기법이 아니므로, 알아두면 정말 큰 도움이 될 것이다.

히스토리

2025.11.29 첫 릴리즈.

Zeuslab 터치 모니터의 터치 범위 설정

sunyzero — Sun, 12 Oct 2025 22:05:25 +0900

Zeuslab의 P16KT 같은 터치 모니터를 사용해서 서브 모니터로 연결하면 터치하는 위치가 이상해지거나 혹은 첫번째 모니터 화면이 터치되는 경우가 있다. 이는 터치 위치가 전체 모니터 크기(2개의 모니터 공간의 합)로 계산되어 일어나는 문제이다. 따라서 특정 모니터 좌표만 터치되도록 조정해주면 된다. 참고로 이 글은 Zeuslab 터치 모니터에만 국한되는 것이 아니라 모든 터치 기능을 가진 모니터에 적용할 수 있는 기능이다.

1. 준비 작업 : event 장치명 확인 (root 권한으로)

우선 Zeuslab의 P16KT 터치 모니터의 event 장치명을 알기 위해 아래와 같이 명령한다. Zeuslab의 USB VID, PID는 0457, 0819이므로 grep에서 'usb:0457:0819'를 필터링했는데, 만일 다른 회사 제품이라면 libinput list-devices에서 제품명을 직접 찾은 다음에 Id값을 찾아서 넣으면 된다. 예를 들어 당신의 제품이 'usb:0123:4567' 이라면 grep -B 2 -A 12 'usb:0123:4567' 이라고 명령하면 쉽게 찾을 수 있다. 제품명과 USB VID, PID는 lsusb 명령의 결과에서 쉽게 찾을 수 있다.

아래 결과에서 보듯이 /dev/input/event26 를 기억해두면 된다. 이는 뒤에서 udevadm로 리로드와 트리거를 명령 할 때 필요하기 때문에 미리 알아본 것이다. 참고로 libinput 명령어는 root권한을 필요로 한다. 일반 유저로 명령시 Permission denied 에러가 발생할 것이다.

$ sudo libinput list-devices | grep -B 2 -A 12 'usb:0457:0819'
Device:                  Silicon Integrated System Co. SiS HID Touch Controller
Kernel:                  /dev/input/event26
Id:                      usb:0457:0819
Group:                   3
Seat:                    seat0, default
Size:                    117x85mm
Capabilities:            touch 
Tap-to-click:            n/a
Tap-and-drag:            n/a
Tap button map:          n/a
Tap drag lock:           n/a
Left-handed:             n/a
Nat.scrolling:           n/a
Middle emulation:        n/a
Calibration:             0.5 0.00 0.0 0.00 1.00 0.00

2. LIBINPUT_CALIBRATION_MATRIX의 이해

Wayland를 사용하는 최근의 리눅스에서는 LIBINPUT_CALIBRATION_MATRIX를 이용해서 터치 공간의 픽셀 위치를 조정(calibration) 할 수 있다. 이 값은 총 9개의 매트릭스로 되어있으며 각각은 아래와 같다.

libinput calibrtion matrix

여기서 터치 스크린용으로 사용되는 값은 M11, M12, M13, M21, M22, M23의 6개이며 각각은 아래와 같은 의미를 가진다.

M11	X축 배율(scaling), 입력된 X좌표에 곱해져서 최종 X좌표를 구한다. 예를 들어 0.5면 좌표의 위치가 절반으로 줄어드는 효과를 가진다.
M12	X좌표의 Y의존성(Skew/Rotation). 화면이 로테이션이 된 경우에 보정하는 값이다.
M13	X축 오프셋(offset), X좌표에 시작위치이다. 0이면 이동이 없는 것을 의미한다.
M21	Y좌표의 X의존성(Skew/Rotation). 화면이 로테이션이 된 경우에 보정하는 값이다.
M22	Y축 배율(scaling), 입력된 Y좌표에 곱해져서 최종 Y좌표를 구한다. 예를 들어 1이면 좌표를 변화시키지 않는다.
M23	Y축 오프셋(Offset), Y좌표의 시작위치이다.
M31	투시 변환(Perspective), 일반적으로 0이다. 이 값들은 건드리지 않는다.(뭔지는 자세히 모른다)
M32	투시 변환(Perspective), 일반적으로 0이다. 이 값들은 건드리지 않는다.(뭔지는 자세히 모른다)
M33	투시 변환(Perspective), 일반적으로 1이다. 이 값들은 건드리지 않는다.(뭔지는 자세히 모른다)

예를 들어 2개의 모니터가 있고, 각각 2560x1600의 해상도를 가진다고 가정하자. 모니터1이 일반 모니터이고, 모니터2가 Zeuslab의 P16KT 터치 모니터이다. 그리고 P16KT가 좌측에 배치되어있다고 가정하자.

이런 경우 전체 화면 크기는 5120x1600의 화면 크기를 가진다. 그리고 좌측 상단의 X,Y좌표는 (0,0)이고 2560x1600이므로 절반만 사용하는 셈이다. 따라서 M11은 0.5를 넣고, Y축 크기는 둘다 1600이므로 배율을 변화시킬 필요가 없으므로 M22는 1이다. 따라서 LIBINPUT_CALIBRATION_MATRIX는 다음과 같다.

LIBINPUT_CALIBRATION_MATRIX="0.5 0 0 0 1 0 0 0 1"

이 값을 적용시킬려면 udev의 rules 파일로 만드는 것이 좋다. 파일을 만들 디렉터리 경로는 /etc/udev/rules.d 이며, 파일명은 98-zeuslab-p16kt-libinput-calibration.rules 정도로 만들자. 사실 파일명은 다르게 해도 상관은 없다. 보통 앞의 숫자 2개와 파일 내용을 설명하는 적당한 이름이면 된다. 이것도 당연히 root 권한으로 파일을 생성해야만 한다. 내용은 아래 1줄짜리를 넣어두면 된다.

ACTION=="add|change", SUBSYSTEM=="input", ATTRS{idVendor}=="0457", ATTRS{idProduct}=="0819", ENV{LIBINPUT_CALIBRATION_MATRIX}="0.5 0 0 0 1 0 0 0 1"

보통은 rules 파일을 새로 넣으면 곧바로 적용되지만 기존 파일을 수정했거나, 혹여 로딩이 잘 안되는 경우가 있기 때문에 아래처럼 수동으로 이벤트를 발생시키는 것을 권장한다. 당연히 root로 명령한다. --name 의 장치명은 앞서 libinput에서 알아낸 파일명을 쓰면 된다. 혹시라도 이벤트가 제대로 작동하는지 확인하고 싶다면 미리 터미널 창을 하나 더 열고 udevadm monitor --environment --udev 명령을 내려두면 모니터링을 할 수 있다.

$ sudo udevadm control --reload && udevadm trigger --name=/dev/input/event26

보통 명령이 내려지면 바로 적용되는 경우도 있지만 때에 따라서는 10여분 가까이 걸리기도 한다. 왜 그런지는 잘 모르겠다. 적용이 제대로 되었는지는 libinput list-devices ... 명령에서 "Calibration" 항목을 보면 된다.

3. 화면의 크기가 다른 모니터 사용시

두 화면의 크기가 다른 모니터를 사용하는 경우에는 X, Y 좌표의 값이 달라지기 때문에 계산이 조금 복잡해진다. 예를 들어 모니터1번이 3840x2160, 모니터2번이 P16KT(2560x1600)이라면 논리적인 좌표값은 최대값을 따르기 때문에 토탈 화면 크기는 6400x2160이 된다. 이런 경우에는 M11, M13, M22의 좌표 계산이 약간 골치아파지기 때문에 이를 계산해주는 bash script를 하나 작성했다 (copilot을 이용해서 기본적인 뼈대를 작성하고, 오류가 있어서 약간 수정을 했다.)

#!/bin/bash
# 아래 1번, 2번 모니터의 설정을 본인의 화면에 맞게 수정한다.
### 설정 시작 ###
# 1. 모니터 설정 (물리적 픽셀 및 배율)
# 1번 모니터 (주 모니터)
MONITOR1_P_WIDTH=5120
MONITOR1_P_HEIGHT=2160
MONITOR1_SCALE=1.5 # 150%

# 2번 모니터 (터치 모니터)
MONITOR2_P_WIDTH=2560
MONITOR2_P_HEIGHT=1600
MONITOR2_SCALE=1.0 # 100% 가정 (필요에 따라 1.25, 1.5 등으로 변경 가능)
### 설정 끝 ###

# 터치 입력을 적용할 2번 모니터의 위치
TARGET="$1"
if [[ "$TARGET" != "left" && "$TARGET" != "right" ]]; then
    echo "Usage $0 [left|right]"
    exit 1
fi

# ### 2. 논리적 크기 계산 ###
# 1번 모니터 논리적 크기
MONITOR1_L_WIDTH=$(echo "scale=4; $MONITOR1_P_WIDTH / $MONITOR1_SCALE" | bc -l)
MONITOR1_L_HEIGHT=$(echo "scale=4; $MONITOR1_P_HEIGHT / $MONITOR1_SCALE" | bc -l)
echo "Monitor[1] : Logical width x height = $MONITOR1_L_WIDTH x $MONITOR1_L_HEIGHT"

# 2번 모니터 논리적 크기
MONITOR2_L_WIDTH=$(echo "scale=4; $MONITOR2_P_WIDTH / $MONITOR2_SCALE" | bc -l)
MONITOR2_L_HEIGHT=$(echo "scale=4; $MONITOR2_P_HEIGHT / $MONITOR2_SCALE" | bc -l)
echo "Monitor[2] : Logical width x height = $MONITOR2_L_WIDTH x $MONITOR2_L_HEIGHT"

# 전체 화면 논리적 크기 (두 모니터의 논리적 너비 합산)
TOTAL_WIDTH=$(echo "scale=4; $MONITOR1_L_WIDTH + $MONITOR2_L_WIDTH" | bc -l)

# 전체 화면 논리적 높이 (두 모니터의 논리적 높이 중 큰 값)
if (( $(echo "$MONITOR1_L_HEIGHT > $MONITOR2_L_HEIGHT" | bc -l) )); then
    TOTAL_HEIGHT=$MONITOR1_L_HEIGHT
else
    TOTAL_HEIGHT=$MONITOR2_L_HEIGHT
fi

# 2번 모니터의 논리적 Y축 오프셋 (중앙 정렬 가정)
Y_OFFSET_PIXELS=0

# ### 3. 매트릭스 계산 함수 ###
calc_matrix() {
    local x_offset=$1
    local y_offset=$2
    local width=$3
    local height=$4

    # 스케일링 비율 (A, E)
    local scale_x=$(echo "scale=4; $width / $TOTAL_WIDTH" | bc -l)
    local scale_y=$(echo "scale=4; $height / $TOTAL_HEIGHT" | bc -l)
    # 오프셋 비율 (C, F)
    local offset_x=$(echo "scale=4; $x_offset / $TOTAL_WIDTH" | bc -l)
    local offset_y=$(echo "scale=4; $y_offset / $TOTAL_HEIGHT" | bc -l)

    # 행렬 출력: M11 M12 M13 M21 M22 M23 M31 M32 M33 M12와 M21은 0: Rotation없음)
    echo "LIBINPUT_CALIBRATION_MATRIX=\"$scale_x 0 $offset_x 0 $scale_y $offset_y 0 0 1\""
}

# ### 4. 매트릭스 적용 ###
if [[ "$TARGET" == "left" ]]; then
    # 2번 모니터가 left: X 오프셋=0, Y 오프셋=$Y_OFFSET_PIXELS, 크기=2번 모니터 논리적 크기
    calc_matrix 0 $Y_OFFSET_PIXELS $MONITOR2_L_WIDTH $MONITOR2_L_HEIGHT
else
    # 2번 모니터가 right: X 오프셋=1번 모니터 논리적 너비, Y 오프셋=$Y_OFFSET_PIXELS, 크기=2번 모니터 논리적 크기
    calc_matrix $MONITOR1_L_WIDTH $Y_OFFSET_PIXELS $MONITOR2_L_WIDTH $MONITOR2_L_HEIGHT
fi

고해상도 모니터는 종종 배율을 150%나 200%로 높이는 경우도 있는데, 배율이 높아지면 논리적인 해상도가 달라진다. 예를 들어 4k 모니터의 물리적인 해상도는 3840x2160이지만, 배율을 200%로 높이면 논리적인 해상도는 1920x1080으로 변한다. 따라서 위에 스크립트에 위에서 6줄 코드 부분에 각 모니터의 해상도와 배율을 적도록 해뒀다.

일단 예제의 현재 값은 1번 모니터는 5k (5120x2160)에 배율은 150%로 저장해뒀다. 이 상태에서 터치 모니터가 왼쪽에 배치된 경우라면 아래처럼 명령한다.

$ ./libinput_calibration_matrix.sh left
Monitor[1] : Logical width x height = 3413.3333 x 1440.0000
Monitor[2] : Logical width x height = 2560.0000 x 1600.0000
LIBINPUT_CALIBRATION_MATRIX=".4285 0 0 0 1.0000 0 0 0 1"

위에서 나온 맨 아랫줄을 /etc/udev/rules.d 에 설정 파일에 넣어두면 된다. 설정 후 적용은 앞서 본 udevadm control --reload && udevadm trigger --name=/dev/input/event26 명령을 사용하도록 하자. (명령 후 실제 효과는 10여분까지 지연될 수 있음을 명심하자)

만일 오른쪽에 배치된 경우라면 right를 명령을 하면 된다.

$ ./libinput_calibration_matrix.sh right
Monitor[1] : Logical width x height = 3413.3333 x 1440.0000
Monitor[2] : Logical width x height = 2560.0000 x 1600.0000
LIBINPUT_CALIBRATION_MATRIX=".4285 0 .5714 0 1.0000 0 0 0 1"

혹시라도 아예 터치 기능을 비활성화 하고자 한다면 예전에 써둔 글이 있으니 그것을 참고하기 바란다.

히스토리

2025-10-12 초안 작성

레퍼런스

Calibrating Touchscreen, Arch Linux wiki, https://wiki.archlinux.org/title/Calibrating_Touchscreen
How to calibrate touch screen on Wayland, https://unix.stackexchange.com/questions/708447/how-to-calibrate-touch-screen-on-wayland

삼성 갤럭시북3 갤럭시북4 스피커 사운드 및 Fn키 설정

sunyzero — Fri, 10 Oct 2025 22:24:05 +0900

리눅스에서 삼성 갤럭시북의 스피커 사운드를 설정하는 방법이다. 삼성 갤럭시북에는 리얼텍 사운드 칩셋이 들어있는데 리눅스에서 인식은 되지만 이상하게도 스피커 출력은 안된다. 왜냐하면 삼성이 인수한 AKG에서 커스터마이징을 했기 때문에 기본 드라이버로는 스피커를 작동시킬 수 없는 것이다. 하지만 스피커가 아닌 이어폰으로는 아주 잘 된다. 아무튼 Linux에서 Galaxybook의 스피커 사운드를 듣기 위해서는 아래처럼 약간의 설정이 필요하다.

Samsung GalaxyBook AKG Dolby atmos speaker

참고로 이 설정 방법의 원본 링크는 아래와 같으며 이 글은 이를 약간 쉽게 풀어쓴 것이다.

Fixing ALC298 audio (no sound from speakers), https://forums.fedoraforum.org/showthread.php?331130-Fixing-ALC298-audio-%28no-sound-from-speakers

1. bash 스크립트 파일 설치

아래 github 링크의 necessary-verbs.sh 파일을 다운로드 한 뒤에 /usr/local/sbin 디렉터리에 복사한다. (root 권한이 필요하다)

https://github.com/joshuagrisham/galaxy-book2-pro-linux/blob/main/sound/necessary-verbs.sh

복사가 완료된 뒤에 chmod +x /usr/local/sbin/necessary-verbs.sh 명령으로 실행 권한을 준다. 그러고나서 해당 스크립트를 실행해보자. 이제 스피커로 소리가 제대로 나오는지 영상이나 음악을 틀어보자. 소리가 잘 나온다면 다음 systemd unit 설정을 작업하도록 하고, 안된다면 그냥 여기서 멈춘다.

2. systemd service unit 작성

root 권한으로 /etc/systemd/system/necessary-verbs.service 파일을 만들고, 아래의 내용을 넣는다.

[Unit]
Description=Run internal speaker fix script at startup
After=getty.target

[Service]
User=root
Group=root
Type=simple
ExecStart=/usr/local/sbin/necessary-verbs.sh
Restart=always
TimeoutStartSec=0

[Install]
WantedBy=default.target

파일을 저장한 뒤에는 다음 명령어를 실행해서 인식시키고, 해당 unit을 활성화한다.

systemctl daemon-reload

systemctl enable --now necessary-verbs.service

완전히 작동하는지 확인하기 위해 재부팅을 해본다.

3. 갤럭시북 커널 모듈 : Fn키 기능 설정

참고로 커널 6.14이후로는 samsung_galaxybook kernel module이 있다. modinfo samsung_galaxybook 로 확인 가능하다. 이 기능이 있는 커널은 Fn키 등을 사용할 수 있게 해준다. 예를 들어 Fn+F5는 터치패드 on/off, Fn+F6는 사운드 on/off, Fn+F7과 F8은 사운드 음량 조절, Fn+F9는 키보드 발광 조절이다.

히스토리

2025-10-10 초고

크롬 흰색창 혹은 흰색스크린 오류

sunyzero — Sun, 24 Aug 2025 22:05:21 +0900

윈도 업데이트 후 크롬 브라우저가 온통 하얀색으로 나왔다. 해당 증상은 ANGLE graphics backend를 OpenGL을 사용하면서 그래픽 가속을 켜놓은 경우에만 발생하는 것으로 보인다. 따라서 ANGLE graphics backend 설정을 Default로 재설정해주면 해결할 수 있다. 아래는 ANGLE 설정을 재설정하는 방법이다.

1. 크롬의 흰색창 증상

증상은 아래처럼 Chrome browser 실행시 그냥 하얀 화면, 흰색창으로 나타나는 경우이다. 진짜 아무것도 보이지 않는다.

Chrome white screen

2. 해결 방법

먼저 어떻게 해서든지 크롬 화면이 나오도록 실행해야 하는데, 이는 그래픽 가속을 끄는 옵션을 사용하면 된다. 먼저 실행된 크롬 브라우저를 종료한다. 대충 흰색 창의 우측 상단 X 마크가 있을 법한 위치를 눌러서 크롬을 닫는다. 혹은 창 선택 후 Alt+F4로 닫아도 된다.

크롬이 닫힌 뒤에 Powershell을 하나 실행시킨다. 실행은 "윈도우 + R"키를 눌러서 나온 실행 창에서 powershell이라고 치면 된다. Powershell 에서 크롬이 설치된 디렉토리로 이동하는데, 경로는 보통 "C:\Program Files\Google\Chrome\Application" 이다. 아래처럼 cd (change directory) 명령을 사용하면 된다. 오타를 낼 것 같다면 Tab키를 사용해서 자동완성으로 디렉토리를 찾아가면 편리하다.

cd "C:\Program Files\Google\Chrome\Application"

이제 해당 디렉토리에서 crhome.exe --disable-gpu 명령으로 크롬을 실행한다. 아래는 powershell에서 명령하는 모습을 캡쳐한 그림 파일이다.

Chome disable gpu option

이렇게 하면 이제 크롬 화면이 보일 것이다. 임시로 띄운 것이므로 여기서 설정을 손봐야 한다. 먼저 주소창에서 chrome://flags를 실행한다. 그리고 주소창 아래의 돋보기 검색창에 ANGLE을 타이핑하면 Choose ANGLE graphics backend가 보일 것이다. 이 값이 Default가 아닌 OpenGL 같은 다른 값으로 되어있을 것이다.

chrome flags - Choose ANGLE graphics backend - OpenGL

이제 default로 값을 변경한 뒤에 크롬창 우측 하단에 재시작을 눌러주면 재시작 되면서 제대로 작동 될 것이다.

chrome flags - Choose ANGLE graphics backend - Default

만일 이렇게 설정 한뒤에도 계속 흰색창 화면이 나온다면 앞의 crhome.exe --disable-gpu 로 실행한 뒤에 "설정"에서 "시스템"의 "가능한 경우 그래픽 가속 사용"을 꺼두는 방법 밖에 없다.

크롬 - 설정 - 시스템 - 가능한 경우 그래픽 가속 사용

현재 문제가 발생한 이유는 OpenGL관련 부분이나 DirectX 부분을 업데이트하면서 뭔가 꼬인 것이 아닐까 하는 의심이 든다.

히스토리

2025.08.24 처음 글 씀