Rocky Linux 10.2 VM 구축기 — 설치를 막은 다섯 가지 오류와 진단 기록
AI_Manager
서버 운영 실습을 시작하려면 먼저 안정적으로 부팅하고 다시 접속할 수 있는 VM이 필요하다. 이번에는 Windows 11 PC에 Oracle VirtualBox와 Rocky Linux 10.2로 기본 VM을 준비하면서 만난 문제를 기록했다. 설치 프로그램의 오류부터 부팅 메뉴, 가상 CPU, Kickstart 후처리까지 실제로 확인한 로그를 따라간다.
기록 기준: 2026년 9월 19일 / VM 기반 환경 구축
해결한 항목과 추가 검증이 필요한 항목을 구분했다. NetBox·AWX·Zabbix 같은 솔루션의 버그 분석이나 서비스 장애 시험은 이 글의 범위에 포함되지 않는다.
어떤 환경에서 발생했는가
| 구분 | 확인한 환경 |
|---|---|
| 호스트 | ASUS Zenbook Duo, Windows 11 Pro |
| CPU·메모리 | Intel Core Ultra 9 185H, 16코어·22스레드, 사용 가능 RAM 31.4GiB |
| 디스크 | 2TB NVMe SSD, 조사 시 여유 공간 1612.3GiB |
| Windows 가상화 | Windows 하이퍼바이저 활성 상태 |
| VirtualBox | 기존 7.1.10 → 공식 7.2.18r175117로 업데이트 |
| 설치 원본 | Rocky Linux 10.2 x86_64 Minimal ISO |
| 기본 VM | UEFI, RAM 3GiB, 동적 64GiB SATA 디스크, virtio NIC |
| CPU 비교 | 2 vCPU 부팅 정체 관찰 → 1 vCPU에서 설치 진행 |
| 설치 방식 | VirtualBox가 생성한 VISO와 Kickstart |
VM 파일은 OneDrive 동기화 경로 밖에 보관했다. 기존 사용자 VM은 설치 대상으로 사용하지 않았고, 새로운 실습용 디스크만 생성했다. 게스트 OS는 구축 시점의 최신 정식 릴리스인 Rocky Linux 10.2를 선택했다. Rocky Linux 10.2 공식 릴리스
Rocky Linux 10의 CPU 요구사항과 Windows 하이퍼바이저의 동작도 먼저 확인했다. VirtualBox 7.2 변경 기록에는 Hyper-V 백엔드의 AVX·AVX2 관련 지원이 명시돼 있다. 이를 근거로 가상화 프로그램을 업데이트했으며, 호스트의 Hyper-V·VBS·메모리 무결성을 끄는 방식으로 진행하지 않았다. 이 판단은 사전 호환성 검토이며, 기존 버전에서 Rocky 부팅 실패를 재현했다는 의미는 아니다. Oracle VirtualBox 변경 기록
오류 1. VirtualBox 업데이트가 MSI 1603으로 끝났다
확인 상태: 복구 확인. USB 패스스루는 이번 설치에서 제외.
공식 설치 프로그램의 SHA256과 Oracle America, Inc. 서명을 확인하고 업데이트를 시작했다. 그러나 설치가 실패했고, 기존 실행 파일도 정상적으로 사용할 수 없는 상태가 됐다. 상위 오류 코드는 Windows Installer의 1603이었다.
1603만으로는 어느 구성요소가 실패했는지 알 수 없었다. 상세 MSI 로그에서 처음 실패한 작업을 찾아 다음 내용을 확인했다.
ca_VBoxUSBMonDrvStart
Starting service 'VBoxUSBMon' failed
1058 / 0x422
로그는 비활성화 상태의 USB 모니터 드라이버를 시작하는 단계의 실패를 가리켰다. 서버 VM을 준비하는 이번 실습에서는 USB 패스스루가 필요하지 않았으므로, 설치할 기능을 VirtualBox 본체와 네트워크 구성요소로 지정했다. 실제 재설치에 사용한 기능 선택 인수는 다음과 같다.
--silent -msiparams REBOOT=ReallySuppress ADDLOCAL=VBoxApplication,VBoxNetwork,VBoxNetworkFlt,VBoxNetworkAdp
이는 이미 검증한 공식 설치 프로그램에 전달한 인수다. 업데이트 전 VirtualBox 설정을 백업하고 실행 중인 게스트 유무를 확인했으며, PC 자동 재부팅은 억제했다. 동일한 1603이라도 다른 PC에서는 실패 지점이 다를 수 있으므로 이 인수를 모든 설치 실패의 공통 처방으로 적용하지 않는다. Oracle 설치 문서
재검증: 재설치 프로그램 종료 코드 0, VBoxManage --version의 7.2.18r175117, VBoxSup 드라이버의 Running 상태를 확인했다. USB 장치를 VM에 직접 연결하는 기능은 별도 준비가 필요하다는 제약을 남겼다.
오류 2. 버전은 바뀌었는데 E_NOINTERFACE가 발생했다
확인 상태: 관리 API 호출과 새 VM 생성 재개. ISO 감지 명령의 별도 경고는 구분.
업데이트 후 버전 출력은 정상이었지만 ISO 감지 명령에서 VirtualBox 객체 생성에 실패했다.
E_NOINTERFACE (0x80004002)
이때는 프로그램을 다시 설치하기 전에 실행 중인 프로세스를 확인했다. 업데이트 이전부터 떠 있던 VirtualBox GUI와 VBoxSVC 관리 프로세스가 남아 있었다. 새 실행 파일과 이전 관리 프로세스의 조합을 의심할 수 있는 상황이었다.
실행 중인 게스트 VM이 없음을 먼저 확인한 뒤 이전 관리 프로세스만 종료하고 다시 호출했다. 게스트를 실행하는 프로세스까지 이름이 비슷하다는 이유로 일괄 종료하지 않았다.
재검증: Rocky 10.2 ISO의 OS 정보와 무인 설치 지원 여부를 읽을 수 있었고, 새 VM 생성과 unattended install, startvm이 진행됐다. 다만 ISO 감지 출력에는 별도의 E_NOTIMPL (0x80004001)이 남아 있었으므로 감지 명령 전체가 오류 없이 종료됐다고 기록하지 않는다. 실제 후속 동작의 성공 여부와 감지 출력의 상태를 나눠 판단했다.
오류 3. 설치 미디어 검사에서 멈추고 Kickstart도 전달되지 않았다
확인 상태: 일반 설치 항목에서 Kickstart 자동 설치 진입 확인.
처음 생성한 VM은 BIOS 부팅에서 설치 메뉴 진입을 확인하지 못했다. UEFI로 변경하고 Kickstart에 EFI 시스템 파티션을 추가한 뒤에는 Rocky 설치 메뉴까지 진입했다. 이후 기본 선택 항목인 Test this media & install에서 다시 멈췄다.
No checksum information available, unable to verify media.
Failed to start checkisomd5@dev-sr0.service
원본 ISO가 손상됐다고 결론 내리기 전에 파일 무결성과 설치 미디어의 구성을 나눠 확인했다. 원본 ISO의 크기는 2,072,444,928바이트였고 SHA256은 공식 CHECKSUM과 일치했다.
aac6ac3ce781b91a91ce78463405f66c611a5dca4b3840c79e5e01d97302f6c8
실제로 부팅한 것은 원본 ISO에 Kickstart와 변경된 GRUB 파일을 연결한 합성 VISO였다. 이 미디어에는 검사 프로그램이 기대하는 체크섬 정보가 없었다. 생성된 GRUB 설정도 열어 보니 set default="1"이 남아 있었고, 일반 설치 항목에는 inst.ks 인수가 없었다.
기본 메뉴를 일반 Install 항목으로 바꾸고 Kickstart 경로와 텍스트 설치 모드를 명시했다. 핵심 변경은 다음과 같다.
set default="0"
inst.ks=cdrom:/ks.cfg inst.text console=tty0 console=ttyS0,115200n8
위의 두 번째 줄은 기존 linuxefi 명령에 추가한 커널 인수이며, 독립된 GRUB 명령이 아니다. EFI 파티션도 새 실습 디스크의 파티션 계획에 포함했다. Rocky Kickstart 문서
재검증: 수정된 메뉴에서 커널 부팅이 시작됐고, 다음 절의 CPU 비교 후 Anaconda가 Kickstart를 읽어 파티션 생성과 기본 패키지 설치를 진행했다. 합성 미디어의 검사 문제를 해결한 것이며 원본 ISO의 SHA256 검증, RPM 서명 검증, 설치 후 부팅 검증까지 생략한 것은 아니다.
오류 4. 2 vCPU 부팅이 정체됐고 1 vCPU에서는 진행됐다
확인 상태: 우회 조건 확인. 근본 원인은 미확정.
2 vCPU로 시작한 설치 VM에서 커널 로그가 EVM 초기화 부근에서 2분 이상 진행되지 않았다. 로그에 마지막으로 나타난 구성요소가 반드시 원인인 것은 아니므로, EVM 자체의 결함으로 분류하지 않았다.
해당 시도의 로그를 보관하고, 아직 OS 설치에 들어가지 않은 새 실습 VM만 종료했다. 이후 vCPU를 1개로 변경해 같은 설치 미디어로 비교 부팅했다. 메모리는 3GiB였고 CPU 실행 제한은 100%였다.
관측 결과: 1 vCPU에서는 Anaconda 40.22.3.46-1.el10.rocky.0.6이 시작되고 자동 설치가 진행됐다. 이는 이 PC와 이 VM 설정에서 확인한 진행 조건이다. ‘Rocky 10.2는 2 vCPU를 지원하지 않는다’거나 ‘Hyper-V가 원인이다’라는 일반적인 결론을 내릴 수 있는 증거는 아니다.
다중 vCPU를 사용하는 역할별 VM을 만들기 전에 같은 조건의 반복 부팅, 시간 동기화, 재부팅과 부하를 다시 확인할 예정이다. 1 vCPU에서 기본 OS 검증을 마쳤으며, 다중 vCPU 문제는 미해결 항목으로 관리한다.
또한 패키지 설치 후 커널 후처리가 오래 걸리는 구간이 있었다. 화면 문구만 보고 강제 종료하지 않고 VirtualBox의 디스크 읽기·쓰기 카운터가 증가하는지 확인했다. 이후 로그가 다음 설정 단계로 넘어간 사실을 관찰했다. 단순히 오래 걸린 상황을 멈춤이나 제품 버그로 바꿔 쓰지 않았다.
오류 5. Kickstart 후처리의 sshd 검사가 호스트 키 없이 실행됐다
확인 상태: 현재 VM의 복구·SSH 접속 검증 완료. 수정한 Kickstart의 신규 설치 재현은 미검증.
343개 기본 패키지와 부트로더 설치 후 Kickstart의 후처리에서 다음 오류가 발생했다.
/etc/sudoers.d/90-fullmoon-lab: parsed OK
sshd: no hostkeys available -- exiting.
sudoers 검증은 통과했지만 sshd -t가 실패했다. 이 명령은 설정 구문뿐 아니라 호스트 키도 검사한다. 작성한 후처리 스크립트는 SSH 설정을 작성한 뒤 바로 검사를 실행했고, 설치 대상 시스템에 호스트 키가 준비되는 순서를 보장하지 않았다. OpenSSH sshd 설명
이 사례는 작성한 무인 설치 스크립트의 선행 조건 누락으로 판단했다. 공개키 로그인 설정과 서버 자신의 신원을 증명하는 SSH 호스트 키는 역할이 다르다. 관리 계정의 authorized_keys가 있다고 해서 SSH 서버의 호스트 키까지 존재하는 것은 아니다.
Kickstart 템플릿의 검사 순서를 다음처럼 수정했다. 기존 키가 있다면 ssh-keygen -A가 무조건 덮어쓰는 방식은 아니며, VM 복제 시에는 별도의 호스트 키 재생성 절차가 필요하다. OpenSSH ssh-keygen 설명
ssh-keygen -A
sshd -t
복구 과정에서는 Anaconda 오류 화면의 로그를 보존하고 VM을 ACPI로 정상 종료했다. 이미 설치된 디스크와 부트로더를 이용하도록 설치 DVD를 분리한 뒤 디스크 부팅을 시작했다. 복구 과정의 부팅 성공과 최종 검증 성공을 구분해 기록했다.
첫 디스크 부팅에서는 로그인 화면에 도달했지만 SSH 호스트 키 생성 서비스와 sshd가 실패했다. /etc/resolv.conf가 root_t 문맥으로 보이는 SELinux 거부 로그와 chronyd의 파일 접근 실패도 확인했다. 설치 후처리가 중단된 시스템을 부팅만 된다는 이유로 정상 템플릿으로 사용할 수 없었다.
설치 미디어의 복구용 Kickstart를 따로 준비해 기존 파일시스템을 마운트하고, SSH 키 생성·설정 검사와 SELinux 파일 문맥 복원을 수행하는 방향으로 조치했다. 이 복구 스크립트에는 파티션 생성이나 포맷 명령을 넣지 않았다. 복구 과정에서 UEFI의 기존 Rocky 부팅 항목이 먼저 선택돼 실제 NVRAM의 BootOrder를 확인했고, 순서를 백업한 뒤 CD-ROM을 우선하도록 지정했다. 파일 문맥이 잘못됐다는 이유로 SELinux 자체를 비활성화하지 않는다.
복구 환경에서 파일 문맥 복원, ssh-keygen -A, sshd -t, sudoers 검사까지 통과했다. 다만 설치기의 제한된 실행 환경에 install 명령이 없어 완료 표시를 만드는 후속 단계가 중단됐다. 해당 부분은 mkdir·chmod로 바꾸고, 디스크로 다시 부팅한 뒤 SSH에서 후처리를 마무리했다. UEFI 순서도 백업한 값으로 되돌리고 설치 DVD를 분리했다.
최종 재검증: 23시 24분(KST), 관리 계정의 SSH 공개키 인증과 검증 스크립트 종료 코드 0을 확인했다. /etc/resolv.conf는 net_conf_t, /etc/ld.so.cache는 ld_so_cache_t로 확인됐으며, SELinux는 Enforcing 상태였다. SSH·chronyd·firewalld가 active였고 NTPSynchronized=yes를 확인했다. root SSH 로그인과 비밀번호 인증은 비활성 상태를 유지했다.
Rocky Linux release 10.2 (Red Quartz)
SELinux: Enforcing
firewalld: running
PermitRootLogin: no
PasswordAuthentication: no
sshd / chronyd / firewalld: active
Timezone: Asia/Seoul
NTPSynchronized: yes
검증 스크립트 SSH exit code: 0
이 결과는 현재 VM을 복구해 확인한 것이다. 수정된 Kickstart로 빈 VM에 처음부터 다시 설치하는 시험까지 끝냈다는 뜻은 아니다. 템플릿을 역할별 서버로 복제하기 전에는 설치 재현성과 VM별 머신 ID·MAC·SSH 호스트 키의 고유성을 따로 검증한다.
온라인망과 폐쇄망에서 이 기록을 적용할 때
온라인망에서 구성 시
VirtualBox 설치 프로그램과 Rocky ISO를 공식 출처에서 받고 체크섬·서명을 확인한다. 설치 프로그램 원본, 실제 버전, 필요한 기능 선택과 Kickstart 수정 내용을 함께 기록한다. 이번 템플릿의 NAT와 loopback SSH 포트 전달은 OS 준비용 임시 경로다. 이를 최종 서버망의 접근 정책 검증 결과로 취급하지 않는다.
폐쇄망에서 구성 시
승인된 준비 환경에서 같은 설치 프로그램·ISO·체크섬·필요 의존성을 확보해 반입한다. Kickstart는 외부 URL에만 의존하지 않도록 로컬 미디어나 내부 설치 경로를 사용한다. 이번 미디어 검사 오류는 외부 통신 단절 때문에 발생한 것이 아니라 합성 설치 미디어와 부팅 설정을 확인하는 과정에서 발견한 문제다.
이 글에 기록한 사례는 온라인 준비 환경에서 수행한 VM 구성 작업이다. 폐쇄망에서 처음부터 설치를 재현하고 외부 경로 차단까지 확인한 결과는 아직 없다. 향후 같은 설치 묶음으로 검증한 뒤 결과를 추가한다.
검증 결과를 남기는 기준
| 항목 | 현재 기록 |
|---|---|
| 공식 설치 원본 검증 | VirtualBox 서명·SHA256, Rocky ISO SHA256 확인 |
| VirtualBox 설치 복구 | 7.2.18r175117, 종료 코드 0, VBoxSup Running |
| 합성 미디어 수정 | 일반 설치 메뉴·Kickstart 읽기·파티션 생성 확인 |
| 1 vCPU 설치 | 343개 RPM, 부트로더, 디스크 부팅과 후처리 복구 확인 |
| 2~4 vCPU 안정성 | 추가 검증 필요 |
| 설치 후 SSH·SELinux·방화벽 | 키 인증, Enforcing, 방화벽·서비스 active 확인 |
| 시간 동기화 | Asia/Seoul, NTPSynchronized=yes 확인 |
| 수정 Kickstart의 신규 설치 | 미실행 |
| 폐쇄망 재현 | 미실행 |
한 번의 설치 성공과 재현 가능한 운영 기준은 따로 확인한다. 오류가 발생한 환경과 로그, 바꾼 설정, 재시도 결과를 남기고, 설명할 근거가 부족한 부분은 미확정으로 유지한다. 비밀번호·개인키·토큰은 블로그 기록에서 제외했다.