소형 PC에 최신 CentOS 7.5 x64를 설치하려고 합니다.ASUS Eee 박스 EB1037. 이것은인텔 셀러론 J1900(Bay Trail)에는 온보드 NVIDIA GeForce GT 820M이 함께 제공됩니다. Nouveau를 먼저 비활성화하지 않으면 설치 미디어가 잠깁니다. 괜찮아요. 그러나 설치 및 재부팅 후 EFI 파티션이 손상된 것으로 나타납니다.
이 질문은 부팅 방법 문제 해결에 관한 것이 아니라 이 부팅 실패로 인해 EFI 파티션이 손상되고 GRUB 실패가 발생하는 이유를 이해하는 것입니다.
설치 과정은 다음과 같습니다.
- CentOS 7.5를 USB에 굽기
- USB 설치 프로그램으로 부팅(grub 부트로더)
- "nouveau.modeset=0"을 추가하도록 그럽 옵션을 편집하세요.
- 시간대 설정
- 소프트웨어 선택: 최소 설치(변경 없음)
- 네트워크 및 호스트 이름: 호스트 이름 설정
- 수동 파티션을 "표준 파티션"(LVM 없음) 및 자동 파티션 레이아웃으로 설정
- 설치가 계속됩니다
- 루트 비밀번호 및 사용자 계정 설정(관리자 권한)
- 설치가 완료되었습니다.
- 재시작
- 하드 디스크 GRUB가 나타납니다.
GRUB 설정(예: Nouveau 비활성화)을 변경하지 않았습니다. 여기에서 기본 설정을 확인하세요.
이러한 기본값으로 CentOS 부팅을 시도했지만 예상대로 중단되었습니다(Nouveau를 비활성화하지 않았기 때문에). 내가 보는 것은 검은 화면뿐입니다. 모니터는 켜져 있지만 키보드 조명과 백라이트, 광학 마우스 LED는 꺼져 있습니다. 키보드는 ctrl-alt-del을 담당하지 않습니다.
하드 리셋을 수행하려면 전원 버튼을 길게 누르세요. 시스템은 두 번째로 문제 없이 하드 디스크 GRUB 메뉴로 부팅되었습니다. 기본값으로 다시 부팅을 시도했는데 이전과 동일하게 잠겼습니다(아직 Nouveau를 비활성화하지 않았기 때문에 예상한 대로).
CentOS USB 설치 프로그램이 아직 연결되어 있습니다. 세 번째 재부팅 시(처음 두 번의 설치 후 재부팅 후) 시스템이 하드 드라이브 대신 USB GRUB로 이동했습니다. 이상한. CentOS USB를 꺼내고 ctrl-alt-del을 사용하여 재부팅하십시오.
이제 GRUB에서 EFI 파티션을 읽을 수 없다는 메시지가 화면에 깜박이는 것을 볼 수 있습니다.
잠시 후 그것이 사라졌고 나는 이것을 보았습니다:
시스템이 더 이상 EFI 파티션으로 부팅할 수 없습니다.
왜 이런 일이 발생합니까? EFI 파티션은 어떻게 손상됩니까?
추가 정보
보안 부팅은~할 수 있게 하다BIOS에서는 비활성화할 수 없지만 "기타 운영 체제"로 설정되어 있습니다.
이 장치에는 내부에 SATA 포트가 하나만 있고 Samsung 850 Pro 500GB SSD가 들어 있습니다. AHCI로 설정되어 있고 SATA1로 나타나며 시스템에 연결된 유일한 디스크인데도 CentOS에서는 sdbUSB sda설치 미디어를 sda. 그러나 설치 중에 USB 드라이브가 두 번째 디스크로 표시되지 않고 삼성 SSD가 유일하게 표시되는 드라이브로 표시됩니다.
연결되면 GRUB는 연결된 CentOS 설치 USB 미디어를 (hd0)로, 온보드 SATA를 (hd1)로 인식합니다. USB 미디어를 제거하면 온보드 SATA가 (hd0)으로 나타납니다. 흥미롭게도 온보드 SATA는 sdCentOS 설치 프로그램에서는 볼 수 있지만 hdGRUB에서는 볼 수 없습니다.
강조하다
- 시스템에 Nvidia 그래픽 프로세서(Optimus?)가 있습니다.
- 보안 부팅이 활성화되었습니다(비활성화할 수 없음)
- BIOS에서 USB 디스크를 연결된 SATA 디스크로 표시합니까? (
sda설치 중hd0GRUB에서)
참고하세요
nouveau.modeset=0USB 스틱을 제거한 다음 GRUB를 설정하고 업데이트하여 설치 후 시스템을 부팅할 수 있었습니다 /boot/efi/EFI/centos/grub.cfg.
문제는 EFI 파티션이 손상된 원인을 이해하는 것입니다!
시스템 시작 사진:
답변1
이 이름은 \EFI\BOOT\grubx64.efi시스템이 CentOS 기본 UEFI 부팅 경로가 아닌 대체 경로를 사용함을 나타냅니다. 그러나 대체 부팅 경로 \EFI\BOOT\bootx64.efi는 SecureBoot shim이 차지한다는 것입니다. 따라서 shim이 로드된 것처럼 보이지만 다음 단계는 불가능합니다. 즉, 백업 디렉터리에서 실제 GRUB 부트 로더를 로드하는 것입니다.
내 이론:
- 설치 시 일반적인 방법으로 부트 로더
\EFI\CentOS\shimx64.efi(SecureBoot 심 부트 로더 및\EFI\CentOS\grubx64.efi실제 GRUB 부트 로더)가 설정됩니다. 이 경로는\EFI\CentOS\shimx64.efiUEFI NVRAM 부팅 변수에 등록됩니다. 또한 설치 프로그램은 기본 폴백/이동식 미디어 부팅 경로에서 shim을 사용하여 두 번째 복사본을 설정(시도)\EFI\BOOT\bootx64.efi하고 GRUB를\EFI\BOOT\grubx64.efi. - 설치 프로그램에 의해 트리거된 첫 번째 재부팅 시 NVRAM 부팅 변수는 그대로 유지되며 펌웨어는
\EFI\CentOS\shimx64.efi커널을 사용하여 성공적으로 부팅하는 "웜 부팅"을 수행합니다\EFI\CentOS\grubx64.efi. Nouveau가 비활성화되지 않았기 때문에 이 부팅 시도로 인해 중단이 발생합니다. - 그런 다음 펌웨어가 NVRAM 부팅 변수를 잊어버리게 되어 시스템이 대체 경로에서 부팅을 시도하게 됩니다
\EFI\BOOT\bootx64.efi. 이는 UEFI에 특정 디스크에서 부팅하도록 지시하지만 부트 로더 경로를 지정하지 않을 때 발생합니다. 어떤 이유로 SecureBoot shim의 대체 복사본을 로드할 수 있지만 로드가 실패합니다\EFI\BOOT\grubx64.efi. 참고하시기 바랍니다말하지 않았다파일이 손상되었습니다: 파일이 존재하지 않음을 나타냅니다.
이제 efibootmgr -v기존 UEFI 부팅 변수를 살펴보고 현재 설정 또는 최소한 CentOS 부팅 항목을 기록해 두어 다시 손실될 경우 이를 재현할 수 있도록 해야 합니다. 이 경우 CentOS 설치 미디어에서 복구 모드로 부팅하고 명령을 사용하여 efibootmgrNVRAM 변수를 수정하거나 UEFI 부팅 설정 메뉴를 사용하여 올바른 설정을 입력할 수 있습니다(허용되는 경우). (슬프게도 내가 본 대부분의 UEFI 구현은 그렇지 않습니다.)
또한 대체 GRUB 부트 로더가 손상되지 않았는지 확인해야 합니다. 파일은 /boot/efi/EFI/BOOT/grubx64.efiLinux에서와 마찬가지로 액세스 가능해야 합니다. 파일이 존재하고 /boot/efi/EFI/CentOS/grubx64.efi.
첫 번째 재부팅과 세 번째 재부팅 사이에 UEFI NVRAM 부팅 변수가 손실되는 원인이 무엇인지 정말로 모르겠습니다.다양한 버그가 있는 UEFI 구현이 있습니다.아니면 Nouveau로 인한 중단 문제를 해결하기 위해 BIOS 설정을 재설정하셨나요? UEFI "BIOS 설정"을 재설정하면 UEFI 구현에 따라 NVRAM 부팅 변수가 재설정되거나 재설정되지 않을 수 있습니다.
가끔씩 누락되는 UEFI NVRAM 부팅 변수가 펌웨어 버그인 것으로 밝혀지면 BIOS 업그레이드: 실행을 확인 dmidecode -s bios-version하여 현재 버전을 확인할 수 있습니다. ASUS 지원 페이지에 따르면 시스템의 최신 UEFI BIOS 버전은 1301입니다. ASUS는 일반적으로 UEFI BIOS 자체에 업데이트 기능을 포함합니다. 시스템의 경우 업데이트 파일을 EFI 시스템 파티션(= /boot/efiCentOS의 어느 곳이든)에 저장하고 BIOS 설정으로 이동하여 업데이트 도구를 활성화할 수 있습니다. 거기서 파일을 업데이트하는 위치를 알려주세요.
NVRAM 손상의 가능한 원인 중 하나는 efi-pstore커널 모듈입니다. 활성화되어 있거나 CentOS 표준 커널에 내장되어 있고 커널 충돌 시 커널 로그를 저장하는 기능이 pstore활성화된 경우 커널 로그를 포함하는 일련의 변수로 NVRAM을 100%까지 채울 수 있습니다. 이로 인해 펌웨어가 변수 저장소가 손상되었음을 감지하고 NVRAM 부팅 변수를 자동으로 다시 초기화할 수 있습니다.
대체가 /boot/efi/EFI/BOOT/grubx64.efi실제로 손상되지 않은 경우 대체 경로에서 부팅할 수 없는 이유는 SecureBoot shim의 버그 또는 HDD 대체 부팅 경로에서 보안 부팅을 과도하게 적용하여 발생할 수 있습니다(기술적으로 문서화되지 않은 UEFI 펌웨어 버그