나는 몇 가지 기능을 갖춘 새로운 데비안 시스템을 구성하고 있습니다:
표준 설치 프로그램을 사용하는 대신 debootstrap을 사용하여 수동으로 설치했습니다. 이유: 내 기본 디스크(SSD 1개 및 대형 HDD 2개)에는 표준 설치 프로그램에서 다루지 않는 특정 요구 사항이 있습니다. HD(백킹 파티션) 중 하나의 bcache를 SSD(캐시)의 파티션에 매핑했습니다. 게다가 여러 개의 luks 암호화 파티션(암호화된 /boot 포함)과 여러 개의 LVM이 있습니다. 이 선택은 이 기계로 수행할 특정 응용 프로그램에만 적용됩니다. 많은 시행착오와 수많은 온라인 리소스 참조 끝에 원하는 방식으로 설치하고 파티션을 마운트하고 시스템에 chroot할 수 있습니다. 사용자와 필요한 패키지 등을 설정했습니다.
내가 겪고있는 문제는 EFI와 grub에 있습니다. 시스템이 부팅되지 않습니다(grub 화면으로 들어가기 전에도 부팅 가능한 장치를 찾을 수 없으므로 문제는 EFI에 있습니다). 예, 라이브 USB 부팅에서 efi=runtime 커널 옵션을 사용했고 /sys/firmware/efi/efivars가 비어 있지 않았으며 efibootmgr이 시스템에 대한 EFI 항목이 있다고 보고했음을 확인했습니다. chroot, update -u -k all, grub-install /dev/sda 및 update-grub 전에 /sys/firmware/efi/efivars를 마운트했습니다. 안전을 위해 grub을 설치하기 전에 모든 EFI 항목(라이브 USB 제외)을 제거했습니다. BIOS에서 보안 부팅을 비활성화했습니다. 이 컴퓨터에는 작동하는 오래된 Linux가 설치되어 있었기 때문에 BIOS에 Linux와 관련된 문제가 없다는 것을 알았습니다.
저는 UUID에 특히 주의를 기울이고 있는데, 그 때문에 뭔가 이상한 점을 발견하게 되었습니다.
위 명령으로 /boot/efi/debian..grub.cfg의 chroot 내에 생성된 UUID는 다음과 일치하지 않습니다.어느시스템에 많은 UUID가 있습니다(예, 확인하고 다시 확인했습니다). 물론 암호화된 /boot를 보유하는 블록 장치인 /dev/sdc1은 아니며 /boot에 매핑된 luks 컨테이너도 아닙니다. /boot/efi는 내 설정에서 유일하게 암호화되지 않은 파티션입니다.
EFI에서 grub.cfg를 수동으로 편집하는 것을 고려했지만 예상되는 동작을 방지하기 위해 보류했습니다.
또한 관련될 수 있는 몇 가지 정보도 있습니다. 시스템의 /dev/sda1에 /boot/efi(암호화되지 않음)가 있고 /dev/sdd1에 /dev/mapper/EncryptedBootPartition이 있습니다(/dev/sdb는 외부 USB 디스크에 의해 점유됩니다(아니요, 설치에 사용되지 않음). 그리고 /dev/sdc1은 백업 파티션이고 캐시는 /dev/sda2에 있습니다. /boot 파티션은 LVM 그룹 외부에 있으므로 /boot는 LVM에 포함되지 않습니다. 외부 USB 디스크가 있으므로 /etc/fstab 및 /etc/crypttab의 모든 항목에 UUID를 사용합니다. 어쨌든, EFI를 통해 얻을 수 없기 때문에 이 질문에 대한 마지막 것은 중요하지 않습니다.
디스크 중 하나에 이전 Linux 설치가 있었지만 이 설정 중에 모든 디스크가 ATA 보안 정리되고 여러 번 다시 포맷되었으므로 이전의 쓸모 없는 UUID가 어떻게 이 새 시스템에 포함되었는지 상상할 수 없습니다.
grub-install이 가짜 UUID를 생성하는 이유는 무엇입니까? 이 문제를 해결하려면 어떻게 해야 합니까? 저는 이 설정이 작동하는 시스템을 생성하는 것으로 입증되면 위의 모든 작업을 수행하는 긴 bash 스크립트를 배포할 계획이므로 스크립트 가능한 솔루션을 선호합니다.