nmbl (No More Boot Loader): बूटलोडर की जगह kernel का उपयोग

• Red Hat की बूटलोडर इंजीनियरिंग टीम GRUB बूटलोडर को बदलने के लिए एक नया तरीका विकसित कर रही है
• nmbl (no more boot loader) नाम का एक तेज़ और सुरक्षित Linux-आधारित user space solution प्रस्तावित किया गया है
• GRUB बूटलोडर की समस्याएँ
  • GRUB एक शक्तिशाली और लचीला बूटलोडर है, जिसका उपयोग कई architectures में होता है (x86_64, aarch64, ppc64le OpenFirmware)
  • लेकिन इसकी functionality जटिल है, इसलिए maintenance कठिन है, और कई बार Linux kernel के साथ duplicate हो जाती है या उससे पीछे रह जाती है
  • इसके अलावा, यह कई security vulnerabilities भी पैदा करता है
• Linux kernel के फायदे
  • Linux kernel के पास बड़ा developer base है, इसलिए features का तेज़ विकास और vulnerabilities पर जल्दी response संभव है
  • overall review भी अधिक thorough तरीके से होता है
• नया solution: kernel को बूटलोडर की तरह उपयोग करना
  • इसे EFI stub द्वारा UEFI में load किया जाता है, और Unified Kernel Image (UKI) के रूप में package किया जाता है
  • kernel, initramfs, kernel command line और final boot target तक पहुँचने के लिए ज़रूरी सब कुछ इसमें शामिल होता है
  • सभी ज़रूरी drivers, file system support और networking पहले से built-in होते हैं, जिससे code duplication रोकी जाती है

[xguru]

Hacker News टिप्पणियाँ

• 10 साल से UEFI इस्तेमाल कर रहा हूँ। बूट समय थोड़ा कम होता है, लेकिन bootloader के कई फ़ायदे हैं

  • Windows के साथ dual boot आसानी से किया जा सकता है
  • kernel cmdline को एडिट करके boot समस्याएँ हल की जा सकती हैं
  • कई kernel और initrd images में से आसानी से चुना जा सकता है
  • UEFI settings menu तक आसानी से पहुँचा जा सकता है
  • दूसरे EFI applications को boot किया जा सकता है

• FreeBSD का bootloader initramfs के बिना boot कर सकता है। ज़्यादा स्मार्ट bootloader की ज़रूरत है

  • यह ZFS को समझ सकता है और ज़रूरी modules पहले से load कर सकता है
  • यह module dependencies को समझ सकता है और सभी ज़रूरी modules पहले से load कर सकता है

• UEFI environment की capabilities और limitations को लेकर बहुत ग़लतफ़हमियाँ हैं। प्रोजेक्ट के असली लक्ष्य को ग़लत समझा जा रहा है

  • Lennart की आलोचनात्मक पोस्ट ज़्यादा दिलचस्प चिंताएँ उठाती है

• इससे 90s के DEC Alpha systems पर Linux boot करने के लिए इस्तेमाल होने वाले MILO की याद आती है

  • एक intermediate bootloader की ज़रूरत होती है, और stability-केंद्रित release cycle चाहिए
  • data-driven menu/configuration layer की ज़रूरत है

• पहले Chromebook पर Linux+Coreboot इस्तेमाल किया था। Tianocore UEFI BIOS के driver bug की वजह से Linux को सीधे इस्तेमाल किया था

  • एक Rust TUI लिखी थी जो सभी partitions mount करती थी और kernel image को kexec करती थी
  • मेरा मानना है कि सभी drivers को duplicate करने की ज़रूरत नहीं है

• UEFI और Linux की ज़्यादा capabilities को अपनाना बेहतर है। ZFSBootMenu 4 साल से EFI application दे रहा है

  • first-stage kernel boot में लगभग 1.5~2 सेकंड लगते हैं

• kexec compatibility issues को लेकर चिंता है

  • उदाहरण के लिए, NVidia module को kexec से पहले unload करना पड़ता है
  • ACPI issues और compatibility problems भी हैं
  • अनुमान है कि kexec mechanism को अलग-अलग kernel versions को support करने के लिए डिज़ाइन किया गया होगा

• EFI stub द्वारा multi-boot, kernel और initrd सेट करने के बाद jump करना सरल है

  • intermediate loader का बहुत बड़ा और जटिल होना ज़रूरी नहीं है
  • UEFI API और अलग programming environment से बचने के लिए पूरे Linux को शामिल करना अनावश्यक है

• यह जानने की जिज्ञासा है कि प्रस्तावित solution multi-OS boot को संभाल पाएगा या नहीं

  • grub Linux, Windows, और तीसरे OS तक को boot कर सकता है
  • चिंता है कि Red Hat का solution कहीं सिर्फ commercial use तक सीमित न रह जाए
  • ऐसे systems जो साल में सिर्फ एक-दो बार reboot होते हैं, उनके लिए यह किस समस्या का समाधान कर रहा है, समझना मुश्किल है

• समझ नहीं आता कि plain EFISTUB के बजाय यह solution क्यों इस्तेमाल करें

  • Arch पर EFISTUB इस्तेमाल कर रहा हूँ, और Windows boot करने के लिए BIOS menu का उपयोग करता हूँ
  • Linux-आधारित bootloader के फ़ायदे समझ में नहीं आते