Los parámetros pasados en la línea de comando del núcleo no tienen que ser significativos para el núcleo: la documentación de los parámetros del núcleo dice
El kernel analiza los parámetros desde la línea de comandos del kernel hasta "-"; si no reconoce un parámetro y no contiene un '.', el parámetro se pasa a init: los parámetros con '=' van al entorno de init, otros se pasan como argumentos de línea de comando a init. Todo después de "-" se pasa como un argumento a init.
Esto no se aplica init
y root
que realmente son parámetros del núcleo, y son manejados por el núcleo. También pueden ser utilizados por el espacio de usuario, ya que aparecen en /proc/cmdline
. (Así, por ejemplo, systemd tiene quiet
en cuenta el parámetro del núcleo para reducir su salida).
Cuando el kernel se inicia con un initramfs, el kernel root
no usa el init
parámetro directamente, y el parámetro solo se usa si rdinit
falla. init
el inicio se maneja en kernel_init
, que funciona de la siguiente manera:
- si hay un "comando de ejecución de ramdisk" (ya sea el valor dado
rdinit
en la línea de comando del núcleo, o /init
) que es accesible, el núcleo intenta ejecutarlo;
- si eso falla, y hay un "comando de ejecución" (el valor dado
init
en la línea de comando del kernel), el kernel intenta ejecutarlo y entra en pánico si no puede;
- como último recurso, el núcleo intenta ejecutar
/sbin/init
, /etc/init
, /bin/init
, y /bin/sh
; si ninguno de esos puede ejecutarse, entra en pánico .
Cuando hay un initramfs, todo esto sucede allí, y el volumen objetivo no está montado por el núcleo. Lo que sucede después de que el núcleo ejecuta el primer init
programa (normalmente, el /init
script en initramfs) depende del programa, no del núcleo. Los argumentos a los que no se pasa init
todavía están disponibles /proc/cmdline
si el /proc
sistema de archivos está montado.
ld-linux.so
ELF o una secuencia de comandos de recursión demasiado profunda o algo simplemente no puede ser ejecutable?