Handbook:X86/Blocks/Bootloader/ko

비록 32비트 CPU에 설치한다지만 대부분의 모든 x86 마더보드(2006-2007년경부터 현재까지)는 64비트 UEFI 펌웨어를 지원하는 모델로 출시합니다. 일부 사용자는 설정 이름과 파일에서 "64"라는 숫자를 눈여겨보게 될지도 모릅니다. 이는 거의 모든 경우에 해당되리라 봅니다.

당연스럽게도 UEFI 펌웨어가 64비트라지만 매우 드문 예외가 있는데, 극히 일부 초기 애플 맥 모델과 인텔 아톰 기반 델 태블릿 PC에서는 32비트 UEFI 펌웨어를 지원합니다. 대부분의 독자는 절대적으로 32비트 UEFI 펌웨어를 볼 일이 없습니다. 이 때문에 32비트 UEFI 펌웨어는 x86 핸드북에서 다루지 않습니다.

부트로더 선택

리눅스 커널을 설정하고, 시스템 도구를 설치하고, 설정 파일을 편집하고 나면, 리눅스 설치의 일부로서 마지막으로 중요한 부분, 부트로더를 설치할 차례입니다.

부트로더는 부팅 과정에서 리눅스 커널의 실행을 담당합니다. 부트로더가 없으면 시스템에서는 전원 단추를 누른 후 그 다음 과정을 어떻게 처리해야 할지 모릅니다.

x86에서는 BIOS 기반 시스템에서 GRUB2 또는 LILO를 설정하는 방법, UEFI 시스템에서 GRUB2 또는 efibootmgr을 사용하는 방법을 문서에 남겨두었습니다.

여기서는 부트로더 꾸러미를 이머징하고 시스템 디스크에 부트로더를 설치하는 방법을 설명합니다. 이머징은 시스템에서 활용할 수 있는 프로그램 꾸러미를 Portage에 만들려고 요청할 때 활용합니다. 설치는 다음에 전원을 다시 켰을 때 부트로더를 활성화한 후 동작 대기 상태로 두도록 시스템 디스크 드라이브의 적당한 부분에 파일을 복사하거나 물리적으로 수정함을 의미합니다.

기본: GRUB2

기본적으로, 젠투 시스템에서는 기존 GRUB을 그대로 이어가는 GRUB2(sys-boot/grub)로 의존 대세가 바뀌었습니다. 설정을 추가로 하지 않아도 이전 BIOS("pc") 시스템을 기꺼이 지원합니다. 빌드 이전에 필요한 일부 설정으로 여러 추가 플랫폼을 지원할 수 있습니다. 자세히 알아보시려면 GRUB 게시글의 선행 과정 부분을 참고하십시오.

Emerge

MBR 분할 영역 테이블만 지원하는 이전 BIOS 시스템을 활용한다면 GRUB을 이머징할 때 추가로 설정할 필요가 없습니다:

root #emerge --ask --verbose sys-boot/grub:2

• UEFI 사용자 참고사항: 위 명령을 실행하면 이머징을 시작하기 전 GRUB_PLATFORMS 활성 변수 값을 나타냅니다. UEFI 기능이 동작하는 시스템을 활용한다면, 해당 사용자는 GRUB_PLATFORMS="efi-64"(기본적인 고려 사항)값을 넣었는지 확인해야합니다. 설치 과정에 이 값이 나타나지 않은 경우라면 GRUB2를 이머징하기 전 /etc/portage/make.conf 파일에 GRUB_PLATFORMS="efi-64" 값을 추가하여, GRUB2에 EFI 기능을 넣어 빌드할 수 있게 해야합니다.

root #echo 'GRUB_PLATFORMS="efi-64"' >> /etc/portage/make.conf

root #emerge --ask sys-boot/grub:2

(위에서와 같이) make.conf에 GRUB_PLATFORMS="efi-64"를 활성화하지 않고 GRUB2를 이머지했다 하더라도 나중에 해당 줄을 추가할 수 있고, emerge에 --update --newuse 옵션을 전달하여 전체 꾸러미 모음^en의 의존성을 다시 처리할 수 있습니다.

root #emerge --ask --update --newuse --verbose sys-boot/grub:2

이제 GRUB2 프로그램을 이머징했지만, 설치한 상태는 아닙니다.

설치

다음, /boot/grub/에 필요한 GRUB2 파일을 grub-install 명령으로 설치할 차례입니다. 첫번째 디스크(부팅할 디스크)를 /dev/sda라고 가정하고, 다음 명령중 하나로 GRUB2 파일을 설치합니다:

• BIOS를 사용하면:

root #grub-install /dev/sda

For DOS/Legacy BIOS systems:

root #grub-install /dev/sda

• UEFI를 사용하면:

중요
grub-install을 실행하기 전 EFI 시스템 공간을 마운트 했는지 확인하십시오. grub-install 프로그램이 잘못된 디렉터리를 사용한 "어떤" 설정 내지는 표시 없이 잘못된 디렉터리의 GRUB EFI 파일(grubx64.efi)로 설치할 수 있습니다.

For UEFI systems:

root #grub-install --target=x86_64-efi --efi-directory=/boot

Upon successful installation, the output should match the output of the previous command. If the output does not match exactly, then proceed to Debugging GRUB, otherwise jump to the Configure step.

Optional: Secure Boot

The sys-boot/grub package does not recognize the secureboot USE flag, this is because the GRUB EFI executable is not installed by the package but is instead built and installed by the grub-install command. GRUB must therefore be manually signed after installation to the boot partition. Additionally, GRUB is a modular bootloader but loading modules is prohibited when Secure Boot is enabled. Therefore all necessary modules must be compiled into the GRUB EFI executable, below an example is shown including some basic modules, this may have to be adjusted for more advanced configurations:

root #emerge --noreplace sbsigntools

root #export GRUB_MODULES="all_video boot btrfs cat chain configfile echo efifwsetup efinet ext2 fat font gettext gfxmenu gfxterm gfxterm_background gzio halt help hfsplus iso9660 jpeg keystatus loadenv loopback linux ls lsefi lsefimmap lsefisystab lssal memdisk minicmd normal ntfs part_apple part_msdos part_gpt password_pbkdf2 png probe reboot regexp search search_fs_uuid search_fs_file search_label sleep smbios squash4 test true video xfs zfs zfscrypt zfsinfo"

root #grub-install --target=x86_64-efi --efi-directory=/efi --modules=${GRUB_MODULES} --sbat /usr/share/grub/sbat.csv

root #sbsign /efi/EFI/GRUB/grubx64.efi --key /path/to/kernel_key.pem --cert /path/to/kernel_key.pem --out /efi/EFI/GRUB/grubx64.efi

To successfully boot with secure boot enabled the used certificate must either be accepted by the UEFI firmware, or shim must be used as a pre-loader. Shim is pre-signed with the third-party Microsoft Certificate, accepted by default by most UEFI motherboards.

How to configure the UEFI firmware to accept custom keys depends on the firmware vendor, which is beyond the scope of the handbook. Below is shown how to setup shim instead:

root #emerge sys-boot/shim sys-boot/mokutil sys-boot/efibootmgr

root #cp /usr/share/shim/BOOTX64.EFI /efi/EFI/GRUB/shimx64.efi

root #cp /usr/share/shim/mmx64.efi /efi/EFI/GRUB/mmx64.efi

Shims MOKlist requires keys in the DER format, since the OpenSSL key generated in the example here is in the PEM format, the key must be converted first:

root #openssl x509 -in /path/to/kernel_key.pem -inform PEM -out /path/to/kernel_key.der -outform DER

참고
The path used here must be the path to the pem file containing the certificate belonging to the generated key. In this example both key and certificate are in the same pem file.

Then the converted certificate can be imported into Shims MOKlist:

root #mokutil --import /path/to/kernel_key.der

And finally we register Shim with the UEFI firmware. In the following command, boot-disk and boot-partition-id must be replaced with the disk and partition identifier of the EFI system partition:

root #efibootmgr --create --disk /dev/boot-disk --part boot-partition-id --loader '\EFI\GRUB\shimx64.efi' --label 'shim' --unicode

Debugging GRUB

When debugging GRUB, there are a couple of quick fixes that may result in a bootable installation without having to reboot to a new live image environment.

In the event that "EFI variables are not supported on this system" is displayed somewhere in the output, it is likely the live image was not booted in EFI mode and is presently in Legacy BIOS boot mode. The solution is to try the removable GRUB step mentioned below. This will overwrite the executable EFI file located at /EFI/BOOT/BOOTX64.EFI. Upon rebooting in EFI mode, the motherboard firmware may execute this default boot entry and execute GRUB.

중요
grub-install 에서 Could not prepare Boot variable: Read-only file system와 같은 오류가 나타났을 경우, 과정을 제대로 넘어가기 위해 efivars 특수 마운트 지점을 다시 마운트 해야합니다:

root #mount -o remount,rw /sys/firmware/efi/efivars

root #mount -o remount,rw,nosuid,nodev,noexec --types efivarfs efivarfs /sys/firmware/efi/efivars

This is caused by certain non-official Gentoo environments not mounting the special EFI filesystem by default. If the previous command does not run, then reboot using an official Gentoo live image environment in EFI mode.

일부 마더보드 제조사에서는 .EFI 파일을 저장할 EFI 시스템 파티션(ESP)의 디렉터리 위치 경로를 /efi/boot/ 디렉터리만 지원하는 것 같습니다. GRUB 설치 관리자에서는 --removable 옵션을 주어 자동으로 처리할 수 있습니다. 다음 명령을 실행하기 전에 ESP를 마운트했는지 확인하십시오. (앞서 말한대로) /boot에 ESP를 마운트했다고 생각한다면, 다음 명령을 실행하십시오:

root #grub-install --target=x86_64-efi --efi-directory=/boot --removable

이 명령은 UEFI 명세로 정의한 기본 디렉터리를 만들고 grubx64.efi 파일을 동일한 명세로 정의한 '기본' EFI 파일 위치에 복사합니다.

설정

다음, /etc/default/grub 파일과 /etc/grub.d 스크립트를 기반으로 정의한 사용자 설정을 기반으로 하여 GRUB2 설정을 만드십시오. GRUB2에서 어떤 커널로 부팅할지 (/boot/에 존재하는 가장 최신의 버전), 루트 파일 시스템이 어디인지 자동으로 찾기 때문에 사용자가 직접 설정할 필요가 없습니다. /etc/default/grub 의 GRUB_CMDLINE_LINUX 변수에 커널 매개 변수를 넣을 수도 있습니다.

최종 GRUB2 설정을 만들려면 grub-mkconfig 명령을 실행하십시오:

root #grub-mkconfig -o /boot/grub/grub.cfg

Generating grub.cfg ...
Found linux image: /boot/vmlinuz-6.6.21-gentoo
Found initrd image: /boot/initramfs-genkernel-x86-6.6.21-gentoo
done

명령 출력은 최소한 시스템 부팅에 필요한 하나의 리눅스 이미지를 찾았다는 알림이 나와야 합니다. initramfs를 사용했거나, 커널 빌드시 genkernel를 사용했다면, 마찬가지로 올바른 initrd 이미지를 찾아야 합니다. 이런 경우가 아니라면 /boot/로 이동해서 ls 명령으로 내용을 확인해보십시오. 여전히 파일이 빠졌다면, 커널 설정으로 되돌아가서 설치 절차를 따르십시오.

요령
os-prober 유틸리티로 붙어있는 드라이브에서 다른 우영체제를 찾아 붙일 수 있습니다. 윈도우 7, 8.1, 10, 그리고 다른 리눅스 배포판을 찾을 수 있습니다. 듀얼 부팅 시스템을 원한다면 sys-boot/os-prober 꾸러미를 설치하고 grub-mkconfig 명령을 (위에서 보신 것처럼) 다시 실행하십시오. 운영체제를 찾는 과정에 문제가 있다면, 젠투 커뮤니티에 지원을 요청하기 전 GRUB 게시글을 다시 확인하십시오.

대안 1: LILO

Emerge

LInuxLOader LILO는 검증되고 본 기능에 충실한 리눅스 부트로더입니다. 그러나 GRUB에 비하면 부족한 측면도 있습니다. LILO를 그래도 사용하는 이유는, 일부 시스템에서 GRUB이 처리할 수 없는 동작을 LILO에서 처리할 수 있기 때문입니다. 물론, 일부 사용자가 여전히 LILO에 집착하기 때문이기도 합니다. 어쨌든간에 젠투는 두 부트로더를 다 지원합니다.

LILO 설치는 순식간입니다. 그냥 emerge 명령을 사용하십시오.

root #emerge --ask sys-boot/lilo

설정

LILO를 설정하려면, 먼저 /etc/lilo.conf 파일을 만드십시오:

root #nano -w /etc/lilo.conf

설정 파일에서 부팅 커널을 참조할 섹션을 사용합니다. 이 설정 파일에서 참조하려는 커널 파일(및 커널 버전)과 initramfs 파일을 알아내십시오.

참고
루트 파일 시스템이 JFS라면, 각각의 부팅 항목 다음에 append="ro"를 추가하여 읽기 쓰기 마운팅이 가능하기 전에 JFS에서 로그 작성을 제고하도록 하십시오

파일 /etc/lilo.confLILO 설정 예제

'"`UNIQ--pre-00000005-QINU`"'

참고
다른 분할 배치 형식을 사용하거나 다른 커널 이미지를 사용한다면, 그에 맞게 조절하십시오.

initramfs가 필요하다면, 이 initramfs 파일을 참고하여 설정을 바꾸고 initramfs에게 실제 루트 장치가 어디있는지 알려주십시오:

파일 /etc/lilo.conf부팅 항목에 initramfs 정보 추가

'"`UNIQ--pre-00000008-QINU`"'

추가 옵션을 커널에 전달해야 한다면 append 구문을 사용하십시오. 예를 들어 프레임버퍼를 활성화할 video 구문을 추가하려면:

파일 /etc/lilo.conf부팅 옵션에 비디오 매개 변수 추가

'"`UNIQ--pre-0000000B-QINU`"'

genkernel을 사용한 사용자는 설치 CD에서 사용한 부팅 옵션과 동일한 옵션을 커널에 사용함을 알아야합니다. 예를 들어 SCSI 장치 활성화가 필요하다면 doscsi를 커널 옵션으로 추가합니다.

이제 파일을 저장하고 빠져나가십시오.

설치

과정을 마무리하려면, /sbin/lilo를 실행하여 LILO가 /etc/lilo.conf 설정을 시스템에 반영(디스크 자체에 설치)할 수 있게 하십시오. 커널 파일 이름을 바꾸고 시스템을 부팅하려면 커널을 새로 설치하거나 lilo.conf 파일을 바꿀 때마다 /sbin/lilo를 실행해야 함을 숙지하십시오.

root #/sbin/lilo

대안 2: efibootmgr

UEFI 기반 시스템에서는, 시스템의 UEFI 펌웨어(기본 부트 로더)에서 UEFI 부팅 항목을 직접 다룰 수 있습니다. 일부 시스템에서는 부팅할 때 GRUB2와 같은 추가(또는 차선) 부트로더가 필요하지 않습니다. 이 말은 결국, GRUB2 같은 EFI 기반 부트로더의 존재 이유가 바로 부팅 과정에서 UEFI 시스템 기능을 "확장"하는데 있습니다. efibootmgr를 사용하는 것이야말로(융통성이 없긴 하지만) 시스템 부팅 관점 접근 상 간소화를 원하는 이들에게 안성맞춤입니다. GRUB2(상부 참고)를 사용하는게 주로 사용자에게 더 쉬운 방법인데 UEFI 시스템을 부팅할 때 유연한 접근 방식을 취하기 때문입니다.

System administrators who desire to take a minimalist, although more rigid, approach to booting the system can avoid secondary bootloaders and boot the Linux kernel as an EFI stub.

sys-boot/efibootmgr 프로그램은 부트로더가 아님을 기억해두십시오. efibootmgr은 UEFI 펌웨어와 소통하고 UEFI 펌웨어 설정을 업데이트할 때 사용하는 도구이기 때문에 이전에 설치한 리눅스 커널을 (필요한 경우)추가 옵션을 통해 부팅할 수 있으며, 또는 다중 부팅 항목을 넣을 수 있습니다. 이러한 동작간 작용은 EFI 변수로 처리할 수 있습니다(따라서 이를 처리하기 전에 커널의 EFI 변수 지원이 필요합니다).

계속하기 전, EFI stub kernel 게시글을 우선 읽어두십시오. 시스템의 UEFI 펌웨어로 바로 부팅할 수 있게 커널의 몇가지 지정 옵션을 활성화해야합니다. 커널을 다시 컴파일 해야 할 수도 있습니다. efibootmgr 게시물을 살펴보시는 것도 좋습니다.

It is also a good idea to take a look at the efibootmgr article for additional information.

참고
다시 반복하지만, efibootmgr은 UEFI 시스템에서 부팅하는데 필수 요건이 아닙니다. 리눅스 커널 자체에서 즉시 부팅할 수 있으며, 추가 커널 명령행 옵션은 리눅스 커널 자체의 일부로 내장할 수 있습니다(사용자가 명령행에서 처럼 부팅 매개 변수를 지원하도록 호출할 수 있는 커널 설정 옵션이 있습니다). 심지어 initramfs도 커널 '그 자체'로 빌드할 수 있습니다.

이런 방식으로 진행하기로 마음먹었다면 프로그램을 설치해야합니다:

root #emerge --ask sys-boot/efibootmgr

그 다음 /boot/efi/boot/ 디렉터리를 만들고, 커널을 bootx64.efi 위치에 복사하십시오:

root #mkdir -p /boot/efi/boot

root #cp /boot/vmlinuz-* /boot/efi/boot/bootx64.efi

참고
UEFI 정의를 활용한다면 디렉터리 구분자로서 \ 사용은 필수입니다.

다음, 새로 컴파일한 EFI 커널로 부팅하는 "Gentoo" 항목을 UEFI 펌웨어에 적어주십시오:

root #efibootmgr --create --disk /dev/sda --part 2 --label "Gentoo" --loader "\efi\boot\bootx64.efi"

초기 램 파일 시스템(initramfs)를 사용한다면, 적당한 부팅 옵션을 추가하십시오:

root #efibootmgr -c -d /dev/sda -p 2 -L "Gentoo" -l "\efi\boot\bootx64.efi" initrd='\initramfs-genkernel-x86-6.6.21-gentoo'

Note that the above command presumes an initramfs file was copied into the ESP inside the same directory as the bootx64.efi file.

설정을 다 바꿨다면, 시스템을 다시 부팅할 때, 부팅 항목에 "Gentoo"가 뜹니다.

Unified Kernel Image

If installkernel was configured to build and install unified kernel images. The unified kernel image should already be installed to the EFI/Linux directory on the EFI system partition, if this is not the case ensure the directory exists and then run the kernel installation again as described earlier in the handbook.

To add a direct boot entry for the installed unified kernel image:

root #efibootmgr --create --disk /dev/sda --part 1 --label "gentoo" --loader /efi/EFI/Linux/gentoo-x.y.z.efi

대안 3: Syslinux

Syslinux는 x86 아키텍처의 또 다른 대안 부트로더입니다. MBR을 지원하며 6.00부터는 EFI 부팅을 지원합니다. PXE(네트워크) 부팅과 잘 알려지지 않은 부팅 옵션도 지원합니다. Syslinux는 핸드북에서 지원하지 않는 다른 여러가지 아키텍처도 지원하는 유명한 부트로더이긴 합니다. 독자 여러분은 Syslinux 게시글을 따라 이 부트로더를 이머징하고 설치하여 정보를 찾아보실 수 있습니다.

Alternative 4: systemd-boot

Another option is systemd-boot, which works on both OpenRC and systemd machines. It is a thin chainloader and works well with secure boot.

To install systemd-boot:

root #bootctl install

중요
Make sure the EFI system partition has been mounted before running bootctl install.

When using this bootloader, before rebooting, verify that a new bootable entry exists using:

root #bootctl list

If no new entry exists, ensure the sys-kernel/installkernel package has been installed with the systemd-boot USE flag enabled, and re-run the kernel installation.

For the distribution kernels:

root #emerge --ask --config sys-kernel/gentoo-kernel

For a manually configured and compiled kernel:

root #make install

중요
When installing kernels for systemd-boot, no root= kernel command line argument is added by default. On systemd systems that are using an initramfs users may rely instead on systemd-gpt-auto-generator to automatically find the root partition at boot. Otherwise users should manually specify the location of the root partition by setting root= in /etc/kernel/cmdline as well as any other kernel command line arguments that should be used. And then reinstalling the kernel as described above.

Optional: Secure Boot

When the secureboot USE flag is enabled, the systemd-boot EFI executable will be signed automatically. bootctl install will automatically install the signed version.

To successfully boot with secure boot enabled the used certificate must either be accepted by the UEFI firmware, or shim must be used as a pre-loader. Shim is pre-signed with the third-party Microsoft Certificate, accepted by default by most UEFI motherboards.

How to configure the UEFI firmware to accept custom keys depends on the firmware vendor, which is beyond the scope of the handbook. A postinst hook to automatically update systemd-boot and set it up with shim instead is provided on the systemd-boot wiki page. However the first time this should be done manually by following the steps below:

root #emerge --ask sys-boot/shim sys-boot/mokutil sys-boot/efibootmgr

root #cp /usr/share/shim/BOOTX64.EFI /efi/EFI/BOOT/BOOTX64.EFI

root #cp /usr/share/shim/mmx64.efi /efi/EFI/BOOT/mmx64.efi

root #cp /efi/EFI/systemd/systemd-bootx64.efi /efi/EFI/BOOT/grubx64.efi

참고
Shim is hardcoded to load grubx64.efi. As such the systemd-boot bootloader must be named as if it were GRUB.

Shims MOKlist requires keys in the DER format, since the OpenSSL key generated in the example here is in the PEM format, the key must be converted first:

root #openssl x509 -in /path/to/kernel_key.pem -inform PEM -out /path/to/kernel_key.der -outform DER

참고
The path used here must be the path to the pem file containing the certificate belonging to the generated key. In this example both key and certificate are in the same pem file.

Then the converted certificate can be imported into Shims MOKlist:

root #mokutil --import /path/to/kernel_key.der

And finally we register Shim with the UEFI firmware. In the following command, boot-disk and boot-partition-id must be replaced with the disk and partition identifier of the EFI system partition:

root #efibootmgr --create --disk /dev/boot-disk --part boot-partition-id --loader '\EFI\BOOT\BOOTX64.EFI' --label 'shim' --unicode