In che modo un kernel Linux è in grado di accedere al suo initramfs / initrd assegnato?


8

Sto cercando di capire il processo di avvio di una macchina nel suo insieme dal momento in cui hai premuto il pulsante di accensione. C'è questo pezzo unico dal bootloader allo stadio initramfs che non capisco bene tra alcuni bit più piccoli.

Data questa configurazione di Grub per una voce, tratta da una recente installazione predefinita di Ubuntu:

insmod gzio
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root 96fb7310-5adb-4f66-bf59-04acd08d76a3
echo    'Loading Linux x.y.z ...'
linux   /vmlinuz-x.y.z root=/dev/mapper/some-device-name ro nomodeset 
echo    'Loading initial ramdisk ...'
initrd  /initrd.img-x.y.z

Cosa fa effettivamente ciò in termini di stato del sistema e memoria? Capisco che il compito di Grub è "caricare ed eseguire il kernel" e ha un proprio set di moduli per accedere ai file su dispositivi (o rete) per raggiungerli. Nell'esempio qui insmods, set roote search- ma questo è solo dal punto di vista di Grub, e non condiviso con il kernel, giusto?

Sto anche immaginando che Grub stia caricando (una copia?) Del kernel in memoria ( linuxcomando ) e stia dando dei calci per iniziare l'esecuzione. (due passaggi diversi apparentemente - quindi, come?) I parametri dati possono essere letti nel kernel e interpretati (è una grande stringa mappata in memoria da qualche parte?) e forniscono le opzioni per organizzare le cose richieste.

Vedo anche questa initrdopzione. Questo punta al mio initramfs compresso con gzip, necessario per avviare il dispositivo root effettivo specificato da root=. Ma come viene fornito questo initramfs al kernel? Non viene passato alcun indirizzo di memoria a dove può caricarlo, né è in grado di accedervi da solo, poiché è già caricato prima dell'avvio del kernel. Alcuni documenti del kernel dicono che questo "file system" di initramfs è accessibile /dev/ram0, ma non vedo come diventi un file di dispositivo accessibile per cominciare. Sta succedendo qualcosa sott'acqua che non vedo, immagino.

Inoltre non vedo come questo si collega ad altri caricatori di avvio, comprese le piattaforme integrate, ad esempio usando U-boot / Coreboot. Sta facendo la stessa cosa di Grub (stessi indirizzi di memoria standard?) E in che misura questi si confrontano con Grub per quanto riguarda il caricamento del kernel / initrd?

Solo per essere chiari sulle mie domande, penso di capire perché esistono le diverse fasi di avvio e quali transizioni avvengono, ma non vedo come avvengano e quali siano le esatte responsabilità per ciascuna fase. Ho la sensazione che mi sto perdendo qualche "standard" a cui tutto si riduce.

Gradirei qualche spiegazione al riguardo.


Nota il bootcomando implicito alla fine della sequenza. Non sono sicuro di cosa faccia esattamente in Grub, ma se usi la riga di comando di Grub per inserire questi comandi manualmente, devi booto rimarrà per sempre grub>(o almeno, finché non ti annoi e spegni il computer ). I comandi precedenti "semplicemente" hanno creato un ambiente.
un CVn

@ MichaelKjörling Dalla mia comprensione ora, bootla CPU salterà all'indirizzo del kernel caricato (avvia l'esecuzione). Per una voce di menu questo è implicitamente definito. vedi questo .
Gertvdijk,

Risposte:


5

In generale deve esserci un qualche tipo di protocollo perché in genere non è sufficiente caricare un file in memoria e saltare in una posizione specifica, ma è necessario passare argomenti aggiuntivi come i parametri del kernel, ovvero accedere agli argomenti memdisk da DOS .

Dato che questo dipende dall'hardware (arm è diverso da x86 per esempio) devi trovare le informazioni corrette, vedi questo articolo sull'avvio di arm o il protocollo di avvio Linux / x86 per alcuni esempi.


6

Il bootloader memorizza initrd in una posizione in memoria e comunica al kernel l'indirizzo di memoria dell'immagine initrd. La maggior parte dei sistemi Linux moderni usa lo schema initramfs usando dracut , che in realtà è un archivio cpio (piuttosto che un'immagine del disco) che è decompresso in un filesystem tmpfs creato dal kernel poco dopo l'esecuzione.


Sono arrivato così lontano; ma come fa il bootloader a dire al kernel la posizione in memoria? Dove recupera quell'indirizzo di memoria il kernel?
Gertvdijk,

3
@gertvdijk dà un'occhiata a kernel.org/doc/Documentation/x86/boot.txt , descrive come comunica il bootloader con il kernel, cioè il bootloader deve fornire anche i parametri del kernel ecc.
Ulrich Dangel,

@UlrichDangel Nice! Esattamente quello che stavo cercando. Apparentemente, è un protocollo specifico dell'hardware (in questo caso x86) che descrive tutto. Scrivilo come risposta con una breve descrizione e lo accetterò.
gertvdijk,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.