Tại sao số ổ đĩa / phân vùng vẫn được sử dụng?

Nhiều lần, đặc biệt là khi loay hoay với bộ tải khởi động, tôi sẽ thấy số ổ đĩa và số phân vùng được sử dụng. Ví dụ, theo tôi /boot/grub/grub.cfgthấy set root='hd0,gpt2', các mục khởi động UEFI của tôi thường tham chiếu số ổ đĩa / phân vùng và dường như nó sẽ mọc lên trong hầu hết mọi bối cảnh mà bộ tải khởi động có liên quan.

Bây giờ chúng ta có UUID và PARTUUID, việc giải quyết các phân vùng theo cách này có vẻ không ổn định (afaik, các ổ đĩa không được đảm bảo được gắn theo cùng một thứ tự, người dùng có thể di chuyển thứ tự các ổ đĩa được cắm vào mobo của họ, v.v.)

Do đó, câu hỏi của tôi có hai mặt:

1. Là lược đồ địa chỉ này là không ổn định như tôi đã nêu ở trên? Tôi có thiếu một cái gì đó trong tiêu chuẩn có nghĩa là lược đồ này đáng tin cậy hơn nhiều so với tôi dự kiến, hoặc liệu lược đồ địa chỉ này sẽ thực sự khiến hệ thống của bạn không thể khởi động được (cho đến khi bạn sửa các mục khởi động ít nhất) do các ổ đĩa của bạn chỉ được nhận ra trong một thứ tự khác nhau hoặc cắm chúng vào các khe khác nhau trên bo mạch chủ của bạn?

2. Nếu câu trả lời cho câu hỏi trên là có, thì tại sao lược đồ địa chỉ này tiếp tục được sử dụng? Sẽ không sử dụng UUID hoặc PARTUUID cho mọi thứ ổn định hơn và nhất quán hơn?

Lược đồ đánh số đơn giản không thực sự được sử dụng trong các hệ thống gần đây (với "gần đây" là Ubuntu 9 trở lên, các bản phân phối khác cũng có thể đã được điều chỉnh trong thời đại đó).
Bạn đã đúng khi quan sát phân vùng gốc được thiết lập với sơ đồ đánh số đơn giản. Nhưng đây chỉ là một thiết lập mặc định hoặc dự phòng thường được ghi đè bằng lệnh tiếp theo, chẳng hạn như:

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

Cái này chọn phân vùng gốc dựa trên UUID của hệ thống tệp.

Trong thực tế, sơ đồ đánh số đơn giản thường ổn định (miễn là không có thay đổi phần cứng). Ví dụ duy nhất tôi quan sát thấy việc đánh số không dự đoán được là hệ thống có nhiều ổ USB được liệt kê dựa trên mẫu phục vụ đầu tiên đến trước và sau đó được mô phỏng như các ổ IDE. Không có quá trình nào trong số này vốn đã hỗn loạn, vì vậy tôi giả sử có vấn đề trong quá trình triển khai BIOS của các hệ thống cụ thể đó.

Lưu ý: "phân vùng gốc" trong ngữ cảnh này có nghĩa là phân vùng để khởi động, nó có thể khác với phân vùng chứa "root aka. / Hệ thống tệp".

Nói đúng ra, UUID không giải quyết .

Địa chỉ rất, rất đơn giản: đọc ổ X sector Y - hoặc cách khác. Đọc địa chỉ bộ nhớ Z - hoặc nếu không. Địa chỉ rất đơn giản, nhanh chóng, không có nhiều chỗ để diễn giải, và nó ở khắp mọi nơi.

UUID không giải quyết. Thay vào đó là tìm kiếm, tìm kiếm, đôi khi chờ đợi các thiết bị xuất hiện và cũng hiểu các hệ thống tệp (★). Và tùy thuộc vào có bao nhiêu thiết bị, có thể mất một thời gian rất dài. Và một khi tìm thấy, trở lại địa chỉ thường xuyên.

Trong GRUB, cái này được gọi là search(★★★) và nó chỉ khả dụng khi GRUB đã mọc cánh (tìm kiếm là một mô-đun, như mọi hệ thống tệp mà nó hỗ trợ, do đó chỉ khả dụng sau khi tải lõi). Trong Linux, nó (ví dụ) được gọi findfs, findfs sẽ tìm kiếm các thiết bị khối trong hệ thống đang tìm kiếm một hệ thống tệp hoặc phân vùng .

Nó đi qua tất cả các blockdevice, đánh thức chúng từ chế độ chờ, đọc dữ liệu và kết quả thậm chí có thể vẫn là ngẫu nhiên nếu UUID không phải là duy nhất như sau (sau dd tai nạn hoặc tương tự) hoặc bạn không nhận được kết quả nếu UUID thay đổi - UUID cũng dễ bị lỗi cấu hình.

Nói chung, UUID là tuyệt vời và tất nhiên bạn nên sử dụng chúng ở mọi nơi nếu có, đặc biệt là khi địa chỉ truyền thống bị ràng buộc thất bại vì thứ tự ổ đĩa là ngẫu nhiên trong Linux; nhưng hiểu rằng sự phức tạp là ở trên và vượt ra ngoài những gì địa chỉ đơn giản có nghĩa là để làm. Và đặc biệt là trong giai đoạn đầu của bộ tải khởi động, nó đơn giản có thể chưa phải là một lựa chọn. Địa chỉ đến trước, phát triển cánh đến sau.

Đối với bộ tải khởi động, đơn giản là không cần thiết phải nỗ lực (không phải mọi bộ tải khởi động đều hỗ trợ một loạt các hệ thống tệp như GRUB). Nếuhd0 được đảm bảo là "đĩa chúng tôi đã khởi động" do hoàn cảnh (BIOS cung cấp), và vì vậy nếu bạn có thể loại trừ các sự cố thứ tự ổ đĩa ngẫu nhiên, có thể không cần phải đi qua một danh sách rất lớn các phân vùng khác trong tìm kiếm UUID.

Nếu bạn đủ tự tin vào cấu hình của mình để nói rằng đó hd0,gpt2là thứ bạn muốn, và nó phải như vậy, và nó không thể khác, thì không có gì sai khi sử dụng nó như thế. Đôi khi, địa chỉ đơn giản và đơn giản hoạt động tốt.

(★) Trước đây tôi đã giải thích điều này cho LABEL ở đây ...

Không có tiêu chuẩn chung cho nhãn, tất cả đều được dệt bằng tay, ví dụ như việc triển khai các định dạng superblocks trong tiện ích linux . Nếu bạn phát minh ra một hệ thống tập tin mới vào ngày mai, ngay cả khi nó có nhãn, nó sẽ không hiển thị cho đến khi hỗ trợ được thêm vào.

... Và nó cũng tương tự đối với UUID.

(★★★) Trên thực tế, GRUB searchcó một --hinttùy chọn và ... bây giờ tôi chưa kiểm tra mã nguồn và thậm chí nó không được ghi lại trong hướng dẫn sử dụng của họ, nhưng một tùy chọn như vậy sẽ có ý nghĩa mang đến cho bạn cả hai thế giới tốt nhất: gợi ý nên báo searchtrước để kiểm tra phân vùng đó và nếu UUID khớp như mong đợi, nó sẽ xác định thiết bị với nỗ lực tối thiểu và nếu nó không khớp, nó vẫn sẽ quay lại tìm kiếm toàn diện để giữ mọi thứ hoạt động. .

Ngoài ra, các UUID được tìm thấy trước đây có xu hướng được lưu trong bộ nhớ cache, do đó, nó không phải đi qua tất cả các thiết bị hết lần này đến lần khác - và điều này cũng hoạt động rất tốt, miễn là UUID bạn đang tìm kiếm thực sự tồn tại ở đâu đó làm cho nó vào bộ đệm ở nơi đầu tiên.

Cũng đừng quên nhãn. Chúng không độc đáo như UUID, nhưng nhiều thông tin hơn và làm cho con người fstab của bạn có thể đọc được. Nếu đó là máy tính để bàn của bạn hoặc một công ty nhỏ - nói cách khác, bạn đang quản lý một vài đến vài chục ổ đĩa, bạn có thể thích nhãn hơn UUID.

Trả lời câu trả lời tuyệt vời của @ frostschutz cho câu hỏi của bạn, một tình huống khi bạn có thể thích địa chỉ liên kết thiết bị "cổ điển" là cài đặt VM, đặc biệt là trong đám mây VM-for-cho thuê (viết tắt, khó hiểu, đám mây IaaS tựa). Giả sử bạn muốn tùy chỉnh một hình ảnh Ubunzima 04,18 . Bạn tạo một VM (throwaway) với 2 đĩa: một sẽ là ổ đĩa hệ thống (throwaway) và thứ hai là cái bạn gắn và tùy chỉnh. Có lẽ, bạn cũng gắn kết phân vùng khởi động UEFI của nó, nếu bạn muốn ghi một grub mới hơn trên đĩa mới của mình. Giả sử bạn đã chọn điểm gắn kết cho các phân vùng mục tiêu bên dưới /mnt, bảng gắn kết mong muốn của bạn trông giống như

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

Vì vậy, bạn tạo 2 ổ đĩa giống hệt nhau từ hình ảnh sẵn có, do nhà cung cấp cung cấp, kết nối chúng với một VM mới và khởi động nó. Một cách tự nhiên,

• Tất cả các bản phát hành hệ điều hành hiện đại, Ubunzima 04,18 tưởng tượng của chúng tôi không phải là một ngoại lệ, dựa trên các gắn kết có tên UUID.
• Tất cả các ổ đĩa cứng được lăn ra từ cùng một hình ảnh có cùng UUID. UUID là duy nhất, vậy điều gì có thể xảy ra?

Bạn đã thấy tất cả những điều này sẽ xảy ra.

Lần đầu tiên frankencontraption này khởi động, nó đã chọn sda9làm phân vùng khởi động EFI, nhưng Linux đã quyết định làm lại sdb1với tư cách là FS gốc:

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

Và vì kịch bản giới thiệu của tôi khá chưa được chuẩn bị cho điều đó, cuối cùng tôi đã có một hình ảnh dud không thể điều khiển được, mà không có một công cụ nào phàn nàn trong nhật ký trong frankenbuild!

Tất nhiên tôi đã in bảng gắn kết trong nhật ký. Và tất nhiên, sự lộn xộn rất khó phát hiện ra, vì mount (8) in các giá treo theo thứ tự giữa chừng và ngẫu nhiên các thiết bị được gắn, vì vậy không ngạc nhiên khi tôi không phát hiện ra nó ngay lập tức. Và hãy tưởng tượng, cùng một kịch bản (nhưng với các đĩa từ các hình ảnh khác nhau) trước đây hoạt động trơn tru như Glenfiddich 15 tuổi. Đoán xem tôi đã dành bao nhiêu giờ để kéo tóc của mình qua nhật ký cố gắng tìm ra vấn đề?

Không có quy tắc cứng và nhanh nào tốt cho mọi tình huống, từ máy tính để bàn đến Linux được nhúng trong bộ định tuyến đến điện thoại Android của bạn đến trung tâm dữ liệu đám mây. Một câu trả lời SO được cho là khách quan, và tất nhiên, kinh nghiệm hoặc sở thích của tôi là không. Vì vậy, tôi muốn đưa ra các ví dụ về lý luận logic khi chọn trong số các phương pháp xác định phân vùng khác nhau:

• Để nó một mình nếu bạn không có lý do để không. Các UUID là mặc định cho hầu hết các bản phân phối hiện đại. Nếu nói đến việc thêm một ổ đĩa thứ hai, hãy thử và quyết định. Có thể bạn sẽ không bao giờ cần phải biết. Nếu hệ thống của bạn vẫn khởi động và bạn có thể xem và phân vùng thiết bị mới, định dạng và thêm nó vào fstab (bằng UUID, LABEL hoặc bằng một /devliên kết, áp dụng các cân nhắc tương tự). Chỉ khi hệ thống của bạn từ chối khởi động sau khi cắm thêm ổ đĩa thì bạn mới gặp sự cố (và có thể thay đổi thứ tự khởi động trong UEFI BIOS là cách nhanh nhất).

  Về mặt thực tế, việc gắn nhãn bộ kết nối SATA nào vào ổ đĩa trong máy tính để bàn của bạn có thể là giải pháp nhanh nhất và dễ dàng nhất, trong khi thay đổi cách hệ thống khởi động và phục hồi từ lỗi khởi động khá có khả năng là kẻ lừa đảo thời gian tồi tệ nhất. Nhưng nếu bạn quản lý nó cho 50 lập trình viên nghĩ rằng việc ném thêm ổ đĩa không phải là vấn đề đáng bận tâm, thì ít nhất đừng kiểm tra giới hạn của sự may mắn của bạn và đảm bảo rằng các ổ đĩa khởi động ban đầu của họ đều được nhìn thấy bởi hd0và hệ thống như sda.

• Nhãn để quản lý các ổ đĩa và phân vùng của riêng bạn trong máy tính để bàn hoặc ba hoặc một milieu nhỏ (một phòng khách của một ngôi nhà chứa đầy các kỹ sư phần mềm, người vui vẻ gọi nơi đặt văn phòng khởi động của họ). Nếu bạn lấy một ổ đĩa vật lý từ máy của ai đó, bạn sẽ biết nó đến từ đâu nếu bạn sử dụng nhãn một cách nhất quán.

  Nếu lsblk (8) nói LABEL=bubba-boot, bạn biết nó đã được kéo từ máy gọi là bubba ; bên cạnh đó, bubba-boot cuộn qua lưỡi tôi dễ dàng hơn nhiều so với 6864c4ea-f9b9-46db-b875-4d7fc2981007 , mà theo sở thích hư hỏng của tôi, là một công cụ bẻ khóa. Đảm bảo rằng các nhãn là duy nhất bây giờ thay đổi theo bạn, nhưng những gì bạn nhận được là ý nghĩa của nhãn.

• /devĐặt tên dựa trên liên kết khi chỉ huy một tiểu đoàn máy ảo tương đối ngắn, bảo trì thấp, là nơi sinh ra của cùng một hình ảnh, và bạn sẽ không đặt cược tiền lương hàng tuần của mình rằng tất cả UUID của chúng đều tuân theo lời hứa của UU. Bất kỳ dịch vụ VM lành mạnh nào , có thể là Vyper-H trên máy chủ vật lý của riêng bạn hoặc Kugel Cloud hoặc bất cứ thứ gì, sẽ không bao giờ gọi ổ đĩa khởi động của bạn sde, và thứ hai và chỉ một sdc² khác. Mặt khác, trong một máy vật lý, bạn có thể dễ dàng có được sự sắp xếp tương tự bằng cách kết nối sáng tạo cáp SATA.

  Bây giờ tôi lạc đề, nhưng trong kịch bản này, tôi đi theo cùng một cách với cái tên được gọi là giao diện Ethernet Ethernet nhất quán: vô hiệu hóa nó trong VM. Đừng hiểu sai ý tôi, việc đặt tên thực sự phù hợp miễn là NIC bạn đặt vào khe PCI 4 sẽ không đột nhiên nhảy sang khe 5 trong khi bạn không nhìn (hoặc thậm chí trong khi bạn đang ở; không có gì xấu hổ). Thật không may, trong tiểu đoàn của VMs, họ thực sự làm điều đó. Trong trường hợp này, phản trực giác, eth0là nhiều hơn phù hợp hơnenp0s4f6. Nhà cung cấp VM không hứa sẽ luôn đặt số ảo ảo số 1 của họ vào khe 4 trên bus PCI 0 (và không có thực thể nào trong số 3 thực thể được đề cập là thực tế) và đó sẽ luôn là Chức năng 6. Nhưng bạn có thể khá phụ thuộc nhiều vào giao diện đầu tiên đi trước giao diện thứ hai, vì chúng thường có cùng một mô-đun trình điều khiển, thường là từ họ virtio (và nếu không phải là NIC đầu tiên eth0, thì vẫn áp dụng cùng một ghi chú).

  ---

Theo nghĩa bóng, tất nhiên. Tôi đã làm nếu doanh nghiệp này quá lâu để có bất kỳ trái.
² Nếu họ đã làm, tôi nghiêm túc xem xét việc chạy đi la hét từ họ thay đổi nhà cung cấp hoặc phần mềm VM hypanneror.

Cả hai lược đồ có thể được trộn lẫn và khớp với hầu hết các bản phân phối linux.

Các hậu quả có thể là mong muốn hoặc không mong muốn tùy thuộc vào trường hợp sử dụng - ví dụ: người ta có thể thích sơ đồ cũ hơn (và thậm chí vô hiệu hóa các bản hack kiên trì kiểu udev) nếu thay thế các ổ đĩa (phần cứng ảo hoặc phần cứng thực tế) mà không phải sửa đổi các tệp cấu hình muốn.

Câu trả lời cho câu hỏi thứ hai của bạn ("tại sao lược đồ địa chỉ này tiếp tục được sử dụng?"), Tôi đoán là, quán tính. Có, hoàn toàn có thể chỉ sử dụng UUID trên các đĩa được phân vùng GPT. Bạn có thể sử dụng UUID thay vì /dev/xxxtên trong /etc/fstab. Và bây giờ chúng ta có Đặc tả phân vùng có thể khám phá , trong nhiều trường hợp, bạn thậm chí không phải chỉ định UUID nữa, chỉ cần phân vùng đĩa của bạn với loại phân vùng và các phân vùng sẽ được chọn tự động. Trên máy của tôi, root=mục nhập bị thiếu hoàn toàn từ dòng lệnh kernel.

Và nói về bộ tải khởi động: GRUB hầu như không cần thiết trên các máy tính UEFI hiện đại, theo nghĩa là nó có rất ít liên quan đến việc bootstrapping máy. Ngày nay GRUB chỉ hoạt động như một chương trình chọn nhân, với nhiệm vụ này có các lựa chọn thay thế đơn giản hơn và tốt hơn, như systemd-boot.