Nighpher, intentaré responder a tu pregunta, pero para una descripción más completa del proceso de arranque, prueba el artículo de IBM .
Ok, supongo que está utilizando GRUB o GRUB2 como su gestor de arranque para la explicación. En primer lugar, cuando el BIOS accede a su disco para cargar el gestor de arranque, utiliza sus rutinas integradas para el acceso al disco, que se almacenan en la famosa interrupción de 13 h. El cargador de arranque (y el núcleo en la fase de configuración) hacen uso de esas rutinas cuando acceden al disco. Tenga en cuenta que el BIOS se ejecuta en modo real (16 bits) del procesador, por lo tanto, no puede direccionar más de 2 ^ 20 bytes de RAM (2 ^ 20 no 2 ^ 16 porque cada dirección en modo real se compone de segmento_dirección * 16 + desplazamiento , donde la dirección del segmento y el desplazamiento son de 16 bits, consulte http://en.wikipedia.org/wiki/X86_memory_segmentation ). Por lo tanto, estas rutinas no pueden acceder a más de 1 MiB de RAM, lo cual es una limitación estricta y un gran inconveniente.
El BIOS carga el código del gestor de arranque directamente desde el MBR: los primeros 512 bytes de su disco y lo ejecuta. Si está utilizando GRUB, ese código es GRUB etapa 1. Ese código carga GRUB etapa 1.5, que se encuentra en los primeros 32 KiB de espacio en disco, denominado región de compatibilidad de DOS o desde una dirección fija del sistema de archivos. No es necesario comprender el sistema de archivos para hacer esto, porque incluso si la etapa 1.5 está en el sistema de archivos, es un código "en bruto" y se puede cargar directamente en la RAM y ejecutar: http://www.pixelbeat.org/ docs / disk / . La carga de stage1.5 desde el disco a la RAM hace uso de las rutinas de acceso al disco del BIOS.
Stage1.5 contiene las utilidades del sistema de archivos, para que pueda leer el stage2 del sistema de archivos (bueno, todavía usa BIOS 13h para leer desde el disco a la RAM, pero ahora puede descifrar la información del sistema de archivos sobre inodes, etc. y extraer el código sin procesar del disco). Es posible que las BIOS más antiguas no puedan acceder a toda la HD debido a limitaciones en su modo de direccionamiento de disco; pueden usar el sistema Cylinder-Head-Sector, incapaz de abordar más de los primeros 8 GiB de espacio en disco: http: //en.wikipedia. org / wiki / Cylinder-head-sector .
Stage2 carga el kernel en la RAM (nuevamente, utilizando las utilidades de disco del BIOS). Si es un kernel 2.6+, también tiene initramfs compilado, por lo que no es necesario cargarlo. Si se trata de un kernel más antiguo, el gestor de arranque también carga una imagen initrd independiente en la memoria, para que el kernel pueda montarlo y obtener controladores para montar el sistema de archivos real desde el disco.
El problema es que el kernel (y el ramdisk) pesan más de 1 MiB, por lo tanto, para cargarlos en la RAM, debe cargar el kernel al primer 1 MiB, luego saltar al modo protegido (32 bits), mover el kernel cargado a la memoria alta (libre el primer 1 MiB para el modo real), luego regrese al modo real (16 bits) nuevamente, obtenga el disco RAM del disco al primer 1 MiB (si es un initrd separado y un kernel anterior), posiblemente cambie nuevamente al modo protegido (32 bits), póngalo donde corresponde, posiblemente regrese al modo real (o no: /programming/4821911/does-grub-switch-to-protected-mode ) y ejecute el código del núcleo. Advertencia: no estoy completamente seguro acerca de la minuciosidad y precisión de esta parte de la descripción.
Ahora, cuando finalmente ejecuta el kernel, ya lo tiene y el ramdisk cargado en la RAM por el gestor de arranque , por lo que el kernel puede usar las utilidades de disco de ramdisk para montar su sistema de archivos raíz real y pivotearlo. Los controladores de ramfs están presentes en el núcleo, por lo que puede comprender el contenido de initramfs, por supuesto.