Jak Linux radzi sobie z osobną partycją / boot?

Chciałbym dowiedzieć się, jak Linux radzi sobie z oddzielnymi partycjami rozruchowymi. Tak naprawdę nie jestem zainteresowany, ale chciałbym wiedzieć, jak to działa pod maską.

Rozważ dysk twardy sda, który ma dwie partycje sda1i sda2. Powiedzmy, że sda2jest to rootpartycja /zawierająca system operacyjny Linux.

Rozumiem, że bootloader GRUB2jest zamontowany na /boot. Kiedy jednak katalog /bootznajduje się na osobnej partycji sda2, jak to się dzieje, że /faktycznie został zamontowany?

Jak w tym przypadku przebiega interakcja między BIOS-em, głównym rekordem rozruchowym i GRUB-em (lub plikami /boot)? Czy to tak, że dane na tym etapie /bootnie są tak naprawdę montowane w /systemie plików?

Uwaga: to pytanie dotyczy montażu partycji głównej, ale nie omawia osobnej partycji rozruchowej.

Oto twój problem:

Rozumiem, że bootloader GRUB2 jest zamontowany na / boot.

GRUB nie jest „montowany” podczas uruchamiania. GRUB jest zainstalowany na /booti jest ładowany z kodu w Master Boot Record. Oto uproszczony przegląd nowoczesnego procesu rozruchu, przy założeniu dystrybucji GNU / Linux z MBR / BIOS (nie GPT / UEFI):

1. System BIOS ładuje się.
2. BIOS ładuje mały fragment kodu, który znajduje się w głównym rekordzie rozruchowym.
3. GRUB nie mieści się w 440 bajtach, wielkości głównego rekordu rozruchowego. Dlatego załadowany kod w rzeczywistości po prostu analizuje tablicę partycji, znajduje /bootpartycję (która, jak sądzę, jest ustalana podczas instalacji GRUBa w głównym rekordzie rozruchowym) i analizuje informacje o systemie plików. Następnie ładuje GRUB poziomu 2. (W tym miejscu pojawia się uproszczenie.)
4. Etap 2 GRUB ładuje wszystko, czego potrzebuje, w tym konfigurację GRUB, a następnie wyświetla menu (lub nie, w zależności od konfiguracji użytkownika).
5. Wybrano sekwencję rozruchową. Może to nastąpić po przekroczeniu limitu czasu, przez wybranie pozycji menu lub uruchomienie listy poleceń.
6. Rozpocznie się sekwencja rozruchowa. Może to zrobić wiele rzeczy - na przykład ładowanie jądra, ładowanie łańcuchowe do innego programu ładującego - ale załóżmy, że sekwencja rozruchowa jest standardowa GNU / Linux.
7. GRUB ładuje jądro Linuksa.
8. GRUB ładuje początkowy ramdysk .
9. Początkowy ramdysk montuje się /pod /new_root(możliwe odblokowanie kryptograficzne), uruchamia udev, zaczyna wznawiać od wymiany itp.
10. Początkowy ramdysk używa pivot_rootnarzędzia do ustawienia /new_rootjako rzeczywistego /.
11. initzaczyna się. Partycje są montowane, uruchamiane demony i system uruchamia się.

Zauważ, że jądro jest ładowane tylko w kroku 7. Z tego powodu nie ma koncepcji montowania aż do kroku 7 . Dlatego /bootnależy ponownie zamontować w kroku 9, mimo że GRUB już go używał.

Przydaje się również przeglądanie sekcji GRUB 2 strony Wikipedii na GRUB.

Pytanie 1

Rozumiem, że bootloader GRUB2 jest zamontowany na / boot. Kiedy jednak katalog / boot znajduje się na oddzielnej partycji sda2, jak to się dzieje, zanim / zostanie faktycznie podłączony?

Nie wydaje mi się, że rozumiesz tutaj. Ze strony Wikipedii GNU GRUB :

fragment

Gdy komputer jest włączony, BIOS komputera znajduje skonfigurowane podstawowe urządzenie rozruchowe (zwykle dysk twardy komputera) oraz ładuje i wykonuje początkowy program ładowania z głównego rekordu rozruchowego (MBR). MBR jest pierwszym sektorem dysku twardego i ma liczbę 0 (liczenie sektorów zaczyna się od 0). Przez długi czas rozmiar sektora wynosił 512 bajtów, ale od 2009 roku dostępne są dyski twarde o rozmiarze sektora 4096 bajtów, zwane dyskami formatu zaawansowanego . Od października 2013 r. Takie dyski twarde są nadal dostępne w sektorach 512-bajtowych przy użyciu emulacji 512e .

W wersji 2 GRUB ma miejsce:

fragment

Uruchamianie komputera

Po włączeniu zasilania dzieje się:

• Sprzęt inicjuje się, ustawia procesor w tryb rzeczywisty (bez pamięci wirtualnej) i przeskakuje do stałej lokalizacji 0xFFFF0 (podłączonej do obwodów procesora)
• Kod BIOS przechowywany w pamięci ROM lub pamięci flash zamapowanej na tę lokalizację jest zatem wykonywany.
• Kod BIOS sprawdza dane konfiguracji BIOS, aby zobaczyć, które urządzenie rozruchowe. Te dane konfiguracji BIOS można zwykle edytować, naciskając specjalną sekwencję klawiszy tuż po włączeniu zasilania, co powoduje uruchomienie programu konfiguracyjnego BIOS. Między innymi zwykle można tutaj wybrać urządzenie rozruchowe.
• Kod BIOS ładuje MBR urządzenia rozruchowego do pamięci RAM. Pamiętaj, że MBR to zaledwie 512 bajtów! Załadowane dane to oczywiście program i dane, które grub-install dynamicznie utworzyły i zapisały tam, gdy program grub-install został uruchomiony.
• Kod BIOS przeskakuje na adres początkowy załadowanego MBR (tzn. Kod Grub wykonuje się po raz pierwszy od momentu włączenia).
• Kod MBR Gruba ładuje pojedynczy sektor, którego adres jest podłączony do bloku MBR. Następnie zapętla pary (adres, długość) w tym sektorze, ładując wszystkie dane z dysku do pamięci (tj. Ładuje zawartość pliku /boot/grub/core.imglub jego „osadzonej” kopii). Kod MBR przeskakuje następnie do załadowanego kodu, tzn. „Wykonuje” program w core.img.
• Jak opisano w sekcji „Instalowanie gruba”, ten sposób osadzania adresów bloków surowego dysku umożliwia przechowywanie core.imgw przestrzeni, która nie znajduje się na partycji i która nigdy nie została sformatowana jako system plików („osadzanie”). W takim przypadku, jeśli core.imgzostanie zmodyfikowany, o ile nowa wersja jest „osadzona” w tym samym miejscu, kod MBR nie musi być aktualizowany.
• Alternatywnie możliwe jest, core.imgaby znajdował się w prawdziwym systemie plików, a Grub mógł odczytać core.imgzawartość pliku bez sterownika dla tego systemu plików. Jednak w takim przypadku, jeśli core.imgzostanie zmodyfikowany, to pierwszy blok pliku może otrzymać nowy adres na dysku; jeśli tak się stanie, MBR musi zostać zaktualizowany, aby wskazywał tę nową lokalizację. Niemniej jednak, jak core.imgzwykle aktualizuje się, uruchamiając grub-install, zwykle nie stanowi to problemu.
• Zauważ, że teoretycznie, jeśli core.imgznajduje się na innym urządzeniu niż MBR i dodany jest nowy sprzęt, wówczas rekord MBR wygenerowany przez Grub może nie być w stanie poprawnie załadować core.imgpliku; identyfikator urządzenia, na którym core.imgmożna znaleźć pierwszy sektor, jest podłączony do MBR, a nie wyszukiwany. Jednak nie ma na to rozwiązania; nie ma możliwości osadzenia odpowiednika polecenia Grub „search” w 512-bajtowym MBR. Ten problem jest jednak mało prawdopodobny; zwykle core.imgjest osadzony na tym samym urządzeniu co MBR. Po core.imgzaładowaniu może użyć search.mod, aby znaleźć wszystkie dalsze /boot/grubpliki, i dlatego jest odporny na zmiany w sprzęcie.
• Wykonany core.imgkod inicjuje teraz wszystkie moduły, które są w nim wbudowane (połączone core.img); jednym z tych modułów będzie sterownik systemu plików zdolny do odczytu systemu plików, w którym znajduje się katalog /boot/grub.
• Rejestruje również zestaw wbudowanych poleceń: set, unset, ls, insmod.
• Jeśli „plik konfiguracyjny” został połączony core.img, jest on następnie przekazywany do bardzo prostego wbudowanego analizatora skryptów w celu przetworzenia. Skrypty w pliku konfiguracyjnym mogą wywoływać tylko polecenia wbudowane lub połączone. Proste scenariusze (np. Uruchamianie typowego komputera stacjonarnego z dysku lokalnego) nie wymagają pliku konfiguracyjnego; /boot/grubfunkcja ta jest używana do takich rzeczy jak uruchamianie poprzez pxe, zdalne nfs lub gdy jest na urządzeniu LVM.
• Core.imgteraz ładuje plik “/boot/grub/normal.mod”dynamicznie z dysku i przeskakuje do jego funkcji wprowadzania. Należy pamiętać, że ten krok wymaga skonfigurowania odpowiedniego sterownika systemu plików (tj. Wbudowanego).

UWAGA: Kiedy zobaczysz typowe menu GRUB2, w którym wybierasz system operacyjny / jądro do uruchomienia, odwołujesz się do /boot/grubkatalogu systemu w tym momencie.

Bibliografia

• Uruchamianie Linuksa na x86 za pomocą Grub2
• GNU GRUB - Wikipedia
• 6 etapów procesu rozruchu systemu Linux (sekwencja uruchamiania)
• Wewnątrz procesu rozruchu systemu Linux
• Proces uruchamiania systemu Linux
• Program ładujący GRUB 2 - Pełny samouczek - Dedoimedo

Linux (jądro) nie dba o to, ile masz partycji rozruchowych. Załadowaniu jądra z dysku jest zadaniem bootloadera (np grub, grub2, lilo) oraz narzędzia te również nie dbają o liczbie miejsc jądro może być zlokalizowane. Dbają tylko o konkretną lokalizację.

Na przykład moją partycją rozruchową jest /dev/md1lustro RAID mdadm wspierane przez partycje fizyczne /dev/sde1i /dev/sdf1. Mogę montować je indywidualnie, jeśli chcę i jako takie technicznie liczy się to, że mam dwie partycje rozruchowe, chociaż powinny one zawierać te same dane.

Posiadanie dwóch partycji dla / boot jest dla mnie problemem związanym z dostępnością, ale mogą być równie różne partycje / boot. Następnym krokiem jest, skąd bootloader wie? Oto jak:

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
}

Jest to wyjątek od grub2konfiguracji i będziesz pamiętać, że jedyne różnice są root=hd0,1i root=hd1,1które ustalają której partycji rozruchowej, która odwołuje wjazdowych.

Teraz poprowadzę Cię przez but, abyś mógł zrozumieć, co się tutaj dzieje.

• BIOS odczytuje MBR z woluminu rozruchowego i przeskakuje do bootloadera
• Program ładujący (np. grub2) Jest skonfigurowany tak, aby wiedzieć, które urządzenie i partycja zawiera twoje jądro. Grub2 uzyskuje bezpośredni dostęp do tej partycji i ładuje jądro do pamięci.
• Program ładujący następnie wskakuje do jądra, a jądro uruchamia maszynę.

Program ładujący nie obchodzi, ile masz partycji rozruchowych, zależy tylko na tym, gdzie się znajdują i musisz podać te informacje.

Jądro nie obchodzi, ile masz partycji rozruchowych, ponieważ nigdy nie musi ich widzieć (wystarczy mieć je na przykład w celu dodania nowych jąder).