Tại sao hầu hết các chuỗi phân phối UEFI và grub?

Hầu hết các bản phân phối đều cài đặt bộ tải khởi động bổ sung trên hệ thống UEFI. Bản thân UEFI là một bộ tải khởi động, nó cung cấp một menu để chọn các hệ điều hành khác nhau hoặc các hạt nhân riêng lẻ. Hơn nữa, các cài đặt UEFI có thể dễ dàng được thay đổi bằng các công cụ không gian người dùng như efibootmgr.

Kernels kể từ 3.3 hỗ trợ EFI_STUB, có nghĩa là hạt nhân có thể được tải trực tiếp từ UEFI. Lý do phân phối quyết định sử dụng bộ tải khởi động bổ sung là gì? Hầu hết các hướng dẫn về Linux / UEFI tập trung chủ yếu vào cách thiết lập trình tải khởi động bổ sung (rEFInd, grub2, ELILO, v.v.) thay vì khởi động Linux bằng EFI_STUB.

Điều duy nhất còn thiếu trong các bản phân phối là hỗ trợ. Vì hầu hết các bản phân phối đều có bộ tải khởi động thứ hai, nên kernel không được thêm vào menu khởi động UEFI và cũng không được sao chép vào phân vùng hệ thống EFI.

Ba kịch bản là đủ để làm tất cả các phép thuật. Một trong đó sao chép các initramfs vào ESP. Một cái thứ hai sao chép kernel vào ESP và tạo một mục mới trong menu khởi động UEFI. Kịch bản thứ ba loại bỏ kernel cũ và initramfs khỏi ESP và xóa mục nhập menu khởi động UEFI. Điều này cho phép cập nhật / thanh lọc kernel / initramfs hoàn toàn tự động mà không cần tương tác của người dùng. Tôi đang sử dụng phương pháp này từ hơn một năm nay và nó đã hoạt động hoàn hảo.

Tại sao hầu hết các bản phân phối sử dụng grub thay vì EFI_STUB?

Liên kết:

• Làm thế nào để tạo lại phân vùng khởi động EFI?

EDIT: Tôi không nói về việc loại bỏ hoàn toàn hỗ trợ grub mà là đưa ra lựa chọn cho những người muốn sử dụng nó vì nhiều lý do. Các bản phân phối có thể cung cấp một gói grub-eficho những ai muốn xâu chuỗi UEFI và grub và một gói efistub-bootchứa các tập lệnh mà tôi đã đề cập ở trên.

Cho rằng UEFI chỉ được xác định vào năm 2005, có một loạt các thiết bị cũ không hỗ trợ thông số kỹ thuật. Để thêm UEFI vào một bản phân phối tiêu chuẩn sẽ yêu cầu thử nghiệm hai đường dẫn mã thay vì một, và không chỉ mã khởi động nổi tiếng là khó xử, đây là một trong những đoạn mã tốn thời gian khó chịu nhất để kiểm tra.

Các bản phân phối có nguồn lực hạn chế và có thể không có bất kỳ lý do nào ngoài điều đó. Nó có thể khá đơn giản và an toàn, nhưng không có vấn đề gì sẽ đòi hỏi nhiều công việc bảo trì hơn vì tùy chọn grub phải được duy trì, nếu chỉ dành cho các hệ thống không phải UEFI.

Tôi chắc rằng mọi người đều có một danh sách các tính năng và tùy chọn mà họ muốn thấy các bản phân phối (tôi sẽ cung cấp cho bạn một vài trang, lol), và chắc chắn nhiều trong số đó sẽ là "hoàn toàn dễ dàng, không phức tạp, trung thực. .. ". Tuy nhiên, không có số lượng người vô hạn để thực hiện chúng. Khi phải đối mặt với các quyết định như thế này ("Chúng ta có đưa công việc vào tính năng này, so với một số câu hỏi khác không?") Các câu hỏi chính phải là:

• Có cần thiết không? (Câu trả lời ở đây là không).
• Có bao nhiêu người sẽ được hưởng lợi, và bao nhiêu? (IMO: một vài, và không nhiều)
• Có một sự thay thế hợp lý bằng cách mà người dùng có thể tự điều chỉnh mà không cần chúng tôi làm gì không? (Rõ ràng là có.)

Lý do mọi người sử dụng distro hoàn toàn là vì mọi người đều bị hạn chế về tài nguyên (nếu không, chỉ cần thuê một nhóm, mua cho họ một số không gian và thiết bị và để họ làm mọi thứ cho bạn chính xác như bạn muốn). Vì vậy, thực tế là các bản phân phối phản ánh nhu cầu chung của người dùng của họ.

Điều đó nói rằng, tôi nghĩ rằng điều này sẽ kịp thời được thông qua như là một lựa chọn, và tôi nêu lên câu hỏi.

Nhắm mục tiêu bộ tải khởi động UEFI ngoài grub sẽ làm phức tạp việc kiểm soát và hỗ trợ chất lượng. Các distro đang nhắm mục tiêu grub chứ không phải thông số kỹ thuật UEFI vì grub là phần mềm miễn phí, có thể hack, linh hoạt hơn và chất lượng cao. Bạn vẫn có thể có được một khởi động UEFI thuần túy bằng cách làm theo hướng dẫn và gắn phân vùng UEFI vào /boot, bởi vì nếu bạn làm điều đó, việc bảo trì sẽ thuộc về bạn.

Vấn đề thực sự là mọi người không hiểu cách thức hoạt động của nó. Ví dụ, trong câu hỏi của bạn, bạn đề cập rằng ba tập lệnh là tất cả những gì cần thiết và hầu hết các câu trả lời ở đây là về tất cả / bất kỳ bảo trì bổ sung nào sẽ được yêu cầu để làm cho nó hoạt động - nhưng sự thật là bạn không cần những tập lệnh đó hoặc bất kỳ công việc bổ sung.

Tất cả những gì bạn cần là liên kết gắn kết ESP - hoặc bất cứ nơi nào bạn muốn giữ kernel - hơn /boot, điều bạn có thể làm với một dòng duy nhất /etc/fstab. Làm điều đó và tất cả các kịch bản cập nhật kernel hiện tại sẽ tiếp tục hoạt động.

`/ Etc / fstab 'của tôi trông giống như:

LABEL=ESP /esp vfat defaults 0 2
#
#^ i like a separate mount point - not necessary though
#
/esp/EFI/arch_root /boot none bind,defaults 0 2
#
#^ i keep separate installations in separate directories
#

Tuy nhiên, có một điểm tốt được thực hiện ở đây về các cài đặt dành riêng cho nhà sản xuất. UEFI rõ ràng không không chỉ định giao diện cho một menu khởi động. Đó là để lấy và sẽ không nhất quán giữa các máy. Thật khó chịu, nhưng sự thật.

Và do đó, trong khi một trình tải như grubthực sự chỉ làm cho nhiều công việc hơn , một ứng dụng menu - chẳng hạn như rEFInd - cân bằng sự khác biệt và đơn giản hóa mọi thứ.

Họ xâu chuỗi UEFI và GRUB như một giải pháp triển khai tạm thời.

Khi hỗ trợ của UEFI và các vấn đề đi kèm (ví dụ: Khởi động an toàn) được giải quyết, ngày càng nhiều bản phân phối sẽ sử dụng trực tiếp. Trong thời gian này, điều này vẫn còn rất mới: Google Xu hướng hiển thị việc áp dụng khá hạn chế: http://www.google.com/trends/explore?q=cannot+boot+uefi#q=uefi%2C%20%20efi%2C % 20% 20 tỷ & cmpt = q

Những người khác đều đã đề cập đến những cạm bẫy tiềm năng của việc tìm kiếm một giải pháp UEFI thuần túy và / hoặc hỗ trợ đồng thời cả hai hệ thống UEFI và UEFI thuần túy. Nhân UEFI có thể hoạt động trên hệ thống không phải UEFY, nhưng các công cụ cập nhật kernel cần cập nhật menu GRUB HOẶC menu khởi động UEFI HOẶC cả hai, v.v.

Đây thực sự là về kiểm soát chất lượng như đã đề cập: các vấn đề quan trọng với mã này có tác động cao: Khi máy tính không khởi động được người dùng mới, tức là chuyển đổi Linux tiềm năng, sẽ bỏ nó thành rác và quay trở lại một cái gì đó "an toàn".

Nhưng như tôi đã nói khi công nghệ được áp dụng nhiều hơn, nó sẽ trở thành tiêu chuẩn.

Mã bổ sung là cần thiết để khắc phục lỗi firmware

Khi không kết nối mạng, phân phối phụ thuộc nhiều hơn vào phần sụn để khởi động chính xác. Vì bất kỳ phần mềm nào cũng sẽ có vấn đề, phần sụn cũng dễ bị như vậy. Bây giờ các bản phân phối Linux cũng sẽ phải viết để khắc phục các lỗi phần sụn này.

Một trường hợp thực tế cuộc sống là một ví dụ. Bo mạch chủ Asrock H81 pro BTC P1.80 cho phép tạo các mục menu khởi động với efibootmgr. Có thể có nhiều mục menu khởi động được tạo và có thể thay đổi thứ tự khởi động bằng cách sử dụng efibootmgr --bootorder XXXX,YYYY,ZZZZhoặc tùy chọn khởi động tiếp theo tạm thời có thể được đặt bằng cách sử dụng efibootmgr --bootnext XXXX. Cả hai đầu ra trả về lệnh này cung cấp cho bạn ý tưởng rằng thứ tự khởi động đã thay đổi hoặc ví dụ lần khởi động tiếp theo sẽ chạy BootNext: XXXX. Tuy nhiên, khi khởi động lại, phần sụn cứng đầu chỉ cần bỏ qua tùy chọn khởi động mới được yêu cầu và khởi động lại vào BootCurrent:giá trị trước đó . Thay đổi thứ tự khởi động vĩnh viễn chỉ có thể được thực hiện từ tiện ích thiết lập phần sụn. Và một thay đổi không vĩnh viễn là không có sẵn ở tất cả.

Tôi nghĩ rằng nếu việc khởi động chỉ được trao bởi EFI và chúng tôi loại bỏ bộ nạp khởi động thì sẽ khó khăn cho cả nhà cung cấp CTNH và nhà sản xuất Hệ điều hành. Nhà cung cấp CTNH sẽ có nhiều hạt nhân hơn để kiểm tra trong khi đối với các công ty sản xuất HĐH, sẽ giống như liệu hạt nhân của họ có được tải bởi các FW khác nhau hay không.

Hơn nữa với việc khởi động trực tiếp kernel từ EFI, nơi nào trong stack stack boot sẽ phù hợp? Trong kịch bản hiện tại, một khi điều khiển chuyển đến bộ tải khởi động hệ điều hành, sau đó bộ nạp khởi động kiểm tra xem kernel có được ký chính xác hay không. Trong trường hợp chúng ta tải kernel trực tiếp từ EFI thì tôi nghĩ rằng nó sẽ chỉ tạo ra sự lộn xộn vì toàn bộ stack sẽ bị xáo trộn. Chỉ là một ý kiến ​​từ những gì tôi hiểu.