부팅 후 드라이버가 올라오지 않거나 장치 기능이 멈춘 경우, 실행 중인 커널 버전과 모듈 파일 경로, 의존성 목록, 서명 상태를 차례로 확인해야 합니다. 무작정 재설치하기보다 오류 로그와 모듈 이름을 기준으로 누락·버전 불일치·호환성 문제를 구분해 조치합니다.
커널 모듈을 찾지 못할 때 버전·의존성부터 복구하는 방법
부팅은 되었지만 네트워크, 그래픽, 저장장치 같은 장치 기능이 멈추면 드라이버 모듈 적재 실패부터 확인해야 합니다.
장치 자체의 고장으로 단정하기 전에 현재 커널이 어떤 모듈을 찾는지 확인하는 편이 안전합니다.
모듈 파일이 보이더라도 실행 중인 커널과 버전이 다르거나, 의존성 색인이 오래되었거나, 필요한 심볼을 찾지 못하면 적재되지 않습니다.
특히 자동 업데이트 뒤에는 새 커널이 설치됐는데 이전 ABI용 외부 드라이버만 남아 오류가 반복되는 경우가 있습니다.
부팅과 네트워크 연결이 유지된다면 원격으로 로그와 패키지 상태를 먼저 확인할 수 있으며, 초기 문의는 010-6833-8119 로 가능합니다.
오류 화면 한 줄보다 커널 릴리스, 모듈명, 발생 시점 세 가지를 함께 확보하는 것이 복구 시간을 줄입니다.
실행 중인 커널과 모듈 파일 경로 대조
STATUS_KERNEL_MODULE_NOT_FOUND 유형의 문제는 모듈이 완전히 사라진 경우만 뜻하지 않습니다. 현재 부팅된 커널이 참조하는 경로와, 실제 드라이버 파일이 설치된 경로가 서로 다른 경우에도 같은 방향의 오류가 나타날 수 있습니다. 영동 STATUS_KERNEL_MODULE_NOT_FOUND 증상처럼 표시되더라도 먼저 장치명보다 커널 릴리스를 기준으로 분리 진단해야 합니다.
우선 터미널에서 uname -r을 실행해 현재 실제로 구동 중인 커널 버전을 확인합니다. 이어서 /lib/modules/커널버전/ 경로의 디렉터리 이름이 이 결과와 일치하는지 대조합니다. 최신 커널 패키지를 설치했더라도 재부팅하지 않았다면 이전 커널로 동작할 수 있고, 반대로 새 커널로 부팅됐는데 이전 버전용 모듈만 남아 있을 수도 있습니다.
모듈 이름도 정확히 확인해야 합니다. 요청 이름은 modprobe에서 쓰는 논리 이름일 수 있고, 실제 파일은 .ko, .ko.xz, .ko.zst처럼 압축된 형태일 수 있습니다. 파일 확장자가 다르다는 이유만으로 누락으로 판단하지 말고, 현재 커널 디렉터리 아래에 해당 모듈과 관련 하위 경로가 있는지 확인합니다.
| 확인 결과 | 의미 | 우선 조치 |
|---|---|---|
| uname -r 와 모듈 경로가 다름 | 다른 커널용 드라이버가 남은 상태 | 현재 커널에 맞는 패키지 또는 빌드 결과 확인 |
| 파일은 있으나 modprobe 실패 | 의존성·ABI·서명 문제 가능성 | 로그와 depmod 결과를 함께 점검 |
| 모듈 파일 자체가 없음 | 패키지 누락 또는 빌드 실패 가능성 | 설치 방식에 맞춰 패키지 복구 또는 재빌드 |
의존성 목록과 심볼 오류를 구분하는 법
modprobe 모듈명의 결과만 보고 파일 누락으로 결론 내리면 안 됩니다. modprobe는 모듈 간 의존성 정보를 참고해 필요한 구성요소를 함께 적재하므로, 모듈을 수동 추가·교체했거나 커널 업데이트 직후라면 색인 정보가 실제 파일 상태를 따라가지 못할 수 있습니다. 이때 depmod -a로 의존성 데이터베이스를 다시 만든 뒤 재시도할 수 있습니다.
다만 depmod -a는 경로와 목록을 갱신하는 작업일 뿐, 호환되지 않는 바이너리를 현재 커널에 맞게 바꾸지는 못합니다. 따라서 dmesg 또는 journalctl -k에서 적재 거부 사유를 함께 봐야 합니다. 오류 문구가 서로 비슷해도 조치 방향은 다릅니다.
invalid module format은 대체로 실행 중인 커널 ABI와 모듈 빌드 대상이 다르거나 아키텍처가 맞지 않을 때 의심합니다. unknown symbol은 모듈이 요구하는 심볼을 현재 커널 또는 선행 모듈이 제공하지 못하는 상태로, 단순 파일 복사보다 관련 모듈 묶음과 빌드 환경을 확인해야 합니다. dependency missing은 필요한 선행 모듈 파일 또는 의존성 색인이 빠졌을 가능성이 있으므로 경로, 패키지 상태, depmod 결과를 순서대로 확인합니다.
업데이트 직후 오류가 시작됐다면 새 커널용 파일과 이전 ABI용 외부 드라이버가 섞였는지 특히 살펴봅니다. 같은 이름의 모듈이라도 커널 릴리스가 다르면 정상 적재를 보장하지 않으며, 출처가 다른 파일을 임의로 복사하면 심볼 충돌과 부팅 지연이 더해질 수 있습니다.
드라이버 재설치 전 확인할 호환성 체크
재설치 방법은 처음 어떤 방식으로 드라이버를 넣었는지에 따라 달라집니다. 배포판 패키지 관리자로 설치한 모듈은 현재 커널용 패키지와 커널 이미지·헤더 패키지의 설치 상태를 맞추는 방식이 우선입니다. 반면 DKMS 기반 모듈은 새 커널이 들어올 때마다 해당 커널용으로 빌드가 완료됐는지 확인해야 합니다.
수동 컴파일한 외부 모듈은 가장 신중해야 합니다. 현재 커널에 대응하는 헤더가 설치돼 있는지, 빌드 당시 컴파일러 환경이 크게 달라지지 않았는지, 시스템 아키텍처와 모듈 아키텍처가 일치하는지 점검합니다. 모듈 파일이 존재해도 빌드 로그에 경고나 실패가 남았다면 정상 파일로 판단하기 어렵습니다.
Secure Boot 가 활성화된 환경에서는 외부 모듈이 서명 문제로 차단될 수 있습니다. 이 경우 로그에 키 검증 또는 서명 관련 거부 기록이 남을 수 있으므로, 무작정 재설치하기보다 서명 상태와 등록 절차가 필요한 환경인지 먼저 판단합니다. 패키지형 모듈, DKMS 모듈, 수동 빌드 모듈은 각각 복구 경로가 다르므로 설치 이력을 지우기 전에 확인하는 것이 좋습니다.
현장 점검 일정은 증상 재현 기준으로 조율
부팅이 가능하고 원격 접속이 유지되면 커널 버전, 모듈 목록, 최근 업데이트 이력, 로그를 먼저 확보해 작업 범위를 줄일 수 있습니다. 반대로 저장장치·네트워크 드라이버까지 영향을 받아 접속이 끊기거나 부팅 화면에서 멈춘다면 현장 점검이 필요할 수 있습니다.
방문 작업은 장치가 멈추는 시점과 재부팅 가능 여부를 기준으로 정합니다. 출장 점검은 09:00~18:00 에 서울·경기·인천·세종에서 가능하며, 원격 점검은 새벽 시간을 제외하고 진행합니다.
로그가 남아 있을 때 문의하기
문의 전에는 문제가 업데이트 직후인지, 부팅 직후인지, 특정 USB·그래픽카드·네트워크 장치를 연결한 직후인지 메모해 두면 원인 분류가 빨라집니다. 가능하면 오류 화면, uname -r 결과, 실패한 모듈명, dmesg의 관련 줄, 최근 커널 업데이트 내역을 함께 준비합니다.
동네형컴퓨터는 패키지 설치 상태와 DKMS 빌드 기록, 모듈 경로, 의존성 색인, Secure Boot 차단 여부를 순서대로 확인해 복구 방향을 잡습니다. 상담 및 점검 문의는 010-6833-8119, 안내 페이지는 https://udns.kr/에서 확인할 수 있습니다.
자주 묻는 질문
커널 모듈을 찾을 수 없다는 메시지는 무엇을 뜻하나요?
현재 실행 중인 커널이 필요한 드라이버 모듈 파일 또는 그 모듈의 의존 정보를 찾지 못했다는 뜻입니다. 실제 파일 누락뿐 아니라 커널 버전 불일치, 잘못된 경로, 오래된 의존성 색인도 원인이 될 수 있습니다.
모듈 파일을 다시 복사하면 해결되나요?
동일한 커널 릴리스용 파일인지, 의존성 정보가 갱신됐는지, 필요한 심볼을 제공하는지 먼저 확인해야 합니다. 다른 커널에서 가져온 파일을 단순 복사하면 invalid module format 이나 unknown symbol 오류가 추가될 수 있습니다.
원격으로 확인 가능한 문제인가요?
운영체제가 부팅되고 네트워크 접속이 유지된다면 로그, 커널 버전, 패키지 상태를 원격으로 점검할 수 있습니다. 부팅 불가 상태이거나 저장장치·네트워크 드라이버까지 영향을 받았다면 현장 확인이 더 적절할 수 있습니다.
모듈 누락처럼 보이는 오류도 먼저 실행 커널과 모듈 경로를 대조해야 합니다.
그다음 의존성 색인과 심볼 오류를 구분하면 불필요한 재설치를 줄일 수 있습니다.
오류 문구보다 커널 릴리스·모듈명·로그 세 줄이 정확한 복구 방향을 결정합니다.