Windows 듀얼 부트 시스템에서 매우 느린 Debian 부팅 해결
Source: Dev.to
문제 개요
Debian 부팅 시간이 비정상적으로 길었습니다:
Startup finished in 7s (firmware)
+ 5s (loader)
+ 4s (kernel)
+ 2min 41s (userspace)커널은 빠르게 로드되었습니다. 지연은 전적으로 userspace에 있었으며, 이는 시스템 서비스가 무언가를 기다리면서 차단되고 있음을 의미합니다.
단계 1: 부팅 과정 측정
시간이 어디에 사용되는지 확인합니다:
systemd-analyze이 명령을 통해 userspace가 지연의 원인임을 확인했습니다.
느린 서비스를 확인합니다:
systemd-analyze blame몇몇 서비스가 약 30초 정도 걸리는 것으로 나타났지만, 많은 서비스가 병렬로 시작되기 때문에 출력이 오해를 일으킬 수 있습니다.
실제 차단 요소를 찾으려면 다음을 사용합니다:
systemd-analyze critical-chain단계 2: 차단 의존성 식별
critical chain은 다음과 같이 표시되었습니다:
dev-disk-by-uuid-1CEE-9C07.device @ 1min+
└─ systemd-fsck@...
└─ boot-efi.mount모든 것이 디스크 장치, 특히 /boot/efi에 사용되는 장치를 기다리고 있었습니다.
단계 3: 장치 확인
이 UUID가 어떤 장치에 해당하는지 확인합니다:
lsblk -f관련 출력:
nvme0n1p7 vfat UUID=1CEE-9C07 /boot/efi차단 장치는 EFI 시스템 파티션이며, VFAT 형식으로 Windows와 공유되고 있었습니다.
근본 원인
듀얼 부팅 시스템에서는:
- Windows가 EFI 파티션을 자주 수정합니다.
- VFAT 장치는 펌웨어 전달 후 안정화되는 데 시간이 걸릴 수 있습니다.
systemd는/boot/efi를 중요한 마운트로 취급합니다.- 기본 타임아웃은 약 90초입니다.
/boot/efi가 매우 초기에 마운트되기 때문에 다른 모든 서비스가 해당 파티션이 사용 가능해질 때까지 차단되었습니다. 이는 Debian 버그가 아니라 흔히 발생하는 듀얼 부팅 엣지 케이스입니다.
단계 4: 안전하게 수정 적용
목표는 /boot/efi를 제거하는 것이 아니라 부팅 전체를 차단하지 않도록 하는 것입니다.
/etc/fstab을 편집합니다:
sudo nano /etc/fstab원본 항목
UUID=1CEE-9C07 /boot/efi vfat umask=0077 0 1수정된 항목
UUID=1CEE-9C07 /boot/efi vfat umask=0077,nofail,x-systemd.device-timeout=5s 0 1이 변경이 하는 일
nofail– EFI 파티션이 느리게 나타나거나 없더라도 시스템이 부팅을 계속하도록 허용합니다.x-systemd.device-timeout=5s–systemd가 EFI 장치를 기다리는 시간을 5초로 제한합니다.
EFI 파티션은 여전히 정상적으로 마운트되지만, 부팅을 차단하지는 않습니다.
결과
Debian으로 직접 재부팅한 뒤:
Startup finished in 7.0s (firmware)
+ 4.7s (loader)
+ 4.2s (kernel)
+ 8.8s (userspace)
= ~25 seconds total문제가 완전히 해결되었습니다.
주요 교훈
- 항상
systemd-analyze부터 시작하세요. critical-chain을 사용해 실제 차단 요소를 찾으세요.- 듀얼 부팅 EFI 파티션은 부팅 지연의 흔한 원인입니다.
- 단일
fstab수정으로 수분 단위 부팅 시간을 해결할 수 있습니다. fsck나 핵심 서비스를 무작정 비활성화하지 마세요.
결론
긴 부팅 시간은 성능 문제, 커널 문제, 혹은 손상된 설치가 아니라 systemd가 공유된 EFI 파티션을 너무 오래 기다리고 있었기 때문입니다. 시스템이 무엇을 기다리고 있는지를 이해하는 것이 무작위 서비스 비활성화보다 더 효과적입니다.
Linux와 Windows를 듀얼 부팅하고 부팅 시간이 오래 걸린다면, 먼저 /boot/efi를 점검하세요.