Neden çoğu dağıtım UEFI ve grub zincirini kullanıyor?

Çoğu dağıtım bir UEFI sistemine ek bir önyükleyici yükler. UEFI'nın kendisi bir önyükleyicidir, farklı işletim sistemlerini veya tek tek çekirdekleri seçmek için bir menü sunar. Ayrıca, UEFI ayarları gibi kullanıcı araçları ile kolayca değiştirilebilir efibootmgr.

3.3'ten beri olan çekirdekler EFI_STUB'ı desteklemektedir, bu da çekirdeğin doğrudan UEFI'den yüklenebileceği anlamına gelir. Dağıtımların ek bir önyükleyici kullanmaya karar vermesinin nedeni nedir? Linux / UEFI hakkındaki çoğu öğretici, Linux'u EFI_STUB ile başlatmak yerine, ek önyükleyici (rEFInd, grub2, ELILO, vb.) Ayarlarının nasıl yapıldığına odaklanır.

Dağılımlarda eksik olan tek şey destek. Çoğu dağıtım ikinci bir önyükleyici zinciri oluşturduğundan, çekirdek UEFI önyükleme menüsüne eklenmez ve EFI sistem bölümüne de kopyalanmaz.

Tüm sihri yapmak için üç senaryo yeterli. Initramfs'i ESP'ye kopyalayan biri. İkincisi, çekirdeği ESP'ye kopyalar ve UEFI önyükleme menüsünde yeni bir giriş oluşturur. Üçüncü komut dosyası eski çekirdeği ve initramfs öğelerini ESP'den kaldırır ve UEFI önyükleme menüsü girişini siler. Bu tam otomatikleştirilmiş çekirdek / initramfs güncelleme / temizleme işlemlerini kullanıcı etkileşimi olmadan sağlar. Bu yaklaşımı bir yıldan fazla bir süredir kullanıyorum ve kusursuz çalıştı.

Neden çoğu dağıtım EFI_STUB yerine grub kullanıyor?

Bağlantılar:

• EFI önyükleme bölümü nasıl yeniden oluşturulur?

EDIT: Grub desteğini tamamen kaldırmaktan değil, çeşitli nedenlerle kullanmak isteyenler için bir seçenek sunmaktan bahsetmiyorum. Dağıtımlar, grub-efiUEFI'yi ve grubunu zincirlemek isteyenler için bir paket ve efistub-bootyukarıda bahsettiğim senaryoları içeren bir paket sağlayabilir .

UEFI’nin yalnızca 2005’te tanımlandığı göz önüne alındığında , şartnameyi desteklemeyen bir sürü eski donanım var. UEFI'yı standart bir dağılıma eklemek için, bir yerine iki kod yolunun test edilmesi gerekir ve yalnızca önyükleme kodu titizlikle titiz değildir, test edilmesi en rahatsız edici zaman alan kod bitlerinden biridir.

Dağıtımların kaynakları sınırlı ve bunun ötesinde herhangi bir sebep olmayabilir. Oldukça basit ve güvenli olabilir, ancak daha fazla bakım çalışması gerektirecek ne olursa olsun , yalnızca UEFI olmayan sistemler için grub seçeneğinin korunması gerekir.

Herkesin dağıtımların benimsemesini görmek istedikleri özellik ve seçeneklerin bir listesi olduğundan eminim (size birkaç sayfa vereceğim) ve bunların birçoğunun "tamamen kolay, güçlükler olmadan, dürüstçe olacağından şüphesiz." .. ". Ancak, bunları uygulamak için sonsuz sayıda insan saati yoktur. Bu gibi kararlarla karşılaştığımızda ("Bu özelliğe iş koyar mıyız, diğerlerine karşı mı?") Temel sorular şöyle olmalıdır:

• Bu gerekli? (Buradaki cevap hayır).
• Kaç kişi faydalanacak ve ne kadar? (IMO: çok az)
• Kullanıcının, hiçbir şey yapmadan kendi kendine uyum sağlayabileceği makul bir alternatif var mı? (Görünüşe göre var.)

İnsanların dikkat dağıtıcıları kullanmasının nedeni, herkesin kaynak kısıtlamalarına maruz kalmasıdır (aksi takdirde, sadece bir ekip kiralayın, onlara bir alan ve ekipman satın alın ve istediğiniz gibi her şeyi yapmalarını isteyin). Dolayısıyla gerçek şu ki dağıtımlar kullanıcılarının genel ihtiyaçlarını yansıtıyor .

Bununla birlikte, bunun zaman içinde bir seçenek olarak benimseneceğini düşünüyorum ve soruyu geçersiz kıldım.

Gruba ek olarak UEFI önyükleyicilerini hedef almak kalite kontrol ve desteğini zorlaştırır. Dağıtımlar UEFI spesifikasyonundan ziyade grubun hedefini oluşturuyor, çünkü grub özgür yazılım, hacklenebilir, daha esnek ve yüksek kalitede. Bir öğreticiyi takip ederek ve UEFI bölümünü monte ederek hala saf bir UEFI önyüklemesi alabilirsiniz /boot, çünkü bunu yaparsanız, bakım size bağlıdır.

Asıl sorun, insanların nasıl çalıştığını anlamadıkları. Örneğin, sorunuzda üç komut dosyasının gerekli olduğunu söylersiniz ve buradaki yanıtların çoğu, çalışması için gereken tüm ek bakımlarla ilgilidir - ancak gerçek şu ki, bu komut dosyalarına ihtiyacınız yok. veya herhangi bir ek iş.

İhtiyacınız olan tek şey, ESP'yi veya çekirdeği korumak istediğiniz her yerde /boot, tek bir çizgiyle yapabileceğiniz bağlama bağlamaktır /etc/fstab. Bunu yapın ve mevcut çekirdek güncelleme komut dosyalarının tümü çalışmaya devam edecektir.

Benim `/ etc / fstab 'benziyor:

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
#

Üreticiye özgü ayarlarla ilgili, burada yapılmış iyi bir nokta var. UEFI açıkça gelmez değil bir önyükleme menüsü için arayüz belirtin. Bu kapmak için ve makineler arasında tutarlı olmayacak. Can sıkıcı, ama doğru.

Ve böylece, aslında sadece gibi bir yükleyici daha fazla iş yapılmasını sağlarken, rEFInd gibi bir menü uygulaması farklılıkları eşitler ve her şeyi basitleştirir.grub

UEFI ve GRUB'u geçici bir uygulama çözümü olarak zincirlediler.

UEFI desteği ve beraberindeki sorunlar (örneğin Güvenli Önyükleme) çözüldükçe, daha fazla dağıtım doğrudan kullanacaktır. Bu arada, bu hala çok yeni: Google Trends, oldukça sınırlı bir kullanım olduğunu gösteriyor: http://www.google.com/trends/explore?q=cannot+boot+uefi#q=uefi%2C%20%20efi%2C % 20% 20bios ve CMPT = q

Diğerleri, saf bir UEFI çözümü için gitmenin ve / veya hem UEFI olmayan hem de saf UEFI sistemlerini aynı anda desteklemenin olası tehlikelerinden bahsetti. Bir UEFI çekirdeği UEFY olmayan bir sistemde çalışabilir, ancak çekirdek güncelleme araçlarının bir GRUB menüsünü veya bir UEFI önyükleme menüsünü VEYA her ikisini de vb. Güncellemesi gerekir.

Gerçekten bahsedildiği gibi kalite kontrolü ile ilgilidir: bu kodla ilgili sorunların büyük bir etkisi vardır: Bilgisayar yeni kullanıcıları önyüklemediğinde, yani potansiyel Linux dönüştürürken, onu çöpe atıp "güvenli" bir şeye geri dönecektir.

Ancak, teknolojinin daha fazla benimsemesiyle birlikte dediğim gibi, standart olacak.

Ürün yazılımı hatalarını gidermek için ekstra kod gerekir

Grub zincirleme olmadığında, dağıtım doğru bir şekilde önyükleme yapmak için bellenime daha fazla dayanır. Herhangi bir yazılımın sorunları olacağı için ürün yazılımı da buna açıktır. Artık Linux dağıtımları da bu ürün yazılımı hatalarını gidermek için yazmak zorunda kalacak.

Örnek olarak gerçek bir hayat olgusu. Asrock H81 pro BTC P1.80 anakartı ile önyükleme menüsü girişleri oluşturulmasını sağlıyor efibootmgr. Birden fazla önyükleme menüsü girişi oluşturulmuş olabilir ve önyükleme sırası kullanılarak değiştirilebilir efibootmgr --bootorder XXXX,YYYY,ZZZZveya geçici bir sonraki önyükleme seçeneği kullanılarak ayarlanabilir efibootmgr --bootnext XXXX. Her ikisi de bu komut geri dönüşü çıktısı, örneğin önyükleme sırasının değiştiği veya bir sonraki önyüklemenin çalışacağı fikrini verir BootNext: XXXX. Ancak yeniden başlatma sırasında inatçı bellenim yeni istenen önyükleme seçeneğini yoksayar ve önceki BootCurrent:değere yeniden başlar . Kalıcı bir önyükleme sırası değişikliği yalnızca üretici yazılımı kurulum yardımcı programından yapılabilir. Ve kalıcı olmayan bir değişiklik hiç mevcut değildir.

Önyükleme yalnızca EFI tarafından gerçekleştirilirse ve önyükleyiciyi kaldırırsak, bunun hem HW satıcısı hem de İşletim Sistemi üreticileri için zor olacağını düşünüyorum. HW satıcısı, işletim sistemi yapan şirketler için çekirdeğinin farklı FW tarafından yüklenip yüklenmediği gibi olacaktır.

Üstelik EFI’den çekirdeğin doğrudan önyüklenmesiyle istifin neresinde güvenli bir çizme olacak? Mevcut senaryoda, kontrol OS önyükleyicisine gittiğinde, daha sonra önyükleyici çekirdeğin doğru imzalanıp imzalanmadığını kontrol eder. Çekirdeği doğrudan EFI'den yüklersek, o zaman sadece yığının tamamı rahatsız edileceği için karışıklık yaratacağını düşünüyorum. Ne anlama geldiğime dair bir görüş.