티스토리 뷰
Extensible Firmware Interface System Partition (ESP)
PARTITION_SYSTEM_GUID: C12A7328-F81F-11D2-BA4B-00A0C93EC93B
BIOS는 MBR/PBR의 실행 code를 통해 booting을 진행하지만 UEFI firmware는 file system driver를 포함하고 있어
필요한 파일을 system partition에서 직접 읽어 booting을 진행하므로 MBR/PBR의 code와는 무관합니다.
UEFI booting은 GPT disk와 MBR disk에서 모두 가능하지만 반드시 system partition(ESP)이 있어야 합니다.
System partition은 booting에 필요한 파일을 저장하는 공간으로 GPT disk에서는 ESP이며
MBR disk에서는 partition type 0xEF의 ESP입니다.
UEFI firmware는 FAT file system 및 partition GUID의 적합성을 확인하여 system partition을 찾습니다.
UEFI firmware는 FAT file system을 기반으로 FAT32, FAT16, FAT12 variant를 지원합니다.
어떤 EFI FAT을 사용하는지는 media의 크기에 따라 다르며 보통 disk의 system partition은 FAT32,
removable media는 FAT12 또는 FAT16을 지원합니다.
UEFI는 system partition의 개수나 위치에 특별한 제한을 두지 않습니다.
Windows에서는 제한 사항이 있습니다!!!
1) 32bit UEFI booting은 지원하지 않습니다.
2) UEFI booting은 반드시 GPT disk라야 합니다.
MBR disk 또는 MBR disk의 ESP(0xEF partition)에서의 UEFI booting을 지원하지 않습니다.
3) 여러 개의 OS로 여러 개의 ESP가 존재할 수 있으나 system에서는 오직 하나의 ESP만 허용합니다.
4) ESP는 disk의 가장 앞부분에 위치해야 합니다.
5) ESP의 최소 크기는 100MB입니다.
6) ESP는 반드시 FAT32로 format 해야 합니다.
Windows는 오직 basic data partitions만 보여줍니다. ESP는 숨김 속성은 아니며 mount는 되지만 drive 문자는
지정되지 않아 explorer에서 볼 수 없지만 mount는 되어있으므로 Windows에서 실행되는 프로그램은 ESP의
내용을 수정할 수 있습니다. 관리자 권한의 mountvol /s로 ESP에 drive 문자를 할당하여 접근할 수 있습니다.
UEFI Firmware Boot Manager
UEFI firmware boot manager는 OS boot manager인 ***.efi 파일을 검색하여 booting 하는데 이를 위해서는
정해진 directory structure를 구성해야 합니다. ESP에는 root에 \EFI 폴더가 있어야 되고 모든 OS loader와
application은 \EFI의 하위 폴더에 존재해야 합니다. 하위 폴더명은 서로 달라야 하고 각각의 vendor
subdirectory에는 UEFI firmware boot manager가 읽을 수 있는 executable EFI image가 오직 하나만 존재해야
합니다. 만약 1개 이상의 executable EFI image가 존재하면 system의 booting 과정이 헝클어질 수도 있습니다.
UEFI firmware boot manager는 booting OS가 없을 경우 optional vendor subdirectory(\EFI\BOOT 폴더)의
default file name인 BOOT{machine type short-name}.EFI(일반적으로 bootx64.efi)로 부팅을 시도합니다.
Removable media device는 오직 하나의 system partition과 \EFI\BOOT에 오직 하나의 EFI image만
존재해야 하며 모든 OS loaders와 applications은 \EFI\BOOT에 저장해야 합니다.
UEFI에서의 Multi-Booting의 선택
통상의 multi-booting은 하나의 boot manager(Windows boot manager 또는 grub 등)로 booting 후
원하는 OS를 선택하는 방법입니다.
하지만 이 글에서는 이런 방법이 아닌 UEFI firmware boot manager에서 직접 원하는 boot manager를
선택하여 booting 하는 방법을 알아볼 것입니다.
Windows boot manager는 통상 아래 그림처럼 여러 운영 체제를 보기 쉽게 나열해줍니다.
하지만 firmware boot manager level에서 OS boot manager를 선택할 수 있는 menu를 보여주는 방법은 없습니다({fwbootmgr}-timeout도 의미 없습니다).
하지만 어떤 OS boot manager가 등록이 되어있는지 확인은 가능합니다. 즉, UEFI firmware로 진입하면 boot order list를 볼 수 있고 One-Time Boot Menu Hot-Key로 boot menu에서 booting 할 OS를 선택할 수도 있습니다.
또한, Windows에서도 BCD store의 {fwbootmgr} 항목에 {bootmgr}를 포함해서 다른 boot manager 또는
firmware application을 볼 수 있습니다.
displayoder에서 첫 번째가 default booting이며 bcdedit /set {fwbootmgr} default {GUID}로 설정 가능합니다.
bcdedit로 {fwbootmgr}를 특정 설정을 하면 즉시 UEFI firmware의 NVRAM에 반영이 됩니다.
비록 UEFI firmware boot manager level에서 Windows Boot Manager처럼 보기 쉬운 menu를 사용할 수는 없지만
다음의 3가지 방법 중 One-Time Boot Menu Hot-Key를 이용하면 나름 준수한 OS 선택 화면을 볼 수 있습니다.
UEFI firmware boot manager에서 직접 Booting 방법은 3가지 중 하나입니다.
1. UEFI firmware boot manager는 NVRAM에서 boot order list를 읽어 default OS로 자동 booting 합니다.
(default: BCD에서는 {fwbootmgr}-displayorder의 첫 번째 값)
일반적으로 Windows 단독 설치 시에 해당합니다.
2. One-Time Boot Menu Hot-Key로 firmware boot menu에 진입 후 원하는 OS를 선택 후 booting 합니다.
Gigabyte mainboard에서 booting 시에 F12 key를 누르면 아래와 같이 boot device 선택창이 나타납니다.
3. UEFI firmware로 진입 후 Boot Override에서 원하는 OS를 선택 후 booting 합니다.
One-Time Boot Menu Hot-Key를 이용하려면 UEFI firmware boot menu에 원하는 OS boot manager를 반드시
먼저 등록해야 합니다.
UEFI firmware boot manager({fwbootmgr})에 new OS boot manager(BCD의 firmware application) 등록하기
1. bootice로 UEFI Boot entry를 설정하면 됩니다 - 권장!!!
2. bcdedit를 이용하는 방법
A. bcdedit /copy로 기존 Firmware Application의 복사본을 생성하면 됩니다.
/copy 명령어를 이용하므로 기존 Firmware Application이 반드시 필요합니다.
B. bcdedit /copy {bootmgr}로 가능하지만 2개의 Windows boot manager가 되므로 권장하지 않습니다.
3. UEFI firmware에서 자동 등록하는 방법
A. FAT format 된 partition(이하 FAT-partition)이 존재해야 된다.
a. ESP GUID가 아니라도 무관
b. FAT-partition은 하나의 disk 또는 여러 개의 disk에 각각 존재 가능
c. 각각의 disk에 FAT-partition의 개수는 여러 개 가능
B. FAT-partition에 \EFI\BOOT\bootx64.efi가 존재해야 한다.
C. 단점: 동일한 disk에 존재하는 FAT-partition의 boot device 명칭이 모두 동일하여 구분이 불가능합니다.
4. UEFI shell(built-in EFI shell 또는 shell.efi)을 이용하여 NVRAM에 boot entry에 등록하는 방법
메인보드에 따라 UEFI Shell이 내장되어 있는 UEFI firmware도 있고 아닌 경우도 있습니다.
Gigabyte는 없는 것 같습니다.
Releases · pbatard/UEFI-Shell (github.com)
※ Rufus에서도 다운로드 받을 수 있습니다.
참고)
Windows는 설치하는 동안 ESP\EFI\Microsoftf라는 자신의 OS 폴더를 생성하고 Windows boot manager를
UEFI firmware boot manager에 등록합니다. 하지만 수동으로 ESP\OS_Name 폴더와 ***.efi, BCD를 생성하고
bootice 등으로 UEFI firmware boot menu에 수동 등록하지 않은 경우는 booting 하는 동안 UEFI firmware boot manager가 수동 생성한 ***.efi를 자동으로 등록해 주지 않습니다. UEFI firmware boot manager는 FAT-partition에
있는 \EFI\BOOT\bootx64.efi(BOOT{machine type short-name}.EFI)만 자동으로 등록해주기 때문입니다.
UEFI forum 설명대로라면 \EFI 하부의 모든 폴더를 조사하여 자동 등록해줄 것 같지만 Gigabyte 메인보드는
UEFI firmware 제작 시에 이런 기능을 탑재한 것 같지는 않습니다.
참고)
Microsoft는 bcdedit /set {fwbootmgr} displayorder {bootmgr} /addfirst로 UEFI firmware에 등록 가능하다지만
{bootmgr}와 firmware application만 해당됩니다. bcdcedit /create /appication <apptype> (<apptype>은 startup | bootapp | bootsector | osloader)으로 생성된 object들은 {bootmgr}와 firmware application이 아니며 bcdedit /set {fwbootmgr} displayorder 명령으로 firmware boot menu에 등록이 안됩니다. bootapp(Boot Application)과
동일한 ***.efi 파일을 bootice로 UEFI boot entry로 등록해도 파일만 같을 뿐 서로 상관없는 boot entry가 됩니다.
결론은 bcdedit로 특정 OS를 UEFI firmware에 등록하여 firmware boot order list에 나타나게 할 방법이 없습니다.
(Windows의 bcdedit 입장에서는 다른 OS를 NVRAM의 boot entry에 등록해 줄 이유가 없습니다)
*** <apptype> stratup, bootapp은 OS loader가 아니므로 당연히 OS selection에 표시되지 않습니다.
*** <apptype> bootsector는 Real-Mode Boot Sector로 <apptype> osloader와 마찬가지로 {bootmgr} 관리하의
OS loader로 취급되므로 firmware에 당연히 등록되지 않습니다.
참고)
firmware boot order list의 순서는 bootice UEFI tab에서 설정 가능하며 bcdedit에서도 가능합니다.
bcdedit /set {fwbootmgr} default {GUID}
bcdedit /set {fwbootmgr} displayorder {GUID} [ /addfirst | /addlast | /remove ]
bcdedit /set {fwbootmgr} displayorder {GUID} {GUID}...
UEFI Firmware Boot Menu에서 Boot Manager를 직접 선택하는 Multi-Booting
1. 하나의 disk에 하나의 공용 ESP에 개별 OS 폴더를 구성하는 법 - UEFI, Microsoft에서 권장하는 방법
2. 하나의 disk에 여러 개의 ESP로 각각 booting 하는 방법
3. 하나의 disk에 하나의 공용 ESP, 하나의 공용 OS 폴더에 개별 OS ***.efi와 공용 BCD로 booting 하는 방법
1. 하나의 Disk에 하나의 공용 ESP에 개별 OS Booting 폴더를 구성하는 방법
UEFI forum 및 Microsoft 자료에 기술된 방법입니다.
ESP의 root directory에 \EFI 폴더가 존재하고 \EFI 폴더 하위에 각각의 OS 폴더가 존재합니다.
Windows 계열은 각 OS 폴더에 ***.efi 파일과 BCD 파일이 필요합니다.
각 OS 폴더 내의 ***.efi 파일의 이름은 임의로 변경해도 됩니다.
하지만 \BOOT 폴더 내의 bootx64.efi는 변경하면 안 됩니다.
참고) rufus의 bootx64.efi, ntfs_x64.efi, exfat_x64.efi에 관하여 짧게 정리하면.......
1. rufus 파일이 존재하는 FAT-partition의 bootx64.efi가 실행됩니다.
2. bootx64.efi는 boot disk(자신이 존재하는 저장장치)의 제일 앞부분부터 partition type을 확인합니다.
3. NTFS 또는 exFAT 중 하나라도 발견하면 즉시 검색을 중단합니다
4. 발견된 partition이 NTFS 또는 exFAT service가 필요한지 확인합니다.
5. service가 필요하다면 \efi\rufus 폴더 내에 대응하는 ntfs_x64.efi, exfat_x64.efi가 존재하는지 검색합니다.
6. 대응하는 ntfs_x64.efi, exfat_x64.efi이 존재하면 각각의 driver service를 시작합니다.
7. 해당하는 NTFS 또는 exFAT partition의 \efi\boot\bootx64.efi로 제어권을 넘깁니다.
참고) rufus의 작업 순서는 partition을 먼저 검색하고 해당 partition에 맞는 service(driver)를 찾는 방식입니다.
1. rufus 파일이 존재하는 FAT-partition은 저장장치의 처음 또는 마지막 어디에나 가능합니다.
2. FAT-partition 내의 폴더 구조를 변경하면 안됩니다. rufus 폴더와 내부 파일이 존재해야 됩니다.
3. boot disk에 NTFS와 exFAT이 모두 존재하는 경우
a. 먼저 발견하는 partition만 유효합니다.
즉, NTFS 또는 exFAT partition 중 하나가 존재하면 추가 검색 없이 그시점에서 검색을 중단합니다.
b. NTFS partition이 먼저 존재하면 \efi\rufus\ntfs_x64.efi이 있어야 부팅이 됩니다.
c. exFAT partition이 먼저 존재하면 \efi\rufus\exfat_x64.efi이 있어야 부팅이 됩니다.
d. \efi\rufus에 ntfs_x64.efi와 exfat_x64.efi이 모두 존재하면 먼저 발견한 partition으로만 부팅합니다.
예) NTFS - exFAT 순으로 partition이 존재하고 exfat_x64.efi만 있는 경우는 부팅되지 않습니다.
NTFS가 먼저 발견되었기 때문에 NTFS만 유효하고 반드시 ntfs_x64.efi가 필요합니다.
ntfs_x64.efi가 없다고 자동으로 다음 exFAT partition으로 부팅이 진행되지는 않습니다.
partition을 먼저 검색하고 해당 partition에 맞는 service(driver)를 찾는 방식이기 때문입니다.
참고) 설치 시에 자동으로 firmware boot menu에 등록되는 경우 외에는 bootice로 직접 등록해야 됩니다.
FAT-partition에 \EFI\BOOT\bootx64.efi 만 자동으로 등록됩니다. 그 외 전부 수동 등록해야 됩니다.
2. 하나의 Disk에 여러 개의 ESP로 각각 Booting 하는 방법
UEFI Specification, version 2.9에 의하면 ESP의 개수나 위치에 제한을 두지 않지만
Wimdows는 하나의 disk에 하나의 ESP만 허용하고 disk의 첫 부분에 위치하도록 권장합니다.
개별 OS에 대하여 각각의 ESP를 따로 만듭니다. ESP 내에는 ***.efi와 BCD가 필요합니다.
1번 방법에 비해 단점은 basic data partition은 동일하지만 ESP의 개수가 많아져서 비효율적입니다.
장점은 각각의 ESP의 bootx64.efi 파일을 UEFI firmware에서 자동 인식하여 boot order list에 등록합니다.
이 방법은 Microsoft 권장 사항이 아닙니다.
참고) 아래 그림의 ESP1, 2, 3, 4는 수동으로 이름을 수정한 것이고
동일 disk의 ESP 들은 자동 등록 시에는 동일 이름으로 등록됩니다.
참고) bootx64.efi 외에는 자동 등록되지 않습니다.
3. 하나의 공용 ESP, 하나의 공용 OS 폴더에 개별 OS.efi와 공용 BCD로 Booting 하는 방법
ESP\EFI\OS 폴더 내에 2개 이상의 ***.efi 파일을 만들고 하나의 BCD에 2개 이상의 Windows Boot Manager를
생성하여 각각 Windows Boot(OS) Loader와 연결하면 정상 booting이 가능합니다.
Windows에서 {bootmgr}는 오직 1개로 정해져 있지만 bcdedit /copy {bootmgr} /d "SRS7+++"처럼 bcdedit로
새로운 Windows Boot Manager를 만들고 element를 수정하시면 됩니다. 물론 GUID가 다르므로 {bootmgr}로
표시되지는 않습니다. bcdedit /enum active로는 {bootmgr}가 1개밖에 출력이 안돼서 bcdedit /enum bootmgr로
확인해야 됩니다. bootice로 ***.efi 파일명을 변경 및 등록할 수 있으며 bcdedit는 파일명이 변경된 ***.efi 파일을
등록할 수 있습니다.
이 방법은 UEFI forum과 Microsoft 모두에서 권장 사항이 아닙니다.
참고)
Windows Boot(OS) Loader 또는 Real-mode Boot Sector로 multi-booting 하는 방법
multi-booting은 Windows 설치 후 다른 Windows를 추가로 설치하거나 ubuntu 등 다른 OS를 추가 설치하는
경우에 나중에 설치하는 OS에서 multi-booting이 자동 설정됩니다.
그러나 ubuntu를 설치 후 Windows를 설치하면 multi-booting이 깨지고 ubuntu booting이 안됩니다.
이때는 GRUB bootloader를 복구하면 ubuntu 우선 booting과 Windows와의 multi-booting도 복구됩니다.
Windows 우선 booting을 하려면 UEFI boot menu의 default를 Windows boot manager로 변경하고 BCD에
ubuntu를 Real-mode Boot Sector로 추가하면 Windows boot manager에서 ubuntu를 선택할 수 있습니다.
UEFI Specification, version 2.9
https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/boot-and-uefi
uefi.org/sites/default/files/resources/UEFI-Plugfest-WindowsBootEnvironment.pdf
https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-and-gpt-faq
- Total
- Today
- Yesterday
- SRS8
- recovery
- 쓰기 캐시 버퍼 플러시
- SRS7
- multi-booting
- LG Recovery
- LG PC
- Admintool
- GIGABYTE BIOS # BIOS 복구 # BIOS 손상 # BIOS pin
- unassigned
- unallocated
- Write Back
- write-cache buffer flushing
- 다시 쓰기
- 할당되지 않은 공간
- 한글2022 #무인설치 #시디키 자동입력
- UEFI
- 1mb
- winre.wim
- 일반PC
- 1MiB
- 쓰기 캐싱
- system partition
- LDM
- ReagentC
- 쓰기 캐시 버퍼 플러싱
- SRS
- winre
- 삼성PC
- write-caching
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 |