최근 USB에서 Ubuntu 18.04를 설치했습니다. 제가 한 모든 일은 14에서 16으로, 16에서 17로 업그레이드할 때와 동일했고 지금까지 매번 작동합니다. USB 이미지에서 18을 실행할 때 "Erase ubuntu 17 and install ubuntu 18"을 선택했습니다. 내 문제는 다음과 같습니다. Grub2가 로드되지만 잘못된 파티션에서 잘못된 구성 파일을 사용하는 것 같습니다. 우분투를 실행하려면 루트 디렉토리를 설정하고 루트 디렉토리가 /dev/sda8있는 올바른 파일과 파일을 설정 해야 합니다 linux(사용하려는 파일이 있는 곳이기도 함). 위의 파일이 BIOS 파티션을 가리키는 것을 볼 수 있습니다. 내 질문은 우분투(위치)에서 업데이트한 구성 파일을 grub에서 사용하도록 어떻게 해야 합니까? 이걸 바꾸면 뭔가 심각하게 깨질까 걱정되는데, 그렇지 않다면 cfg 파일의 내용을 사용하는 것으로 충분할까요?initrd/dev/sda8/bootgrub.cfggrub.cfgdev/sda1/EFI/ubuntu/grub.cfg/dev/sda5/dev/sda8/boot/dev/sda1sda8
fdisk -l참조용 터미널 출력은 다음과 같습니다.
Device Start End Sectors Size Type
/dev/sda1 2048 206847 204800 100M EFI System
/dev/sda2 206848 468991 262144 128M Microsoft reserved
/dev/sda3 468992 816990982 816521991 389.4G Microsoft basic data
/dev/sda4 816992256 818726911 1734656 847M Windows recovery environment
/dev/sda5 818726912 818728959 2048 1M BIOS boot
/dev/sda6 935913472 939819007 3905536 1.9G Linux swap
/dev/sda7 942651392 976773119 34121728 16.3G Microsoft basic data
/dev/sda8 818728960 935913471 117184512 55.9G Linux filesystem
파일의 /dev/sda1/EFI/ubuntu/grub.cfg내용은 다음과 같습니다. (hd0,5)이는 BIOS 파티션입니다.
search.fs_uuid 7e076866-97b4-4d3c-b864-491137212645 root hd0,gpt5
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg
답변1
앞으로 이 문제를 발견하고 사용하시는 분들을 위해클라우드 초기화서버(예: MAAS를 통한 전용 서버 또는 가상화 소프트웨어 또는 "클라우드" 공급자를 통한 가상 서버(VPS))에 매우 간단한 수정 사항이 있습니다.
이 문제가 어떻게 발생했습니까?
가상 머신 중 하나의 rootfs를 원래 루트 파티션에서 새 디스크로 마이그레이션했습니다. update-grub원래 rootfs의 PARTUUID를 계속 사용한다는 것을 알았습니다. 우선 chroot에서 실행하는데 관련된 문제인 줄 알고 수동으로 UUID를 수정 /boot/grub/grub.cfg하고 재부팅을 했습니다.
새 rootfs 파티션으로 부팅한 후 update-grub새 디스크에서 실행 중인 실제 시스템에서 실행하면 이제 올바른 UUID와 작동하기를 바라면서 를 실행했습니다. 불행히도 작동하지 않았습니다.
인터넷을 검색하여 StackExchange 질문을 찾았는데, 한 답변에서는 /boot/efi역할을 할 수 있는 잠재적인 추가 구성 파일이 있는지 확인하는 것이 좋습니다. 물론, /boot/efi/boot/grub/grub.cfg하드코딩된 FS UUID가 포함되어 있는 것으로 나타났습니다.
root@host ~ # cat /boot/efi/boot/grub/grub.cfg
# CLOUD_IMG: This file was created/modified by the Cloud Image build process
search.fs_uuid 897a358a-acba-4b07-867c-33d1ca3b28dc root hd0,gpt1
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg
이를 수정했지만 .NET 에서 잘못된 PARTUUID 설정이 fs_uuid여전히 완전히 수정되지 않았습니다 .update-grub/boot/grub/grub.cfg
그러나 결국 명령 로그에서 의심스러운 구성 파일을 발견했습니다 update-grub.
root@host ~ # update-grub
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/40-force-partuuid.cfg'
Sourcing file `/etc/default/grub.d/50-cloudimg-settings.cfg'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.4.0-71-generic
Found initrd image: /boot/initrd.img-5.4.0-71-generic
Found linux image: /boot/vmlinuz-5.4.0-24-generic
Found initrd image: /boot/initrd.img-5.4.0-24-generic
done
문제에 대한 최종 수정
흠... Sourcing file '/etc/default/grub.d/40-force-partuuid.cfg'- 강제로 파트투이드? 범인인 것 같습니다.
root@host ~ # cat /etc/default/grub.d/40-force-partuuid.cfg
GRUB_FORCE_PARTUUID=897a358a-acba-4b07-867c-33d1ca3b28dc
물론, 비록 잘못되었지만 GRUB 구성에서 지속적으로 설정되는 파티션 UUID가 포함되어 있었습니다.
GRUB_FORCE_PARTUUID내 rootfs 파티션의 PARTUUID로 변경 하고 다시 실행한 후 update-grub마침내 grub.cfg에서 올바른 PARTUUID를 사용했습니다. :)
일반화하다
시스템에서 이 문제를 해결하려면 먼저 루트 파일 시스템(및/또는 별도의 파티션이 있는 경우 부팅 파티션)의 cloud-init파일 시스템 UUID( ) 및 파티션 UUID()를 기록해 두어야 합니다 .UUID=PARTUUID=blkid
root@host ~ # blkid
/dev/sda1: UUID="wcrpSm-QCZu-VN3A-I503-sQqQ-5xfw-76r5bd" TYPE="LVM2_member" PARTUUID="bec389fc-4274-5245-babb-7d90674f1662"
/dev/sdb2: LABEL_FATBOOT="UEFI" LABEL="UEFI" UUID="072E-C819" TYPE="vfat" PARTUUID="78730ead-03d3-e14d-b4fe-ee0abf4f0ad5"
/dev/sdb3: UUID="6cea6786-510a-4fba-871b-7811b63b3453" TYPE="xfs" PARTUUID="530c353b-0be8-e34e-affb-bd5c2332abc7"
제 경우에는 /dev/sdb3rootfs와 부팅 파티션이었습니다.
이제 /boot/efi/boot/grub/grub.cfg원하는 편집기(예: nano또는 vim)로 열고 UUID 부분을 fs_uuid XXXX-XXXX파일 시스템 UUID로 바꿉니다. 예를 들어 제 경우에는6cea6786-510a-4fba-871b-7811b63b3453
다음으로 /etc/default/grub.d/40-force-partuuid.cfgUUID 값을 열고 이를 GRUB_FORCE_PARTUUID=PARTITION UUID(PARTUUID)로 바꿉니다. 제 경우에는 530c353b-0be8-e34e-affb-bd5c2332abc7.
마지막으로 update-grub-를 실행하고 /boot/grub/grub.cfg이제 올바른 FS UUID + PARTUUID를 사용하는지 확인합니다.
이제 잘못된 UUID로 인해 initramfs에 갇히지 않고 GRUB 구성을 업데이트하고 재부팅할 수 있습니다. :)
답변2
댓글에서 언급했듯이 grub.cfg"BIOS 부팅" 파티션의 목적과 여러 파일이 서로 다른 파티션에 분산되어 있는 이유가 무엇인지 혼란스럽습니다. 제 생각엔 파일 하나면 충분 grub.cfg하고 Linux와 Windows를 부팅할 수 있어야 합니다.
또 다른 사항은 업데이트하려는 라이브 USB가 EFI 모드에서 생성되고 부팅되었는지 절대적으로 확인하는 것입니다.아니요레거시 BIOS 부팅 모드. 이를 확인하는 쉬운 방법은 USB로 부팅하고 /sys/firmware/efi 파일이 있는지 확인하는 것입니다. 그렇지 않은 경우 EFI 모드로 부팅되지 않습니다.
저는 Windows/Linux와 매우 유사한 이중 부팅 시스템을 가지고 있습니다. 확인해 보니 grub.cfgLinux 시스템 루트 파티션의 /boot/grub 폴더에 파일이 하나만 있는 것으로 나타났습니다 . EFI 시스템 파티션은 부팅 중에 /boot/efi에 마운트됩니다.
EFI 파티션 수정에 대한 질문 과 관련하여 grub.cfg그렇게 해도 아무런 해가 없어야 합니다. 실제로 grub.cfg어떤 이유로든 여러 파일이 필요한 경우 자동 업데이트 도구가 올바르게 처리하기를 바라기보다는 파일을 직접 유지 관리하는 것이 좋습니다. 먼저 자동으로 생성된 파일을 백업하겠습니다. 파일을 수정하기 전에 grub 명령줄에서 부팅 명령을 테스트할 수도 있습니다. 뭔가를 엉망으로 만들면 일어날 수 있는 최악의 상황은 GRUB 명령 프롬프트에 들어가 수동으로 부팅 명령을 입력해야 하는 것입니다. 이 작업을 수행하는 방법을 모르는 경우 라이브 USB를 통해 부팅하고 파일을 복구/복원해야 할 수도 있습니다.
또 다른 점은 수동으로 변경하면 grub.cfg다음에 GRUB가 자동 업데이트를 수행할 때 덮어쓰여질 수 있다는 것입니다(이 경우 update-grub commandLinux 배포판에서는 비활성화할 것입니다).
답변3
도움을 주신 @Time4Tea에게 감사드립니다. 아주 아주 간단한 해결책이 있다는 것이 밝혀졌습니다. aka grub.cfg에 있던 이전에 게시한 파일은 접두어를 에서 로 변경했으며 , 제가 만든 파일이 있는 곳 이 바로 그 위치입니다. nano로 덮어 쓰고 우분투에서 설치하여 저장했습니다 (grub 터미널을 사용하여 우분투로 수동 부팅 한 후). 다음은 작은 변경 사항이 포함된 새 파일입니다.(hd0,1)/EFI/ubuntu/grub.cfg/dev/sda1/EFI/ubuntu/grub.cfg(hd0,gpt5)(hd0,8)grub.cfgsudo update-grub2/dev/sda1/
search.fs_uuid 7e076866-97b4-4d3c-b864-491137212645 root hd0,gpt5
set prefix=(hd0,8)'/boot/grub'
configfile $prefix/grub.cfg
답변4
"GRUB_FORCE_PARTUUID 시도 initrdless 부팅" 오류가 발생하여 Virt-manager에서 실행 중인 Ubuntu 클라우드 이미지를 가져오려고 오랜 검색 끝에 여기까지 온 경우 여기를 참조하세요.https://askubuntu.com/questions/1375589/what-are-the- Different-versions-available-as-ubuntu-cloud-images
위에서 언급한 대로 /etc/default/grub.d/40-force-partuuid.cfg 파일에서 이 줄을 주석 처리하고 다른 두 파일을 이동하는 것은 update-grub.