SLES 부팅 시 "커널 모듈 로드 시작 실패" 오류 해결

SLES 부팅 메시지 "커널 모듈 로드 시작 실패" 는 일반적으로 systemd-modules-load.service하나 이상의 커널 모듈을 로드하려고 시도했지만 요청 중 하나가 실패했음을 의미합니다. 이 메시지의 목적은 단순히 빨간색 부팅 라인을 숨기는 것만이 아닙니다. 제대로 된 복구는 서비스를 정상 상태로 유지하고, 더 이상 사용되지 않는 모듈 요청을 제거하며, 시스템에 실제로 필요한 드라이버를 보존하고, 다음 재부팅 후에도 정상적으로 작동하도록 합니다.

이 가이드는 SUSE Linux Enterprise Server 15를 기준으로 작성되었으며, 최신 SLES 15 SP7 관리 가이드와 일치합니다. SUSE 문서에 따르면, systemd-modules-load.service모듈은 에 지정된 이름으로 로드되는 /etc/modules-load.d/*.conf반면, 대부분의 최신 하드웨어 모듈은 장치가 감지되면 자동으로 로드됩니다. 이러한 차이점은 중요합니다. 오래된 정적 항목이 더 이상 존재하지 않는 모듈을 가리키는 경우, 해당 항목을 삭제하거나 수정하는 것이 시스템에 더 이상 사용되지 않는 드라이버를 강제로 다시 설치하는 것보다 안전한 경우가 많습니다. SLES 15 SP7에 대한 자세한 내용은 SUSE의 커널 모듈 관리 문서를 참조하십시오 .

성공적인 해결책은 이런 모습이어야 합니다.

변경하기 전에 원하는 결과를 먼저 정의하세요. 수정 후:

• systemctl status systemd-modules-load.service더 이상 실패 결과를 보고해서는 안 됩니다.
• 새로 부팅할 때 더 이상 동일한 모듈 로드 오류가 저널에 표시되지 않아야 합니다.
• 해당 모듈이 정말로 필요한 것이라면 modprobe MODULE_NAME성공적으로 설치되어야 하며, 관련 하드웨어 또는 기능도 정상적으로 작동해야 합니다.
• 해당 모듈이 더 이상 사용되지 않는 경우, 관련 없는 모듈로 교체하는 대신 오래된 요청을 제거해야 합니다.
• 문제가 초기 부팅과 관련된 경우, initramfs를 재구축하면 시스템이 정상적으로 재부팅될 것입니다.

이러한 검사 항목이 모두 상황에 적용되지 않는 경우, 오류가 발생한 구성 요소에 해당하는 검사 항목을 사용하십시오. 예를 들어, 선택적 모듈에 오류가 있더라도 서버가 성공적으로 부팅될 수 있습니다. 이러한 경우에도 문제를 해결해야 하지만, 루트 파일 시스템이 나타나지 못하게 하는 스토리지 드라이버 누락과는 다릅니다.

1단계: 고장난 장치를 확인하고 정확한 모듈 오류를 기록합니다.

시작 화면 메시지만 보고 추측하지 말고 서비스 자체부터 살펴보세요.

sudo systemctl status systemd-modules-load.service --no-pager

모듈 이름과 Module ... not found, No such device, 와 같은 오류 Operation not permitted메시지 또는 지원되지 않는 모듈이 거부되었다는 메시지를 찾아보세요. 정확한 메시지 문구에 따라 다음 조치가 결정됩니다.

상태 출력 내용이 잘린 경우, 아직 구성을 편집하지 마십시오. 먼저 전체 부팅 로그를 확인하십시오.

2단계: 모듈 파일을 변경하기 전에 부트 저널을 읽으십시오.

현재 부팅에 대해서만 이 서비스를 조회합니다.

sudo journalctl -b -u systemd-modules-load.service --no-pager

모듈 로딩과 관련된 커널 메시지도 확인할 수 있습니다.

sudo journalctl -b -k --no-pager | grep -iE 'module|modprobe|firmware|taint'

첫 번째 명령은 어떤 정적 로드 요청이 실패했는지 알려줍니다 . 커널 로그에는 감지된 장치를 거부하는 드라이버, 펌웨어 종속성, 서명 문제 또는 기타 하위 수준 오류와 같은 컨텍스트 정보가 추가될 수 있습니다.

일반적 으로 이러한 결과 Module foo not found in directory /lib/modules/...는 오래된 구성, 커널/패키지 불일치 또는 활성 커널용으로 다시 빌드되지 않은 타사 드라이버를 나타냅니다. No such device다른 경우는 모듈 파일은 존재하지만 현재 하드웨어 또는 가상 장치가 드라이버가 예상하는 것과 일치하지 않을 수 있음을 의미합니다.

3단계: SLES에 해당 모듈을 로드하도록 요청하는 주체를 찾습니다.

일반적인 정적 부하 위치와 modprobe 구성을 검색하세요.

grep -Rns --color=auto 'MODULE_NAME'   /etc/modules-load.d /run/modules-load.d /usr/lib/modules-load.d   /etc/modprobe.d /usr/lib/modprobe.d 2>/dev/null

MODULE_NAME저널에 있는 이름으로 바꾸십시오 . SLES 15 SP7에서는 `modules-load.d` 디렉터리에 있는 로컬 항목 /etc/modules-load.d/은 부팅 시 로드해야 하는 모듈에 대한 표준 관리자 관리 위치이며, 패키지 항목은 `modules-load.d` 디렉터리 아래에 존재할 수 있습니다 /usr/lib/modules-load.d/. SUSE는 대부분의 모듈은 수동으로 `modules-load.d` 디렉터리에 항목을 추가할 필요가 전혀 없다고 언급합니다.

그런 다음 활성화된 커널에 해당 모듈이 실제로 있는지 확인합니다.

uname -r
sudo modinfo MODULE_NAME
sudo modprobe MODULE_NAME

모듈이 더 이상 사용되지 않는 경우

해당 파일을 요청하는 로컬 파일을 제거하거나 비활성화하십시오. 오류를 없애기 위해 벤더 파일을 삭제하지 마십시오 /usr/lib. 패키지 업데이트로 인해 복원될 수 있습니다. 로컬 파일이 단종된 하드웨어 또는 오래된 소프트웨어용으로 생성된 것으로 판단되면 /etc/modules-load.d/*.conf해당 로컬 항목을 제거하고 다시 테스트하십시오.

모듈이 존재해야 하는데 modinfo에서 찾을 수 없는 경우

실행 중인 커널이 설치된 모듈 트리와 일치하는지 확인하십시오.

uname -r
ls -ld /lib/modules/$(uname -r)
rpm -q kernel-default

일반적인 품질 검사는 간단합니다. /lib/modules/$(uname -r)실행 중인 커널에 필요한 모듈이 존재하고 포함되어 있어야 합니다. 타사 드라이버가 이전 커널용으로 컴파일된 경우, 해당 드라이버를 공급업체에서 지원하는 절차에 따라 현재 SLES 커널용으로 다시 설치하거나 재빌드하십시오. .ko단순히 특정 기능을 찾기 위해 다른 커널 버전의 파일을 복사하는 것은 피해야 합니다 modprobe. 커널 ABI 또는 서명 차이로 인해 안전하지 않거나 효과가 없을 수 있습니다.

모듈이 블랙리스트에 등록된 경우

블랙리스트를 검색하거나 재정의 기능을 설치하세요.

grep -Rns --color=auto -E '^[[:space:]]*(blacklist|install)[[:space:]]+MODULE_NAME'   /etc/modprobe.d /usr/lib/modprobe.d 2>/dev/null

블랙리스트를 추가한 이유를 확인한 후에만 블랙리스트를 제거하십시오. 블랙리스트는 충돌하는 드라이버로부터 시스템을 보호할 수 있습니다. SUSE의 모듈 가이드에는 영구 블랙리스트와 GRUB 실행 시 임시 블랙리스트 모두에 대한 설명이 있으므로, 블랙리스트를 제거하는 대신 정적 로드 요청을 제거하는 것이 올바른 해결책일 수 있습니다.

SLES에서 지원되지 않는 모듈이라고 보고하는 경우

지원되지 않는 모듈의 자동 로딩을 활성화하지 마십시오. SLES는 커널 모듈에 대한 지원 상태를 표시하며, 지원되지 않는 모듈을 강제로 사용하면 지원 가능성에 영향을 미칠 수 있습니다. SUSE는 관리 가이드에서 테스트 또는 벤더 핫픽스 시나리오에 대한 예외 처리 메커니즘을 설명하고 있습니다. 지원에 미치는 영향을 이해하고 정당한 드라이버 요구 사항이 있는 경우에만 사용하십시오. 해당 SUSE 가이드는 SLES 15 SP7 관리 가이드 에서 확인할 수 있습니다 .

4단계: 변경 사항이 초기 부팅에 영향을 미치는 경우에만 initramfs를 재구축합니다.

오류가 발생한 모듈이 initramfs 내부에 필요하거나, 부팅에 필수적인 드라이버 또는 블랙리스트 구성을 변경하여 해당 내용이 반영되어야 하는 경우, 이미지를 다시 생성하십시오.

sudo dracut -f

SUSE는 부팅에 영향을 미치는 드라이버 변경 후 initramfs를 재구축하는 과정을 구체적으로 문서화했습니다. 최신 부팅 프로세스 가이드에서는 드라이버를 initramfs에 추가해야 하는 시점과 initramfs dracut를 다시 생성하는 방법을 설명합니다. 자세한 내용은 SLES 15 SP7의 부팅 프로세스 소개를 참조하십시오 .

선택적 모듈 오류가 발생할 때마다 initramfs를 재 구축하는 것을 의식처럼 생각하지 마십시오 dracut -f. 일반적인 부팅 후 모듈이 단순히 에 나열된 경우라면 /etc/modules-load.d해당 파일을 수정하는 것만으로도 충분할 수 있습니다. initramfs 재구축은 잘못된 구성이 부팅 이미지에 포함되어 있거나 실제 루트 파일 시스템이 완전히 마운트되기 전에 필요한 드라이버를 사용할 수 있어야 하는 경우에 가장 중요합니다.

문제가 해결된 것으로 간주하기 전에 수리 사항을 확인하십시오.

안전한 시점이 되면 재부팅 없이 먼저 테스트를 진행하세요.

sudo systemctl restart systemd-modules-load.service
systemctl status systemd-modules-load.service --no-pager
systemctl is-failed systemd-modules-load.service

필요한 모듈이 이제 로드되었는지 확인하고, 로드가 완료되면 이를 확인하십시오.

lsmod | grep -w MODULE_NAME

그런 다음 적절한 유지 관리 시간 동안 재부팅하고 새 부팅 상태를 확인하십시오.

sudo reboot

로그인 후:

systemctl --failed
journalctl -b -u systemd-modules-load.service --no-pager

가장 확실한 성공 신호는 콘솔 메시지가 한 번 사라진 것이 아닙니다. 새로 부팅했을 때 동일한 모듈 오류가 다시 발생하지 않고 해당 모듈에 의존하는 하드웨어 또는 하위 시스템이 여전히 정상적으로 작동하는 것입니다.

접근 방식을 언제 바꿔야 할까요?

이 해결책의 한계

"커널 모듈 로드 시작 실패" 메시지는 단일 결함이 아니라 증상입니다. 이 절차는 정적 모듈 요청, 누락되거나 일치하지 않는 모듈, 블랙리스트 및 initramfs 동기화로 인해 발생하는 오류를 해결합니다. 이 절차는 하드웨어 진단, 타사 드라이버 지원, 보안 부팅 서명 작업 또는 루트 장치를 사용할 수 없는 경우의 스토리지 복구를 대체하지 않습니다.

운영 중인 SLES 시스템의 경우, 지원 가능성을 유지하기 위해 SLES 커널에 제공되는 모듈을 우선적으로 사용하고, 타사 드라이버는 해당 공급업체의 지원 매트릭스를 준수하며, 서비스 오류를 해결하기 위해 검사를 우회하는 대신 SUSE에서 제공하는 공식 메커니즘을 사용하십시오. 서비스 상태, 부팅 저널 및 종속 하드웨어가 모두 문제가 해결되었음을 확인할 때 복구가 완료된 것입니다.