ทำไมพาร์ติชัน efi ถูกเมาท์


10

ใน Ubuntu และ distros อื่น ๆ อีกหลายพาร์ติชัน EFI /boot/efiจะติดตั้งอยู่ที่

ที่ฉันเข้าใจพาร์ติชัน EFI อ่านก่อน OS rootfs ( /) ดังนั้นหลังจากที่เคอร์เนลโหลดและติดตั้ง/แล้วเรายังต้องการพาร์ติชัน EFI ไว้ทำอะไร? ในทางทฤษฎีหลังจากการติดตั้งครั้งแรกคุณไม่จำเป็นต้องเข้าถึง/boot/efiอีกต่อไปเพราะมันมีไบนารี. fi ...

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


แก้ไข:

บางระบบล่าสุดอาจรวมถึงส่วนgrub.cfgefi ของพวกเขา ดูรายงานข้อผิดพลาดนี้แต่นี่ไม่ใช่กรณีของ 16.04LTS ของฉัน ดังนั้นสำหรับระบบที่มีไฟล์กำหนดค่าใน ESP มันเหมาะสมกว่าที่จะเมานท์ แต่บ่อยครั้งที่ผู้คนต้องการเรียกใช้update-grubและสคริปต์ไม่สามารถเมานต์และติดตั้งใหม่อีกครั้งหลังจากการอัพเดต

คำตอบ:


9

มีเหตุผลหลายประการที่อาจจำเป็นต้องเข้าถึง ESP ในสถานการณ์ที่หลากหลาย:

  • /boot/efi/EFI/ubuntu/grubx64.efi - นี่คือไบนารี EFI GRUB 2 ซึ่งจะต้องถูกแทนที่หากแพ็กเกจ GRUB ถูกอัพเดต
  • /boot/efi/EFI/ubuntu/grub.cfg- นี่คือไฟล์กำหนดค่า GRUB ที่ทำงานได้น้อยมาก /boot/grub/grub.cfgส่วนใหญ่จะโหลด การเปลี่ยนเส้นทางนี้ทำเพื่อเปิดใช้งาน "hook" สำหรับระบบ Secure Boot โดยไม่ต้อง Boot การรักษาความปลอดภัยที่grubx64.efiไบนารีสามารถสร้างขึ้นทั้งในประเทศและจุดโดยตรงที่/boot/grub/grub.cfg; แต่เนื่องจากตำแหน่งของ/boot/grub/grub.cfgแตกต่างกันไป (ตามที่เห็นโดย ESP) จากระบบหนึ่งไปอีกระบบหนึ่งการวางgrub.cfgไฟล์ลงบน ESP จึงเป็นสิ่งจำเป็นสำหรับ Secure Boot ซึ่งไม่อนุญาตgrubx64.efiให้สร้างขึ้นภายในเครื่อง IMHO จะเหมาะสมกว่าที่จะวางหลักgrub.cfgและไฟล์สนับสนุน GRUB อื่น ๆ ลงใน ESP แต่ผู้พัฒนาที่รับผิดชอบเรื่องนี้ได้เลือกแนวทางที่อนุรักษ์นิยมมากขึ้นเมื่อเทียบกับสิ่งที่ระบบที่ใช้ BIOS ทำ ไม่ว่าในกรณีใดgrub.cfgบน ESP จะไม่ค่อยมีการอัพเดท; แต่นั่นอาจจำเป็นในบางกรณีโดยเฉพาะอย่างยิ่งหากแพ็กเกจ GRUB Debian ได้รับการอัพเดต
  • /boot/efi/EFI/ubuntu/shimx64.efi- นี่คือ Shim binary ซึ่งจำเป็นสำหรับ Secure Boot ในการทำงาน เช่นเดียวกับไบนารี GRUB 2 มันอาจได้รับการอัพเดตโดยการอัพเดตแพ็คเกจ Debian แต่เป็นshim-signedแพ็คเกจ
  • /boot/efi/EFI/ubuntu/MokManager.efi- นี่คือไบนารี MokManager ซึ่งเป็นเครื่องมือสนับสนุนชิม เช่นเดียวกับ Shim อาจมีการอัปเดตในการอัปเดตแพ็คเกจ
  • /boot/efi/EFI/ubuntu/fwupx64.efi- เป็นเครื่องมือที่ช่วยในการอัปเดตเฟิร์มแวร์บนคอมพิวเตอร์ที่ใช้ EFI โดยอัตโนมัติ เช่นเดียวกับไบนารี EFI ที่ผ่านมามันอาจถูกอัพเดตโดยการอัพเดตแพ็คเกจ Debian
  • ไฟล์เฟิร์มแวร์ EFI - การอัปเดตเฟิร์มแวร์มีแนวโน้มว่าจะต้องคัดลอกไฟล์เฟิร์มแวร์ไปยัง ESP นี่อาจเป็นกระบวนการแบบแมนนวลหรือบางอย่างที่เป็นระบบอัตโนมัติอย่างน้อยบางส่วนโดยใช้fwupdateไบนารีLinux และfwupx64.efiไบนารี EFI ที่ตรงกัน (ฉันไม่แน่ใจ 100% ว่าหลังต้องเขียนไฟล์ลงใน ESP แต่มันค่อนข้างใหม่และมีเอกสารน้อยที่สุดในตอนนี้)
  • เครื่องมือที่เกี่ยวข้องกับ EFI อื่น ๆ - โปรแกรมเช่นตัวจัดการการบูตของฉันrEFIndและตัวจัดการการบูตที่ไม่ได้มาตรฐานอื่น ๆ ของ EFI อาจต้องติดตั้งลงใน ESP จำนวนของเครื่องมือที่จำเป็นต้องติดตั้งนั้นมีความสำคัญ แต่ส่วนใหญ่เป็นเครื่องมือที่แปลกใหม่ดังนั้นจำนวนของระบบที่ได้รับผลกระทบจึงมีน้อย
  • การปรับแต่งไฟล์การกำหนดค่าด้วยตนเอง - หากคุณต้องการกำหนดค่าบูตโหลดเดอร์ใหม่อีกครั้งคุณอาจต้องอ่านไฟล์กำหนดค่าของมันใน ESP แก้ไขและบันทึกไฟล์ที่แก้ไขแล้วกลับออกมา สำหรับเรื่องนั้นเพียงแค่ตรวจสอบการกำหนดค่าต้องการให้เมาต์ ESP (แม้ว่ามันจะเป็นเมาท์แบบอ่านอย่างเดียว)
  • เครื่องมือข้อมูลระบบ - เครื่องมือเช่นBoot Info Scriptอ่านไฟล์การกำหนดค่าใน ESP เพื่อสร้างรายงานเกี่ยวกับวิธีการกำหนดค่าระบบ Boot Info Script อาจติดตั้ง ESP แม้ว่าจะไม่ได้เมาต์เพื่อทำงาน แต่ฉันก็ไม่ได้บวก 100% อาจมีเครื่องมืออื่นที่สมมติว่าติดตั้ง ESP แล้วและฟังก์ชันการทำงานของมันจะลดลงหากไม่ตรงตามข้อสันนิษฐานนี้

โดยรวมแล้วมีเหตุผลบางประการที่ระบบปฏิบัติการของคุณเองหรือคุณอาจต้องการหรือต้องการอ่านหรือเขียนลงใน ESP ดังกล่าวด้วยเหตุผลเหล่านี้มีจำนวนไม่เพียงพอที่กลไกในการเมานต์ ESP ชั่วคราวและยกเลิกการเมานท์เมื่อดำเนินการเสร็จอาจเป็นประโยชน์ ตัวอย่างเช่นสคริปต์การติดตั้งแพคเกจ Debian สามารถทำงานได้เช่นเดียวกับเครื่องมืออัตโนมัติที่ปรับเปลี่ยนไฟล์การกำหนดค่าใน ESP อย่างไรก็ตาม AFAIK การเปลี่ยนสถานะการเมานท์ของ ESP ไม่ได้อยู่บนขอบฟ้า

โปรดทราบว่า ESP จะถูกเมาท์ด้วยสิทธิ์ที่ จำกัด โดยค่าเริ่มต้น เมื่อเร็ว ๆ นี้ (เริ่มต้นด้วย 15.10 หรือ 16.04 บางที - ฉันไม่แน่ใจว่าเมื่อไหร่) สิทธิ์การเมานท์นั้นเปลี่ยนไปเพื่อให้rootสามารถอ่าน/boot/efiได้เท่านั้น แม้แต่ก่อนหน้านั้นก็rootสามารถเขียนไปยัง ESP ได้แม้ว่าการอนุญาตการอ่านจะเป็นแบบโยก เนื่องจากrootสามารถติดตั้งพาร์ติชันได้มีประโยชน์ด้านความปลอดภัยน้อยที่สุดเมื่อปล่อยให้ ESP ไม่ได้เมาท์ ณ จุดนี้แม้ว่าจะมีประโยชน์ในกรณีที่มีความเสี่ยงน้อยกว่าที่ระบบไฟล์เสียหายต่อ ESP เนื่องจากข้อผิดพลาดไฟดับ ฯลฯ


มันเป็นเรื่องบังเอิญที่หลาย distros มีนโยบายการติดตั้งนี้หรือไม่? หรือมันอาจจะเกี่ยวข้องกับ POSIX หรือมาตรฐานอื่น ๆ ? ตราสารอนุพันธ์ Debian +, Arch + derivs, OpenSUSE บางที Fedora ...
jiggunjer

ในสต็อกติดตั้ง 17.04 ฉันไม่มีข้อ จำกัด ใด ๆ/boot/efi(คำตอบข้างต้นกล่าวถึงเฉพาะการเข้าถึงรูทไม่ใช่กรณีสำหรับฉันและการเมาท์rw): fstabรายการ:UUID=1234-5678 /boot/efi vfat defaults 0 1
sxc731

2

คุณพูดถูก: ไม่จำเป็นต้องเมานต์ ESP ที่/boot/efiในการตั้งค่าเริ่มต้น (aka กับด้วง 2 )

update-grubอัพเดตgrub.cfgที่มีอยู่/boot/grubดังนั้นการกำหนดค่าของ grub จะถูกอัพเดตโดยไม่มีปัญหาหาก ESP ไม่ถูกเมาท์

ฉันไม่ได้ติดตั้งไว้สองสามปีในการติดตั้งครั้งก่อนโดยไม่มีปัญหา

คุณสามารถได้รับไมโครวินาทีในระหว่างการบู๊ตโดยไม่ต้องติดตั้งหากคุณต้องการ ;-)


ดูเหมือนการออกแบบที่โง่สำหรับฉัน การลบโดยไม่ได้ตั้งใจ = การสูญเสีย bootloaders ทั้งหมด โปรแกรมติดตั้ง openSuse เตือนฉันอย่างแข็งขันหากฉันไม่ได้เพิ่มลงในfstabแต่การยกเลิกการต่อเชื่อมไม่ได้ทำให้เกิดการล่มสลายของนิวเคลียร์
jiggunjer

1
คุณไม่สามารถลบไฟล์ระบบโดยไม่ได้ตั้งใจ มีไฟล์อื่น ๆ อีกมากมายที่สามารถทำลายระบบของคุณได้ และสิ่งนี้สามารถเรียกคืนได้ง่าย
Pilot6

1
@ Pilot6 1) คุณทำได้ 2) ไม่เกี่ยวข้อง 3) ขึ้นอยู่กับวิธีการกำหนดค่าระบบ
jiggunjer
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.