기존의 문제점 중,이것파티션을 확대하려고 한다는 점을 제외하면 내가 하고 있는 작업과 가장 비슷해 보이지만 /boot/ 및 /boot/efi가 다른 파티션으로 마운트되는 이유와 걱정하지 않고 진행하는 방법을 모르겠습니다.
지금까지 새 파티션을 생성하고 여기에 마운트 /newBoot
하고 작업을 실행했으므로 sudo rsync -a /boot/ /newBoot/
전환하려는 새 파티션에 모든 관련 파일이 있다고 가정합니다.
$ lsblk -e 7 -o name,fstype,size,fsused,label,partlabel,mountpoint,uuid,partuuid
NAME FSTYPE SIZE FSUSED LABEL PARTLABEL MOUNTPOINT UUID PARTUUID
sda 7.3T
└─sda1 crypto 7.3T 4dffc196-9926-43d9-a7c8-38898681f402 85b3a656-4886-4b37-b9c1-2acb0158587a
...
nvme0n1 931.5G
├─nvme0n1p1 vfat 512M 5.3M EFI System Partition
│ /boot/efi FD0E-EECA 587cf214-f068-4879-a833-9dffa5ec6e3d
├─nvme0n1p2 ext2 488M 313.7M /boot 606a1976-d1c2-4246-a256-a8afddb04f84 2e10e277-560f-4f5e-abce-1dce5187a7f0
...
└─nvme0n1p4 vfat 1.5G NEWBOOT newboot 530D-4828 ea886018-714f-46fb-8f21-785c74543891
$ efibootmgr -v
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0004
Boot0004* ubuntu HD(1,GPT,587cf214-f068-4879-a833-9dffa5ec6e3d,0x800,0x100000)/File(\EFI\UBUNTU\SHIMX64.EFI)
$ sudo efibootmgr -c -L ubuntuNew -l \\EFI\\UBUNTU\\SHIMX64.EFI
$ efibootmgr -v
BootCurrent: 0004
Timeout: 1 seconds
BootOrder: 0000,0004
Boot0000* ubuntuNew HD(1,GPT,85b3a656-4886-4b37-b9c1-2acb0158587a,0xffff,0x3a3535ca9)/File(\EFI\UBUNTU\SHIMX64.EFI)
Boot0004* ubuntu HD(1,GPT,587cf214-f068-4879-a833-9dffa5ec6e3d,0x800,0x100000)/File(\EFI\UBUNTU\SHIMX64.EFI)
그래서 현재 폴더에 두 개의 파티션이 포함된 이유를 이해하지 못하지만 /boot
하나도 작동해야 한다고 가정합니까? 적어도 위에 링크된 질문에 대해 선택한 답변은 읽혀졌죠?
지금 무엇이 빠졌나요? /etc/fstab
?
$ cat /etc/fstab
...
UUID=606a1976-d1c2-4246-a256-a8afddb04f84 /boot ext2 defaults 0 2
...
UUID=FD0E-EECA /boot/efi vfat umask=0077 0 1
...
lsblk
이제 and (@oldfred 덕분에) 에 따르면 efibootmgr -v
새로운 첫 번째 부팅 옵션은 가 될 것이며 sda1
가 아닐 것입니다 nvme0n1p4
. sda1
그것은 외장 드라이브이고 확실히 그것에서 부팅하고 싶지 않습니다. 왜 기본값입니까? ?
- 새 파티션에서 부팅할 때 누락된 변경 사항은 무엇입니까?
- 재부팅하기 전에 fstab을 변경해야 합니까
UUID
?/boot
- 별도의 파티션이 필요합니까
/boot/efi
?
답변1
/boot
및 를 /boot/efi
별도의 파일 시스템으로 처리하는 것은 중복되지만 다음과 같습니다.
- 매우 오래된 BIOS 기반 시스템에는
/boot
BIOS 제한을 피하기 위해 별도의 파티션이 필요할 수 있습니다. - UEFI를 부팅하는 모든 시스템에는
/boot/efi
ESP 파티션 또는 이에 상응하는 파티션이 필요합니다. 펌웨어는 그곳에서 부트로더 파일을 찾을 것으로 예상하기 때문입니다. - 별도의 암호화되지 않은 암호화를 사용하면 GRUB이 이해하는 더 제한된 암호화 세트 대신 루트 파일 시스템에서 지원하는 모든 암호화 방법을
/boot
사용할 수 있습니다 .cryptsetup
최신 Debian/Ubuntu의 기본 파티셔닝에는 두 개의 별도 파티션이 있으므로 기본 구성은 가능한 가장 넓은 범위의 시스템을 포괄할 수 있습니다.
의견에서 oldfred가 언급했듯이 UEFI는 GPT 파티션 테이블에서 파티션의 고유 GUID가 사용할 ESP 파티션을 식별합니다. 이 GUID는 Linux에서 PARTUUID라고 합니다. lsblk -o +partuuid
표시할 것입니다.
귀하의 efibootmgr
주문은 거의 정확합니다. 올바른 디스크로 ubuntuNew 부팅 옵션을 생성하려면 다음을 사용해야 합니다:
sudo efibootmgr -c -d /dev/nvme0n1 -L ubuntuNew -l \\EFI\\UBUNTU\\SHIMX64.EFI
efibootmgr
PARTUUID 자체를 찾아서 자동으로 사용하여 새 시작 항목을 만듭니다. 디스크만 지정하면 됩니다(디스크에 EFI 시스템 파티션이 여러 개 없는 경우).
shimx64.efi
가 로드 되면 grubx64.efi
Debian/Ubuntu 기반 시스템에서 로 구성됩니다 grub.cfg
. grubx64.efi
파일에는 디렉토리가 포함된 파일 시스템의 파일 시스템 UUID를 식별하는 몇 줄만 포함됩니다 /boot
(별도의 파티션인지 루트 파일 시스템의 일반 파일 시스템인지 여부). . 목차). 따라서 Debian/Ubuntu 시스템은언제나/boot/grub/grub.cfg
시스템이 BIOS를 사용하든 UEFI를 사용하든 상관없이 "기본" GRUB 구성 파일이 있습니다. 이는 다양한 세대의 시스템이 많은 경우에 편리합니다.
/boot/grub2/grub.cfg
참고로 RedHat 7 및 8에는 /boot/efi/EFI/redhat/grub.cfg
UEFI 시스템뿐만 아니라 BIOS 스타일 시스템에도 실제 GRUB 구성이 있습니다.
하지만/boot
, 합계를 병합하려는 경우 /boot/efi
주의해야 할 몇 가지 사항이 있습니다.
- 주어진 부트로더 경로는
efibootmgr
ESP 파일 시스템의 루트를 기반으로 합니다. 처음에 경로는 로 시작하므로/boot/efi
Linux 관점에서는\\EFI\\UBUNTU\\SHIMX64.EFI
을 의미합니다./boot/efi/EFI/UBUNTU/SHIMX64.EFI
UBUNTU만 사용하는 경우/boot
UBUNTU 디렉터리를 한 수준 위로 이동하거나 부트로더 경로를\\EFI\\EFI\\UBUNTU\\SHIMX64.EFI
. /boot
GRUB이 거기에서 커널과 initramfs 파일을 로드할 수 있도록 이해할 수 있는 것이어야 합니다. Ubuntu용 GRUB의 UEFI 버전은 ext2와 vfat를 확실히 이해하므로 ext2와 vfat를 단일 vfat 파티션에/boot
병합해도 GRUB에는 문제가 없습니다 ./boot/efi
펌웨어는 해당 파티션에서 SHIMX64.EFI 및 GRUBX64.EFI를 읽어야 하고 일반 UEFI 펌웨어는 ext2를 인식하지 못하므로 ext2를 사용할 수 없습니다.- 부팅할 때
/boot
Linux 커널이 아닌 GRUB만 필요합니다./boot
이를 마운트할 수 없으며 시스템은 여전히 정상적으로 부팅됩니다. 하지만/boot
커널 업데이트가 제대로 진행될 수 있도록 마운트된 상태를 유지해야 합니다 . (또는 제거하여 숨기려면/etc/kernel/pre*.d/
커널 업데이트를 설치하기 전에 자동으로 설치하고/etc/kernel/post*.d
특정 커널 패키지 설치/제거가 완료된 후 다시 제거하는 스크립트를 추가할 수 있습니다.)
요구 사항이 무엇인지 확실히 파악하지 못한 경우 부트로더는 종종 "무섭고 위험한" 것으로 간주됩니다. 반면에 일반적으로 상당히 독립적이므로 부트로더 관련 문제는 일반적으로 수정하기가 그리 어렵지 않습니다. 외부 미디어에서 시스템을 부팅하는 첫 번째 장애물을 극복하고 나면 문제를 해결할 수 있습니다. 그것. 작동하지 않는 부트로더가 있는 시스템이 "완화"되었다고 말할 수는 없습니다. 단지 약간의 외부 도움이 필요할 뿐입니다.
답변2
부트로더는 현재 설치되어 있는 항목을 검색하므로 /boot/efi
파티션을 확대하지 않으려면 그대로 두고 아래 설명에 따라 파일을 약간만 변경하면 됩니다.
새 부팅 파티션 준비
ext2
원하는 크기로 새 파티션을 만듭니다 . 이 파티션에는 부팅 플래그가 필요하지 않습니다. efi 파티션이 진입점이며 이 새 파티션에 위임됩니다.- 새 파티션을 어딘가에 마운트하십시오.
/newBoot
예를 들어 - 예를 들어 다음을 사용하여 이전 부팅 파티션에서 파일을 복사합니다.
rsync --recursive --delete --archive /boot/ /newBoot/
- 내용을 삭제하려면
/newBoot/efi/
다음 폴더 하나만 있으면 됩니다rm -rf /newBoot/efi/EFI/
. 삭제하지 마세요newBoot/efi/
.efi
거기에 이전 폴더를 설치하고 싶습니다 .
efi
새 파티션을 사용하라고 지시
/newBoot
UUID를 알아보세요 :
$ lsblk -e 7 -o name,fstype,size,fsused,label,partlabel,mountpoint,uuid,partuuid
NAME FSTYPE SIZE FSUSED LABEL PARTLABEL MOUNTPOINT UUID PARTUUID
nvme0n1 931.5G
├─nvme0n1p1 vfat 512M 5.3M EFI System Partition /boot/efi FD0E-EECA 587cf214-f068-4879-a833-9dffa5ec6e3d
├─nvme0n1p2 ext2 488M 313.7M /boot 606a1976-d1c2-4246-a256-a8afddb04f84 2e10e277-560f-4f5e-abce-1dce5187a7f0
├─nvme0n1p3 crypto_LUKS 927.7G e7f674b8-4bec-4502-a1e5-0e93aa34786f 2fed2ecb-b548-479b-aa3f-7f1bbfb9981f
│ └─sda3_crypt LVM2_member 927.7G 9tx8Yv-XDCR-RmGf-fmXo-WiX2-SDpG-xH1si4
│ ├─ubuntu--gnome--vg-root ext4 911.6G 734.2G / 1cccfb0a-69da-4246-a071-52f882681418
│ └─ubuntu--gnome--vg-swap_1 swap 15.8G [SWAP] e3facfb8-db2e-426d-aef4-b6c81004fd6f
└─nvme0n1p4 ext2 1.5G newBoot newBoot 5aca79e7-b740-46d3-bc76-aa7e8b8b93da 9e8baf2f-2118-4042-9c47-7ffb824ada52
그에 따라 편집하여 /boot/efi/EFI/ubuntu/grub.cfg
이전 현재 UUID를 새 UUID로 바꿉니다.
# cat /boot/efi/EFI/ubuntu/grub.cfg
# search.fs_uuid 606a1976-d1c2-4246-a256-a8afddb04f84 root
search.fs_uuid 5aca79e7-b740-46d3-bc76-aa7e8b8b93da root
set prefix=($root)'/grub'
configfile $prefix/grub.cfg
정리하다
이제 시스템은 새 파티션에서 부팅되어야 하지만, /boot/
새 파티션에서 부팅한 후에는 이전 파티션이 됩니다. /etc/fstab
시스템이 해당 위치에서 발견된 모든 파일을 업데이트하도록 편집하십시오 .
# UUID=606a1976-d1c2-4246-a256-a8afddb04f84 /boot ext2 defaults 0 2
UUID=5aca79e7-b740-46d3-bc76-aa7e8b8b93da /boot ext2 defaults 0 2
/boot/efi
다음 줄은 /etc/fstab
그대로 유지됩니다.
UUID=FD0E-EECA /boot/efi vfat umask=0077 0 1