ทำไมการกระจายส่วนใหญ่ถึงเชน UEFI และด้วง

การกระจายส่วนใหญ่จะติดตั้งบูทโหลดเดอร์เพิ่มเติมบนระบบ UEFI UEFI นั้นเป็นบูตโหลดเดอร์มันมีเมนูให้เลือกระบบปฏิบัติการที่แตกต่างกันหรือแต่ละเมล็ด นอกจากนี้การตั้งค่า UEFI สามารถจะเปลี่ยนแปลงได้ด้วยเครื่องมือ userspace efibootmgrเช่น

เคอร์เนลตั้งแต่ 3.3 รองรับ EFI_STUB ซึ่งหมายความว่าเคอร์เนลสามารถโหลดได้โดยตรงจาก UEFI เหตุผลการกระจายการตัดสินใจที่จะใช้บูตโหลดเดอร์เพิ่มเติมคืออะไร? บทเรียนส่วนใหญ่บน Linux / UEFI มุ่งเน้นไปที่วิธีการตั้งค่าบูตโหลดเดอร์เพิ่มเติมเป็นหลัก (rEFInd, grub2, ELILO และอื่น ๆ ) แทนการบูท Linux ด้วย EFI_STUB

สิ่งเดียวที่ขาดหายไปในการกระจายคือการสนับสนุน เนื่องจากดิสทริบิวชันส่วนใหญ่เชื่อมโยงบูตโหลดเดอร์ตัวที่สองเคอร์เนลจะไม่ถูกเพิ่มลงในเมนูการบู๊ต UEFI และจะไม่คัดลอกไปยังพาร์ติชันระบบ EFI

มีสคริปต์สามบทที่เพียงพอที่จะใช้เวทมนตร์ทั้งหมด หนึ่งซึ่งคัดลอก initramfs ไปยัง ESP อันที่สองคัดลอกเคอร์เนลไปที่ ESP และสร้างรายการใหม่ในเมนูการบู๊ต UEFI สคริปต์ที่สามลบเคอร์เนลเก่าและ initramfs ออกจาก ESP และลบรายการเมนูการบูต UEFI สิ่งนี้จะช่วยให้การปรับปรุง / การล้างเคอร์เนล / เริ่มต้นโดยอัตโนมัติโดยไม่ต้องมีการโต้ตอบกับผู้ใช้ ฉันใช้วิธีนี้มานานกว่าหนึ่งปีและใช้งานได้อย่างไม่มีที่ติ

ทำไมการกระจายส่วนใหญ่จึงใช้ด้วงแทน EFI_STUB

ลิงค์:

• จะสร้างพาร์ติชันการบูต EFI ใหม่ได้อย่างไร

แก้ไข: ฉันไม่ได้พูดถึงการลบการสนับสนุนด้วงทั้งหมด แต่เพื่อเสนอทางเลือกสำหรับผู้ที่ต้องการใช้ด้วยเหตุผลต่างๆ การแจกแจงสามารถให้แพคเกจgrub-efiสำหรับผู้ที่ต้องการเชื่อมโยง UEFI และด้วงและแพ็คเกจefistub-bootที่มีสคริปต์ที่ฉันกล่าวถึงข้างต้น

ระบุว่า UEFI ถูกกำหนดในปี 2005เท่านั้นมีอุปกรณ์ดั้งเดิมที่มีอยู่มากมายที่ไม่รองรับข้อมูลจำเพาะ ในการเพิ่ม UEFI ลงในการแจกแจงแบบมาตรฐานนั้นจำเป็นต้องทำการทดสอบสองโค้ดพา ธ แทนที่จะเป็นหนึ่งอันและไม่เพียง แต่จะเป็นรหัสการบู๊ตที่โด่งดังที่สุดมันเป็นหนึ่งในบิตที่ใช้เวลานานมากในการทดสอบโค้ด

Distros มีทรัพยากรที่ จำกัด และอาจไม่มีเหตุผลใด ๆ เลย มันอาจจะง่ายและปลอดภัยพอสมควร แต่ไม่ว่าจะต้องการงานบำรุงรักษามากขึ้นเพราะตัวเลือกด้วงนั้นต้องได้รับการบำรุงรักษาหากสำหรับระบบที่ไม่ใช่ UEFI เท่านั้น

ฉันแน่ใจว่าทุกคนมีรายการคุณสมบัติและตัวเลือกที่พวกเขาต้องการเห็น distros นำมาใช้ (ฉันจะให้คุณสองสามหน้าฮ่า ๆ ) และไม่ต้องสงสัยเลยว่าหลายคนจะ "ง่ายโดยไม่ต้องยุ่งยากและสุจริต .. " อย่างไรก็ตามไม่มีจำนวนชั่วโมงของคนที่จะใช้งานได้ไม่ จำกัด เมื่อต้องเผชิญกับการตัดสินใจเช่นนี้ ("เราจะนำงานนี้ไปใช้กับคุณลักษณะนี้กับคำถามอื่น ๆ หรือไม่") คำถามหลักควรเป็น:

• จำเป็นหรือไม่ (คำตอบนี่คือไม่)
• มีกี่คนที่จะได้ประโยชน์และเท่าไหร่ (IMO: น้อยและไม่มาก)
• มีทางเลือกที่สมเหตุสมผลตามที่ผู้ใช้สามารถรองรับตนเองโดยที่เราไม่ทำอะไรเลย? (เห็นได้ชัดว่ามี)

เหตุผลที่คนใช้ distros เลยก็เพราะทุกคนอยู่ภายใต้ข้อ จำกัด ของทรัพยากร (มิฉะนั้นเพียงจ้างทีมซื้อพื้นที่และอุปกรณ์และให้พวกเขาทำทุกอย่างตามที่คุณต้องการ) ดังนั้นความจริงคือ distros สะท้อนความต้องการทั่วไปของผู้ใช้

ที่กล่าวว่าฉันคิดว่าในเวลานี้จะได้รับการยอมรับเป็นตัวเลือกและฉัน upvoted คำถาม

การกำหนดเป้าหมาย bootloaders UEFI นอกเหนือจากด้วงจะทำให้การควบคุมและการสนับสนุนมีความซับซ้อน ดิสรอสเป็นเป้าหมายของด้วงมากกว่าสเป็คของ UEFI เพราะด้วงเป็นซอฟต์แวร์เสรีที่สามารถแฮกได้ยืดหยุ่นและมีคุณภาพสูง คุณยังสามารถรับการบูท pure-UEFI ได้โดยทำตามบทช่วยสอนและติดตั้งพาร์ติชัน UEFI บน/bootเพราะถ้าคุณทำเช่นนั้นการบำรุงรักษาจะอยู่ที่คุณ

ปัญหาที่แท้จริงคือคนไม่เข้าใจวิธีการทำงาน ตัวอย่างเช่นในคำถามของคุณคุณพูดถึงว่ามีสามสคริปต์ทั้งหมดที่จำเป็นและคำตอบส่วนใหญ่ที่นี่คือทั้งหมดเกี่ยวกับ / การบำรุงรักษาเพิ่มเติมใด ๆ ที่จะต้องใช้ในการทำงาน - แต่ความจริงก็คือคุณไม่ต้องการสคริปต์เหล่านั้น หรืองานเพิ่มเติมใด ๆ

ทั้งหมดที่คุณต้องการก็คือการผูกติด ESP - หรือทุกที่ที่คุณต้องการให้เคอร์เนล - มากกว่าซึ่งคุณสามารถทำได้ด้วยบรรทัดเดียวใน/boot /etc/fstabทำอย่างนั้นและสคริปต์อัพเดทเคอร์เนลปัจจุบันทั้งหมดจะสามารถทำงานต่อไปได้

`/ etc / fstab 'ของฉันดูเหมือนว่า:

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
#

มีจุดที่ดีที่ทำที่นี่ แต่เกี่ยวกับการตั้งค่าเฉพาะของผู้ผลิต UEFI อย่างชัดเจนไม่ได้ระบุอินเตอร์เฟซสำหรับเมนูบูต นั่นขึ้นอยู่กับการคว้าและจะไม่สอดคล้องกันระหว่างเครื่อง มันน่ารำคาญ แต่จริง

ในขณะที่โหลดเดอร์เช่นgrubจริง ๆ แล้วใช้งานได้มากกว่าแอปพลิเคชันเมนู - เช่น rEFInd จะทำให้ความแตกต่างเท่ากันและทำให้ทุกอย่างง่ายขึ้น

พวกเขาโยง UEFI และ GRUB เป็นโซลูชันการดำเนินการชั่วคราว

เนื่องจากการสนับสนุนของ UEFI และปัญหาที่เกี่ยวข้อง (เช่น Secure Boot) ได้รับการแก้ไขการกระจายมากขึ้นจะใช้โดยตรง ในขณะนี้ยังใหม่มาก: Google Trends แสดงการยอมรับที่ค่อนข้าง จำกัด : http://www.google.com/trends/explore?q=cannot+boot+uefi#q=uefi%2C%20%20efi%2C % 20% 20bios & cmpt = Q

คนอื่น ๆ ล้วนกล่าวถึงข้อผิดพลาดที่อาจเกิดขึ้นจากการไปหาโซลูชั่น UEFI ที่บริสุทธิ์และ / หรือสนับสนุนทั้งระบบที่ไม่ใช่ UEFI และระบบ UEFI ที่บริสุทธิ์พร้อมกัน เคอร์เนล UEFI อาจทำงานบนระบบที่ไม่ใช่ UEFY แต่เครื่องมืออัปเดตเคอร์เนลจำเป็นต้องอัปเดตเมนู GRUB หรือเมนูบูต UEFI หรือทั้งสองอย่าง ฯลฯ

จริงๆแล้วมันเกี่ยวกับการควบคุมคุณภาพตามที่กล่าวไว้: ปัญหาที่สำคัญของรหัสนี้มีผลกระทบสูง: เมื่อคอมพิวเตอร์ไม่สามารถบูตผู้ใช้ใหม่ได้เช่นตัวแปลง Linux ที่มีศักยภาพจะทิ้งมันเป็นขยะและกลับไปที่สิ่งที่ "ปลอดภัย"

แต่อย่างที่ฉันพูดเมื่อเทคโนโลยีได้รับการยอมรับมากขึ้นมันจะกลายเป็นมาตรฐาน

จำเป็นต้องมีรหัสเพิ่มเติมเพื่อแก้ไขข้อบกพร่องของเฟิร์มแวร์

เมื่อไม่ได้ผูกมัดด้วงการกระจายจะขึ้นอยู่กับเฟิร์มแวร์มากขึ้นในการบูตอย่างถูกต้อง เนื่องจากซอฟต์แวร์ใด ๆ จะมีปัญหาเฟิร์มแวร์ก็มีแนวโน้มที่จะ ทีนี้ลีนุกซ์ดิสทริบิวชันจะต้องเขียนเพื่อแก้ไขข้อบกพร่องของเฟิร์มแวร์เหล่านี้ด้วย.

กรณีชีวิตจริงเป็นตัวอย่าง เมนบอร์ด Asrock H81 pro BTC P1.80 ช่วยให้สามารถสร้างรายการเมนูการบู๊ตefibootmgrได้ อาจมีรายการเมนูการบูตหลายสร้างขึ้นและลำดับการบูตสามารถเปลี่ยนการใช้หรือตัวเลือกการบูตต่อไปชั่วคราวสามารถตั้งค่าการใช้efibootmgr --bootorder XXXX,YYYY,ZZZZ ทั้งสองนี้ออกคำสั่งผลตอบแทนที่ช่วยให้คุณความคิดที่ว่าลำดับการบูตที่มีการเปลี่ยนแปลงหรือการบูตต่อไปจะทำงานเช่นefibootmgr --bootnext XXXX BootNext: XXXXอย่างไรก็ตามในการรีบูตเฟิร์มแวร์ที่ดื้อรั้นเพียงแค่เพิกเฉยตัวเลือกการบูตที่ร้องขอใหม่และทำการรีบูตเป็นBootCurrent:ค่าก่อนหน้า การเปลี่ยนแปลงคำสั่งบูตอย่างถาวรสามารถทำได้จากยูทิลิตี้การตั้งค่าเฟิร์มแวร์เท่านั้น และการเปลี่ยนแปลงที่ไม่ถาวรไม่สามารถใช้ได้เลย

ฉันคิดว่าถ้า EFI ส่งมอบโดยเฉพาะและเราลบ bootloader มันจะเป็นเรื่องยากสำหรับทั้งผู้จำหน่าย HW และผู้ผลิตระบบปฏิบัติการ ผู้ขาย HW จะมีเมล็ดมากขึ้นเพื่อทดสอบในขณะที่สำหรับ บริษัท ที่ทำระบบปฏิบัติการมันจะเป็นเหมือนว่าเคอร์เนลของพวกเขาจะถูกโหลดโดย FW ที่แตกต่างกัน

นอกจากนี้ยังมีการบูทเคอร์เนลโดยตรงจาก EFI ซึ่งการบูทการรักษาความปลอดภัยแบบสแต็คจะเหมาะกับใคร ในสถานการณ์ปัจจุบันเมื่อการควบคุมไปที่ OS bootloader จากนั้น bootloader ตรวจสอบว่าเคอร์เนลมีการลงชื่ออย่างถูกต้องหรือไม่ ในกรณีที่เราโหลดเคอร์เนลโดยตรงจาก EFI ฉันคิดว่ามันจะสร้างความยุ่งเหยิงเพียงเพราะสแต็กทั้งหมดจะถูกรบกวน เพียงความเห็นจากสิ่งที่ฉันเข้าใจ