Linux 부팅 시 에러 메시지가 나올 때 원인과 자세한 해결 방법

Linux를 부팅할 때 화면에 영어 에러 메시지가 나타나거나, 부팅 도중 멈춰서 바탕화면까지 들어가지 못하는 경우가 있습니다. 이런 메시지는 당황스럽지만, 실제로는 문제 원인을 찾는 가장 중요한 단서입니다.

이 글에서는 Linux 부팅 시 자주 나타나는 에러의 원인과, 상황별로 시도할 수 있는 자세한 해결 방법을 설명합니다.

1. 무작정 재부팅부터 반복하지 말기

부팅 에러가 보이면 많은 사용자가 전원 버튼이나 재시작을 반복합니다. 하지만 파일 시스템 문제나 디스크 문제가 있을 경우, 이런 행동이 상태를 더 악화시킬 수 있습니다.

우선 다음을 해두는 것이 좋습니다.

에러 문구를 정확히 확인한다
화면 사진을 찍어둔다
어느 단계에서 멈추는지 본다
직전에 한 작업을 떠올린다

예를 들어, 바로 전에 커널 업데이트를 했다면 커널 문제일 가능성이 높고, 정전이 있었다면 파일 시스템 손상을 의심할 수 있습니다.

2. 자주 나타나는 부팅 에러 유형

GRUB 또는 부트로더 오류
파일 시스템 손상
커널 또는 initramfs 문제
systemd 서비스 시작 실패
GPU 드라이버 또는 그래픽 표시 문제
디스크 공간 부족
SSD/HDD 자체 고장

같은 “부팅 실패”처럼 보여도 원인은 전혀 다를 수 있으므로, 에러 유형을 먼저 구분하는 것이 중요합니다.

3. 부팅 로그를 자세히 보이게 만들기

대부분의 배포판은 quiet splash 때문에 자세한 부팅 메시지를 숨깁니다. 원인을 찾으려면 GRUB에서 이 옵션을 잠시 제거하는 것이 좋습니다.

컴퓨터를 다시 시작한다
부팅 직후 Shift 또는 Esc 를 여러 번 눌러 GRUB를 연다
부팅 항목에서 e 를 누른다
quiet splash 를 삭제한다
Ctrl + X 로 부팅한다

이렇게 하면 어느 단계에서 멈추는지 더 정확히 확인할 수 있습니다.

4. “grub rescue” 또는 파티션 관련 오류가 나오는 경우

부팅 직후 grub rescue 가 보이거나 “no such partition” 같은 오류가 나오면, 부트로더나 파티션 정보에 문제가 있을 가능성이 큽니다.

주요 원인은 다음과 같습니다.

파티션 구조 변경
Windows 듀얼부팅 환경에서 부트 정보 덮어쓰기
EFI 파티션 또는 /boot 파티션 손상
GRUB 설정 파일 손상

이 경우 Live USB로 부팅한 뒤 GRUB를 다시 설치하는 방법이 대표적입니다.

sudo mount /dev/sda2 /mnt
sudo mount /dev/sda1 /mnt/boot/efi   # UEFI 환경만 필요

sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys

sudo chroot /mnt
grub-install /dev/sda
update-grub
exit
sudo reboot

장치명은 실제 환경에 맞게 바꿔야 하며, lsblk -f 로 먼저 확인하는 것이 좋습니다.

5. emergency mode 로 들어가는 경우

You are in emergency mode 메시지가 뜨면, 시스템이 심각한 문제를 감지해 최소한의 복구 환경으로 들어간 상태입니다. 대개 /etc/fstab 설정 오류나 파일 시스템 마운트 실패가 원인입니다.

먼저 로그를 확인합니다.

journalctl -xb

이후 fstab 내용을 확인합니다.

cat /etc/fstab

자주 있는 실수는 다음과 같습니다.

잘못된 UUID 입력
존재하지 않는 마운트 경로
외장 디스크를 fstab에 넣었지만 현재 연결되지 않음

문제가 보이면 수정합니다.

nano /etc/fstab

수정 후 재부팅해서 확인합니다.

6. fsck 관련 오류나 파일 시스템 손상이 의심되는 경우

fsck failed, UNEXPECTED INCONSISTENCY 와 같은 메시지가 보이면 파일 시스템 손상을 의심해야 합니다. 정전, 강제 종료, 저장 중 멈춤 이후 자주 발생합니다.

복구 모드나 Live USB에서 다음과 같이 검사할 수 있습니다.

sudo fsck -f /dev/sda1

단, 현재 마운트된 루트 파티션에 직접 fsck를 실행하면 안 되므로 외부 부팅 환경에서 작업하는 것이 안전합니다.

추가로 디스크 상태도 확인하면 좋습니다.

sudo smartctl -a /dev/sda

SMART 오류가 많으면 우선 데이터를 백업해야 합니다.

7. systemd 서비스 시작 실패가 원인인 경우

커널은 부팅되었지만 중요한 서비스가 실패해서 시스템이 멈추는 경우도 있습니다. 이때는 다음과 같은 메시지가 보일 수 있습니다.

Failed to start ...
Dependency failed for ...

이럴 때는 TTY로 전환합니다.

Ctrl + Alt + F2

로그인 후 실패한 서비스를 확인합니다.

systemctl --failed
journalctl -xb

특정 서비스의 상세 상태도 확인할 수 있습니다.

systemctl status NetworkManager
journalctl -u NetworkManager -b

문제를 일으키는 서비스가 핵심이 아니라면 일시적으로 비활성화하여 부팅 여부를 확인할 수도 있습니다.

8. 커널 또는 initramfs 문제일 때

커널 업데이트 직후부터 부팅이 안 된다면, 새 커널이나 initramfs가 원인일 가능성이 큽니다. 이 경우 GRUB의 이전 커널로 먼저 부팅해 보는 것이 좋습니다.

GRUB 열기
Advanced options 선택
이전 버전 커널 선택

이전 커널로 부팅된다면 initramfs를 다시 생성해볼 수 있습니다.

sudo update-initramfs -u

이후 현재 커널이 정상 부팅되는지 다시 확인합니다.

9. GPU 드라이버 또는 그래픽 문제일 때

시스템은 실제로 켜졌지만, 그래픽 환경만 올라오지 않아 에러처럼 보이는 경우도 있습니다. 특히 NVIDIA 드라이버 업데이트 후 자주 발생합니다.

이 경우 GRUB에서 nomodeset 을 추가해 임시로 부팅해 볼 수 있습니다.

linux /boot/vmlinuz ... quiet splash nomodeset

이 상태로 진입된다면, 그래픽 드라이버 문제일 가능성이 높습니다. 이후 드라이버를 다시 설치합니다.

sudo apt update
sudo ubuntu-drivers autoinstall

10. 디스크 공간 부족도 의외로 흔한 원인

루트 파티션이나 /boot 파티션의 공간이 부족하면 업데이트가 중간에 실패하고, 그 결과 부팅 에러로 이어질 수 있습니다.

먼저 용량을 확인합니다.

df -h

공간이 거의 없다면 캐시와 오래된 패키지를 정리합니다.

sudo apt clean
sudo apt autoremove

오래된 커널과 큰 로그 파일을 정리하는 것도 도움이 됩니다.

11. 아무 방법도 통하지 않을 때는 먼저 백업

TTY도 안 되고 Recovery Mode도 어렵다면 Live USB로 들어가서 중요한 데이터를 먼저 백업하는 것이 가장 안전합니다. 디스크 고장이 의심될 때는 특히 더 그렇습니다.

Live USB 환경에서는 다음 작업이 가능합니다.

중요 파일 백업
파일 시스템 검사
GRUB 재설치
설정 파일 확인
디스크 상태 확인

정리

Linux 부팅 시 에러 메시지가 나온다고 해서 무조건 재설치가 필요한 것은 아닙니다. 핵심은 메시지를 잘 읽고, 유형별로 차근차근 원인을 좁혀가는 것입니다.

에러 문구를 기록한다
상세 부팅 로그를 확인한다
TTY, Recovery Mode, Live USB를 활용한다
GRUB, 파일 시스템, 서비스, 커널, 드라이버, 디스크 공간을 차례로 점검한다
디스크 이상이 의심되면 먼저 백업한다

이런 순서로 접근하면, 많은 Linux 부팅 오류는 재설치 없이도 해결할 수 있습니다.