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