UEFI 부팅은 /dev/sda에서 실행되지 않지만 복구 DVD에서는 작동합니다.

UEFI 부팅은 /dev/sda에서 실행되지 않지만 복구 DVD에서는 작동합니다.

RHEL 7.9를 실행하는 1세대 가상 머신이 있는 Windows 10 노트북에 Hyper-V가 설치되어 있습니다. UEFI 부팅을 사용하여 Gen 2 VM에서 실행되도록 업데이트하려고 합니다.

Gen 2 가상 머신으로 마이그레이션하는 과정에서 UEFI 부팅 코드를 /boot 파티션에 설치해야 합니다.

나에게 필요한 다음 패키지를 설치했습니다.

grub2-efi-x64.x86_64         (1:2.02-0.07.el7_9.9)
shim-x64.x86_64              (15-11.el7)
grub2-efi-x64-modules.noarch (1:2.02-0.07.el7_9.9)
shim-unsigned-x64.x86_64     (15-9.el7)

efibootmgr -v다음을 표시합니다.

여기에 이미지 설명을 입력하세요.

보시다시피 몇 가지 다른 구성을 시도했지만 efibootmgr그 중 아무 것도 작동하지 않는 것 같습니다.

VM 시작 설정:

여기에 이미지 설명을 입력하세요.

따라서 이론적으로 가상 머신은 에서 부팅되어야 하며 \EFI\redhat\shimx64.efi, 제가 이해한 바로는 다음 /boot/efi/EFI/redhat/shimx64.efi파일이 존재해야 합니다.

여기에 이미지 설명을 입력하세요.

df -h복구 DVD를 통해 부팅할 때 I /boot이후의 설치를 보여줍니다 /dev/sda1.chroot /mnt/sysimage

/boot 파티션의 스크린샷에서 볼 수 있듯이, 커널에 대한 유효한 initramfs 파일이 있는 것 같습니다(아직까지는 도달하지 못했다고 생각합니다).

여기에 이미지 설명을 입력하세요.

또한 grubs 구성을 재설정해 보았습니다.

grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

파일 grub.cfg에는 커널 버전 관점에서 보면 올바르게 보이는 메뉴 항목이 포함되어 있지만 grub 메뉴를 본 적이 없기 때문에 아직 여기까지 도달하지 못했다고 생각합니다. UEFI 부트로더 문제인 것 같지만 해결 방법을 모르겠습니다.

DVD를 제거하고 컴퓨터를 부팅하면 Hyper-V는 네트워크 어댑터에 도달할 때까지 부팅 순서를 아래로 내립니다.

여기에 이미지 설명을 입력하세요.

결국 Hyper-V는 다음을 보여주었습니다.

여기에 이미지 설명을 입력하세요.

내가 뭘 잘못했나요?

복구 DVD로 부팅한 다음 grub 메뉴의 명령줄로 이동하여 를 c실행하면 configfile (hd0,gpt1)/efi/EFI/redhat/grub.cfg설치된 Linux OS를 부팅할 수 있습니다.

mount | grep -i "boot"운영 체제에서 부팅하면 다음이 표시됩니다.

/dev/sda1 on /boot type xfs (rw,relatime,seclabel,attr2,inode64,noquota)

답변1

UEFI에는 더 이상 "부팅 블록"과 같은 것이 없다는 점을 이해해야 합니다.UEFI 펌웨어는 파일 시스템을 이해합니다.그리고파일 로드.

부팅 *.efi파일은 UEFI 펌웨어(또는 하이퍼바이저)가 이해하는 파일 시스템에 있어야 합니다. UEFI 사양에는 펌웨어만 필요합니다.~ 해야 하다다른 파일 시스템 유형에 대해 알아보세요.가능한필요한 경우 추가할 수 있습니다.

그러나 RHEL 7.x의 기본 파일 시스템 유형은 XFS이며 HyperV의 가상 펌웨어에는 XFS 파일 시스템 지원이 포함되어 있지 않습니다.

따라서 시스템 디스크에 작은 파티션을 추가하고(512M이면 충분할 수도 있고 그보다 작으면 충분할 수도 있습니다. 최신 디스크에서는 디스크를 1GB보다 작은 단위로 파티션하는 것이 미세 관리라고 생각합니다) 다음 유형으로 설정해야 합니다. 시스템 디스크가 MBR 파티션인 것처럼 파티션 테이블에서 0xef또는 GPT 파티션을 사용하는 경우 선택한 파티션 도구를 사용하여 파티션 유형을 ESP(= EFI 시스템 파티션)로 설정하면 됩니다. 그런 다음 mkfs.fat해당 파티션에서 실행하고 /boot/efi현재 내용을 새 파티션으로 이동할 수 있는 위치에 마운트한 다음 새 파티션을 /boot/efi.

나중에 이 efibootmgr명령을 사용하여 이전 시도를 지우고 grub2-install다시 실행하여 올바른 UEFI 부팅 변수 항목을 자동으로 빌드할 수 있습니다. 또는 efibootmgr원하는 경우 직접 할 수도 있습니다. 표시된 부팅 항목의 UUID 문자열은 efibootmgr -v설치하려는 FAT32 파티션의 PARTUUID와 일치해야 합니다 /boot/efi. ( 를 이용하여 확인하실 수 있습니다 lsblk -o +PARTUUID.)

답변2

위의 답변은 현재 매우 훌륭하지만 문제의 근본 원인을 적절하게 강조하지 않습니다.

infodump를 읽으면 Linux 형식의 /boot 파티션만 있을 수 있지만 UEFI 시스템을 부팅하기에는 충분하지 않습니다.

디스크가 UEFI에서 지정한 부팅 가능한 디스크 레이아웃과 일치하지 않습니다.

위에서 이미 언급했듯이 UEFI를 사용하면 부트로더 설정 방법에 대한 새로운 세계로 들어가고 있으며 요구 사항은 이전 BIOS 접근 방식과 완전히 다릅니다. UEFI는 새로운 파티션 테이블 형식을 사용하며 이제 파일 시스템(!)을 이해합니다.

이는 UEFI 펌웨어가 디스크를 UEFI 부팅 가능 디스크로 인식하고 다음에서 부팅하기 위한 가장 간단한 기본 요구 사항입니다.

  1. 디스크는 GPT 파티션 구성표를 사용하여 파티션을 나누어야 합니다.
  2. 디스크 어딘가, GPT 파티션 테이블에 다음이 있어야 합니다.하나 그리고 정확히 하나redhat anaconda와 같은 자동화된 단순화 설정에는 소위 ESP 라고 표시되어야 하는 파티션이 있는데 EFI System Partition, 이는 일반적으로 크기가 약 512MB인 GPT 파티션입니다.
  3. 파티션은 파일 시스템으로 포맷되어야 하며 해당 드라이버는 UEFI 펌웨어에 있어야 합니다(즉, VM 에뮬레이션 UEFI 칩에서도 마더보드 칩 내부 UEFI 설치에 "설치"됨).
  4. 모든 UEFI 설치에서 UEFI 사양에 따라 항상 필수로 설치해야 하는 유일한 UEFI 파일 시스템 드라이버는 FAT32입니다. 즉, 이는 ESP 포맷을 위한 가장 안전한(/유일한) 옵션입니다.
  5. 지정된 ESP 파티션에는 \EFI\BOOT\BOOTx64.EFI특수 UEFI EXE(64비트 시스템인 경우)가 있어야 하며 유효한 실행 가능한 부트로더 exe여야 합니다.
  6. 이 파일을 찾을 수 없으면 여러 다른 경로를 확인하지만 EFIVAR는 efibootmgr편집기로 사용되는 사용자 정의 부트로더 exe 경로로 모든 경로를 재정의할 수 있습니다.

설정에는 파일 시스템이 마운트된 sda1파티션 이 하나만 있는 것 같습니다 .xfs/boot

물론 UEFI에는 XFS 드라이버가 설치되어 있지 않으므로 파티션을 읽을 수 없습니다. XFS 드라이버를 사용하더라도 ESP 유형이 아니면 여전히 파티션에서 부팅할 수 없습니다.

를 추가하는 것을 잊었기 때문에 이것이 최선의 추측입니다 fdisk -l.

최신 UEFI에서 Linux는 ESP를 설치하지 않지만 /boot/boot/efi와 같이 /boot 내부 더 깊은 곳에 설치됩니다!

수정 방법은 비교적 간단합니다. 파티션 테이블이 GPT 유형인지 확인하고(grub 라인에 따르면 이미 GPT 유형임) 새 파티션을 추가한 다음 FAT32로 포맷하고 파티션 테이블이 GPT 유형이 아닌지 ESP type확인 해야 합니다. 일반 유형 의 /boot경우로 표시됩니다 .ESP/bootLinux filesystem

GPT 체계에서 파티션 유형은 UUID입니다(그러나 파티션 유형 UUID와 파티션 식별 UUID를 혼동하지 마십시오!). 따라서 ESP는 EFI System (C12A7328-F81F-11D2-BA4B-00A0C93EC93B)정확한 유형 Linux filesystem이지만 여러 유형 중 하나 Linux root (x86-64) (4F68BCE3-E8CD-4DB1-96E7-FBCAF984B709)입니다 . 리눅스 유형 /boot.

이제 UEFI는 ESP에만 관심을 갖고 ESP를 찾을 수 있는 한 그곳에서 찾은 모든 UEFI exe를 실행합니다. 이 "마법의" exe는 "부트로더"라고 불렸던 프로그램입니다. 실제 운영 체제가 로드되어야 합니다.

이제 부트로더 "설치"가 exe를 FAT32 형식의 ESP에 복사하는 것만큼 간단해졌기 때문에 부트로더 설치 프로세스가 사용자에게 "더 쉬워졌습니다". UEFI exe는 Windows PE exe에서 파생된 잘 알려진 형식이므로 이제 부트 로더 작성도 더 쉬워졌습니다. 결과적으로 이제 선택할 수 있는 부트로더가 더 많아졌습니다.

몇 가지 예를 들면 다음과 같습니다.

  • 다시 찾기
  • 시스템 부팅
  • 고무 장화
  • 시스템리눅스
  • 리눅스(!!!)
  • 그리고...벌레

예, 맞습니다. EFI 스텁(대부분)으로 컴파일된 최신 Linux 커널은 완전한 기능을 갖춘 UEFI 부트로더입니다. 실제로 중간 정크 없이 ESP에서 직접 부팅됩니다. 따라서 이미 UEFI에서 Linux로 직접 쉽게 부팅할 수 있습니다.

불행하게도 여기서 언급한 모든 부트로더 중에서 grub이 아마도 최악일 것입니다. 이 부인할 수 없는 품질 때문에,선택하다시중에 나와 있는 Linux 배포판의 95%에서(이러한 동작은 Linux 생태계에서 일반적입니다).

이 선택의 이유는 종종 매우 까다롭습니다. 아마도 부팅 시 grub이 제공하는 쓸모없는 커널 선택 메뉴와 해당 메뉴에 나타나는 새 커널 설치를 패키지 관리에 통합하기 위해 배포판에서 스크립트를 완성하는 데 걸린 시간 때문일 것입니다. 선박에서.

따라서 이제 ESP가 준비되고 올바르게 포맷되어 있고 올바르게 Linux로 직접 부팅할 수 있더라도 "grub 문제"라고 하는 두 번째 큰 Linux 부팅 문제가 여전히 발생합니다.

GRUB는 UEFI보다 먼저 출시되었으며 UEFI와 동일한 방식으로 이전 BIOS의 많은 부팅 문제를 해결합니다. 이제 UEFI는 마더보드에 직접 사전 로드되어 제공된다는 점을 제외하면 기본적으로 Windows 98 수준 운영 체제의 자체 버전이라는 점을 알아야 합니다. 그것은 또한 매우 복잡합니다.

마찬가지로 GRUB는 기존 파티션에 사전 설치된 고유한 특수 미니 OS입니다 /boot(UEFI와 마찬가지로 자체 파일 시스템 드라이버가 있고 UEFI와 마찬가지로 자체 셸이 있으며 UEFI와 마찬가지로 기타 어리석은 기능도 있습니다). 아무도 그것들을 사용하고 다루는 방법을 모르거나 기억하지 못합니다). 이를 포기할 수 있지만 이제 커널 패키지 업데이트(yum/dnf를 통해)와 결합된 자동 커널 업데이트를 원할 때 이를 수정해야 합니다.

따라서 귀하의 경우 부트 체인은 UEFI(OS)->GRUB(OS)->LINUX(OS)와 같아야 합니다.

따라서 위에 나열된 UEFI 필수 구성 요소를 수정한 후 이제 GRUB 필수 구성 요소를 수정해야 합니다. UEFI가 ESP로 부팅할 수 있도록 GRUB를 ESP에 올바르게 설치해야 하며, 그런 다음 Linux를 부팅하도록 구성해야 합니다.

이제 Linux /트리에서 작동하기 위해 ESP를 설치하는 위치는 배포판에 따라 크게 다르므로 이는 내 범위를 벗어나지만 이것이 /boot/efiRedhat 라인의 기본값이라고 생각합니다.

따라서 rm -rf디렉터리를 /boot비우도록 설정한 다음 vfat 드라이버를 사용하여 포맷된 빈 ESP를 해당 디렉터리( /boot/efi)에 마운트해야 합니다. 이 작업이 완료되면 설치에 chroot를 적용하고 로컬 grub이 UEFI 모드에서 "/dev/sda/esp"로 설치를 다시 빌드하도록 강제해야 합니다 /boot/efi.

이는 배포판에 따라 다르며 grub 버전에 따라 다르며 다음 사이의 값이 될 수 있습니다.

grub-install /dev/sdX
update-grub

도착하다

grub-install --target=x86_64-efi /dev/sdbX
grub-install --recheck /dev/sdX

chroot 내부에서.

올바르게 수행했다면 이전에 비어 있던 ESP 파티션에 GRUB 설치 파일이 나타나는 것을 볼 수 있으며 UUID를 통해 이와 유사한 \EFI\redhat\shimx64.efi것을 가리키는 새로운 EFIVAR이 나타날 수도 있습니다.ESP

efbootmgr추가된 항목을 확인할 수 있도록 grub 재구축/재설치 전에 사용되지 않는 모든 부팅 efvar를 제거하는 것이 좋습니다 .

완료되면 재부팅 후 grub 커널 부팅 메뉴가 표시됩니다.

이 질문과 관련된 좋은 밤 독서를 제안합니다:

https://en.wikipedia.org/wiki/GUID_Partition_Table

https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface

http://www.rodsbooks.com/efi-bootloaders/

답변3

미래의 방문객을 위해 내가 해야 할 일을 정확하게 문서화합니다. 다른 답변에 제공된 세부 정보가 없으면 훨씬 더 어려울 것입니다.

내 Hyper-V 컴퓨터를 "1세대"에서 "2세대"로 전환하고 있습니다. 가장 큰 차이점은 부팅 메커니즘이 BIOS가 부팅 섹터를 메모리에 직접 로드하고 이를 수행하도록 하는 검증된 방법에서 UEFI 펌웨어가 "ESP" 또는 "BOOT" 파티션을 찾아 EFI를 로드하도록 한다는 것입니다. 거기 문서에서 부팅하십시오.

UEFI 부팅을 위해서는 UEFI 펌웨어가 파티션을 부팅 가능으로 표시해야 하며 UEFI 펌웨어는 FAT 형식의 파티션 외에는 아무것도 인식하지 못할 수 있습니다. Hyper-V는 Microsoft 제품이므로 NTFS로 포맷된 파티션에서 부팅하는 방법도 알고 있을 것입니다.

Red Hat Enterprise Linux 7에서는 기본적으로 UEFI 펌웨어에서 읽을 수 없는 XFS 파일 시스템을 사용합니다.

그래서 제가 취한 조치는 다음과 같습니다.

  1. 내 파일 시스템을 백업합니다 /boot. 내 가상 머신에 다음과 같이 마운트된 보조 VHDX 디스크가 연결되어 있으므로 /data이를 백업 위치로 사용합니다.

    mkdir /data/old_boot
    cp --archive /boot /data/old_boot
    
  2. 파일 시스템이 lsblk포함된 장치를 확인 하는 데 사용됩니다 ./boot

    > lsblk
    
    NAME          MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
    sda             8:0    0   129G  0 disk
    ├─sda1          8:1    0   499M  0 part /boot
    └─sda2          8:2    0 126.5G  0 part
      ├─rhel-root 253:0    0    50G  0 lvm  /
      ├─rhel-swap 253:1    0   7.9G  0 lvm  [SWAP]
      └─rhel-home 253:2    0  68.6G  0 lvm  /home
    sdb             8:16   0   512G  0 disk /data
    
  3. parted기존 파티션을 삭제 하려면 /boot:

    > parted /dev/sda
    print
    Model: Msft Virtual Disk (scsi)
    Disk /dev/sda: 139GB
    Sector size (logical/physical): 512B/4096B
    Partition Table: gpt
    Disk Flags:
    
    Number  Start   End    Size   File system  Name       Flags
     1      1049kB  524MB  523MB  xfs          primary    
     2      525MB   136GB  136GB               Linux LVM  lvm
    

    위에서 명령을 실행 parted하여 print파티션 목록을 표시하므로 /dev/sda삭제하려는 파티션은 다음과 같습니다. /dev/sda1크기의 차이는 1GB = 1,000,000,000바이트를 사용하고 1GB = 1,073,741,824바이트를 사용하기 때문입니다.lsblkpartedpartedlsblk

    이 명령은 셸 내에서 실행되며 parted실제로 파티션을 삭제합니다.

    rm 1
    
  4. 새 파티션을 생성하고 UEFI 펌웨어에 부팅을 시도할 파티션임을 알리기 위해 efi또는 플래그를 할당합니다.boot

    > parted
    (parted) mkpart primary fat32 1 524
    (parted) print
    Model: Msft Virtual Disk (scsi)
    Disk /dev/sda: 139GB
    Sector size (logical/physical): 512B/4096B
    Partition Table: gpt
    Disk Flags:
    
    Number  Start   End    Size   File system  Name       Flags
     1      1049kB  524MB  523MB  fat32        primary    
     2      525MB   136GB  136GB               Linux LVM  lvm    
    

    플래그 설정 boot:

    (parted) set 1 boot on
    (parted) print
    Model: Msft Virtual Disk (scsi)
    Disk /dev/sda: 139GB
    Sector size (logical/physical): 512B/4096B
    Partition Table: gpt
    Disk Flags:
    
    Number  Start   End    Size   File system  Name       Flags
     1      1049kB  524MB  523MB  fat32        primary    boot
     2      525MB   136GB  136GB               Linux LVM  lvm
    

    보시다시피 boot이제 플래그가 파티션 번호 1로 설정되었습니다.

  5. 다음으로 새 파티션을 포맷하겠습니다.

    > mkfs.fat -F 32 /dev/sda1
    
  6. /etc/fstab올바른 항목이 표시되는지 확인해야 합니다 . Timed out waiting for device그렇지 않으면 Linux가 Dependency failed for /boot. 다음을 통해 부팅 장치의 파티션 UUID가 필요합니다 lsblk.

    > lsblk -o +PARTUUID
    NAME          MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT   PARTUUID
    sda             8:0    0   129G  0 disk
    ├─sda1          8:1    0   499M  0 part /boot        93be2242-cfa5-4759-86a8-e563092da88d
    └─sda2          8:2    0 126.5G  0 part              484a1ac4-eba0-49b4-9910-b6471462d8b0
      ├─rhel-root 253:0    0    50G  0 lvm  /
      ├─rhel-swap 253:1    0   7.9G  0 lvm  [SWAP]
      └─rhel-home 253:2    0  68.6G  0 lvm  /home
    

    제 경우에는 파티션 UUID가 93be2242-cfa5-4759-86a8-e563092da88d귀하의 것이었습니다.~ 할 것이다이러한 식별자는 설계상 보편적으로 고유하므로 서로 다릅니다.

    /etc/fstab다음으로 파일에 장치에 대한 올바른 파티션 UUID가 포함되어 있는지 확인합니다 /boot.

    > cat /etc/fstab
    #
    # /etc/fstab
    # Created by anaconda on Mon Jan 16 22:52:23 2017
    #
    # Accessible filesystems, by reference, are maintained under '/dev/disk'
    # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
    #
    /dev/mapper/rhel-root   /                       xfs     defaults        0 0
    /dev/sda1               /boot                   vfat    defaults        0 0
    /dev/mapper/rhel-home   /home                   xfs     defaults        0 0
    /dev/mapper/rhel-swap   swap                    swap    defaults        0 0
    

    위의 예에서 우리는 장치가 무엇 /boot인지 알 수 /dev/sda1있으며 대신 시스템이 시작되기 전에 이 줄이 있는지 확인해야 합니다 PARTUUID=93be2242-cfa5-4759-86a8-e563092da88d. /dev/sda1나는 사용했다변경을 하되, 마음에 들지 않는 편집기를 사용해 보세요. 변경하고 나면 다음과 같습니다.

    #
    # /etc/fstab
    # Created by anaconda on Mon Jan 16 22:52:23 2017
    #
    # Accessible filesystems, by reference, are maintained under '/dev/disk'
    # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
    #
    /dev/mapper/rhel-root   /                       xfs     defaults        0 0
    PARTUUID=93be2242-cfa5-4759-86a8-e563092da88d /boot                   vfat    defaults        0 0
    /dev/mapper/rhel-home   /home                   xfs     defaults        0 0
    /dev/mapper/rhel-swap   swap                    swap    defaults        0 0
    
  7. /boot이전 파티션에서 파일을 복구하려면 다음 명령을 사용하십시오 cp.

    > cp --archive /data/old_boot /boot
    
  8. 그럽 구성 업데이트:

    > grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg
    
  9. 필요한 UEFI 부팅 구성 요소를 설치합니다.

    > yum reinstall grub2 grub2-efi-x64 grubby shim-x64
    
  10. efibootmgr.efi 부팅 파일을 가리키는 항목을 만드는 데 사용됩니다 .

    > efibootmgr -c -d /dev/sda -p 1 -l '\efi\EFI\redhat\shimx64.efi' -L 'Red Hat Enterprise Linux'
    

    efibootmgr그런 다음 UEFI 부팅 옵션 목록을 확인합니다 .

    > efibootmgr -v
    BootCurrent: 0006
    Timeout: 0 seconds
    BootOrder: 0000
    Boot0000* Red Hat Enterprise Linux      HD(1,GPT,93be2242-cfa5-4759-86a8-e563092da88d,0x800,0xf9800)/File(\efi\EFI\redhat\shimx64.efi)
    

이제 재부팅할 수 있고 Linux가 올바르게 부팅됩니다.

관련 정보