Nighpher, cercherò di rispondere alla tua domanda, ma per una descrizione più completa del processo di avvio, prova questo articolo su IBM.
Ok, presumo che tu stia usando GRUB o GRUB2 come bootloader per la spiegazione. Prima di tutto, quando il BIOS accede al tuo disco per caricare il bootloader, utilizza le sue routine integrate per l'accesso al disco, che sono memorizzate nel famoso interrupt 13h. Bootloader (e kernel in fase di installazione) fanno uso di queste routine quando accedono al disco. Si noti che il BIOS funziona in modalità reale (modalità a 16 bit) del processore, quindi non può indirizzare più di 2^20 byte di RAM (2^20, non 2^16, perché ogni indirizzo in modalità reale è composto da segment_address* 16 + offset, dove sia l'indirizzo del segmento che l'offset sono a 16 bit, vedi "segmentazione della memoria x86" su Wikipedia). Pertanto, queste routine non possono accedere a più di 1 MiB di RAM, che è una limitazione rigorosa e un grave inconveniente.
Il BIOS carica il codice del bootloader direttamente dall'MBR, i primi 512 byte del disco, e lo esegue. Se stai usando GRUB, quel codice è GRUB stage 1. Quel codice carica GRUB stage 1.5, che si trova nei primi 32 KiB di spazio su disco, chiamato regione di compatibilità DOS, o da un indirizzo fisso del file system. Non è necessario comprendere la struttura del file system per farlo, perché anche se lo stage 1.5 si trova nel file system, è codice "raw" e può essere caricato direttamente nella RAM ed eseguito:vedere "Dettagli di GRUB sul PC " su pixelbeat.org, che è la fonte dell'immagine qui sotto. Il caricamento dello stage1.5 dal disco alla RAM utilizza le routine di accesso al disco del BIOS.
Stage1.5 contiene le utilità del filesystem, in modo che possa leggere lo stage 2 dal filesystem (beh, usa ancora il BIOS 13h per leggere dal disco alla RAM, ma ora può decifrare le informazioni del filesystem sugli inode, ecc., e ottenere codice non elaborato fuori dal disco). I BIOS meno recenti potrebbero non essere in grado di accedere all'intero HD a causa di limitazioni nella modalità di indirizzamento del disco:potrebbero utilizzare il sistema Cylinder-Head-Sector, incapace di indirizzare più dei primi 8GiB di spazio su disco:http://en.wikipedia. org/wiki/Cylinder-head-sector.
La fase 2 carica il kernel nella RAM (di nuovo, utilizzando le utilità del disco del BIOS). Se è un kernel 2.6+, ha anche initramfs compilato all'interno, quindi non è necessario caricarlo. Se si tratta di un kernel più vecchio, il bootloader carica anche un'immagine initrd autonoma in memoria, in modo che il kernel possa montarlo e ottenere i driver per il montaggio del file system reale dal disco.
Il problema è che il kernel (e il ramdisk) pesano più di 1MiB; quindi, per caricarli nella RAM devi caricare il kernel nel primo 1MiB, quindi passare alla modalità protetta (32 bit), spostare il kernel caricato nella memoria alta (liberare il primo 1MiB per la modalità reale), quindi tornare di nuovo alla modalità reale (16 bit), porta il ramdisk dal disco al primo 1MiB (se è un initrd separato e un kernel precedente), possibilmente passa di nuovo alla modalità protetta (32 bit), mettilo dove appartiene, possibilmente ottieni tornare alla modalità reale (o meno:https://stackoverflow.com/questions/4821911/does-grub-switch-to-protected-mode) ed eseguire il codice del kernel. Attenzione:non sono del tutto sicuro della completezza e dell'accuratezza di questa parte della descrizione.
Ora, quando finalmente esegui il kernel, lo hai già e il ramdisk caricato nella RAM dal bootloader , quindi il kernel può utilizzare le utilità del disco da ramdisk per montare il tuo vero file system root e fare il pivot root su di esso. I driver ramfs sono presenti nel kernel, quindi può comprendere il contenuto di initramfs, ovviamente.