드라이버 패키지 묶음의 모양

한 줄 요약

NVIDIA 드라이버는 패키지 하나가 아니라 커널 모듈 / 유저 공간 라이브러리 / 유틸리티 / 디스플레이 드라이버 네 갈래가 얽힌 묶음이다.

왜 이게 필요했나

nvidia-driver-550 하나만 받으면 될 것 같지만, 그건 메타 패키지다. 실제 파일은 하나도 들어 있지 않고 의존성 목록만 있다. 그 목록을 따라가면 십여 개가 나온다.

어떻게 동작하나

네 갈래

nvidia-driver-550  (메타)├─ nvidia-kernel-dkms-550        커널 모듈 소스 (DKMS 로 빌드)│  ├─ dkms│  ├─ nvidia-kernel-common-550│  └─ linux-headers-*            <- 커널 버전에 묶인다├─ nvidia-utils-550              nvidia-smi 등│  ├─ nvidia-compute-utils-550│  └─ libnvidia-compute-550      CUDA 런타임 (Provides: libcuda1)│     └─ libnvidia-cfg1-550├─ libnvidia-gl-550              OpenGL/GLX/EGL└─ xserver-xorg-video-nvidia-550 X.Org 드라이버

여기서 폐쇄망 관점의 함정이 셋 나온다.

1. linux-headers 는 커널 버전에 묶인다. DKMS 가 커널 모듈을 빌드하려면 실행 중인 커널의 헤더가 필요하다. 그런데 커널이 업데이트되면 헤더 패키지 이름도 바뀐다. 반입 시점의 커널과 설치 대상의 커널이 다르면 빌드가 실패한다. 그래서 반입 전에 대상 서버의 uname -r 을 확인하는 것이 첫 단계다.

2. Provides 로 만족되는 의존이 있다. libnvidia-compute-550 은 libcuda1 을 Provides 한다. 그래서 libcuda1 을 요구하는 패키지가 있어도 저장소에 libcuda1 이라는 이름의 패키지가 없다. 이 관계를 모르고 "libcuda1 이 없다" 며 찾아 헤매는 일이 흔하다.

3. 컨테이너 툴킷은 별개 묶음이다.

nvidia-container-toolkit├─ nvidia-container-toolkit-base     nvidia-ctk, 런타임 바이너리└─ libnvidia-container-tools         nvidia-container-cli   └─ libnvidia-container1           공용 라이브러리

드라이버와 툴킷은 저장소도 다르고 버전 체계도 다르다. 드라이버는 배포판 저장소나 NVIDIA 저장소에서, 툴킷은 NVIDIA 의 별도 저장소에서 온다. 반입할 때 한쪽만 챙기는 실수가 잦다.

그래프를 푸는 법

apt 쪽 도구들.

apt-get install --print-uris -y nvidia-driver-550     # 받을 URI 목록만apt-get install --download-only -y nvidia-driver-550  # 받기만apt-cache depends --recurse --no-recommends --no-suggests nvidia-driver-550apt-rdepends nvidia-driver-550                         # 별도 패키지dpkg-deb -f pkg.deb Depends                            # 파일에서 직접 읽기

닫힘(closure) 검사가 핵심이다. 번들 안의 모든 패키지가 요구하는 것이 전부 번들 안에 있는가? 하나라도 밖을 가리키면 안쪽에서 설치가 멈춘다. 저장소를 만들어 apt-get install -s(시뮬레이션)를 돌려 보는 것이 가장 확실한 검사다.

설치 순서 산출

dpkg -i 로 하나씩 설치할 때는 의존이 먼저 와야 한다. 위상 정렬(topological sort)의 문제다.

libnvidia-cfg1-550libnvidia-compute-550nvidia-compute-utils-550nvidia-utils-550libnvidia-gl-550xserver-xorg-video-nvidia-550nvidia-kernel-common-550dkmslinux-headers-...nvidia-kernel-dkms-550nvidia-driver-550

apt 를 쓸 수 있으면 이 순서를 apt 가 알아서 정해 주므로 목록만 있으면 된다. 하지만 순서를 산출할 줄 아는 것과 apt 에 맡기는 것은 다르다 — apt 가 실패했을 때 어디서 끊겼는지 읽으려면 그래프를 이해해야 한다.

현장에서 만나는 모습

DKMS 빌드 실패. 반입은 성공했는데 설치 중 커널 모듈 빌드가 실패한다. 로그를 보면 헤더가 없거나 컴파일러 버전이 안 맞는다. 그래서 GPU 노드는 커널 업데이트를 hold 로 묶어 두는 경우가 많다 — 커널이 올라가면 드라이버를 다시 빌드해야 하고, 폐쇄망에서는 그게 또 한 번의 반입이기 때문이다.

Secure Boot. 서명되지 않은 커널 모듈은 Secure Boot 가 켜진 시스템에서 로드되지 않는다. MOK 등록 절차가 추가로 필요하고, 이건 물리 콘솔 접근을 요구한다.

다음 실습에서 할 것

반입했다고 가정한 소스 트리에서 .deb 를 직접 빌드하고, 의존성 그래프를 파싱하고, 번들 안에서 해결되지 않는 의존을 찾아내고, 위상 정렬로 설치 순서를 산출한다.