[opensuse-es] Ejecución de "mkinitrd" tras actualizar el kernel
Hola, Una pregunta de curiosidad. Cuando se actualiza el kernel desde YaST tras un parche de seguridad ¿se ejecuta el comando "mkinitrd"? Es que me gustaría activar el ahci en la bios pero no me arriesgo a correr el comando "mkinitrd", y si lo hace el YaST automáticamente al actualizar el kernel, pues mejor O:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-07-12 a las 16:42 +0200, Camaleón escribió:
Una pregunta de curiosidad.
Cuando se actualiza el kernel desde YaST tras un parche de seguridad ¿se ejecuta el comando "mkinitrd"?
Mmmm... Puede traer un initrd de serie, pero... espera, es facil de ver, no tengo que dar vueltas. nimrodel:~ # l /boot/*2.6.25.20-0.4* - -rw-r--r-- 1 root root 918128 Jun 2 02:32 /boot/System.map-2.6.25.20-0.4-pae - -rw-r--r-- 1 root root 88650 Jun 2 02:36 /boot/config-2.6.25.20-0.4-pae - -rw-r--r-- 1 root root 5964806 Jul 7 15:31 /boot/initrd-2.6.25.20-0.4-pae - -rw-r--r-- 1 root root 197190 Jun 2 02:42 /boot/symsets-2.6.25.20-0.4-debug.tar.gz - -rw-r--r-- 1 root root 240325 Jun 2 02:40 /boot/symsets-2.6.25.20-0.4-default.tar.gz - -rw-r--r-- 1 root root 110750 Jun 2 02:42 /boot/symsets-2.6.25.20-0.4-lockdep.tar.gz - -rw-r--r-- 1 root root 238742 Jun 2 02:37 /boot/symsets-2.6.25.20-0.4-pae.tar.gz - -rw-r--r-- 1 root root 237140 Jun 2 02:41 /boot/symsets-2.6.25.20-0.4-xen.tar.gz - -rw-r--r-- 1 root root 443521 Jun 2 02:37 /boot/symtypes-2.6.25.20-0.4-pae.gz - -rw-r--r-- 1 root root 128961 Jun 2 02:37 /boot/symvers-2.6.25.20-0.4-pae.gz - -rw-r--r-- 1 root root 2733940 Jun 2 02:36 /boot/vmlinux-2.6.25.20-0.4-pae.gz - -rw-r--r-- 1 root root 2131488 Jun 2 02:32 /boot/vmlinuz-2.6.25.20-0.4-pae Fíjate las fechas, el initrd es posterior, y corresponde al dia de instalación; ergo, se ha generado al vuelo durante la instalación del rpm. ¿Es el mkinird ese? Otro comando: nimrodel:~ # l /boot/initrd* lrwxrwxrwx 1 root root 24 Jul 7 15:31 /boot/initrd -> initrd-2.6.25.20-0.4-pae - -rw-r--r-- 1 root root 11665001 Jan 28 19:55 /boot/initrd-2.6.25.20-0.1-cer - -rw-r--r-- 1 root root 5964806 Jul 7 15:31 /boot/initrd-2.6.25.20-0.4-pae lrwxrwxrwx 1 root root 24 Jan 28 20:00 /boot/initrd-cer -> initrd-2.6.25.20-0.1-cer Tienen fechas distintas, luego mi hipótesis es que no, no corre el script entero, sino sólo la parte perteneciente al kernel que se está instalando, o un script equivalente.
Es que me gustaría activar el ahci en la bios pero no me arriesgo a correr el comando "mkinitrd", y si lo hace el YaST automáticamente al actualizar el kernel, pues mejor O:-)
El comando "suele" ser inocuo. Digo "suele", porque no me ha fastidiado nada hasta ahora, o no que yo recuerde, en este momento (que ando una chispa cansado). - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkpaBSMACgkQtTMYHG2NR9U4aQCeIHo+tlL8DjeI/zRZXPDTFFbj WIwAoJg8NfRg9pTvJgoOWuVnosFCrktb =RnsE -----END PGP SIGNATURE-----
El 2009-07-12 a las 17:45 +0200, Carlos E. R. escribió:
El 2009-07-12 a las 16:42 +0200, Camaleón escribió:
Una pregunta de curiosidad.
Cuando se actualiza el kernel desde YaST tras un parche de seguridad ¿se ejecuta el comando "mkinitrd"?
Mmmm...
Puede traer un initrd de serie, pero... espera, es facil de ver, no tengo que dar vueltas.
(...)
- -rw-r--r-- 1 root root 2733940 Jun 2 02:36 /boot/vmlinux-2.6.25.20-0.4-pae.gz - -rw-r--r-- 1 root root 2131488 Jun 2 02:32 /boot/vmlinuz-2.6.25.20-0.4-pae
Fíjate las fechas, el initrd es posterior, y corresponde al dia de instalación; ergo, se ha generado al vuelo durante la instalación del rpm. ¿Es el mkinird ese? Otro comando:
nimrodel:~ # l /boot/initrd* lrwxrwxrwx 1 root root 24 Jul 7 15:31 /boot/initrd -> initrd-2.6.25.20-0.4-pae - -rw-r--r-- 1 root root 11665001 Jan 28 19:55 /boot/initrd-2.6.25.20-0.1-cer - -rw-r--r-- 1 root root 5964806 Jul 7 15:31 /boot/initrd-2.6.25.20-0.4-pae lrwxrwxrwx 1 root root 24 Jan 28 20:00 /boot/initrd-cer -> initrd-2.6.25.20-0.1-cer
Tienen fechas distintas, luego mi hipótesis es que no, no corre el script entero, sino sólo la parte perteneciente al kernel que se está instalando, o un script equivalente.
¿Y alguna forma de forzar al yast a ejecutarlo? :-?
Es que me gustaría activar el ahci en la bios pero no me arriesgo a correr el comando "mkinitrd", y si lo hace el YaST automáticamente al actualizar el kernel, pues mejor O:-)
El comando "suele" ser inocuo. Digo "suele", porque no me ha fastidiado nada hasta ahora, o no que yo recuerde, en este momento (que ando una chispa cansado).
Ya... es que me da repelús lanzarlo sin argumentos, así, sin más. Preferiría que lo hiciera YaST O:-) Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 12 de julio de 2009 17:25, Camaleón
¿Y alguna forma de forzar al yast a ejecutarlo? :-?
Es que me gustaría activar el ahci en la bios pero no me arriesgo a correr el comando "mkinitrd", y si lo hace el YaST automáticamente al actualizar el kernel, pues mejor O:-)
El comando "suele" ser inocuo. Digo "suele", porque no me ha fastidiado nada hasta ahora, o no que yo recuerde, en este momento (que ando una chispa cansado).
Ya... es que me da repelús lanzarlo sin argumentos, así, sin más. Preferiría que lo hiciera YaST O:-)
Los argumentos los busca en /etc/sysconfig/kernel, en donde se indica que modulos del kernel debe incluir en el initrd. Se puede ejecutar solo sin parametros, por lo que acabo de escribir. Salu2 -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-07-12 a las 22:25 +0200, Camaleón escribió:
Tienen fechas distintas, luego mi hipótesis es que no, no corre el script entero, sino sólo la parte perteneciente al kernel que se está instalando, o un script equivalente.
¿Y alguna forma de forzar al yast a ejecutarlo? :-?
¿Para que?
Es que me gustaría activar el ahci en la bios pero no me arriesgo a correr el comando "mkinitrd", y si lo hace el YaST automáticamente al actualizar el kernel, pues mejor O:-)
El comando "suele" ser inocuo. Digo "suele", porque no me ha fastidiado nada hasta ahora, o no que yo recuerde, en este momento (que ando una chispa cansado).
Ya... es que me da repelús lanzarlo sin argumentos, así, sin más. Preferiría que lo hiciera YaST O:-)
Yo llevo años ejecutandolo sin argumento alguno. De hecho no se que argumentos admite en la linea de comandos. De alguna manera al ejecutarse sabe que kernels hay y mete los initrd adecuados; usa algun tipo de magia para saber que módulos añadir, y también los que se le liste en el sysconfig. Y si tienes dudas, sólo tienes que hacer un respaldo del directorio /boot, y ejecutarlo. Si toca algo que no quieres que toque, pues repones el fichero anterior y santas pascuas. - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkpae0AACgkQtTMYHG2NR9U3+QCgjg1NSRqjWS28ha3EsCeQaXPR skEAoJRsCl2y0UUQyhCMaWlo0DNwDgSS =ZRmo -----END PGP SIGNATURE-----
El 2009-07-13 a las 02:09 +0200, Carlos E. R. escribió:
El 2009-07-12 a las 22:25 +0200, Camaleón escribió:
Tienen fechas distintas, luego mi hipótesis es que no, no corre el script entero, sino sólo la parte perteneciente al kernel que se está instalando, o un script equivalente.
¿Y alguna forma de forzar al yast a ejecutarlo? :-?
¿Para que?
Para no hacerlo yo :-) Tengo la sospecha de que cambiando los módulos para cargar en el kernel desde el editor de los archivos /etc/sysconfig de YaST, también se ejecuta el mkinitrd, pero es sólo una ligera sospecha, no lo sé con certeza.
Es que me gustaría activar el ahci en la bios pero no me arriesgo a correr el comando "mkinitrd", y si lo hace el YaST automáticamente al actualizar el kernel, pues mejor O:-)
El comando "suele" ser inocuo. Digo "suele", porque no me ha fastidiado nada hasta ahora, o no que yo recuerde, en este momento (que ando una chispa cansado).
Ya... es que me da repelús lanzarlo sin argumentos, así, sin más. Preferiría que lo hiciera YaST O:-)
Yo llevo años ejecutandolo sin argumento alguno. De hecho no se que argumentos admite en la linea de comandos. De alguna manera al ejecutarse sabe que kernels hay y mete los initrd adecuados; usa algun tipo de magia para saber que módulos añadir, y también los que se le liste en el sysconfig.
Y si tienes dudas, sólo tienes que hacer un respaldo del directorio /boot, y ejecutarlo. Si toca algo que no quieres que toque, pues repones el fichero anterior y santas pascuas.
Bueno, perdón por la tardanza. Hasta hoy no me he atrevido a cambiar la bios y poner el modo achi por lo que no podía poner el resultado. La respuesta a la pregunta del hilo es "sí". Tras actualizar el kernel, automáticamente se ejecuta el mkinitrd y los módulos listados para cargarse en /etc/sysconfig/kernel se cargan sin necesidad de ejecutar posteriormente y de forma manual el comando "mkinitrd". No había caído hasta ahora. Me he dado cuenta de que al listar los módulos con lsmod el achi aparecía cargado pero sin ningún dispositivo asociado (0). Así que el módulo estaba cargado desde la última actualización del kernel y yo sin enterarme O:-) He cambiado la bios al modo ahci y el sistema ha iniciado sin problemas. Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-07-27 a las 00:07 +0200, Camaleón escribió:
El 2009-07-13 a las 02:09 +0200, Carlos E. R. escribió:
El 2009-07-12 a las 22:25 +0200, Camaleón escribió:
Tienen fechas distintas, luego mi hipótesis es que no, no corre el script entero, sino sólo la parte perteneciente al kernel que se está instalando, o un script equivalente.
¿Y alguna forma de forzar al yast a ejecutarlo? :-?
¿Para que?
Para no hacerlo yo :-)
Total, es un simple comando...
Tengo la sospecha de que cambiando los módulos para cargar en el kernel desde el editor de los archivos /etc/sysconfig de YaST, también se ejecuta el mkinitrd, pero es sólo una ligera sospecha, no lo sé con certeza.
En todo caso, sería al ejecutar "SuSEconfig". Eso es facil de ver. nimrodel:~ # ls /sbin/conf.d/ SuSEconfig.desktop-file-utils SuSEconfig.gdm SuSEconfig.groff SuSEconfig.ispell SuSEconfig.postfix SuSEconfig.scpm SuSEconfig.wdm SuSEconfig.fonts SuSEconfig.glib2 SuSEconfig.gtk2 SuSEconfig.permissions SuSEconfig.scim SuSEconfig.texlive SuSEconfig.words nimrodel:~ # nimrodel:~ # grep -i initrd /sbin/conf.d/* Pue entonces, va a ser que no.
Y si tienes dudas, sólo tienes que hacer un respaldo del directorio /boot, y ejecutarlo. Si toca algo que no quieres que toque, pues repones el fichero anterior y santas pascuas.
Bueno, perdón por la tardanza. Hasta hoy no me he atrevido a cambiar la bios y poner el modo achi por lo que no podía poner el resultado.
La respuesta a la pregunta del hilo es "sí".
Tras actualizar el kernel, automáticamente se ejecuta el mkinitrd y los módulos listados para cargarse en /etc/sysconfig/kernel se cargan sin necesidad de ejecutar posteriormente y de forma manual el comando "mkinitrd".
Sí, al actualizar el kernel se ejecuta, eso es lo que dije.
No había caído hasta ahora. Me he dado cuenta de que al listar los módulos con lsmod el achi aparecía cargado pero sin ningún dispositivo asociado (0). Así que el módulo estaba cargado desde la última actualización del kernel y yo sin enterarme O:-)
He cambiado la bios al modo ahci y el sistema ha iniciado sin problemas.
Que era lo del ahci :-? - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkpt/pcACgkQtTMYHG2NR9V8HwCeNe6fpuzoMJ1P8V2voUoHMO8V 8jMAn2YxGqIuUKpVOm3twmvZupkPFSHf =JzPo -----END PGP SIGNATURE-----
El 2009-07-27 a las 21:22 +0200, Carlos E. R. escribió:
El 2009-07-27 a las 00:07 +0200, Camaleón escribió:
¿Y alguna forma de forzar al yast a ejecutarlo? :-?
¿Para que?
Para no hacerlo yo :-)
Total, es un simple comando...
Con unas cuantas opciones (man mkinitrd) >:-)
Tengo la sospecha de que cambiando los módulos para cargar en el kernel desde el editor de los archivos /etc/sysconfig de YaST, también se ejecuta el mkinitrd, pero es sólo una ligera sospecha, no lo sé con certeza.
En todo caso, sería al ejecutar "SuSEconfig". Eso es facil de ver.
nimrodel:~ # ls /sbin/conf.d/ SuSEconfig.desktop-file-utils SuSEconfig.gdm SuSEconfig.groff SuSEconfig.ispell SuSEconfig.postfix SuSEconfig.scpm SuSEconfig.wdm SuSEconfig.fonts SuSEconfig.glib2 SuSEconfig.gtk2 SuSEconfig.permissions SuSEconfig.scim SuSEconfig.texlive SuSEconfig.words nimrodel:~ #
nimrodel:~ # grep -i initrd /sbin/conf.d/*
Pue entonces, va a ser que no.
Lo habré soñado... o lo habré leído en alguna parte. Aquí: *** SUSE Linux Install Problems and Their Solutions http://www.novell.com/coolsolutions/trench/17080.html 4.In order to avoid item (3) on each following boot you have to correct initrd's module load-sequence, which is governed by the INITRD_MODULES line in /etc/sysconfig/kernel. Under SUSE Linux 10.0 you can do this from Yast using the /etc/sysconfig Editor item in the System module; I do not remember if 9.3 allows this, so you may have to edit the file manually. If your problem is the first one given above, then you simply have to add “ide-generic” to the INITRD_MODULES line (I placed it first): e.g. change INITRD_MODULES="sym53c8xx cpqarray processor thermal fan reiserfs" to INITRD_MODULES="ide-generic sym53c8xx cpqarray processor thermal fan reiserfs". If your problem is the second, you need to identify and swap the positions of the modules driving your hard drive connections: e.g. change INITRD_MODULES="pdc202xx_old via82cxxx scsi_mod sd_mod reiserfs" to INITRD_MODULES="via82cxxx pdc202xx_old scsi_mod sd_mod reiserfs". After this create a new initrd with “mkinitrd”. This is done for you under SuSE 10.0 if you do this editing using YaST; otherwise just run “mkinitrd” in a terminal window as root. With the next reboot everything will be o.k. (even a future kernel-update should be fine, since this will not change the INITRD_MODULES sequence any more). ***
Bueno, perdón por la tardanza. Hasta hoy no me he atrevido a cambiar la bios y poner el modo achi por lo que no podía poner el resultado.
La respuesta a la pregunta del hilo es "sí".
Tras actualizar el kernel, automáticamente se ejecuta el mkinitrd y los módulos listados para cargarse en /etc/sysconfig/kernel se cargan sin necesidad de ejecutar posteriormente y de forma manual el comando "mkinitrd".
Sí, al actualizar el kernel se ejecuta, eso es lo que dije.
No había caído hasta ahora. Me he dado cuenta de que al listar los módulos con lsmod el achi aparecía cargado pero sin ningún dispositivo asociado (0). Así que el módulo estaba cargado desde la última actualización del kernel y yo sin enterarme O:-)
He cambiado la bios al modo ahci y el sistema ha iniciado sin problemas.
Que era lo del ahci :-?
Una especificación abierta del SATA, que lo mejora en algunos aspectos: *** http://linux-ata.org/driver-status.html#ahci AHCI (newer Intel ICH, ULi, others) Driver name: ahci Summary: Full NCQ support, full SATA control including hotplug and PM. Note1: AHCI specification is completely open. Note2: ATI, Intel, JMicron, NVIDIA, SiS, ULi and VIA are currently known to have deployed AHCI in their chipsets. Hopefully others will follow. AHCI is a nice, open design. *** libata: http://ata.wiki.kernel.org/index.php/Libata_Feature_Table ahci: http://linux-ata.org/driver-status.html#matrix Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2009-07-27 a las 23:59 +0200, Camaleón escribió:
El 2009-07-27 a las 21:22 +0200, Carlos E. R. escribió:
El 2009-07-27 a las 00:07 +0200, Camaleón escribió:
¿Y alguna forma de forzar al yast a ejecutarlo? :-?
¿Para que?
Para no hacerlo yo :-)
Total, es un simple comando...
Con unas cuantas opciones (man mkinitrd) >:-)
Nunca las uso. Funciona perfectamente sin darle nada más.
Pue entonces, va a ser que no.
Lo habré soñado... o lo habré leído en alguna parte.
Aquí:
***
...
After this create a new initrd with “mkinitrd”. This is done for you under SuSE 10.0 if you do this editing using YaST;
Curioso... Pues quizás lo haga el yast directamente, pero me extraña, debiera ser que lo hiciera el suseconfig.
***
He cambiado la bios al modo ahci y el sistema ha iniciado sin problemas.
Que era lo del ahci :-?
Una especificación abierta del SATA, que lo mejora en algunos aspectos:
*** http://linux-ata.org/driver-status.html#ahci
AHCI (newer Intel ICH, ULi, others) Driver name: ahci Summary: Full NCQ support, full SATA control including hotplug and PM.
Note1: AHCI specification is completely open. Note2: ATI, Intel, JMicron, NVIDIA, SiS, ULi and VIA are currently known to have deployed AHCI in their chipsets. Hopefully others will follow. AHCI is a nice, open design. ***
libata: http://ata.wiki.kernel.org/index.php/Libata_Feature_Table
Ah, ¡interesante! - -- Saludos Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkpuMMAACgkQtTMYHG2NR9Wy+ACfeOf53bGdF0OCXgLYuDyI/zYD 974An3fj7E4ZYPHCodymLz7rGO+eeMoa =pq6U -----END PGP SIGNATURE-----
On 12/07/09 10:42, Camaleón wrote:
Hola,
Una pregunta de curiosidad.
Cuando se actualiza el kernel desde YaST tras un parche de seguridad ¿se ejecuta el comando "mkinitrd"?
LO ejecuta RPM que es lo hace exactamente lo puedes ver ejecutando rpm -q --scripts kernel-default -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
El 2009-07-12 a las 14:37 -0400, Cristian Rodríguez escribió:
On 12/07/09 10:42, Camaleón wrote:
Cuando se actualiza el kernel desde YaST tras un parche de seguridad ¿se ejecuta el comando "mkinitrd"?
LO ejecuta RPM
que es lo hace exactamente lo puedes ver ejecutando rpm -q --scripts kernel-default
Pues veo ésto: # Both perl-Bootloader and mkinitrd need valid partitioning # information in /etc/fstab, so only run the scripts in that # case. Also check for /.buildenv because of autobuild and # check for /sbin/mkinitrd because of the BuildService # (in a normal system, the RPM dependencies take care that # /sbin/mkinitrd is always there). Pero no me queda claro si esa rutina se ejecuta al actualizar el kernel :-? Saludos, -- Camaleón -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
On 12/07/09 16:28, Camaleón wrote: n/mkinitrd is always there).
Pero no me queda claro si esa rutina se ejecuta al actualizar el kernel :-?
se ejecuta en postinstall ... cada vez que instalas el paquete en cuestion, yast no tiene nada que ver aqui en todo caso. -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
participants (4)
-
Camaleón -
Carlos E. R. -
Cristian Rodríguez -
Juan Erbes