Posible solución para “Kernel Panics” aleatorios en el boot de Arch Linux

Esta entrada es para mostrar como “solucionar” casi el problema de los inicios con errores de Arch Linux. Algo así como la siguiente imagen:

Que como se aprecia, vemos que este es uno de los tantas “combinaciones” de errores que salen aleatoriamente al arrancar un sistema operativo con este problema. Según dice en ese error, indica que puede haber un problema en el “Hardware”, sin embargo, como todos sabemos en este sistema operativo se pueden solucionar hasta las mala mañas de lo que no le pertenece al SO.

Así que, voy a describir mi experiencia de este problema. Según lo que pude experimentar, el problema solo se daba con Arch Linux u otra distro que probara externamente, ya que con cualquier ubuntu que tuviese instalado o probado, arrancaba sin problemas. Pero si trataba de arrancar el Arch Linux instalado en el disco duro, tenía un problema que tenía que reiniciar alrededor de unas 50 veces para poder que el SO arrancara normalmente y lo pudiera utilizar.

Esto ya me tenía algo mal porque solo podía utilizar el ubuntu que tenía instalado para probarlo y no podía hacer ni la mitad de las cosas que podía hacer con Arch Linux. Por lo que me propuse solucionar este problema y comencé a investigar, buscando hilos de foros que tenían el mismo problema, mencionaban también que se trataba de un error de hardware y que era precisamente el CPU, por lo que me comenzó a preocupar, por lo que llegué abrir la PC y verificar que ocurría, sin embargo, no sirvió de nada.

Pero algo que me demostraba, que no debía rendirme era que si Ubuntu podía porque Arch Linux no (¿acaso Ubuntu es mejor que Arch…?). Por eso, comencé a escribir parámetros de arranque en el kernel de Arch Linux, cosas como: lapic, nomce, intel_idle.max_cstate=0, disable_cpu_apic, acpi_skip_timer_override, acpi=stric, clk, apm, noapic, acpi=oldboot, acpi-cpufreq, intel_pstate=disable, i8042.noacpi=1, apm=off, acpi=copy_dsdt, pci=nocrs, rhgb, acpi=force, pnpacpi=0ff y otras más… Todo esto lo recomendaban en los foros que leía.

Hasta que tuve que entrar a la documentación de los parámetros del kernel, que por cierto la recomiendo: https://www.kernel.org/doc/Documentation/kernel-parameters.txt

Y encontré un parámetro bastante interesante que por el momento logré arrancar Arch Linux sin problemas:

linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce maxcpus=0

Como indica allí, este parámetro lo que hace es limitar el uso a un cpu sin activar el modo simétrico de procesamiento. Al principio funcionaba bastante bien hasta cuando utilicé el comando pacman -Syyu; me arrojó un core dumped o segmentation fault.

Por lo que automáticamente noté que algo extraño estaba sucediendo, por lo que me puse a ejecutar otros proceso hasta que de repente se congeló completamente el sistema y no funcionó más, hasta que lo reinicié. Así que hice la misma operación, pero esta vez logré ejecutar htop y me mostraba lo siguiente:

Como era de esperarse, solo mostraba un CPU, ya que el otro lo había deshabilitado, sin embargo, me parecía muy extraño porqué los programas arrojaban segfault, y ni siquiera podía iniciar el entorno gráfico; así que fue algo que al menos me dio más esperanza de que si configuraba los parámetros del kernel de una manera, arrancaría mi Arch Linux como siempre.

Así que continué probando con los otros parámetros que escribí en la lista hasta que me encontré con este, que por el momento es la mejor solución:

 linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce isolcpus=1

Este parámetro, hace algo tan simple como aislar (no desactivar) el segundo núcleo del CPU en el procesamiento simétrico, es decir, que la carga de procesamiento se la da a un solo núcleo mientras el otro solo está de complementario. Esto a pesar que parezca contradictorio, no afecta tanto el rendimiento, ya que este gran SO fue capaz de correr aplicaciones de esta manera:

Así que con esto, el único problema que observé que da en el momento del boot, es uno o dos kernel panics o oops; pero comparado las 50 veces que tenía que reiniciar anteriormente, lo puedo considerar una solución “provisional”. Por lo demás, hasta ahora me ha permitido utilizar el SO y escribir este post que están leyendo ahora mismo :-).

Espero que les ayuden, y no se salgan de GNU/Linux, que es el mejor sistema operativo que han inventado. Lo digo con toda seguridad.


31 comentarios

  1.   Gregorio Espadas dijo

    Muy interesante info. Nunca he tenido esos kernel panics en ArchLinux en los años que vengo usándolo, pero es bueno saber qué hacer si en algún momento se me presentara el problema. ¡Gracias!

    1.    kik1n dijo

      Igual, llevo mucho tiempo usando Arch (Estuve como 1 año sin Arch) y sin un kernel panic.
      Gracias por el tip.

    2.    c4explosive dijo

      Lo más probable es que, como lo mencionaba en el post, el problema suceda por el hardware, porque en lo que use arch, tampoco me había dado ningún problema de este tipo.

    3.    elav dijo

      Otro con excelente resultado en Arch. Nunca he tenido un Kernel Panic

    4.    rawBasic dijo

      Más de 2 años con GNU/Linux.. ..2 años ya con ArchLinux, nunca un kernel panic.. 😉

    5.    Manuel de la Fuente dijo

      Creo que los kernel panics se deben más al hardware que a la propia distro. En la laptop que uso ahora jamás he visto un kernel panic excepto una vez que le metí una alfa de Ubuntu (y también aquí estuvo Arch Linux por dos años). En cambio, en otra laptop que tengo, cualquier distro que le ponga siempre da kernel panic y una amplia variedad de errores para todos los gustos.

  2.   eliotime3000 dijo

    Con el kernel 3.14 en Debian, me he topado con el problema del kernel panic, además que siempre cuando prendo mi PC, me aparece un mensaje de “connect/disconnect timeout” (y también cuando lo apago).

    1.    Amaury dijo

      Me ha pasado tanto en Fedora cómo en Arch, pero no se la razón, y cómo no veo diferencia pues no le he dedicado tiempo a investigar o resolver eso (si es que es un problema).

    2.    dasasd dijo

      Creo que la razon es que estan compilados con gcc 4.9

      http://libuntu.com/linus-torvalds-considera-que-la-version-4-9-de-gcc-es-una-pura-y-absoluta-mierda/

  3.   Tony dijo

    Muchas gracias por la info. Algo de las muchas cosas que podemos presumir es de este tipo de foros

  4.   manu dijo

    Porque justo a Arch Linux le pasa esto? ,acaso no es suficiente con los problemas que se presentan frecuentemente con la lentitud oh el colgamiento del sistema llegando a tal punto de echar el sistema al traste.

    1.    elav dijo

      Eh? ¿De que hablas? o_O

    2.    Amaury dijo

      Arch es una distribución KISS configurable desde la base del mismo sistema operativo, en pocas palabras, si el sistema es pesado es porqué tú lo armaste de esa forma, si el sistema tiene errores es porqué tú los generaste o por no haber configurado algo correctamente la wiki de Arch es bastante completa, hace algunos años no había muchos temas importantes en español, eso y que el proceso de instalación era mucho más tosco y en cierta forma difícil, ahora todo está un poco más automatizado.
      Culpar a la distro por los errores del usuario es tan… Windows(?).

      1.    Dayara dijo

        Culpar a la distro por los errores es ser coherente, simplemente porque es la verdad. Después de tener un problema similar con Manjaro, probé Arch, Antergos y otra distribución desconocida (no recuerdo el nombre ahora, lo siento) que me recomendó alguien asegurándome que no daba problemas, pero nada; todas lo dan. En OpenSuse, Fedora, Mint, Mageia y todas las que he probado después no pasa. Por lo tanto, en lo que a mí respecta, no me queda otra opción que pensar que es culpa de la distro. Pero, oye, no la demonizo ni nada, es más, me jode mucho no poder usar nada basado en Arch, porque me gusta mucho, pero ese dichoso problema me lo impide. Tampoco pienso que se trate del hardware, pues a muchos de los que nos pasa no nos pasaba antes utilizando el mismo jodido. Bueno, en realidad sí ha de ser algo relacionado con el hardware, pero, volviendo a lo mismo, si yo no he hecho ningún cambio y tengo problemas con el mismo equipo con el que antes no los tenía, obviamente se deberá a un cambio realizado por Arch que me ha jodido.

      2.    juanfgs dijo

        “Culpar a la distro por los errores del usuario es tan… Windows(?).”

        Te diría que culpar a los usuarios por los errores del producto es tan Apple. Sinceramente le he dado mil vueltas al asunto pero no veo la ventaja en utilizar algo cuyos mantenedores básicamente se lavan las manos, para ningún proposito serio. Y eso lo digo teniendo en cuenta que el software GPL viene sin garantía.

        Podes decir como quieras pero si es el mismo caso de los reportes de falta de señal al iPhone y la respuesta de Apple “es que lo estas agarrando mal” de hace varios años. Si hacés una distro por lo general queres brindar algo de calidad, y un minimo soporte, y la verdad es que Arch básicamente es un sistema de hobbyistas, donde se ve que sus desarrolladores se divierten empaquetando cosas nuevas, pero tienen poco interés en ofrecer un soporte verdadero. Cada vez que veo este tipo de posts valoro más el trabajo detrás de la distro que utilizo.

        Y si, es un problema del software si no funciona, si deja de funcionar en un update, o si te rompe algo del hardware. Que una distro te de kernel panic mientras otra no lo hace… pues si, claramente hay una distro que esta haciendo las cosas bien y otra mal. Ahora si es tu gusto utilizar Linux al estilo de los 90 donde teníamos que recompilar el kernel cada vez que enchufabamos una impresora nueva… allá vos.

  5.   mario dijo

    Es el kernel compilado por los desarrolladores? o uno propio?
    Los kernel panic se generan al no haber seleccionado (Y) ciertos componentes al compilar, o no haberse activado algunos módulos para que soporte cierto hardware. Ya con la practica y conocimiento de tu hardware (hay que abrir la pc y ver que marcas de chips tiene), se puede armar un kernel a medida (mediante chrooting). Si ubuntu y el CD de instalación de Arch andaron en tu equipo, hay algo en la compilación que no esta activado.

    1.    c4explosive dijo

      Era el kernel stock del mismo archlinux, de los repositorios.

  6.   anonimo dijo

    El núcleo que estás usando, le esta sobrando algo que a tu hardware no le gusta, debes tener alguna versión rara de algún chip en tu placa madre o incluso un bug en algún chip (suele pasar).
    Puede ser una tabla corrupta del acpi de tu bios, es normal que el chino de turno ni siquiera calcule bien el checksum de cada tabla, esos mensajes suele salir con $ dmesg –human en el inicio del booteo.
    También deberías de probar con otra fuente de alimentación, cuando falla el filtrado el ripple suele hacer ese tipo de fallas justamente.
    Primero proba a cambiar la fuente y ver que pasa, si sigue igual probá a configurarte un núcleo a la medida de tu hardware, de paso conocerás mejor tu pc en el proceso.

    1.    c4explosive dijo

      Gracias, por los consejos. Por cierto es una laptop, pienso que debería cambiarle la batería. Pero veo lo que me has dicho me puede servir.

  7.   Yukiteru dijo

    El unico kernel panic que aún me saca de quicio es en parte culpa de los muchachos de nouveau y mi vetusta, anticuada y muy empolvada tarjeta integrada nVidia 6150 SE (digo en parte porque; han hecho un excelente trabajo soportando un universo de chips gráficos como los que tiene nVidia, y todo ello, usando solo ingeniería inversa, además de que el problema solo se presenta para algunas tarjetas con el chipset NV4E).

    Basta con que inicie Openbox + Firefox y se arma el desastre (nada más bonito que ver un mosaico blanco y negro en tu pantalla completamente aleatorio). Y lo vengo cantando desde el kernel 3.6 en Debian, Fedora, Archlinux, Slackware y ahora reverificado nuevamente en Gentoo (recien instalado con el kernel 3.12), no me molesto ya por sacar un log, al kernel ni le da tiempo para escribir algo que no sea una friolera de caracteres sin sentido.

    1.    anonimo dijo

      Te doy la solución, a una pc que tengo con gentoo y video nvidia integrado le pasa lo mismo con el driver nouveau, así que no me quedó otra que usar el driver cerrado de nvidia, mi chip debe usar el driver 304.123

      00:0d.0 VGA compatible controller [0300]: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] [10de:03d6] (rev a2) (prog-if 00 [VGA controller])

      Hay que parchear un archivo del núcleo antes de compilarlo, si no se parchea el modo gráfico se negará a iniciar.

      Los pasos son:
      # nano -w /usr/src/linux-3.15.7-gentoo/drivers/acpi/osl.c
      buscas con ctrl+w dentro de nano este texto, acpi_os_wait_events_complete y nano te lleva a esta parte:

      void acpi_os_wait_events_complete(void)
      {
      flush_workqueue(kacpid_wq);
      flush_workqueue(kacpi_notify_wq);
      }
      EXPORT_SYMBOL(acpi_os_wait_events_complete);

      El parche que tienes que agregar es esta última línea que comienza con EXPORT, ctrl+o ctrl+x
      Luego compilas el núcleo, instalas los modulos, instalas el núcleo, generas el initramfs si lo necesitas, agregas al initramfs el splash si es que usas splash, regeneras las entradas para grub y por ultimo y muy importante debes reconstruir los módulos que no son del núcleo o sea el módulo nvidia propietario, sin hacer esto no te va a andar el modo grafico.

      # eselect kernel list
      # eselect kernel set x
      # cd /usr/src/linux
      # make
      # make modules_install
      # mount /boot
      # make install
      # dracut –hostonly ” 3.15.7-gentoo –force
      # splash_geninitramfs –verbose –res 1400×1050 –append /boot/initramfs-3.15.7-gentoo.img emerge-world
      # grub-mkconfig -o /boot/grub/grub.cfg
      # emerge @module-rebuild
      # umount /boot
      # shutdown -r now

      Si usas genkernel, solo parcheas ese archivo y tengo entendido que genkernel se arregla solo.
      Además debes quitar el soporte drm y los drivers nvidia y otros chips de video del núcleo para que no choquen de frente con el driver cerrado nvidia que se instala como módulo nvidia.
      En el caso de usar bootsplash debes incluir en el núcleo el driver uvesa para que soporte resoluciones altas de pantalla ya que el driver cerrado nvidia (si mal no recuerdo) no soporta mas que 800×600 en la terminal tty1 “F1” del booteo.
      No se en otras distros, pero supongo que deberia andar en cualquier distro si se hicieran estos pasos, salvando el cambio de emerge por lo que fuera.

      Estas son las guias que debes seguir, para nvidia y uvesa:
      http://wiki.gentoo.org/wiki/NVidia/nvidia-drivers/es
      http://wiki.gentoo.org/wiki/Uvesafb

      1.    Yukiteru dijo

        Gracias por la info, pero el problema lo solucione precisamente cambiando a los privativos. Recuerdo que el anterior driver de nVidia (304.121) también había que parchearlo al pasar a la 3.13 porque tenia un problema en la compilación del modulo (no había errores, pero el modulo se negaba a funcionar) y todo también por el manejador de eventos ACPI. En Debian me conseguí con el problemita y di con la solución también.

        https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740097

    2.    Dayara dijo

      He puesto Manjaro como ejemplo, pero ya he mencionado antes que me ha ocurrido lo mismo con Arch y otros derivados. Por lo tanto creo que el problema es más de ellos que de los afectados.

      Pd: No he podido responderte directamente al mensaje pertinente porque no me aparece la opción de responder…

  8.   Dayara dijo

    Yo precisamente me pasé de Manjaro a Linux Mint porque se me congelaba al arrancar después de actualizar a alguna versión posterior a la 0.8.9 (no recuerdo cuál). Por lo que leí, esto suele pasar en los portátiles. Mi problema en cuestión no era el mismo que el de esta entrada, creo que llegué a la conclusión de que podía estar relacionado con la gestión de energía. Había gente a la que no se le congelaba si arrancaba el portátil estando desenchufado. Ahora mismo no recuerdo si eso me permitía arrancar siempre sin problemas, pero desde luego lo conseguía más veces a costa de tardar más en haceelo.
    En fin, al final desistí y me pasé a Fedora y a Linux Mint.

    1.    c4explosive dijo

      Casualmente, ayer probé suspenderla sin el cargador y al reanudarla se colgó y tuve que reiniciar.

  9.   Amaury dijo

    Es bastante curioso, llevo unos cuantos meses con Arch y no he tenido ni un solo Kernel Panic! Me ha pasado con Antergos (Arch con un repositorio agregado) desde el entorno live, pero ahí lo considero más entendible. ¿Será posible que sea algún problema de la Mother Board o bien de un módulo de la RAM defectuoso? Recuerdo que hace cómo 2 años un módulo de RAM me provocó varios pantallazos azules en Windows e igualmente varios Kernel Panic! en Mandriva. Tuve que probar cada memoria a la vez entre reinicio y reinicio.

    1.    Dayara dijo

      Es un problema de Arch (que arrastra a todos sus derivados), porque en otras distros no hay problemas de ese tipo. Lo que me parece vergonzoso es que a estas alturas no lo hayan solucionado. ¡Lleva pasándole años sólo a ellos! He leído problemas similares de 2011. Tengo claro que se trata de algo que viene y va según actualizan, porque usando las versiones 0.8.7, 0.8.8 y 0.8.9 sin actualizarlas no pasa nada. De ahí en adelante se va todo a la mierda, y seguramente en versiones antiguas también pasaba. ¿Por qué nos ocurre sólo a unos cuántos? No lo sé, pero no creo que sea nuestro problema, sino de Arch, pues, como ya se ha dicho, otras distribuciones van perfectamente. Yo ya me rompí los cuernos en su día por encontrar una solución, pero me cansé. Así que, por mucho que me pese, no pienso usar Arch.

      1.    Yukiteru dijo

        ¿Arch 0.8.7, 0.8.8 y 0.8.9? Me entero que Arch usa esa nomenclatura de versiones.

        ¿No será que estas usando Manjaro?

      2.    Yukiteru dijo

        Vale me respondo a mi mismo leyendo tu comentario anterior, y una cosa es Manjaro y otra es Arch.

        Eso de culpar a una distro por un determinado problema tampoco es coherente (nada coherente en realidad), por lo menos en mi caso no puedo a culpar a cuanta distro pruebe por el problema con nouveau y mi tarjeta nVidia 6150SE, porque el problema es el manejo de MMIO del driver y la tarjeta (sabrán los nVidia que fix y cosas locas tendrán para arreglar ese detalle). El hardware también puede ser el del problema, y eso lo puedes ver en cualquier SO que uses (Windows, Linux, BSD), y en mi experiencia reparando computadores me ha tocado ver problemas de hardware muy extraños (como un PC que se niega a arrancar a no ser que cambies la memoria de lugar, y al apagarse tengas que repetir el proceso), y no puedo culpar a Windows y a Debian por eso.

  10.   raalso7 dijo

    yo tuve un kernel panic con un live de ubuntu 12.04

  11.   Ulises Bernal Perez dijo

    Tengo frenetic a mi mi Segura computadora HP pavilion dm4 Notebook PC, 8 GB de RAM, 500 de hard drive, tiene más de 5 a nos de uso. No recuerdo la Velocidad del microprocesador, un Intel core i5, creo que más de 2 mhz.
    No puedo escribir nada en la pantalla del terminal. Seguiré buscando mas información, para solution are este problema.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.