Ubuntu GRUB 부팅 관리자 eep 누락 (부팅 정보 요약)


1

최근에 Windows 10과 함께 LG gram 17 랩톱에 Ubuntu 16.04를 설치했습니다.

부팅 우선 순위를 변경하기로 결정할 때까지 Windows 기본값으로 이동하지 않고 우분투 기본값으로 직접 이동합니다.

그런 다음 창 부팅 관리자뿐만 아니라 우분투 부팅 관리자가 사라지고 화면에

Failed to open \EFI\BOOT\grubx64.efi - Not Found
Failed to load image \EFI\BOOT\grubx64.efi: Not Found
start_image() returned Not Found 

부팅 복구를 계속 사용합니다. 그러나 이것은 단지 일시적인 문제 해결 일 뿐이며 두 부팅 관리자는 곧 사라집니다.

여기 내 BOOT-INFO 요약입니다


올바른 위치는 /EFI/ubuntu/grubx64.efi입니다. 시스템 기본값은 /EFI/BOOT/bootx64.efi입니다. grubx64.efi의 복사본 이름을 bootx64.efi로 바꾸고 / EFI / BOOT /에 넣습니다
ravery

UEFI의 우분투 항목이 없습니다. Boot-Repair를 사용하여 grub을 다시 설치하면 다시 추가됩니다. 또는 efibootmgr을 사용하여 항목을 추가 할 수 있습니다. 일반적으로 원래 bootx64.efi의 부팅 복구 백업 인 bkpbootx64.efi가 있으므로 위의 내용에서 알 수 있듯이 부팅 복구는 shimx64.efi를 bootx64.efi로 복사했을 수 있습니다. 그러나 UEFI 부팅 항목이 해당 하드 드라이브 또는 폴백 항목으로 부팅되는지 확실하지 않습니다. 참조 : askubuntu.com/questions/486752/...
oldfred

Boot Repair 출력은 EFI/BOOT/bootx64.efi파일이 존재 함을 나타냅니다 . 그러나 그 출력은 그것이 올바른 파일인지 아닌지를 나타내지 않습니다. 어쨌든 파일이 존재하기 때문에이 Not Found메시지는 실제 파일이 아니라 파일 시스템 손상 또는 파일 시스템 드라이버 비 호환성 (Linux와 EFI 간)을 나타냅니다.
Rod Smith

답변:


1

Boot Repair 출력에 따라 메시지 클레임이 누락 된 파일이 있습니다. FAT 파일 시스템 드라이버가 크지 않은 일부 컴퓨터에서 FAT16 또는 크기가 작은 FAT32를 사용하면 이러한 불일치가 발생할 수 있습니다. 이러한 EFI의 대부분은 상당히 오래된 것입니다 (2012 년 또는 그 이전). 그러나 더 자주 원인은 Windows에서 빠른 시작최대 절전 모드 를 비활성화하지 못하기 때문입니다 . 이 Windows 기능이 활성화되면 부트 로더가 상주하는 EFI 시스템 파티션 (ESP)을 포함한 공유 파티션에서 파일 시스템이 손상됩니다. 앞의 링크에서 설명한대로 이러한 기능을 비활성화하고 Windows로 몇 번 재부팅하면 문제가 해결 될 수 있습니다. 윈도우 빠른 시작 기능이 유의 하지많은 EFI에서 이름이 비슷한 기능과 동일합니다. EFI 기능은 하드웨어 초기화에 대한 바로 가기를 사용하지만 Windows가 종료 작업 (Fast Startup 및 Hibernate가 수행하는 작업)을 처리하는 방법에는 영향을 미치지 않습니다. 이중 부팅 구성을 훨씬 더 위험하게 만듭니다).

문제가 지속되면보다 근본적인 시정 조치를 취해야합니다. 첫 번째 단계로 ESP를 백업하는 것이 좋습니다 (필자 /dev/sda2의 경우). Windows 또는 Ubuntu 에서이 작업을 수행 할 수는 있지만 우분투 절차에만 익숙합니다.이 절차에 더 익숙 하고이 답변에서 혼란을 최소화하고 싶습니다. USB 플래시 드라이브 또는 CD-R에서 rEFInd 부팅 관리자 를 사용 하여 기존 설치를 부팅하거나 Ubuntu 설치 프로그램을 "설치 전 시도"모드로 부팅하여 Ubuntu로 부팅 할 수 있습니다. 전자의 경우 ESP는 /boot/efi; 후자에서는 ESP를 수동으로 마운트해야합니다. 이 작업을 수행하지만, 파일 레벨 백업 (사용 cp, zip,tar또는 유사한 파일 수준 도구)가 적절해야하지만 부팅 실패에 기록 된 파일이 백업되어 있는지 확인하십시오.

백업이 완료되면 첫 번째 수준의 복구 시도는 파일 시스템 검사 및 복구를 수행하는 것입니다. dosfsck우분투 에서이 작업을 수행합니다 . 파일 시스템이 마운트 해제되어 있어야 -a하고에서와 같이 옵션을 전달해야합니다 sudo dosfsck -a /dev/sda2. 이렇게 하면 문제 해결되지만 드물게 더 많은 손상이 발생할 수 있으므로 더 진행해야합니다. 작동하지 않으면 더 나아가 야 할 수도 있습니다 ....

파일 시스템 복구가 작동하지 않으면 다음 시도는 파일 시스템 을 만들고 백업을 해당 파일 시스템으로 복원하는 것입니다. 우분투에서는 파티션을 마운트 해제해야하며 sudo mkdosfs -F32 /dev/sda2파일 시스템을 만드는 데 사용 합니다. ( 이 명령에 주의 하십시오 . 잘못된 장치 파일 이름을 지정하면 Windows 또는 Ubuntu 설치를 지울 수 있습니다!) 파일 시스템을 다시 만든 후에는 이전에 만든 백업을 복원합니다. 이 작업을 수행하고 작동하면 /etc/fstabUbuntu에서 편집해야 합니다. /boot/efi행을 찾아서 UUID=새 파일 시스템 의 값을 변경하십시오 . (이 값을 입력하여 찾을 수 있습니다sudo blkid /dev/sda2.)이 변경을 수행하지 않으면 ESP가 자동으로 마운트되지 않으므로 GRUB에 대한 향후 업데이트가 설치되지 않을 수 있습니다.

oldfred가 제안한 것처럼 Boot Repair를 사용하는 것도 또 다른 방법입니다. 그러나 먼저 Windows 빠른 시작 및 최대 절전 기능을 해제하지 않고이 작업을 수행하면 문제가 다시 발생할 수 있습니다. 더 나쁜, 더 악화 문제가 발생할 수 이러한 기능이 추가 파일 시스템이 손상 될 수 있습니다 비활성화하기 전에 우분투에서 ESP에 쓸 시도, (어쩌면 아무것도예를 들어 부팅됩니다). 파일 시스템에 이미 심각한 문제가있는 경우 부팅 복구를 사용하면 문제가 악화 될 수 있습니다. 따라서 문제를 해결하는 방법이 전적으로 위험이없고 쉬운 것은 아닙니다. IMHO, 빠른 시작 및 최대 절전 모드 (해당 부분은 안전)를 비활성화하고 파일 시스템 검사 (또는 상대적으로 안전)를 시작하는 것이 가장 좋습니다. 이것으로 충분하지 않으면 ESP를 백업 및 재 작성하거나 부팅 복구를 사용하여 어떤 위험을 감수해야하는지 결정해야합니다. 사용자 파일을 백업하는 것이 좋습니다. 그것들을 손상시킬 가능성은 꽤 적지 만, 그렇게한다면 그 결과는 분명히 파괴적 일 것입니다.


너무 감사합니다, 나는이 의견을 추가하는 것을 잊었다. 나는 전체 시스템을 다시 설치하고 고쳤습니다.
sihyeondev
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.