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 inity rootque 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 quieten cuenta el parámetro del núcleo para reducir su salida).
Cuando el kernel se inicia con un initramfs, el kernel rootno usa el initparámetro directamente, y el parámetro solo se usa si rdinitfalla. initel 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
rdiniten 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
initen 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 initprograma (normalmente, el /initscript en initramfs) depende del programa, no del núcleo. Los argumentos a los que no se pasa inittodavía están disponibles /proc/cmdlinesi el /procsistema de archivos está montado.
ld-linux.soELF o una secuencia de comandos de recursión demasiado profunda o algo simplemente no puede ser ejecutable?