나는 grub이 무엇이든 "검색"하는 것을 원하지 않습니다. 나는 내 루트 파일 시스템이 어디에 있는지 알고 있으며 항상 거기에 있습니다(/dev/sda1). 그리고 grub이 다른 루트를 찾기 위해 연결된 모든 드라이브를 살펴보는 것을 원하지 않습니다.잘못된하나).
커널 로드 라인에서 UUID 사용을 비활성화할 수 있었습니다.
GRUB_DISABLE_LINUX_UUID=true
에서는 /etc/default/grub, 그러나 결과는 다음과 같습니다./boot/grub/grub.cfg 아직다음과 같은 줄이 있습니다.
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 3f8c2b36-5d8f-40ac-9b63-7d1445805925
나는 이런 것을 원하지 않습니다. 검색되는 걸 원하지 않아요별말씀을요. 나는 "os-probing"을 더 껐습니다.
GRUB_DISABLE_OS_PROBER=true
search이로 인해 연결된 다른 디스크에서 내 시스템의 백업 복사본을 찾을 수 없지만 사용하지 말라고 한 UUID는 물론이고 grub에서 해당 명령의 인스턴스가 실행되는 것도 원하지 않습니다 .
나는 땅벌레를 싫어합니다. root=/dev/sda1전체 시스템을 조사할 필요 없이 내 컴퓨터가 부팅되어 존재하지 않을 수도 있는 UUID를 찾길 원합니다 . LILO를 부팅한 1999년과 같습니다.
나는 실제로 할 것이다사용LILO나 syslinux와 같은 것(Ubuntu가 아니라면 grub을 사용하므로 커널 업데이트를 계속 유지하려면 거의 강제로 grub을 사용해야 합니다). 나는 단지 그것이 인간이 가능한 가장 간단한 구성이기를 원할 뿐입니다. (이렇게 하면 여전히 grub.cfg 200줄이 생성된다는 것을 알지만, 뭐 그렇죠).
답변1
grub-mkconfig작동 방식은 다음과 같습니다 . 검색한 각 코어에 대해 GRUB 메뉴 항목을 자동으로 생성합니다. 그러나 원하는 것이 무엇인지, 무엇을 하고 있는지 알고 있다면 사용할 필요가 없습니다.간단한 구성전혀 그렇지 않습니다. 왜냐하면 당신은 grub.cfg당신의 것을 쓸 수 있기 때문입니다.
grub-mkconfig실제로 몇 가지 제한 사항이 있습니다. 편집 하거나 생성하여/etc/grub.d/40_custom목록 끝에 추가 사용자 정의 메뉴 항목을 추가 할 수 있지만/boot/grub/custom.cfg메뉴 항목의 순서를 변경하거나 제목을 변경하려면 메뉴에 저장된 메뉴 항목을 일부 수정해야 할 수 있습니다/etc/grub.d/. 미래. 동시에, 이런 식으로 쓰는 것이 더 쉬울 것이라고 생각하는 사람들은grub.cfg그냥 쓰는 것이 더 쉬울 것이라고 생각하는 사람들에게 그렇게 하도록 격려합니다. 전원 켜짐, 그리고쉘형 스크립트), 배포판에서 제공하는 시스템 자동 실행 grub-mkconfig를 비활성화합니다.
여기서는 원하는 만큼 간단한 설정이 포함된 하나의 메뉴 항목(비활성화된 메뉴)만 가질 수 있습니다. 여기에서 이 커널을 부팅하고 싶다고 말할 수 있습니다. 그게 전부입니다.
한 줄은 menuentry { }200줄이 아니라 5줄이 될 수 있습니다.
기억하다:
- 먼저 사용자 정의 메뉴 항목을 사용자 정의 메뉴 항목에 추가하여 테스트하십시오.
- 시스템에서 이를 비활성화하면 커널을 업데이트할 때마다 수동으로 업데이트해야 합니다
grub-mkconfig.grub.cfg
답변2
루트 파일 시스템 정보는 실제로 /dev/sda1커널 부팅 인수 string 의 일부로 root=/dev/sda1Linux 커널에 전달되는 것 외에 GRUB에 전혀 사용되지 않습니다.
GRUB가 알아야 할 것은 시스템 펌웨어 호출에서 디스크에 사용할 식별자, GRUB 코어 이미지에 포함되지 않은 GRUB 모듈, 커널 및 자체 구성 파일을 로드할 때 initramfs 파일입니다.
클래식 BIOS 기반 시스템에서 이 식별자의 기본 형식은 16진수 바이트입니다. 0x80은 BIOS가 감지한 첫 번째 디스크를 나타내고, 0x81은 두 번째 디스크를 나타냅니다. GRUB는 이를 자체 식별자( (hd0)0x80, (hd1)0x81 및 곧)에 매핑합니다.
UEFI 시스템에서는 UEFI 셸을 실행하고 해당 map명령을 사용하여 UEFI 파티션 식별자를 볼 수 있습니다(펌웨어가 감지하는 순서대로). UEFI 인식 파일 시스템이 있는 첫 번째 파티션은 fs0:, 두 번째 파티션은 fs1:, 등등 등등. 전체 디스크 및 원시 파티션 액세스는 예를 들어 blk0:GRUB의 UEFI 버전을 통해 이루어지며 콘텐츠가 로드될 디스크 또는 파티션을 식별하려면 이러한 것(또는 기계에서 읽을 수 있는 UEFI API 등가물)을 사용해야 합니다. GRUB는 주로 자체 파일 시스템 드라이버를 사용하므로 blkN:펌웨어 식별자를 (hdN).
search명령
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1
이는 명령에 사용할 수 있는 최상의 정보(특히 BIOS 기반 시스템의 경우 최선의 추측일 수 있음)를 기반으로 쓰기 후 하드웨어 구성이 승리한다고 가정할 때 grub-mkconfig후속 명령에 필요한 파일이 포함된 파티션이 (hd0,msdos1)부팅 시에 있을 가능성이 가장 높다는 것을 의미합니다. 구성 파일을 더 이상 변경하지 마십시오.
--set=root이 검색 명령의 목적은 rootGRUB의 변수가 이 검색의 결과인 모든 파티션을 가리키도록 설정하는 것입니다.
search따라서 이 명령 이후에 필요한 파일이 디스크의 첫 번째 파티션에 있고 펌웨어가 항상 이를 첫 번째 디스크로 감지한다는 것을 알고 있는 경우 search이 명령을 다음으로 바꿀 수 있습니다.
set root=(hd0,msdos1)
참고: GRUB root변수 설정은 Linux 커널의 루트 파일 시스템과 전혀 관련이 없습니다. 유일한 목적은 경로 이름을 사용하여 디스크의 파일을 참조하는 후속 GRUB 명령에 대한 루트 경로(디스크/파티션 포함)를 정의하는 것입니다.
클래식 BIOS 스타일 부팅 프로세스에서 합리적으로 확신할 수 있는 유일한 것은 BIOS 설정에서 모든 디스크가 부팅 가능으로 선택되었다는 것입니다(BIOS 설정에 여러 디스크가 나열되어 있는 경우 BIOS는 현재 부팅을 시도하고 있습니다). 그것에서) 부팅 순서)는 BIOS 디스크 0x80...으로 액세스할 수 있으므로 GRUB의 경우 (hd0).
BTW, Debian 및 Ubuntu는 단순히 기본 부트 로더이기 때문에 GRUB를 "사용"합니다. 원한다면 GRUB를 제거하고 즐겨 사용하는 부트로더로 교체할 수 있습니다. 유일한 요구 사항은 적절한 디렉터리에서 구성을 업데이트하기 위해 자체 스크립트를 작성하는 것입니다 /etc/kernel/. GRUB의 경우 이러한 스크립트 /etc/kernel/postinst.d/zz-update-grub는 /etc/kernel/postrm.d/zz-update-grub.이는 패키지 관리 시스템과 GRUB 구성 간의 유일한 연결입니다.
새로운 커널 패키지가 설치되거나 제거될 때마다 해당 디렉터리의 모든 스크립트가 실행됩니다. 및 디렉터리 lilo에서 실행되는 스크립트를 배치하면 Ubuntu 업데이트를 통해 기본적으로 GRUB에서와 마찬가지로 LILO를 원활하게 사용할 수 있습니다.postinst.dpreinst.d
2012년에는 당시 GRUB에 문제를 일으키는 펌웨어 버그가 있는 초기 UEFI 구현 시스템이 있었습니다. rEFInd가 이 버그를 피할 수 있다는 사실을 발견하고 이를 사용하여 Debian의 GRUB를 rEFInd로 교체했습니다. 펌웨어가 수정된 버전으로 업데이트되고 GRUB이 UEFI 버그에 대한 많은 해결 방법을 받았음에도 불구하고 당시에 작성한 간단한 스크립트를 백업 부트로더로 8년 동안 실행해 왔습니다.
최신 버전의 데비안은 실제로 rEFInd를 패키지하고 패키지에 유사한 스크립트를 포함합니다. 배포판에 포함된 다른 부트로더 패키지의 경우에도 마찬가지입니다. Ubuntu에 LILO 또는 Syslinux용 패키지가 있는 경우 이를 설치해 보고 패키지에 커널 postinstall/postrm 스크립트가 포함되어 있는지 확인할 수 있습니다. 그렇다면 "그냥 작동한다"는 것을 알 수 있을 것입니다.
디스크나 파일 시스템을 복제하는 습관이 있는 경우 새 복제본이 원래 복제본과 함께 시스템에 표시되도록 하려면 해당 복제본의 UUID를 변경하는 것이 좋습니다.이 문제이에 대한 많은 제안이 있습니다.
LVM의 SAN 수준 스냅샷이 있는 엔터프라이즈 환경에서는~ 해야 하다클론을 생성하자마자 다시 통합하십시오. 그렇지 않으면 클론과 원본이 동일한 시스템(한때 존재하고 문제를 해결했으며 vgimportclone친구였던 시스템)에 나타나면 고통스러운 세계에 빠지게 될 것입니다. 다른 유형의 환경에서는 여전히 좋은 생각일 수 있습니다.