드라이브 / 파티션 번호가 여전히 사용되는 이유는 무엇입니까?

여러 번, 특히 부트 로더를 망칠 때 숫자 드라이브와 파티션 번호가 사용됩니다. 내 예를 들어,에서 /boot/grub/grub.cfg내가 볼 set root='hd0,gpt2', 내 UEFI 부팅 항목은 종종 드라이브 / 파티션 번호를 참조, 그리고 부트 로더가 우려되는 경우 거의 모든 상황에서 돌발 것으로 보인다.

이제 우리는 UUID와 PARTUUID를 가지고 있습니다. 이러한 방식으로 파티션을 처리하는 것은 믿을 수 없을 정도로 불안정합니다 (아 파크, 드라이브가 항상 같은 순서로 마운트되는 것은 보장되지 않습니다.

따라서 내 질문은 두 가지입니다.

1. 위에서 설명한 것처럼이 주소 지정 체계가 불안정합니까? 이 구성표가 예상보다 훨씬 안정적이라는 것을 의미하는 표준이 누락되었거나이 주소 지정 구성표는 드라이브가 단순히 인식 된 결과로 시스템을 부팅 할 수 없게합니다 (적어도 부팅 항목을 수정할 때까지). 순서가 다르거 나 마더 보드의 다른 슬롯에 연결하셨습니까?

2. 위의 질문에 대한 답변이 예인 경우,이 주소 지정 체계가 왜 계속 사용됩니까? 모든 것이 훨씬 더 안정적이고 일관되게 UUID 또는 PARTUUID를 사용하지 않습니까?

일반 번호 체계는 최근 시스템에서 실제로 사용되지 않습니다 ( "최근"이 우분투 9 이상이면 다른 배포판도 그 시대에 적응했을 수 있습니다).
루트 파티션이 일반 번호 체계로 설정되어 있는지 확인하십시오. 그러나 이것은 기본 또는 폴백 설정일 뿐이며 일반적으로 다음과 같은 다음 명령으로 대체됩니다.

search --no-floppy --fs-uuid --set=root 74686973-6973-616e-6578-616d706c650a

파일 시스템의 UUID를 기반으로 루트 파티션을 선택합니다.

실제로 일반 번호 매기기 체계는 일반적으로 안정적입니다 (하드웨어 변경이없는 한). 내가 예측할 수없는 번호 매기기를 관찰 한 유일한 사례는 USB 드라이브가 많은 시스템으로 선착순 서빙 패턴을 기반으로 열거 된 다음 IDE 드라이브로 에뮬레이트되었습니다. 이러한 프로세스 중 어느 것도 본질적으로 혼란스럽지 않으므로 특정 시스템 BIOS 구현에서 문제가 있다고 가정합니다.

참고 :이 컨텍스트에서 "루트 파티션"은 부팅 할 파티션을 의미하며 "루트 일명 / 파일 시스템"을 포함하는 파티션과 다를 수 있습니다.

엄밀히 말하면 UUID는 전혀 다루지 않습니다 .

주소 지정은 매우 간단합니다. 드라이브 X 섹터 Y를 읽거나 그렇지 않으면 간단합니다. 메모리 주소 Z 또는 기타를 읽습니다. 어드레싱은 간단하고 빠르며 해석의 여지가 많지 않으며 어디에나 있습니다.

UUID가 해결되지 않습니다. 대신 검색, 찾기, 때로는 장치가 나타날 때까지 기다림 및 파일 시스템 이해 (★)입니다. 또한 장치 수에 따라 시간이 오래 걸릴 수 있습니다. 그리고 일단 발견되면, 정규 주소로 돌아가는 것입니다.

GRUB에서는 이것을 search(★★) 라고하며 GRUB이 이미 날개를 확장 한 경우에만 사용할 수 있습니다 (검색은 모듈이며, 지원하는 모든 파일 시스템과 마찬가지로 코어를로드 한 후에 만 ​​사용 가능합니다). 리눅스에서, 그것은이라고합니다 (예를 들어)입니다 findfs, findfs는 파일 시스템 또는 파티션을 찾는 시스템의 블록 장치를 검색합니다 .

모든 블록 장치를 거치고 대기 모드에서 깨어나 데이터를 읽으며 UUID가 고유하지 않은 경우 ( dd사고 후 등) 결과가 무작위 로 표시되거나 UUID가 변경된 경우 결과가 나타나지 않을 수 있습니다. UUID도 구성 오류가 발생하기 쉽습니다.

일반적으로 UUID는 훌륭합니다. 물론 Linux에서 드라이브 순서가 무작위이기 때문에 기존 주소 지정이 실패 할 경우 특히 사용 가능한 모든 곳에서 UUID를 사용해야합니다. 그러나 주소 지정이 단순한 주소 지정보다 복잡하다는 점을 이해하십시오. 특히 부트 로더의 초기 단계에서는 아직 옵션이 아닐 수도 있습니다. 어드레싱이 먼저, 날개가 커지면 나중에 나옵니다.

부트 로더의 경우, 노력을 기울일 필요는 없습니다 (모든 부트 로더가 GRUB과 같은 광범위한 파일 시스템을 지원하지는 않습니다). 경우 hd0로 보장됩니다 당신이 임의 드라이브 순서 문제를 배제 할 수있는 경우 상황 때문 "우리의 오프 부팅 디스크가"(BIOS가 제공) 등, 다른 파티션의 잠재적으로 거대한 목록을 통과 할 필요가 없을 수도 있습니다 UUID를 검색하십시오.

당신이 당신의 구성에 대해 hd0,gpt2당신이 원하는 것, 그것이 되어야한다고 말할만큼 충분히 확신한다면 , 그렇지 않다면 그렇게 사용하는 데 아무런 문제가 없습니다. 때로는 단순하고 간단한 주소 지정이 제대로 작동하는 경우가 있습니다.

(★) 이전 에 LABEL 에 대해 이것을 설명했습니다 ...

레이블에 대한 일반적인 표준은 없으며 모두 손 으로 짜여져 있습니다 (예 : util-linux의 수퍼 블록 형식 구현 참조) . 내일 새 파일 시스템을 만들면 레이블이 있어도 지원이 추가 될 때까지 표시되지 않습니다.

... 그리고 UUID도 마찬가지입니다.

(★★) 실제로 GRUB 's search에는 --hint옵션이 있습니다. 이제 소스 코드를 확인하지 않았으며 설명서에 문서화되어 있지 않지만 이러한 옵션은 두 가지 이점을 모두 제공합니다. 힌트는 파티션을 먼저 확인하도록search 지시 하고 UUID가 예상대로 일치하면 최소한의 노력으로 장치를 식별했으며 일치하지 않는 경우 여전히 작동을 유지하기 위해 완전한 검색으로 돌아갑니다. .

또한 이전에 발견 된 UUID는 캐시되는 경향이 있으므로 모든 장치를 반복해서 반복 할 필요가 없으며 찾고있는 UUID가 실제로 어딘가에 존재하는 경우에도 훌륭하게 작동합니다. 우선 캐시에 넣습니다.

라벨도 잊지 마십시오. 그것들은 UUID만큼 독특하지는 않지만 훨씬 유익하며 fstab을 사람이 읽을 수있게 만듭니다. 데스크탑 또는 소규모 회사 인 경우 즉, 수십에서 수십 개의 드라이브를 관리하는 경우 UUID 레이블을 선호 할 수 있습니다.

귀하의 질문에 대한 @frostschutz의 탁월한 답변 을 무시 하면서, "클래식"장치 링크 주소 지정을 선호 할 수있는 한 가지 시나리오는 VM 설정, 특히 VM-for-hire (약칭, 혼란스럽고 "IaaS") 클라우드에서 VM 설정입니다. Ubunzima 04.18 이미지 를 사용자 정의하려고한다고 가정하십시오 . 2 개의 디스크로 (throwaway) VM을 생성합니다. 하나는 (throwaway) 시스템 드라이브이고 다른 하나는 마운트하고 사용자 정의하는 것입니다. 아마도 새 디스크에서 새로운 그럽을 제거하려면 UEFI 부팅 파티션도 마운트해야합니다. 아래에서 대상 파티션에 대한 마운트 지점을 선택했다고 가정하면 /mnt원하는 마운트 테이블은 다음과 같습니다.

/dev/sda1    /
/dev/sda9    /boot/efi
/dev/sdb1    /mnt/root
/dev/sdb9    /mnt/efi

따라서 제공자가 제공 한 기존 클라우드 지원 이미지에서 동일한 2 개의 드라이브를 만들어 새 VM에 연결 한 후 부팅합니다. 당연히,

• 우리의 가상 우분 지마 04.18도 예외가 아닌 모든 최신 OS 배포판 은 UUID라는 이름의 마운트에 의존합니다.
• 동일한 이미지에서 롤아웃 된 모든 하드 드라이브는 동일한 UUID를 갖습니다. UUID는 고유하기 때문에 무엇이 잘못 될 수 있습니까?

당신은 이미이 모든 것이 진행되고 있음을 알았습니다.

이 frankencontraption이 처음 부팅 sda9될 때 EFI 부팅 파티션으로 선택했지만 Linux는 sdb1루트 FS 로 다시 마운트하기로 결정했습니다 .

/dev/sda1    /mnt/root
/dev/sdb1    /
/dev/sda9    /boot/efi
/dev/sdb9    /mnt/efi

그리고 내 롤아웃 스크립트는 그에 대한 준비가되어 있지 않았기 때문에, 프랑켄 빌드 동안 로그에 단일 도구로 불평하지 않고 결국 부팅 할 수없는 멍청한 이미지가 생겼습니다!

물론 마운트 테이블을 로그에 인쇄했습니다. 그리고 물론 혼란 업의 중간 임의 사이에있는 장치가 장착 된 순서대로 (8) 인쇄 마운트를 장착하기 때문에 그것이 내가 바로 그것을 발견하지 않았다 놀라운 일이 아니다 그래서, 발견하기가 매우 어렵다. 그리고 동일한 스크립트 (그러나 다른 이미지의 디스크로)는 이전에 15 세의 Glenfiddich처럼 부드럽게 작동했다고 상상해보십시오. 문제를 파악하기 위해 통나무 위로 머리카락을 당기는 데 몇 시간이 걸 렸는지 추측하십니까?

데스크탑 PC에서 라우터에 내장 된 Linux, Android 폰, 클라우드 데이터 센터에 이르기까지 모든 상황에 적합한 강력하고 빠른 규칙은 없습니다. SO 답변은 객관적이어야하며 내 경험이나 선호도는 아닙니다. 따라서 파티션을 식별하는 여러 가지 방법 중에서 선택할 때 논리적 추론의 예를 보여 드리겠습니다.

• 이유가 없다면 혼자 두십시오 . UUID는 대부분의 최신 배포판의 기본값입니다. 두 번째 드라이브를 추가하는 경우 시도하고 결정하십시오. 당신도 알 필요가 없을 것입니다. 시스템이 여전히 부팅되어 있고 새 장치를보고 파티션 할 수있는 경우, 장치를 포맷하고 fstab에 추가하십시오 (UUID, LABEL 또는 /dev링크). 동일한 고려 사항이 적용됩니다. 여분의 드라이브를 연결 한 후 시스템 부팅을 거부 한 경우에만 문제가 발생합니다 (UEFI BIOS에서 부팅 순서를 변경하는 것이 가장 빠른 방법 일 수 있습니다).

  실제로, 어떤 SATA 커넥터가 자신의 데스크탑에있는 어떤 드라이브로 연결되는지 표시하는 것이 가장 빠르고 쉬운 솔루션 일 수 있지만 시스템 부팅 방법을 변경하고 부팅 오류 가능성을 복구하는 것은 최악의 시간 고비입니다. 그러나 당신은 여분의 드라이브에 던지고 행운의 한계를 테스트하고 있는지 초기 부트 드라이브 모두로 GRUB으로 볼 수 있습니다하지 않는 적어도 당신을 귀찮게 가치가 문제가 아니라고 생각 (50 개) 프로그래머를 관리하는 경우 hd0와 로 시스템 sda.

• 데스크탑 또는 3 개의 작은 드라이브 또는 파티션 (소규모의 환경을“스타트 업 사무실”이라고 부르는 소프트웨어 엔지니어들로 구성된 집안의 거실)에서 자신의 드라이브와 파티션을 관리하기위한 레이블 . 다른 사람의 컴퓨터에서 실제 드라이브를 꺼내면 레이블을 일관되게 사용하면 드라이브의 출처를 알 수 있습니다.

  lsblk (8) 말한다면 LABEL=bubba-boot, 당신은 그것을 호출 시스템에서 가져온되었습니다 알 부바 ; 게다가, 바바 부팅 보다 훨씬 쉽게 내 혀를 통해 롤 6864c4ea --f9b9-46db b875-4d7fc2981007 , 내 버릇 취향에 명백히 jawbreaker입니다. 레이블이 고유한지 확인하면 이제 사용자에게 변화가 있지만 그 대가로 얻는 것은 레이블의 의미입니다.

• /dev동일한 이미지가 생성되는 상대적으로 짧은 수명의 유지 보수가 적은 VM 대대를 명령 할 때 링크 기반 이름 지정. 모든 UUID가 UU 약속을 지키는 주간 임금을 걸지 않을 것입니다. 모든 제정신 VM 서비스는 그것을 할 수 Vyper-H를 자신의 물리적 서버 나에 쿠겔 클라우드 , 또는 아무것도 부팅 드라이브를 호출하지 않을 것이다 sde, 두 번째와 유일하게 다른 하나는 sdc². 반면 물리적 시스템에서는 SATA 케이블을 창의적으로 연결하여 동일한 구성을 쉽게 얻을 수 있습니다.

  지금은 멀었지만이 시나리오에서는 소위 "일관된"이더넷 인터페이스 이름 지정과 동일한 경로를 사용합니다. VM에서이를 비활성화합니다. 잘못 이해하지 마십시오. PCI 슬롯 4에 넣은 NIC가 보이지 않는 동안 또는 자신이 보이지 않는 동안 갑자기 슬롯 5로 점프하지 않는 한 이름은 실제로 일관됩니다. 부끄러운 일이 없습니다). 불행하게도,“VM 대대”환경에서는 실제로 그렇습니다. 이 경우, 반 직관적 eth0이고 더 이상 일치enp0s4f6. VM 프로 바이더는 항상 가상 NIC 번호 1을 PCI 버스 0의 슬롯 4에 넣지 않겠다고 약속하지 않았으며 언급 된 3 개의 엔터티 중 어느 것도 실제로 실제가 아닙니다. 일반적으로 virtio 제품군과 동일한 드라이버 모듈을 가지고 있다는 점을 고려할 때 두 번째 인터페이스보다 먼저 첫 번째 인터페이스에 의존합니다 (첫 번째 NIC가 항상 그렇지 않은 경우 eth0에도 동일한 note²이 여전히 적용됨).

  ---

¹ 물론입니다. 이 사업이 너무 오래 남아서 남은 것이 없었습니다.
² 만약 그렇다면 , 제공자 나 VM 하이퍼 바이저 소프트웨어를 바꾸는 소리를 피하는 것이 좋습니다.

두 가지 방식을 혼합하여 대부분의 Linux 배포판과 일치시킬 수 있습니다.

결과는 사용 사례에 따라 바람직하거나 바람직하지 않을 수 있습니다. 예를 들어 구성 파일을 수정하지 않고 (가상 하드웨어 또는 실제 하드웨어) 드라이브를 핫 교체하는 경우 이전 방식을 선호하고 심지어 udev 스타일 지속성 해킹을 비활성화 할 수도 있습니다. 원했다.

두 번째 질문에 대한 답은 "이 주소 지정 체계가 계속 사용되는 이유는 무엇입니까?"라는 것 같습니다. 예, GPT 파티션 디스크에서 UUID 만 사용할 수 있습니다. 의 /dev/xxx이름 대신 UUID를 사용할 수 있습니다 /etc/fstab. 이제 Discoverable Partitions Specification 이 발견 되었으므로 더 이상 UUID를 지정하지 않아도 파티션 유형으로 디스크를 파티션하기 만하면 파티션이 자동으로 선택됩니다. 내 컴퓨터에서 root=커널 명령 줄에 항목이 모두 없습니다.

그리고 부트 로더에 관해서는 GRUB은 대부분의 최신 UEFI PC에서 불필요합니다. 요즘 GRUB은 단지 커널 선택기 프로그램의 기능을하며, systemd-boot와 같이 더 간단하고 더 나은 대안이있는 작업입니다.