Bagaimana cara Linux menangani partisi / boot terpisah?


11

Saya tertarik untuk mempelajari tentang bagaimana Linux menangani partisi boot terpisah. Saya tidak tertarik untuk benar-benar melakukan ini, tetapi saya ingin tahu bagaimana ini bekerja di bawah tenda.

Pertimbangkan hard drive sda, yang memiliki dua partisi sda1dan sda2. Katakanlah itu sda2adalah rootpartisi /yang berisi OS Linux.

Pemahaman saya adalah bahwa bootloader GRUB2, sudah terpasang ke /boot. Ketika direktori /bootberada di partisi yang terpisah sda2, bagaimana ini bisa terjadi sebelum di /-mount?

Bagaimana interaksi antara BIOS, rekaman boot Master dan GRUB (atau file /boot) berhasil terjadi dalam kasus ini? Apakah data dalam /bootsebenarnya tidak dipasang ke sistem /file pada tahap awal ini?

Catatan: pertanyaan ini berkaitan dengan pemasangan partisi root, tetapi tidak membahas partisi boot terpisah.

Jawaban:


18

Inilah masalah dalam pemahaman Anda:

Pemahaman saya adalah bahwa bootloader GRUB2, sudah di-mount ke / boot.

GRUB tidak "dipasang" saat boot. GRUB diinstal ke /boot, dan diambil dari kode di Master Boot Record. Berikut ini adalah ikhtisar yang disederhanakan dari proses boot modern, dengan asumsi distribusi GNU / Linux dengan MBR / BIOS (bukan GPT / UEFI):

  1. BIOS memuat.
  2. BIOS memuat potongan kecil kode yang ada di Master Boot Record.
  3. GRUB tidak muat dalam 440 byte, ukuran Master Boot Record. Oleh karena itu, kode yang dimuat sebenarnya hanya mem-parsing tabel partisi, menemukan /bootpartisi (yang saya percaya ditentukan saat Anda menginstal GRUB ke Master Boot Record), dan mem-parsing informasi sistem file. Itu kemudian memuat Tahap 2 GRUB. (Di sinilah penyederhanaan masuk.)
  4. Tahap 2 GRUB memuat semua yang dibutuhkan, termasuk konfigurasi GRUB, lalu menyajikan menu (atau tidak, tergantung pada konfigurasi pengguna).
  5. Urutan boot dipilih. Ini bisa dengan timeout, oleh pengguna memilih entri menu, atau dengan mem-boot daftar perintah.
  6. Urutan booting mulai dijalankan. Ini dapat melakukan beberapa hal - misalnya, memuat kernel, memuat rantai ke bootloader lain - tetapi mari kita asumsikan bahwa urutan boot adalah GNU / Linux standar.
  7. GRUB memuat kernel Linux.
  8. GRUB memuat ramdisk awal .
  9. Ramdisk awal dipasang di /bawah /new_root(mungkin secara kriptografis membuka kuncinya), mulai udev, mulai resume-from-swap, dll.
  10. Ramdisk awal menggunakan pivot_rootutilitas untuk ditetapkan /new_rootsebagai yang asli /.
  11. initdimulai. Partisi dipasang, daemon memulai, dan sistem melakukan boot.

Perhatikan bagaimana kernel hanya dimuat pada langkah 7. Karena itu, tidak ada konsep pemasangan sampai langkah 7 . Inilah sebabnya mengapa /bootharus dipasang kembali pada langkah 9, meskipun GRUB telah menggunakannya.

Mungkin juga berguna untuk melihat bagian GRUB 2 dari halaman Wikipedia di GRUB.


Anda benar-benar menemukan kebingungan saya. Inilah yang saya cari. Jadi awalnya /boottidak merujuk ke direktori yang dipasang di partisi root?
jII

@ jesterII luar biasa! dalam hal itu, maukah Anda menerima jawaban ini dengan mengklik tanda centang tepat di bawah panah suara?
strugee

7
Kode MBR tidak dapat menguraikan sistem file. Itu memuat gambar inti grub dari sektor-sektor yang tidak digunakan mengikuti MBR sebelum partisi pertama, dan kode itu memahami bagaimana menemukan dan memasang partisi / boot untuk menemukan file konfigurasi grub, modul tambahan, dan kernel Anda. Juga pivot_root dianggap sebagai hack kotor dan telah diganti dengan run-inityang menghapus semua file di initramfs, dan kemudian chroot ke sistem file root.
psusi

Proses boot modern sekarang harus menjadi proses boot Legacy karena UEFIsemakin banyak popurlar ;-) @strugee
Kiwy

1
@ Strugee, setelah diskusi di mailing list util-linux tampaknya ingatan saya sedikit tidak aktif: mereka berhenti mengizinkan pivot_root di rootfs yang sebenarnya, jadi itu sebabnya tidak ada yang menggunakannya saat boot lagi. Systemd menggunakannya pada saat shutdown, bukan untuk kembali ke initrd yang asli (yang menghapus sendiri ketika beralih ke root yang sebenarnya), tetapi untuk beralih ke yang baru dimuat. Lihat marc.info/?l=util-linux-ng&m=139100788306216&w=2
psusi

6

Pertanyaan 1

Pemahaman saya adalah bahwa bootloader GRUB2, sudah di-mount ke / boot. Ketika direktori / boot berada di partisi sda2 yang terpisah, bagaimana ini bisa terjadi sebelum / sebenarnya di-mount?

Saya rasa pemahaman Anda tidak benar di sini. Dari halaman Wikipedia GNU GRUB :

kutipan

Ketika komputer dihidupkan, BIOS komputer menemukan perangkat bootable utama yang dikonfigurasi (biasanya hard disk komputer) dan memuat serta menjalankan program bootstrap awal dari master boot record (MBR). MBR adalah sektor pertama dari hard disk, dan memiliki angka 0 (penghitungan sektor dimulai dari 0). Untuk waktu yang lama, ukuran suatu sektor adalah 512 byte, tetapi sejak 2009 ada hard disk yang tersedia dengan ukuran sektor 4.096 byte, yang disebut disk Format Lanjutan . Pada Oktober 2013, hard disk tersebut masih diakses di sektor 512-byte, dengan memanfaatkan emulasi 512e .

Dalam GRUB versi 2 terjadi hal berikut:

kutipan

Booting Komputer

Ketika daya dihidupkan, hal berikut terjadi:

  • Perangkat keras menginisialisasi, mengatur CPU ke mode nyata (tidak ada memori virtual) dan melompat ke lokasi tetap 0xFFFF0 (bawaan pada sirkuit CPU)
  • Kode BIOS yang disimpan dalam ROM atau memori flash yang dipetakan ke lokasi tersebut dieksekusi.
  • Kode BIOS melihat data konfigurasi BIOS untuk melihat mana yang merupakan perangkat booting. Data konfigurasi BIOS ini biasanya dapat diedit dengan menekan beberapa urutan tombol khusus tepat setelah menyalakannya, yang menyebabkan program konfigurasi BIOS berjalan. Antara lain, perangkat boot biasanya dapat dipilih di sini.
  • Kode BIOS memuat MBR perangkat boot ke dalam RAM. Ingatlah bahwa MBR hanya 512 byte! Data yang dimuat tentu saja program & data yang menginstal secara dinamis dibuat dan ditulis di sana ketika program instalasi grub dijalankan.
  • Kode BIOS melompat ke alamat awal MBR yang dimuat (yaitu kode Grub dijalankan untuk pertama kali sejak dinyalakan).
  • Kode MBR Grub memuat satu sektor tunggal yang alamatnya terhubung ke blok MBR. Itu kemudian loop di atas (alamat, len) pasangan di sektor itu memuat semua data dari disk ke memori (yaitu memuat konten file /boot/grub/core.img, atau salinan "tertanam" -nya). Kode MBR kemudian melompat ke kode yang dimuat, yaitu "mengeksekusi" program di core.img.
  • Seperti yang dijelaskan di bagian "Menginstal Grub", trik menanamkan alamat blok disk mentah ini memungkinkan untuk menyimpan core.imgdi ruang yang tidak ada di partisi, dan yang tidak pernah diformat sebagai sistem file sama sekali ("embedding"). Dan dalam hal ini, jika core.imgdiubah, selama versi baru "tertanam" di lokasi yang sama, kode MBR tidak perlu diperbarui.
  • Atau, dimungkinkan untuk core.imgberada di dalam sistem file nyata, dan bagi Grub untuk membaca core.imgkonten file tanpa memiliki driver untuk sistem file itu. Namun dalam hal ini, jika core.imgdimodifikasi maka blok pertama dari file tersebut mungkin dapat diberikan alamat baru pada disk; jika ini terjadi maka MBR harus diperbarui untuk menunjuk ke lokasi baru ini. Namun demikian, seperti core.imgyang biasanya diperbarui dengan menjalankan grub-install, ini biasanya tidak menjadi masalah.
  • Perhatikan bahwa secara teoritis, jika core.imgberada di perangkat yang berbeda dari MBR, dan perangkat keras baru ditambahkan maka catatan MBR yang dihasilkan Grub mungkin tidak dapat memuat core.imgfile dengan benar ; id perangkat di mana sektor pertama yang core.imgditemukan adalah terprogram ke dalam MBR, tidak dicari. Namun tidak ada solusi untuk ini; tidak ada cara untuk menanamkan setara dengan perintah "pencarian" Grub ke MBR 512-byte. Masalah ini tidak mungkin; biasanya core.imgtertanam pada perangkat yang sama dengan MBR. Dan sekali core.imgtelah dimuat dapat menggunakan search.mod untuk menemukan semua /boot/grubfile lebih lanjut , dan karena itu kebal terhadap penyusunan ulang perangkat keras.
  • core.imgKode yang dieksekusi sekarang menginisialisasi semua modul yang dibangun di dalamnya (dihubungkan ke core.img); salah satu modul ini akan menjadi driver sistem file yang mampu membaca sistem file di mana direktori /boot/grubhidup.
  • Ini juga mendaftarkan serangkaian perintah bawaan: set, unset, ls, insmod.
  • Jika "file config" telah ditautkan ke dalamnya core.img, ini kemudian diteruskan ke parser skrip build-in yang sangat sederhana untuk diproses. Perintah skrip dalam file konfigurasi hanya dapat menjalankan perintah built-in atau linked-in. Skenario sederhana (mis. Mem-boot komputer desktop khas dari drive lokal) tidak memerlukan file konfigurasi; fasilitas ini digunakan untuk hal-hal seperti booting melalui pxe, nfs jarak jauh atau ketika /boot/grubada pada perangkat LVM.
  • Core.imgsekarang memuat file “/boot/grub/normal.mod”secara dinamis dari disk, dan melompat ke fungsi entri. Perhatikan bahwa langkah ini membutuhkan driver sistem file yang sesuai untuk diatur (yaitu built-in).

     ss dari proses boot

CATATAN: Ketika Anda melihat menu GRUB2 khas tempat Anda memilih OS / Kernel mana yang akan di-boot, Anda merujuk /boot/grubdirektori sistem pada titik ini.

                                         ss dari grub tui

Referensi


Seseorang harus memperbaiki entri wikipedia itu karena itu salah. Tahap 1 / 1.5 / 2 hanya berlaku untuk legacy grub. Mereka sepenuhnya dihilangkan dengan dalam penulisan ulang grub2 dan Anda tidak akan menemukan referensi ke istilah-istilah itu dalam dokumentasi resmi grub2.
psusi

@psusi - terima kasih telah menjelaskan. Saya agak bingung ketika saya melihat mereka disebutkan di sana juga, karena saya pernah mendengar hal yang sama, bahwa 1 / 1.5 / 2 hilang. Saya tidak tahu harus bertanya siapa untuk mengedit artikel Wikipedia, saya tidak akan merasa memenuhi syarat untuk mengedit posting seperti itu. Mungkin mengingatkan tim GRUB2 akan menjadi hal terbaik berikutnya?
slm

@psusi - ini referensi. ke tahap yang dihilangkan dalam off. docs untuk GRUB2: gnu.org/software/grub/manual/grub.html ... "File gambar (lihat Gambar) yang membentuk GRUB telah ditata ulang; Tahap 1, Tahap 1.5, dan Tahap 2 sudah tidak ada lagi."
slm

6

Linux (kernel) tidak peduli berapa banyak partisi boot yang Anda miliki. Memuat kernel dari disk adalah tugas dari bootloader (mis grub. grub2, lilo) Dan alat-alat ini juga tidak peduli dengan jumlah lokasi yang mungkin ditemukan oleh kernel. Mereka hanya peduli dengan lokasi spesifik.

Sebagai contoh, partisi boot saya adalah /dev/md1, yang merupakan mirror RAID mdadm yang didukung oleh partisi fisik /dev/sde1dan /dev/sdf1. Saya dapat me-mount ini secara individual jika saya mau dan karena itu secara teknis ini dianggap memiliki dua partisi boot, meskipun mereka harus berisi data yang sama.

Memiliki dua partisi untuk / boot untuk saya adalah masalah ketersediaan, tetapi keduanya bisa sama / partisi boot. Langkah selanjutnya adalah bagaimana bootloader tahu? Begini caranya:

menuentry 'Linux 3.10.17 (sde) kernel-3.10.17-g' {
        root=hd0,1
        linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3
        initrd /boot/initrd-3.10.17-g
}

menuentry 'Linux 3.10.17 (sdf) kernel-3.10.17-g' {
        root=hd1,1
        linux /boot/kernel-3.10.17-g domdadm dolvm root=/dev/md3 
        initrd /boot/initrd-3.10.17-g
}

Ini adalah kutipan dari grub2konfigurasi dan Anda akan perhatikan bahwa satu-satunya perbedaan adalah root=hd0,1dan root=hd1,1yang menentukan partisi boot mana yang menjadi referensi.


Sekarang untuk memandu Anda melalui boot sehingga Anda dapat memahami apa yang sedang terjadi di sini.

  • BIOS membaca MBR dari volume boot dan melompat ke bootloader
  • Bootloader (mis. grub2) Dikonfigurasi untuk mengetahui perangkat dan partisi mana yang berisi kernel Anda. Grub2 mengakses partisi ini secara langsung dan memuat kernel Anda ke dalam memori.
  • Bootloader Anda kemudian melompat ke kernel dan kernel mem-boot mesin Anda.

Bootloader tidak peduli berapa banyak partisi boot yang Anda miliki, itu hanya peduli di mana mereka berada dan Anda harus memberi tahu informasi itu.

Kernel tidak peduli berapa banyak partisi boot yang Anda miliki, karena tidak perlu melihatnya (Anda hanya perlu membuatnya tersedia untuk menambahkan kernel baru misalnya).

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.