Possible solució per «Kernel Panics» aleatoris en el boot d'Arch Linux

Aquesta entrada és per mostrar com «solucionar» gairebé el problema dels inicis amb errors de Arch Linux. Una cosa així com la següent imatge:

IMG_20140707_210559

Que com s'aprecia, veiem que aquest és un dels tantes «combinacions» d'errors que surten aleatòriament a l'arrencar un sistema operatiu amb aquest problema. Segons diu en aquest error, indica que hi pot haver un problema al «maquinari», però, com tots sabem en aquest sistema operatiu es poden solucionar fins a les dolenta aragoneses del que no li pertany a l'SO.

Així que, vaig a descriure la meva experiència d'aquest problema. Segons el que vaig poder experimentar, el problema només es donava amb Arch Linux o una altra distro que provés externament, ja que amb qualsevol ubuntu que tingués instal·lat o provat, arrencava sense problemes. Però si tractava d'arrencar el Arch Linux instal·lat en el disc dur, tenia un problema que havia de reiniciar al voltant d'unes 50 vegades per poder perquè el sistema operatiu arrenqués normalment i el pogués utilitzar.

Això ja em tenia alguna cosa malament perquè només podia utilitzar el ubuntu que tenia instal·lat per provar-lo i no podia fer ni la meitat de les coses que podia fer amb Arch Linux. Pel que em vaig proposar fer això i vaig començar a investigar, buscant fils de fòrums que tenien el mateix problema, esmentaven també que es tractava d'un error de maquinari i que era precisament el CPU, pel que em va començar a preocupar, per la qual que vaig arribar obrir la PC i verificar que passava, però, no va servir de res.

Però una cosa que em demostrava, que no havia de rendir-me era que si Ubuntu podia perquè Arch Linux no (per ventura Ubuntu és millor que Arc...?). Per això, vaig començar a escriure paràmetres d'arrencada en el nucli de Arch Linux, Coses com: 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 i altres més ... Tot això ho recomanaven en els fòrums que llegia.

Fins que vaig haver de entrar a la documentació dels paràmetres de l'nucli, que per cert la recomano: https://www.kernel.org/doc/Documentation/kernel-parameters.txt

I vaig trobar un paràmetre força interessant que de moment vaig aconseguir arrencar Arch Linux sense problemes:

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

Com indica allà, aquest paràmetre el que fa és limitar l'ús a un cpu sense activar la manera simètric de processament. A el principi funcionava força bé fins quan vaig utilitzar la comanda pacman -Syyu; em va donar un core dumped o segmentation fault.

Pel que automàticament vaig notar que alguna cosa estranya estava succeint, pel que em vaig posar a executar altres procés fins que de sobte es va congelar completament el sistema i no va funcionar més, fins que el vaig reiniciar. Així que vaig fer la mateixa operació, però aquest cop vaig aconseguir executar htop i em mostrava el següent:

IMG-20140729-WA0001

Com era d'esperar, només mostrava un CPU, ja que l'altre ho havia deshabilitat, però, em semblava molt estrany perquè els programes llançaven segfault, i ni tan sols podia iniciar l'entorn gràfic; així que va ser una cosa que al menys em va donar més esperança que si configurava els paràmetres de l'nucli d'una manera, arrencaria la meva Arch Linux com sempre.

Així que vaig continuar provant amb els altres paràmetres que vaig escriure a la llista fins que em vaig trobar amb aquest, que de moment és la millor solució:

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

Aquest paràmetre, fa una cosa tan simple com aïllar (no desactivar) el segon nucli de l'CPU en el simètric, és a dir, que la càrrega de processament es la dóna a un sol nucli mentre l'altre només està d'complementari. Això tot que sembli contradictori, no afecta tant el rendiment, ja que aquest gran SOTA va ser capaç de córrer aplicacions d'aquesta manera:

prova

Linux_rlz_compiz

Així que amb això, l'únic problema que vaig observar que dóna en el moment de l'boot, és un o dos nucli panics o oops; però comparat les 50 vegades que havia de reiniciar anteriorment, el puc considerar una solució «provisional». Per la resta, fins ara m'ha permès utilitzar el SO i escriure aquest post que estan llegint ara mateix :-).

Espero que els ajudin, i no se surtin de GNU / Linux, Que és el millor sistema operatiu que han inventat. Ho dic amb tota seguretat.


31 comentaris, deixa el teu

Deixa el teu comentari

La seva adreça de correu electrònic no es publicarà. Els camps obligatoris estan marcats amb *

*

*

  1. Responsable de les dades: Miguel Ángel Gatón
  2. Finalitat de les dades: Controlar l'SPAM, gestió de comentaris.
  3. Legitimació: El teu consentiment
  4. Comunicació de les dades: No es comunicaran les dades a tercers excepte per obligació legal.
  5. Emmagatzematge de les dades: Base de dades allotjada en Occentus Networks (UE)
  6. Drets: En qualsevol moment pots limitar, recuperar i esborrar la teva informació.

  1.   Gregorio Espases va dir

    Molt interessant info. Mai he tingut aquests nucli panics en ArchLinux en els anys que vinc usant-ho, però és bo saber què fer si en algun moment es em presentés el problema. Gràcies!

    1.    kik1n va dir

      Igual, porto molt de temps usant Arch (Vaig estar com 1 any sense Arch) i sense un kernel panic.
      Gràcies pel tip.

    2.    c4explosive va dir

      El més probable és que, com ho esmentava al post, el problema passi pel maquinari, perquè en el que faci servir fitxers, tampoc m'havia donat cap problema d'aquest tipus.

    3.    ILAV va dir

      Un altre amb excel·lent resultat en Arch. Mai he tingut un Kernel Panic

    4.    rawBasic va dir

      Més de 2 anys amb GNU / Linux .. ..2 anys ja amb ArchLinux, mai un nucli panic .. 😉

    5.    Manuel de la Font va dir

      Crec que els nuclis panics es deuen més a el maquinari que a la pròpia distro. En la portàtil que faig servir ara mai he vist un kernel panic excepte una vegada que li vaig ficar una alfa d'Ubuntu (i també aquí va estar Arch Linux per dos anys). En canvi, en una altra portàtil que tinc, qualsevol distro que li posi sempre dóna kernel panic i una àmplia varietat d'errors per a tots els gustos.

  2.   eliotime3000 va dir

    Amb el nucli 3.14 a Debian, m'he topat amb el problema de l'nucli panic, a més que sempre quan prenc el meu PC, m'apareix un missatge de «connect / disconnect timeout» (i també quan l'apago).

    1.    Amaury va dir

      M'ha passat tant a Fedora com a Arch, però no la raó, i com no veig diferència doncs no li he dedicat temps a investigar o resoldre això (si és que és un problema).

  3.   De Tony va dir

    Moltes gràcies per la info. Una cosa de les moltes coses que podem presumir és d'aquest tipus de fòrums

  4.   manu va dir

    Perquè just a Arch Linux li passa això? , Per ventura no n'hi ha prou amb els problemes que es presenten freqüentment amb la lentitud oh la penjada de sistema arribant a tal punt de fer el sistema a l'orris.

    1.    ILAV va dir

      Eh? De què parles? o_O

    2.    Amaury va dir

      Arch és una distribució KISS configurable des de la base de el mateix sistema operatiu, en poques paraules, si el sistema és pesat és perquè tu ho armar d'aquesta forma, si el sistema té errors és per què tu els vas generar o per no haver configurat una cosa correctament la wiki d'Arch és bastant completa, fa alguns anys no hi havia molts temes importants en espanyol, això i que el procés d'instal·lació era molt més tosc i en certa forma difícil, ara tot està una mica més automatitzat.
      Culpar la distro pels errors de l'usuari és tan ... Windows (?).

      1.    Dayara va dir

        Culpar la distro pels errors és ser coherent, simplement perquè és la veritat. Després de tenir un problema similar amb Manjaro, vaig provar Arch, Antergos i una altra distribució desconeguda (no recordo el nom ara, ho sento) que em va recomanar algú assegurant-me que no donava problemes, però res; totes ho donen. En OpenSuse, Fedora, Mint, Mageia i totes les que he provat després no passa. Per tant, pel que fa a mi, no em queda una altra opció que pensar que és culpa de la distro. Però, escolta, no la va demonitzar ni res, és més, em fot molt no poder usar res basat en Arch, perquè m'agrada molt, però aquest maleït problema m'ho impedeix. Tampoc penso que es tracti d'el maquinari, doncs a molts dels que ens passa no ens passava abans utilitzant el mateix fotut. Bé, en realitat sí que ha de ser alguna cosa relacionada amb el maquinari, però, tornant al mateix, si jo no he fet cap canvi i tinc problemes amb el mateix equip amb el que abans no els tenia, òbviament s'haurà a un canvi realitzat per Arch que m'ha fotut.

      2.    juanfgs va dir

        «Culpar la distro pels errors de l'usuari és tan ... Windows (?).»

        Et diria que culpar els usuaris pels errors del producte és tan Apple. Sincerament li he donat mil voltes a l'assumpte però no veig l'avantatge en utilitzar una mica els mantenidors bàsicament es renten les mans, per a cap propòsit seriós. I això ho dic tenint en compte que el programari GPL ve sense garantia.

        Podis dir com vulguis però si és el mateix cas dels informes de falta de senyal a l'iPhone i la resposta d'Apple «és que ho aquestes agafant mal» de fa diversos anys. Si fas una distro en general queres brindar una mica de qualitat, i un mínim suport, i la veritat és que Arch bàsicament és un sistema de hobbyistas, on es veu que els seus desenvolupadors es diverteixen empaquetant coses noves, però tenen poc interès en oferir un suport veritable. Cada vegada que veig aquest tipus de posts valoro més la feina darrere de la distro que faig servir.

        I si, és un problema de programari si no funciona, si deixa de funcionar en un update, o si et trenca una mica de el maquinari. Que una distro et de nucli panic mentre una altra no ho fa ... doncs si, clarament hi ha una distro que aquesta fent les coses bé i una altra malament. Ara si és teu gust utilitzar Linux a l'estil dels 90 on havíem de recompilar el nucli cada vegada que enchufabamos una impressora nova ... allà vós.

  5.   Mario va dir

    És el nucli compilat pels desenvolupadors? o un de propi?
    Els kernel panic es generen al no haver seleccionat (I) certs components a l'compilar, o no haver-se activat alguns mòduls perquè suporti cert maquinari. Ja amb la pràctica i coneixement de la teva maquinari (cal obrir la pc i veure que marques de xips té), es pot armar un nucli a mida (mitjançant chrooting). Si ubuntu i el CD d'instal·lació d'Arch andaron en el teu equip, hi ha alguna cosa en la compilació que no està activat.

    1.    c4explosive va dir

      Era el nucli estoc d'ell mateix ArchLinux, dels dipòsits.

  6.   anonimo va dir

    El nucli que estàs fent servir, li aquesta sobrant alguna cosa que al teu maquinari no li agrada, heu de tenir alguna versió rara d'algun xip a la teva placa mare o fins i tot un error en algun xip (sol passar).
    Pot ser una taula corrupta d'el acpi del teu vis, és normal que el xinès de torn ni tan sols calculi bé el checksum de cada taula, aquests missatges sol sortir amb $ dmesg -human en l'inici de l'booteig.
    També hauries de provar amb una altra font d'alimentació, quan falla el filtrat el ripple sol fer aquest tipus de falles justament.
    Primer proba a canviar la font i veure que passa, si segueix igual proba a un nucli configurar-a la mida del teu maquinari, de pas coneixeràs millor el teu pc en el procés.

    1.    c4explosive va dir

      Gràcies, pels consells. Per cert és un portàtil, penso que hauria de canviar-li la bateria. Però veig el que m'has dit em pot servir.

  7.   Yukiteru va dir

    L'únic nucli panic que encara em treu de polleguera és en part culpa dels nois de nouveau i el meu vetusta, antiquada i molt emoolsada targeta integrada nVidia 6150 ES (dic en part perquè; han fet un excel·lent treball suportant un univers de xips gràfics com els que té nVidia, i tot això, usant només enginyeria inversa, a més que el problema només es presenta per a algunes targetes amb el chipset NV4E).

    Només cal que iniciï Openbox + Firefox i s'arma el desastre (res més bonic que veure un mosaic blanc i negre a la pantalla completament aleatori). I ho vinc cantant des del nucli 3.6 a Debian, Fedora, Archlinux, Slackware i ara reverificado novament en Gentoo (recent instal·lat amb el nucli 3.12), no em molest ja per treure registre, a l'nucli ni té temps per escriure alguna cosa que no sigui una barbaritat de caràcters sense sentit.

    1.    anonimo va dir

      Et dono la solució, a una pc que tinc amb gentoo i vídeo nvidia integrat li passa el mateix amb el controlador nouveau, així que no em va quedar altra que fer servir el controlador tancat de nvidia, el meu xip de fer servir el controlador 304.123

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

      Cal posar pegats un arxiu de el nucli abans de compilar-lo, si no es parchea la manera gràfica es negarà a iniciar.

      Els passos són:
      # Nano -w /usr/src/linux-3.15.7-gentoo/drivers/acpi/osl.c
      busques amb ctrl + w dins de nano aquest text, acpi_os_wait_events_complete i nano et porta a aquesta part:

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

      El pegat que has de afegir és aquesta última línia que comença amb EXPORT, ctrl + o ctrl + x
      Després compilas el nucli, instal·les els mòduls, instal·les el nucli, generes l'initramfs si ho necessites, agregues a l'initramfs el splash si és que fas servir splash, regeneres les entrades pel grub i per últim i molt important, reconstrueix els mòduls que no són de l' nucli o sigui el mòdul nvidia propietari, sense fer això no et va a caminar la manera gràfic.

      # Eselect nucli list
      # Eselect nucli setembre x
      # Cd / usr / src / linux
      # fer
      # 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 emergeix-world
      # Grub-mkconfig -o grub.cfg
      # Emergeix @ module-rebuild
      # Umount / boot
      # Shutdown -r now

      Si fas servir genkernel, només parcheas aquest arxiu i tinc entès que genkernel s'arregla sol.
      A més has de treure el suport drm i els drivers nvidia i altres xips de vídeo de el nucli perquè no xoquin de front amb el controlador tancat nvidia que s'instal·la com a mòdul nvidia.
      En el cas d'utilitzar bootsplash has d'incloure en el nucli el driver Uvesa perquè suporti resolucions altes de pantalla ja que el controlador tancat nvidia (si no recordo malament) no suporta mes que 800 × 600 a la terminal tty1 «F1» de l'booteig.
      No en altres distros, però suposo que hauria caminar en qualsevol distro si es fessin aquests passos, salvant el canvi de emergeix pel que fos.

      Aquestes són les guies que has de seguir, per nvidia i Uvesa:
      http://wiki.gentoo.org/wiki/NVidia/nvidia-drivers/es
      http://wiki.gentoo.org/wiki/Uvesafb

      1.    Yukiteru va dir

        Gràcies per la info, però el problema el solucioni precisament canviant als privatius. Recordo que l'anterior driver de nVidia (304.121) també calia parchearlo a l'passar a la 3.13 perquè tenia un problema a la compilació de l'mòdul (no hi havia errors, però el mòdul es negava a funcionar) i tot també pel gestor d'esdeveniments ACPI . A Debian em vaig aconseguir amb el petit problema i vaig trobar la solució també.

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

    2.    Dayara va dir

      He posat Manjaro com a exemple, però ja he esmentat abans que m'ha passat el mateix amb Arch i altres derivats. Per tant crec que el problema és més d'ells que dels afectats.

      Pd: No he pogut respondre't directament a l'missatge pertinent perquè no m'apareix l'opció de respondre ...

  8.   Dayara va dir

    Jo precisament em vaig passar de Manjaro a Linux Mint perquè es em congelava a l'arrencar després d'actualitzar a alguna versió posterior a la 0.8.9 (no recordo quin). Pel que vaig llegir, això sol passar en els portàtils. El meu problema en qüestió no era el mateix que el d'aquesta entrada, crec que vaig arribar a la conclusió que podia estar relacionat amb la gestió d'energia. Hi havia gent a la qual no se li congelava si arrencava el portàtil estant desconnectat. Ara mateix no recordo si això em permetia arrencar sempre sense problemes, però per descomptat ho aconseguia més vegades a costa de trigar més en haceelo.
    En fi, a la fi vaig desistir i em vaig passar a Fedora ja Linux Mint.

    1.    c4explosive va dir

      Casualment, ahir vaig provar suspendre-sense el carregador i a l'reprendre es va penjar i vaig haver de reiniciar.

  9.   Amaury va dir

    És bastant curiós, porto uns quants mesos amb Arch i no he tingut ni un sol Kernel Panic! M'ha passat amb Antergos (Arch amb un repositori agregat) des de l'entorn live, però aquí el considero més entenedora. Serà possible que sigui algun problema de la Mother Board o bé d'un mòdul de la RAM defectuós? Recordo que fa com 2 anys un mòdul de RAM em va provocar diversos pantallazos blaus en Windows i igualment diversos Kernel Panic! en Mandriva. Vaig haver de provar cada memòria alhora entre reinici i reinici.

    1.    Dayara va dir

      És un problema d'Arch (que arrossega a tots els seus derivats), perquè en altres distros no hi ha problemes d'aquest tipus. El que em sembla vergonyós és que a hores d'ara no ho hagin solucionat. 'Porta passant-li anys només a ells! He llegit problemes similars de 2011. Tinc clar que es tracta d'una cosa que ve i va segons s'actualitzen, perquè usant les versions 0.8.7, 0.8.8 i 0.8.9 sense actualitzar-no passa res. D'aquí en endavant es va tot a la merda, i segurament en versions antigues també passava. Per què ens passa només a uns quants? No ho sé, però no crec que sigui el nostre problema, sinó d'Arch, doncs, com ja s'ha dit, altres distribucions van perfectament. Jo ja em vaig trencar les banyes al seu dia per trobar una solució, però em vaig cansar. Així que, per molt que em pesi, no penso fer servir Arch.

      1.    Yukiteru va dir

        ¿Arch 0.8.7, 0.8.8 i 0.8.9? M'assabento que Arch fa servir aquesta nomenclatura de versions.

        No serà que aquestes usant Manjaro?

      2.    Yukiteru va dir

        Val em responc a mi mateix llegint el teu comentari anterior, i una cosa és Manjaro i una altra és Arch.

        Això de culpar una distro per un determinat problema tampoc és coherent (res coherent en realitat), almenys en el meu cas no puc a culpar a quanta distro provi pel problema amb nouveau i la meva targeta nVidia 6150SE, perquè el problema és el maneig de MMIO de l'driver i la targeta (sabran els nVidia que fix i coses boges tindran per arreglar aquest detall). El maquinari també pot ser el de el problema, i això ho pots veure en qualsevol SO que facis servir (Windows, Linux, BSD), i en la meva experiència reparant computadors m'ha tocat veure problemes de maquinari molt estranys (com un PC que es nega a arrencar tret que canviïs la memòria de lloc, i a l'apagar-hagis de repetir el procés), i no puc culpar Windows ja Debian per això.

  10.   raalso7 va dir

    jo vaig tenir un kernel panic amb un live de ubuntu 12.04

  11.   Ulisses Bernal Perez va dir

    Tinc Frenetic al meu meu Segura ordinador HP pavilion DM4 Llibreta PC, 8 GB de RAM, 500 d'hard drive, té més de 5 a ens d'ús. No recordo la Velocitat de el microprocessador, un Intel core i5, crec que més de 2 mhz.
    No puc escriure res a la pantalla de l'terminal. Seguiré buscant més informació, per solution are aquest problema.