Mengapa sebagian besar rantai distribusi UEFI dan grub?

Sebagian besar distribusi memasang bootloader tambahan pada sistem UEFI. UEFI sendiri adalah boot loader, ia menawarkan menu untuk memilih sistem operasi atau kernel yang berbeda. Selain itu, pengaturan UEFI dapat dengan mudah diubah dengan alat seperti userspace efibootmgr.

Kernel sejak 3.3 mendukung EFI_STUB, yang berarti kernel dapat dimuat langsung dari UEFI. Apa alasan distribusi memutuskan untuk menggunakan bootloader tambahan? Sebagian besar tutorial tentang Linux / UEFI berfokus terutama pada cara mengatur bootloader tambahan (rEFInd, grub2, ELILO, dll.) Daripada mem-boot Linux dengan EFI_STUB.

Satu-satunya hal yang hilang dalam distribusi adalah dukungan. Karena sebagian besar distribusi membuat boot loader kedua, kernel tidak ditambahkan ke menu boot UEFI, juga tidak disalin ke partisi sistem EFI.

Tiga skrip sudah cukup untuk melakukan semua keajaiban. Satu yang menyalin initramf ke ESP. Yang kedua menyalin kernel ke ESP dan membuat entri baru di menu boot UEFI. Skrip ketiga menghapus kernel dan initramf lama dari ESP dan menghapus entri menu boot UEFI. Ini memungkinkan pembaruan / pembersihan kernel / initramfs sepenuhnya otomatis tanpa interaksi pengguna. Saya menggunakan pendekatan ini sejak lebih dari setahun dan telah bekerja dengan sempurna.

Mengapa sebagian besar distribusi menggunakan grub alih-alih EFI_STUB?

Tautan:

• Bagaimana cara membuat ulang partisi boot EFI?

EDIT: Saya tidak berbicara tentang menghapus dukungan grub sepenuhnya tetapi untuk menawarkan pilihan bagi mereka yang ingin menggunakannya karena berbagai alasan. Distribusi dapat menyediakan paket grub-efiuntuk mereka yang ingin rantai UEFI dan grub dan paket efistub-bootyang berisi skrip yang saya sebutkan di atas.

Mengingat bahwa UEFI hanya didefinisikan pada tahun 2005 ada banyak peralatan warisan di luar sana yang tidak mendukung spesifikasi. Untuk menambahkan UEFI ke distribusi standar akan memerlukan pengujian dua jalur kode alih-alih satu, dan tidak hanya kode boot yang terkenal rewel, itu juga salah satu bit kode yang paling memakan waktu untuk diuji.

Distro memiliki sumber daya yang terbatas dan mungkin tidak ada alasan sama sekali selain itu. Ini mungkin cukup sederhana dan aman, tetapi tidak peduli apa itu akan memerlukan lebih banyak pekerjaan pemeliharaan karena opsi grub harus dipertahankan, jika hanya untuk sistem non UEFI.

Saya yakin semua orang memiliki daftar fitur dan opsi yang ingin mereka adopsi dari distro (saya akan memberi Anda beberapa halaman, lol), dan tidak diragukan lagi banyak dari mereka akan "benar-benar mudah, tidak ada kerepotan, jujur. .. " Namun, tidak ada jumlah jam orang yang tak terbatas untuk menerapkannya. Ketika dihadapkan dengan keputusan seperti ini ("Apakah kita menempatkan pekerjaan dalam fitur ini, vs. beberapa lainnya?") Pertanyaan utama seharusnya:

• Apakah itu perlu? (Jawabannya di sini adalah tidak).
• Berapa banyak orang yang akan mendapat manfaat, dan berapa banyak? (IMO: beberapa, dan tidak banyak)
• Apakah ada alternatif yang masuk akal dimana pengguna dapat mengakomodasi dirinya sendiri tanpa kita melakukan apa pun? (Rupanya ada.)

Alasan orang menggunakan distro sama sekali adalah karena semua orang tunduk pada keterbatasan sumber daya (jika tidak, hanya menyewa tim, membelikan mereka beberapa ruang dan peralatan, dan minta mereka melakukan segalanya untuk Anda persis seperti yang Anda inginkan). Jadi kenyataannya adalah bahwa distro mencerminkan kebutuhan umum pengguna mereka.

Yang mengatakan, saya pikir ini pada waktunya akan diadopsi sebagai pilihan, dan saya menjawab pertanyaan itu.

Menargetkan bootloader UEFI selain grub akan mempersulit kontrol kualitas dan dukungan. Distro lebih mengutamakan grub daripada spesifikasi UEFI karena grub adalah perangkat lunak bebas, dapat diretas, lebih fleksibel, dan berkualitas tinggi. Anda masih bisa mendapatkan boot UEFI murni dengan mengikuti tutorial dan memasang partisi UEFI /boot, karena jika Anda melakukannya, perawatannya ada pada Anda.

Masalah sebenarnya adalah bahwa orang tidak mengerti cara kerjanya. Misalnya, dalam pertanyaan Anda, Anda menyebutkan bahwa tiga skrip adalah semua yang diperlukan, dan sebagian besar jawaban di sini adalah tentang semua / setiap perawatan tambahan yang diperlukan untuk membuatnya berfungsi - tetapi sebenarnya Anda tidak memerlukan skrip tersebut atau pekerjaan tambahan.

Yang Anda butuhkan hanyalah mengikat mount ESP - atau di mana pun Anda ingin menyimpan kernel - /bootyang dapat Anda lakukan dengan satu baris /etc/fstab. Lakukan itu dan semua skrip pembaruan kernel saat ini hanya akan terus bekerja.

`/ Etc / fstab 'saya terlihat seperti:

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
#

Ada poin bagus yang dibuat di sini, tentang pengaturan khusus pabrikan. UEFI secara eksplisit tidak tidak menentukan antarmuka untuk menu boot. Itu untuk diperebutkan dan tidak akan konsisten di antara mesin. Itu menjengkelkan, tapi benar.

Jadi, sementara loader seperti grubsebenarnya hanya membuat lebih banyak pekerjaan, aplikasi menu - seperti rEFInd - menyamakan perbedaan dan menyederhanakan semuanya.

Mereka rantai UEFI dan GRUB sebagai solusi implementasi sementara.

Ketika dukungan UEFI dan masalah-masalah yang menyertainya (mis. Boot Aman) diselesaikan, semakin banyak distribusi akan menggunakannya secara langsung. Sementara itu, ini masih sangat baru: Google Trends menunjukkan adopsi yang agak terbatas: http://www.google.com/trends/explore?q=cannot+boot+uefi#q=uefi%2C%20%20efi%2C % 20% 20bios & cmpt = q

Yang lain telah menyebutkan potensi jebakan untuk solusi UEFI murni dan / atau mendukung sistem non-UEFI dan UEFI murni secara bersamaan. Kernel UEFI mungkin bekerja pada sistem non-UEFY, tetapi alat pembaruan kernel perlu memperbarui menu GRUB ATAU menu boot UEFI ATAU keduanya, dll. Dll.

Ini sebenarnya tentang kontrol kualitas seperti yang disebutkan: masalah penting dengan kode ini memiliki dampak tinggi: Ketika komputer gagal mem-boot pengguna baru, yaitu orang yang berpotensi mengonversi Linux, akan membuangnya sebagai sampah dan kembali ke sesuatu yang "aman".

Tapi seperti yang saya katakan saat teknologi mendapat adopsi lebih dari itu akan menjadi standar.

Diperlukan kode tambahan untuk mengatasi bug firmware

Ketika tidak merantai grub, distribusi lebih mengandalkan firmware untuk boot dengan benar. Karena perangkat lunak apa pun akan mengalami masalah, firmware juga rentan terhadap hal itu. Sekarang distribusi Linux harus menulis untuk mengatasi bug firmware ini juga.

Kasus kehidupan nyata sebagai contoh. Motherboard Asrock H81 pro BTC P1.80 memungkinkan pembuatan entri menu boot efibootmgr. Mungkin ada beberapa entri menu boot yang dibuat, dan urutan boot dapat diubah menggunakan efibootmgr --bootorder XXXX,YYYY,ZZZZatau opsi booting sementara berikutnya dapat diatur menggunakan efibootmgr --bootnext XXXX. Kedua perintah ini menghasilkan keluaran yang memberi Anda gagasan bahwa urutan boot telah berubah atau boot berikutnya akan berjalan, misalnya BootNext: XXXX. Namun saat reboot firmware keras kepala hanya mengabaikan opsi boot yang baru diminta dan reboot ke nilai sebelumnya BootCurrent:. Perubahan urutan boot permanen hanya dapat dilakukan dari utilitas pengaturan firmware. Dan perubahan tidak permanen sama sekali tidak tersedia.

Saya pikir jika booting hanya diserahkan oleh EFI dan kami menghapus bootloader maka akan sulit bagi vendor HW dan pembuat Sistem Operasi. Vendor HW akan memiliki lebih banyak kernel untuk diuji sedangkan untuk perusahaan yang membuat OS, itu akan seperti apakah kernel mereka dimuat oleh FW yang berbeda.

Apalagi dengan boot langsung dari kernel dari EFI, di mana di boot aman boot akan cocok? Dalam skenario saat ini, sekali kontrol masuk ke bootloader OS, kemudian bootloader memeriksa apakah kernel ditandatangani dengan benar atau tidak. Jika kita memuat kernel langsung dari EFI maka saya pikir itu akan membuat kekacauan hanya karena seluruh tumpukan akan terganggu. Hanya pendapat dari pengertian apa yang saya miliki.