CentOS 7에서 이 명령을 사용하여 MBR을 손상시키려고 했습니다.
dd if=/dev/zero of=/dev/sda bs=446 count=1
내가 아는 한, 부트 섹터의 길이는 512바이트이고 처음 446바이트는 부트 로더 코드이고 나머지는 파티션 테이블입니다.
안전모드로 재부팅 후 /dev/sda1on /mnt, off 설치를 하다가 chroot /mnt한번 grub2-install부트로더를 복구 했으나 /dev/sda다시 부팅하는데 성공하지 못했습니다.
내가 놓친 점은 무엇입니까?
답변1
루트를 변경한 후 실행하기 전에 grub2-install해당 항목이 있는지 확인해야 합니다 /boot/grub/device.map. 일반적으로 grub2-install아직 존재하지 않는 경우 이를 생성하고 어떤 Linux 장치가 어떤 BIOS/GRUB 디스크 식별자에 해당하는지 추측해 보세요. 이 매핑이 잘못되면 이상한 결과가 나타납니다.
시스템이 매우 특별하지 않은 경우 BIOS에 disk에서 부팅하도록 지시하는 경우 다음 줄을 포함 /dev/sda해야 합니다 ./boot/grub/device.map
(hd0) /dev/sda
런타임에 device.map 파일이 없으면 grub2-installLinux 장치 이름과 BIOS/GRUB 디스크 식별자 간의 매핑을 추측해야 합니다. 때로는 grub2-install잘못 추측할 수도 있습니다. 따라서 존재하지 않는 경우 복구가 성공하도록 /boot/grub/device.map실행하기 전에 올바른 정보로 생성해야 합니다 .grub2-install
파일이 존재 하지만 /boot/grub/device.map정보가 잘못된 경우 실행하기 전에 수정해야 합니다 grub2-install.
이제 다시 복구 모드로 부팅해야 합니다(chroot). 그런 다음 /boot/grub/device.map파일을 확인한 다음 grub2-install /dev/sda.
또 다른 가능성:
MBR의 처음 446바이트를 덮어쓰면 MBR 파티션 디스크의 디스크 UUID로 사용되는 서명 바이트가 포함됩니다. GRUB 구성이 디스크 UUID를 사용하여 GRUB "루트" 파티션을 선택하는 경우 이제 UUID가 달라집니다. 배포판에는 GRUB 구성 파일을 쉽게 다시 빌드하는 데 사용할 수 있는 명령이 있어야 합니다.
데비안 스타일 시스템에서는 update-grub.
RedHat 스타일 시스템(Fedora, CentOS 등)에서는 비슷하거나 grub2-mkconfig > /boot/grub/grub.cfg유사할 수 있습니다.
정보:치명적: INT18: 시작 실패Grub과는 전혀 관련이 없지만 VirtualBox 문제입니다.
분명히 VirtualBox는 파티션 테이블을 확인하여 파티션이 활성으로 표시되었는지 확인하고 활성 파티션이 없으면 MBR 코드를 로드하고 실행하려고 시도하는 대신 오류를 보고합니다.
GRUB의 경우 GRUB가 MBR에 설치된 경우 활성으로 표시된 파티션에 관계없이 부팅 프로세스를 제어하므로 이 확인이 필요하지 않습니다.
원천:https://neosmart.net/wiki/fatal-int18-boot-failure/
설치 미디어 이미지를 가상 CD-ROM 드라이브에 삽입하면 적어도 이전 VirtualBox 버전에서는 이 작업이 수행됩니다.