Linux 부팅이 느리거나 잘못된 운영 상태에 도달했을 때 효과적으로 복구하려면 변경하기 전에 어디를 확인해야 하는지 알아야 합니다. 이 실습 과정은 커널 메시지, 부팅 저장소, GRUB 설정, systemd 타깃, 부팅 시간, 커널 모듈을 하나의 실용적인 진단 흐름으로 연결합니다.
실행 중인 시스템을 검사하고 통제된 런타임 변경을 수행하며 증거를 보고서 파일로 저장합니다. 마지막 복구 시나리오에서는 커널 명령줄을 기록하고 테스트 모듈을 문서화한 뒤 실행 중인 커널에서 제거하고 시스템을 텍스트 기반 다중 사용자 모드로 전환합니다.
학습 내용
dmesg로 초기 커널 메시지를 읽고 현재 부팅 명령줄 식별하기/boot의 저장 방식을 확인하고 생성된 GRUB 메뉴 설정을 안전하게 살펴보기ro,rw,init=/bin/bash같은 커널 부팅 매개변수 해석하기- systemd 타깃을 확인하고
systemctl isolate로 현재 상태 전환하기 - 지연 재부팅을 예약하고 확인한 뒤 실제 실행 전에 취소하기
- 부팅 시간을 측정하고
systemd-analyze blame과critical-chain비교하기 - 안전한 테스트 커널 모듈을 검사, 모의 실행, 로드, 확인, 언로드하기
추천 대상
이 중급 과정은 부팅 진단과 통제된 복구 조치를 체계적으로 배우려는 Linux 관리자, DevOps 학습자, 지원 엔지니어, 개발자를 위한 것입니다. 느린 시작, 예상치 못한 상태, 부트로더 매개변수 또는 의심스러운 모듈을 조사할 때 유용합니다.
선수 지식: Linux 터미널, 파이프와 리디렉션, 파일 검사, sudo를 익숙하게 사용할 수 있어야 합니다. 서비스와 systemd 기초 지식이 있으면 도움이 됩니다.
학습 환경: 생성된 GRUB 설정과 부팅 진단을 제공하며 타깃과 dummy 커널 모듈을 통제된 방식으로 변경할 수 있는 systemd 기반 LabEx Linux 터미널입니다.
자주 묻는 질문
컴퓨터를 재부팅하거나 GRUB 설정을 직접 편집하나요?
아니요. 10분 뒤 재부팅을 예약하고 추적 상태를 확인한 다음 취소합니다. grub.cfg를 읽어 커널 줄을 찾지만 생성된 파일을 편집하거나 복구 셸로 재부팅하지는 않습니다.
systemd-analyze blame과 critical-chain은 어떻게 다른가요?
blame은 개별 유닛의 활성화 시간순으로 정렬하고, critical-chain은 의존 순서와 부팅 경로의 시간을 보여 줍니다. 느린 유닛이 반드시 부팅을 막은 것은 아니므로 두 보기를 함께 사용합니다.
커널 모듈 실습은 안전한가요?
통제된 테스트용으로 dummy 네트워크 장치 모듈을 사용합니다. modprobe -n -v로 동작을 미리 보고, 모듈을 로드하고 확인한 다음 다시 제거합니다. 최종 과제에서도 제거 전에 세부 정보를 기록합니다.
