Questo post mostra come "risolvere" quasi il problema delle startup con errori Arch Linux. Qualcosa di simile alla seguente immagine:
Come si può vedere, vediamo che questa è una delle tante "combinazioni" di errori che compaiono casualmente quando si avvia un sistema operativo con questo problema. Come si dice in quell'errore, indica che potrebbe esserci un problema nell '"Hardware", tuttavia, come tutti sappiamo in questo sistema operativo, anche i brutti trucchi di ciò che non appartiene al sistema operativo possono essere risolti.
Quindi, descriverò la mia esperienza di questo problema. Da quello che ho potuto sperimentare, il problema era solo con Arch Linux o un'altra distro che ho testato esternamente, poiché con qualsiasi ubuntu che avevo installato o testato, è partito senza problemi. Ma se provassi a strappare il file Arch Linux installato sul disco rigido, aveva il problema di dover riavviare circa 50 volte per consentire al sistema operativo di avviarsi normalmente e poterlo utilizzare.
Questo aveva già qualcosa che non andava in me perché potevo usare solo l'ubuntu che avevo installato per testarlo e non potevo fare nemmeno la metà delle cose che potevo fare con Arch Linux. Quindi ho deciso di risolvere questo problema e ho iniziato a indagare, cercando thread del forum che avevano lo stesso problema, hanno anche detto che si trattava di un errore hardware e che era proprio la CPU, quindi ha iniziato a preoccuparmi, quindi Ho avuto modo di aprire il PC e verificare cosa stava succedendo, tuttavia, non ha aiutato.
Ma qualcosa che mi ha mostrato che non avrei dovuto arrendermi era che se Ubuntu Potrei perché Arch Linux no (forse Ubuntu è meglio di Arco...?). Quindi ho iniziato a scrivere i parametri di avvio nel kernel di Arch Linux, cose come: 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.nodtyds = 1, apyds = 0, apyds = copyds, pci = nocrs, rhgb, acpi = force, pnpacpi = XNUMXff e altri ancora… Tutto questo mi è stato consigliato nei forum che ho letto.
Fino a quando non ho dovuto entrare nella documentazione dei parametri del kernel, che tra l'altro consiglio: https://www.kernel.org/doc/Documentation/kernel-parameters.txt
E ho trovato un parametro abbastanza interessante che per il momento sono riuscito ad avviare Arch Linux Nessun problema:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce maxcpus = 0
Come indicato qui, ciò che questo parametro fa è limitare l'uso a una cpu senza attivare la modalità di elaborazione simmetrica. All'inizio ha funzionato abbastanza bene fino a quando ho usato il comando pacman-Syyu; mi ha lanciato un core scaricato o errore di segmentazione.
Quindi ho notato automaticamente che stava accadendo qualcosa di strano, quindi ho iniziato a eseguire altri processi fino a quando improvvisamente il sistema si è bloccato completamente e non ha più funzionato, fino a quando non l'ho riavviato. Quindi ho fatto la stessa operazione, ma questa volta sono riuscito a eseguire htop e mi ha mostrato quanto segue:
Come previsto, mostrava solo una CPU, poiché l'altra l'aveva disabilitata, tuttavia, mi è sembrato molto strano perché i programmi lanciassero errore di segmento, e non potevo nemmeno avviare l'ambiente grafico; quindi era qualcosa che almeno mi dava più speranza che se avessi impostato i parametri del kernel in un modo avrebbe avviato il mio file Arch Linux come di solito.
Quindi ho continuato a provare gli altri parametri che avevo scritto nella lista finché non mi sono imbattuto in questo, che è la soluzione migliore al momento:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce isolcpus = 1
Questo parametro fa qualcosa di semplice come isolare (non disattivare) il secondo core della CPU nell'elaborazione simmetrica, ovvero il carico di elaborazione viene assegnato a un singolo core mentre l'altro è solo complementare. Questo, sebbene sembri contraddittorio, non influisce così tanto sulle prestazioni, poiché questo ottimo sistema operativo è stato in grado di eseguire le applicazioni in questo modo:
Quindi, con questo, l'unico problema che ho notato che si verifica al momento dell'avvio, è uno o due kernel panic o oops; ma rispetto alle 50 volte che ho dovuto riavviare in precedenza, posso considerarlo una "soluzione alternativa". Per il resto, finora mi ha permesso di utilizzare l'OS e scrivere questo post che stai leggendo in questo momento :-).
Spero che ti aiutino e non te ne vada GNU / Linux, che è il miglior sistema operativo che abbiano mai inventato. Lo dico per certo.
Informazioni molto interessanti. Non ho mai avuto quei panic del kernel in ArchLinux negli anni in cui l'ho usato, ma è bene sapere cosa fare se il problema mi si presenta. Grazie!
Ad ogni modo, uso Arch da molto tempo (ero tipo 1 anno senza Arch) e senza kernel panic.
Grazie per il consiglio.
Molto probabilmente, come ho accennato nel post, il problema è dovuto all'hardware, perché in quello che uso arch, non mi aveva dato nessun problema neanche di questo tipo.
Un altro con ottimi risultati in Arch. Non ho mai avuto un Kernel Panic
Più di 2 anni con GNU / Linux ... 2 anni già con ArchLinux, mai un kernel panic .. 😉
Penso che il kernel panic sia dovuto più all'hardware che alla distribuzione stessa. Non ho mai visto un kernel antipanico sul laptop che uso ora, tranne una volta che ho inserito un Ubuntu alpha (e anche Arch Linux è stato qui per due anni). D'altra parte, in un altro laptop che ho, qualsiasi distribuzione che metto dà sempre il panico al kernel e un'ampia varietà di errori per tutti i gusti.
Con il kernel 3.14 su Debian, mi sono imbattuto nel problema del kernel panic, inoltre ogni volta che accendo il mio PC, ricevo un messaggio di "connessione / disconnessione timeout" (e anche quando lo spengo).
Mi è successo così tanto in Fedora come in Arch, ma non so perché e come non vedo alcuna differenza dato che non ho passato il tempo a indagare o risolverlo (se è un problema).
Penso che il motivo sia che sono compilati con gcc 4.9
http://libuntu.com/linus-torvalds-considera-que-la-version-4-9-de-gcc-es-una-pura-y-absoluta-mierda/
Grazie mille per l'informazione. Alcune delle tante cose di cui possiamo vantarci è questo tipo di forum
Perché questo accade ad Arch Linux? Forse non basta con i problemi che si presentano frequentemente con la lentezza o l'impiccagione del sistema che arriva al punto di gettare il sistema al tasto.
Hey? Di cosa stai parlando? o_O
Arch è una distribuzione KISS configurabile dalla base del sistema operativo stesso, in poche parole, se il sistema è pesante è perché l'hai costruito così, se il sistema ha degli errori è perché li hai generati tu o perché non hai configurato qualcosa correttamente. Arch wiki è abbastanza completo, alcuni anni fa non c'erano molti argomenti importanti in spagnolo, e il processo di installazione era molto più ruvido e un po 'difficile, ora tutto è un po' più automatizzato.
Incolpare la distribuzione per gli errori degli utenti è così ... Windows (?).
Incolpare la distribuzione per gli errori è essere coerenti, semplicemente perché è la verità. Dopo aver avuto un problema simile con Manjaro, ho provato Arch, Antergos e un'altra distribuzione sconosciuta (non ricordo il nome ora, scusate) che qualcuno mi ha consigliato assicurandomi che non dava problemi, ma niente; lo danno tutti. In OpenSuse, Fedora, Mint, Mageia e tutti quelli che ho provato in seguito non passa. Quindi, per quanto mi riguarda, non mi resta altra scelta che pensare che sia colpa della distribuzione. Ma, ehi, non lo demonizzo o altro, per di più, mi infastidisce davvero non poter usare nulla basato su Arch, perché mi piace molto, ma quel dannato problema me lo impedisce. Né penso che si tratti di hardware, perché a molti di noi che ci è capitato non è successo prima di usare lo stesso cazzo. Beh, effettivamente deve essere qualcosa legato all'hardware, ma, tornando alla stessa cosa, se non ho apportato modifiche e ho problemi con la stessa attrezzatura con cui prima non le avevo, ovviamente sarà dovuto ad una modifica apportata di Arch che mi ha incasinato.
"Incolpare la distribuzione per gli errori degli utenti è così ... Windows (?)."
Ti direi che incolpare gli utenti per gli errori del prodotto è così Apple. Onestamente ci ho pensato mille volte, ma non vedo il vantaggio di usare qualcosa i cui manutentori si lavano fondamentalmente le mani, per qualsiasi scopo serio. E lo dico considerando che il software GPL viene fornito senza garanzia.
Puoi dire come vuoi ma se è lo stesso caso delle segnalazioni di mancanza di segnale all'iPhone e la risposta di Apple "è che ti sbagli" da diversi anni fa. Se crei una distribuzione, di solito vuoi fornire un po 'di qualità e un supporto minimo, e la verità è che Arch è fondamentalmente un sistema per hobby, dove vedi che i suoi sviluppatori si divertono a confezionare cose nuove, ma hanno poco interesse a offrire un vero supporto. Ogni volta che vedo questo tipo di post apprezzo di più il lavoro dietro la distro che utilizzo.
E sì, è un problema software se non funziona, se smette di funzionare in un aggiornamento o se qualcosa dell'hardware si rompe. Che una distribuzione kernel panic mentre un'altra non lo fa ... beh, sì, chiaramente c'è una distribuzione che sta facendo le cose giuste e un'altra sbagliata. Ora, se è il tuo piacere usare Linux nello stile degli anni '90 in cui dovevamo ricompilare il kernel ogni volta che collegavamo una nuova stampante ... eccoti.
Il kernel è compilato dagli sviluppatori? o il tuo?
I panic del kernel vengono generati quando alcuni componenti non sono stati selezionati (AND) durante la compilazione, o alcuni moduli non sono stati attivati per supportare un determinato hardware. Con la pratica e la conoscenza del tuo hardware (devi aprire il pc e vedere quali marche di chip ha), puoi costruire un kernel personalizzato (tramite chroot). Se ubuntu e il CD di installazione di Arch erano sul tuo computer, c'è qualcosa nella compilation che non è attivato.
Era il kernel di serie dell'archlinux stesso, dai repository.
Il kernel che stai usando, è rimasto qualcosa che il tuo hardware non piace, devi avere una versione rara di un chip sulla tua scheda madre o anche un bug in un chip (di solito succede).
Potrebbe essere una tabella corrotta nel tuo bios acpi, è normale che i cinesi di turno non calcolino bene nemmeno il checksum di ogni tabella, questi messaggi di solito compaiono con $ dmesg -human all'inizio del boot.
Dovresti anche provare un altro alimentatore, quando il filtraggio fallisce, l'ondulazione tende a fare proprio questi guasti.
Per prima cosa, prova a cambiare l'origine e guarda cosa succede, se rimane lo stesso, prova a configurare un kernel su misura per il tuo hardware, dal modo in cui conoscerai meglio il tuo PC nel processo.
Grazie per i suggerimenti. A proposito è un laptop, penso che dovrei cambiare la batteria. Ma vedo che quello che mi hai detto può aiutarmi.
L'unico kernel panic che ancora mi fa impazzire è in parte colpa dei ragazzi nouveau e della mia vecchia scheda integrata nVidia 6150 SE (intendo in parte perché; hanno fatto un ottimo lavoro supportando un universo di chip grafici come quelli che ha nVidia, e tutto questo, utilizzando solo il reverse engineering, in più il problema si verifica solo per alcune schede con chipset NV4E).
Basta avviare Openbox + Firefox e il disastro colpisce (niente di più bello che vedere un mosaico in bianco e nero completamente casuale sullo schermo). E l'ho cantato dal kernel 3.6 in Debian, Fedora, Archlinux, Slackware e ora nuovamente verificato di nuovo in Gentoo (appena installato con il kernel 3.12), non mi preoccupo più di prendere un log, al kernel o dargli il tempo di scrivere qualcosa che non essere un personaggio senza senso enorme.
Ti do la soluzione, un pc che ho con gentoo e video nvidia integrato accade lo stesso con il driver nouveau, quindi non ho avuto altra scelta che usare il driver nvidia chiuso, il mio chip deve usare il driver 304.123
00: 0d.0 Controller compatibile VGA [0300]: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] [10de: 03d6] (rev a2) (prog-if 00 [controller VGA])
Devi patchare un file del kernel prima di compilarlo, se non è patchato la modalità grafica si rifiuterà di avviarsi.
I passaggi sono:
# nano -w /usr/src/linux-3.15.7-gentoo/drivers/acpi/osl.c
Cerca con ctrl + w all'interno di nano questo testo, acpi_os_wait_events_complete e nano ti porta a questa parte:
void acpi_os_wait_events_complete (void)
{
flush_workqueue (kacpid_wq);
flush_workqueue (kacpi_notify_wq);
}
EXPORT_SYMBOL (acpi_os_wait_events_complete);
La patch che devi aggiungere è quest'ultima riga che inizia con EXPORT, ctrl + o ctrl + x
Quindi si compila il kernel, si installano i moduli, si installa il kernel, si genera initramfs se necessario, si aggiunge lo splash a initramfs se si usa splash, si rigenerano le voci per grub e infine, cosa molto importante, si devono ricostruire i moduli che non provengono dal kernel o il modulo proprietario nvidia, senza farlo la modalità grafica non funzionerà.
# eseleziona l'elenco del kernel
# eseleziona il kernel set x
# cd / usr / src / linux
# rendere
# make module_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
# spegnimento -r ora
Se usi genkernel devi solo correggere quel file e capisco che genkernel si aggiusta da solo.
Inoltre, è necessario rimuovere il supporto drm, i driver nvidia e altri chip video dal kernel in modo che non entrino in collisione con il driver nvidia chiuso installato come modulo nvidia.
Nel caso di utilizzo di bootsplash, è necessario includere il driver uvesa nel kernel in modo che supporti risoluzioni dello schermo elevate poiché il driver nvidia chiuso (se non ricordo male) non supporta più di 800 × 600 nel terminale tty1 «F1» del boot.
Non so di altre distribuzioni, ma suppongo che dovrebbe funzionare su qualsiasi distribuzione se questi passaggi fossero fatti, salvando il cambiamento di emerge per qualunque cosa.
Queste sono le linee guida che devi seguire, per nvidia e uvesa:
http://wiki.gentoo.org/wiki/NVidia/nvidia-drivers/es
http://wiki.gentoo.org/wiki/Uvesafb
Grazie per le info, ma ho risolto il problema proprio passando a quelli proprietari. Ricordo che anche il precedente driver nVidia (304.121) doveva essere patchato passando alla 3.13 perché aveva un problema nella compilazione del modulo (non c'erano errori, ma il modulo si rifiutava di funzionare) e tutto anche a causa del gestore eventi ACPI . In Debian ho riscontrato il problema e ho trovato anche la soluzione.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740097
Ho usato Manjaro come esempio, ma ho detto prima che la stessa cosa è successa a me con Arch e altri derivati. Pertanto credo che il problema sia più loro che delle persone colpite.
Pd: Non ho potuto rispondere direttamente al messaggio in questione perché l'opzione per rispondere non compare ...
Sono appena passato da Manjaro a Linux Mint perché si bloccava all'avvio dopo l'aggiornamento a una versione successiva alla 0.8.9 (non ricordo quale). Da quello che ho letto, questo di solito accade sui laptop. Il mio problema in questione non era lo stesso di questo post, penso di essere giunto alla conclusione che potrebbe essere correlato alla gestione dell'energia. C'erano persone che non si bloccavano se avviavano il laptop mentre era scollegato. In questo momento non ricordo se questo mi abbia permesso di iniziare sempre senza problemi, ma ovviamente sono riuscito a farlo più volte a costo di impiegare più tempo per farlo.
Ad ogni modo, alla fine ho rinunciato e sono passato a Fedora e Linux Mint.
Casualmente ieri ho provato a sospenderlo senza caricatore e quando lo ho ripreso si è bloccato e ho dovuto ricominciare.
È abbastanza divertente, sono con Arch da alcuni mesi e non ho avuto un solo Kernel Panic! Mi è successo con Antergos (Arch con un repository aggiunto) dall'ambiente live, ma lo considero più comprensibile lì. Potrebbe essere un problema con la scheda madre o un modulo RAM difettoso? Ricordo che circa 2 anni fa un modulo RAM mi ha causato diverse schermate blu in Windows e anche diversi Kernel Panic! su Mandriva. Ho dovuto testare ogni memoria alla volta tra il riavvio e il riavvio.
È un problema di Arch (che porta tutti i suoi derivati), perché in altre distribuzioni non ci sono problemi di quel tipo. Quello che trovo imbarazzante è che a questo punto non l'hanno risolto. Sono stati solo loro da anni! Ho letto problemi simili dal 2011. Sono chiaro che è qualcosa che va e viene quando si aggiornano, perché utilizzando le versioni 0.8.7, 0.8.8 e 0.8.9 senza aggiornarle, non succede nulla. Da quel momento in poi tutto va a puttane, e sicuramente nelle vecchie versioni è successo anche. Perché succede solo a pochi di noi? Non lo so, ma non credo sia un problema nostro, ma di Arch, perché, come già detto, altre distribuzioni funzionano perfettamente. Già ai suoi tempi mi sono rotto le corna per trovare una soluzione, ma mi sono stancato. Quindi, per quanto mi dispiace, non userò Arch.
Arch 0.8.7, 0.8.8 e 0.8.9? Ho scoperto che Arch usa quella nomenclatura di versione.
Potrebbe essere che stai usando Manjaro?
Ok mi rispondo leggendo il tuo precedente commento, e una cosa è Manjaro e un'altra è l'Arch.
Anche il fatto di incolpare una distribuzione per un certo problema non è coerente (non proprio coerente), almeno nel mio caso non posso incolpare quante distro provo per il problema con nouveau e la mia scheda nVidia 6150SE, perché il problema è il Gestione MMIO del driver e della scheda (la nVidia saprà cosa aggiustare e cose folli dovranno aggiustare quel dettaglio). Anche l'hardware può essere il problema e puoi vedere che in qualsiasi sistema operativo in uso (Windows, Linux, BSD) e nella mia esperienza nella riparazione di computer ho visto problemi hardware molto strani (come un PC che si rifiuta di boot a meno che non si cambi la posizione di memoria, e quando si arresta è necessario ripetere il processo), e non posso incolpare Windows e Debian per questo.
Ho avuto un kernel panic con un live ubuntu 12.04
Ho frenetico il mio PC Notebook Secure HP pavilion dm4, 8 GB di RAM, 500 di hard disk, ha più di 5 anni di utilizzo. Non ricordo la velocità del microprocessore, un Intel Core i5, credo più di 2 mhz.
Non riesco a scrivere nulla sullo schermo del terminale. Continuerò a cercare ulteriori informazioni per risolvere questo problema.