Tämän viestin on tarkoitus näyttää, kuinka "korjata" melkein virheiden kanssa aloittelevien yritysten ongelma Arch Linux. Jotain seuraavan kuvan kaltaista:
Kuten voidaan nähdä, näemme, että tämä on yksi monista virheiden "yhdistelmistä", jotka esiintyvät satunnaisesti käynnistettäessä käyttöjärjestelmää tämän ongelman kanssa. Kuten siinä virheessä sanotaan, se osoittaa, että "laitteistossa" voi olla ongelma, mutta kuten me kaikki tiedämme tässä käyttöjärjestelmässä, jopa huonot temput siitä, mikä ei kuulu käyttöjärjestelmään, voidaan ratkaista.
Joten kuvaan kokemukseni tästä ongelmasta. Sen perusteella, mitä pystyin kokemaan, ongelma oli vain Arch Linux tai jokin muu distro, jonka testasin ulkoisesti, koska minkä tahansa asentamani tai testatun Ubuntun kanssa se alkoi ongelmitta. Mutta jos yritän repiä Arch Linux asennettu kiintolevylle, sillä oli ongelma, että se oli käynnistettävä uudelleen noin 50 kertaa, jotta käyttöjärjestelmä käynnistyy normaalisti ja pystyy käyttämään sitä.
Tällä oli jo jotain vikaa minussa, koska pystyin testaamaan sitä vain asentamallani Ubuntulla, enkä voinut tehdä edes puolta asioista, joita voisin tehdä Arch Linux. Joten päätin ratkaista tämän ongelman ja aloin tutkia, etsimällä foorumiketjuja, joilla oli sama ongelma, he mainitsivat myös, että se oli laitteistovirhe ja että se oli juuri prosessori, joten se alkoi huolestuttaa minua, joten Sain avata tietokoneen ja tarkistaa, mitä tapahtui, mutta se ei auttanut.
Mutta jotain, joka osoitti minulle, että minun ei pitäisi luopua, oli, että jos Ubuntu Voisin koska Arch Linux ei (ehkä Ubuntu on parempi kuin Kaari…?). Joten aloin kirjoittaa käynnistysparametreja Arch Linux, asioita kuten: 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 = poista käytöstä, i8042.noacpi = 1, apm = copyds, ac apm = kopydit, acdtpi = 0, apm = kopydit pci = nokka, rhgb, acpi = voima, pnpacpi = XNUMXff ja muita enemmän ... Kaikkea tätä suositeltiin lukemissani foorumeissa.
Kunnes minun piti mennä ytimen parametrien dokumentaatioon, jota suosittelen muuten: https://www.kernel.org/doc/Documentation/kernel-parameters.txt
Ja löysin varsin mielenkiintoisen parametrin, jonka tällä hetkellä onnistuin käynnistämään Arch Linux Ei ongelmaa:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce maxcpus = 0
Kuten siellä on osoitettu, tämä parametri rajoittaa käytön suorittimeen aktivoimatta prosessin symmetristä tilaa. Aluksi se toimi melko hyvin, kunnes käytin komentoa pacman-Syyu; heitti minulle a ydin polkumyynnillä o segmentointivirhe.
Joten huomasin automaattisesti, että jotain outoa oli tapahtumassa, joten aloin suorittaa muita prosesseja, kunnes yhtäkkiä järjestelmä jäätyi kokonaan eikä toiminut enää, kunnes käynnistin sen uudelleen. Joten tein saman operaation, mutta tällä kertaa onnistuin suorittamaan htop ja se osoitti minulle seuraavat:
Kuten odotettiin, se näytti vain yhden suorittimen, koska toinen oli poistanut sen käytöstä, mutta minusta tuntui hyvin oudolta, miksi ohjelmat heittivät segfault, eikä voinut edes käynnistää graafista ympäristöä; Joten se antoi minulle ainakin enemmän toivoa, että jos asetan ytimen parametrit yhdellä tavalla, se käynnistää minun Arch Linux kuten tavallista.
Joten kokeilin muita luetteloon kirjoittamiani parametreja, kunnes törmäsin tähän, mikä on paras ratkaisu tällä hetkellä:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce isolcpus = 1
Tämä parametri tekee jotain niin yksinkertaista kuin eristää (ei deaktivoi) toinen ydin prosessorista symmetrisessä prosessoinnissa, toisin sanoen prosessointikuorma annetaan yhdelle ytimelle, kun taas toinen on vain täydentävä. Tämä vaikuttaa ristiriitaiselta, mutta ei vaikuta niin paljon suorituskykyyn, koska tämä suuri käyttöjärjestelmä pystyi ajamaan sovelluksia tällä tavalla:
Joten tässä ainoa havaitsemani ongelma, joka esiintyy käynnistyshetkellä, on yksi tai kaksi ytimen paniikkia tai oho; Mutta verrattuna siihen 50 kertaan, jonka jouduin käynnistämään uudelleen aiemmin, voin pitää sitä "kiertotapana". Loput, toistaiseksi se on antanut minun käyttää käyttöjärjestelmää ja kirjoittaa tämän viestin, jota luet juuri nyt :-).
Toivon, että he auttavat sinua, eivätkä päästä pois GNU / Linux, mikä on heidän kaikkien aikojen paras käyttöjärjestelmä. Sanon sen varmasti.
Erittäin mielenkiintoinen info. Minulla ei ole koskaan ollut näitä ytimen paniikkeja ArchLinuxissa vuosina, joita olen käyttänyt sitä, mutta on hyvä tietää, mitä tehdä, jos jossakin vaiheessa ongelma ilmenee. Kiitos!
Joka tapauksessa olen käyttänyt Archia pitkään (olin kuin vuosi ilman Archia) ja ilman ydinpaniikkaa.
Kiitos vinkistä.
Todennäköisesti, kuten mainitsin viestissä, ongelma tapahtuu laitteiston takia, koska siinä, mitä käytän archia, se ei ollut myöskään aiheuttanut minulle tällaista ongelmaa.
Toinen, jolla on erinomaiset tulokset Archissa. Minulla ei ole koskaan ollut ydinpaniikkaa
Yli 2 vuotta GNU / Linuxin kanssa ... 2 vuotta jo ArchLinuxin kanssa, ei koskaan ydinpaniikkia .. 😉
Mielestäni ytimen paniikki johtuu enemmän laitteistosta kuin itse häiriöstä. En ole koskaan nähnyt paniikkisydämää kannettavalla tietokoneella, jota käytän nyt, paitsi kun laitoin siihen Ubuntu-alfan (ja Arch Linux oli täällä myös kaksi vuotta). Toisaalta toisessa minulla olevassa kannettavassa tietokoneessani jokainen laitettani tuottaa aina ytimen paniikkia ja monenlaisia virheitä jokaiseen makuun.
Debianin ytimen 3.14 avulla olen törmännyt ytimen paniikkiongelmaan, sen lisäksi, että aina kun käynnistän tietokoneeni, saan "connect / disconnout timeout" -viestin (ja myös kun sammutan sen).
Minulle on tapahtunut niin paljon Fedorassa kuin Archissa, mutta en tiedä miksi ja miten en näe eroa, koska en ole viettänyt aikaa sen tutkimiseen tai ratkaisemiseen (jos se on ongelma).
Mielestäni syy on se, että ne on koottu gcc 4.9: llä
http://libuntu.com/linus-torvalds-considera-que-la-version-4-9-de-gcc-es-una-pura-y-absoluta-mierda/
Paljon kiitoksia tiedoista. Jotkut monista asioista, joista voimme ylpeillä, on tämäntyyppinen foorumi
Miksi näin tapahtuu Arch Linuxille? Ehkä se ei riitä ongelmiin, jotka usein ilmenevät, kun järjestelmän hitaus tai riippuminen saavuttaa järjestelmän heittämisen tuskaan.
Hei? Mistä sinä puhut? o_O
Arch on KISS-jakelu, joka voidaan konfiguroida itse käyttöjärjestelmän pohjalta, muutamalla sanalla, jos järjestelmä on raskas, se johtuu siitä, että rakennit sen tällä tavalla, jos järjestelmässä on virheitä, se johtuu siitä, että olet luonut ne tai koska et ole Määritä jotain oikein. Arch wiki on melko täydellinen, muutama vuosi sitten espanjaksi ei ollut paljon tärkeitä aiheita, ja asennusprosessi oli paljon karkeampi ja hieman vaikea, nyt kaikki on hieman automatisoitua.
Distron syyttäminen käyttäjävirheistä on niin… Windows (?).
Distron syyttäminen virheistä on johdonmukaista yksinkertaisesti siksi, että se on totuus. Kun minulla oli samanlainen ongelma Manjaron kanssa, kokeilin Archia, Antergosia ja toista tuntematonta jakelua (en muista nimeä nyt, anteeksi), jonka joku suositteli minulle vakuuttamaan minulle, että se ei aiheuttanut ongelmia, mutta ei mitään; he kaikki antavat sen. OpenSuse, Fedora, Mint, Mageia ja kaikki, joita olen kokeillut jälkeenpäin, niin ei tapahdu. Joten minusta ei jää muuta vaihtoehtoa kuin ajatella, että se on distron vika. Mutta hei, en demonisoi sitä tai mitään, mikä vielä enemmän, se todella ärsyttää minua siitä, että en voi käyttää mitään Archin perusteella, koska pidän siitä todella, mutta tuo kirottu ongelma estää minua. En myöskään usko, että kyse on laitteistosta, koska monet meistä, jotka tapahtuvat meille, eivät tapahtuneet ennen saman vitun käyttöä. No, oikeastaan sen on oltava jotain laitteistoon liittyvää, mutta palatakseni samaan asiaan, jos en ole tehnyt mitään muutoksia ja minulla on ongelmia samojen laitteiden kanssa, joilla minulla ei ollut niitä aiemmin, se johtuu ilmeisesti tehdystä muutoksesta Arch, joka on ruuvannut minut.
"Distron syyttäminen käyttäjävirheistä on niin ... Windows (?)."
Sanoisin teille, että käyttäjien syyttäminen tuotevirheistä on niin Apple. Olen rehellisesti ajatellut sitä tuhat kertaa, mutta en näe etua siitä, että käyttäisin jotain, jonka ylläpitäjät pohjimmiltaan pesevät kätensä, mihinkään vakavaan tarkoitukseen. Ja sanon, että kun otetaan huomioon, että GPL-ohjelmistolla on takuu.
Voit sanoa haluamallasi tavalla, mutta jos kyseessä on sama raportti signaalien puutteesta iPhonelle ja Applen vastaus "on, että olet väärässä" useita vuosia sitten. Jos teet distroa, haluat yleensä tarjota jonkin verran laatua ja minimaalista tukea, ja totuus on, että Arch on pohjimmiltaan harrastajajärjestelmä, jossa huomaat, että sen kehittäjät pakastavat uusia asioita, mutta eivät juurikaan ole kiinnostuneita tarjoamaan todellista tukea . Joka kerta, kun näen tämän tyyppisiä viestejä, arvostan enemmän työtä, jota käytän käyttämäni distron takana.
Ja kyllä, se on ohjelmisto-ongelma, jos se ei toimi, jos se lakkaa toimimasta päivityksessä tai jos jokin laitteisto rikkoutuu. Tuo ydinkeskustelu paniikkiin, kun taas toinen ei… no kyllä, selvästi on olemassa distro, joka tekee asioita oikein ja toinen väärin. Jos sinulla on ilo käyttää Linuxia 90-luvun tyyliin, jossa meidän täytyi kääntää ydin uudelleen joka kerta, kun liitimme uuden tulostimen ... siellä sinä.
Onko kehittäjät koonnut ytimen? vai omasi?
Ytimen paniikkeja syntyy siitä, että ei ole valittu (JA) tiettyjä komponentteja käännettäessä tai että ei ole aktivoitu joitain moduuleja tukemaan tiettyjä laitteita. Harjoittelemalla ja tietämällä laitteistosi (sinun on avattava tietokone ja katsottava, mitä merkkejä sillä on), voit rakentaa mukautetun ytimen (chrootingilla). Jos ubuntu ja Arch-asennus-CD olivat tietokoneellasi, kokoelmassa on jotain, jota ei ole aktivoitu.
Se oli varaston ydin itse archlinuxista, arkistoista.
Käyttämässäsi ytimessä on jäljellä jotain, josta laitteistosi eivät pidä, emolevylläsi on oltava harvinainen versio sirusta tai jopa sirussa oleva virhe (se tapahtuu yleensä).
Se voi olla vioittunut taulukko bios acpissasi, on normaalia, että päivystävät kiinalaiset eivät edes laske kunkin taulukon tarkistussummaa hyvin, nämä viestit näkyvät yleensä $ dmesg -human -käynnistyksen alussa.
Kokeile myös toista virtalähdettä, kun suodatus epäonnistuu, aaltoilu pyrkii tekemään juuri tällaisen vian.
Yritä ensin vaihtaa lähdettä ja katso mitä tapahtuu. Jos se pysyy samana, yritä määrittää laitteistolle räätälöity ydin, muuten tunnet tietokoneesi paremmin prosessissa.
Kiitos vinkeistä. Muuten se on kannettava tietokone, mielestäni minun pitäisi vaihtaa akku. Mutta näen, mitä olet kertonut minulle, voi auttaa minua.
Yhden ytimen paniikki, joka edelleen ajaa minut hulluksi, on osittain uudenvuoden kaverien ja vanhan, vanhentuneen ja erittäin pölyisen integroidun nVidia 6150 SE -korttini vika (tarkoitan osittain siksi, että he ovat tehneet erinomaista työtä tukemalla maailmanlaajuista grafiikkapiiriä kuten ne, jotka nVidialla on, ja kaikki tämä käyttää vain käänteistä suunnittelua, ja ongelma esiintyy vain joillakin NV4E-piirisarjan korteilla).
Sinun tarvitsee vain käynnistää Openbox + Firefox ja katastrofi-iskut (ei mitään kauniimpaa kuin nähdä täysin satunnainen mustavalkoinen mosaiikki näytöllä). Ja olen laulanut sitä ytimen 3.6 jälkeen Debianissa, Fedorassa, Archlinuxissa, Slackware: ssä ja nyt vahvistettu uudelleen Gentoolla (juuri asennettu ytimen 3.12 kanssa), en enää vaivaudu ottamaan lokia, ydintä eikä sillä ole aikaa kirjoita jotain, joka ei ole huikea hölynpölyä.
Annan sinulle ratkaisun, tietokone, jonka minulla on gentoo- ja integroidulla nvidia-videolla, tapahtuu samalla tavalla uudenvuoden ohjaimen kanssa, joten minulla ei ollut muuta vaihtoehtoa kuin käyttää suljettua nvidia-ohjainta, siruni on käytettävä 304.123-ohjainta
00: 0d.0 VGA-yhteensopiva ohjain [0300]: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] [10de: 03d6] (rev a2) (prog-if 00 [VGA-ohjain])
Sinun on korjattava ydintiedosto ennen sen kääntämistä, ellei sitä korjata, grafiikkatila kieltäytyy käynnistymästä.
Vaiheet ovat:
# nano -w /usr/src/linux-3.15.7-gentoo/drivers/acpi/osl.c
Hae näppäimistöllä ctrl + w nanosta tämän tekstin kohdalla, acpi_os_wait_events_complete ja nano vie sinut tähän osaan:
void acpi_os_wait_events_complete (mitätön)
{
flush_workqueue (kacpid_wq);
flush_workqueue (kacpi_notify_wq);
}
EXPORT_SYMBOL (acpi_os_wait_events_complete);
Lisättävä korjaustiedosto on tämä viimeinen rivi, joka alkaa sanoilla EXPORT, ctrl + tai ctrl + x
Sitten käännät ytimen, asennat moduulit, asennat ytimen, luot tarvittaessa initramf-tiedostot, lisäät tilkan initramf-tiedostoihin, jos käytät tilkkaa, regeneroit grub-merkinnät ja viimeiseksi ja mikä tärkeintä, sinun on rakennettava uudestaan moduulit, jotka eivät ole ytimestä tai omasta nvidia-moduulista, ilman tätä graafinen tila ei toimi.
#valitse ydinluettelo
# eselect ytinsarja x
# cd / usr / src / linux
# tehdä
# tee modules_install
# mount / boot
# tee asennus
# dracut –hostonly »3.15.7-gentoo –voima
# 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 nyt
Jos käytät genkernelia, vain korjaat kyseisen tiedoston ja ymmärrän, että genkernel korjaa itsensä.
Lisäksi sinun on poistettava drm-tuki, nvidia-ohjaimet ja muut videopiirit ytimestä, jotta ne eivät törmää etupäässä nvidia-moduulina asennetun suljetun nvidia-ohjaimen kanssa.
Bootplashia käytettäessä sinun on sisällytettävä uvesa-ohjain ytimeen, jotta se tukee korkeita näytön tarkkuuksia, koska suljettu nvidia-ohjain (jos muistan oikein) ei tue enempää kuin 800 × 600 käynnistyspäätteessä tty1 «F1».
En tiedä muista distroista, mutta luulen, että sen pitäisi toimia missä tahansa distrossa, jos nämä vaiheet tehtäisiin, mikä säästää syntyvän muutoksen mihin tahansa.
Nämä ovat ohjeet, joita sinun on noudatettava nvidialle ja uvesalle:
http://wiki.gentoo.org/wiki/NVidia/nvidia-drivers/es
http://wiki.gentoo.org/wiki/Uvesafb
Kiitos tiedoista, mutta olen ratkaissut ongelman tarkalleen vaihtamalla omiin. Muistan, että edellinen nVidia-ohjain (304.121) oli myös korjattava, kun meni 3.13: een, koska sillä oli ongelmia moduulin kokoamisessa (virheitä ei ollut, mutta moduuli kieltäytyi toimimasta) ja kaikki myös ACPI-tapahtumakäsittelijän takia . Debianissa sain ongelman ja löysin myös ratkaisun.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740097
Olen käyttänyt Manjaroa esimerkkinä, mutta olen aiemmin maininnut, että sama tapahtui minulle Archin ja muiden johdannaisten kanssa. Siksi uskon, että ongelma on enemmän heidän kuin ongelmien kohteena.
Pd: En ole pystynyt vastaamaan suoraan asiaankuuluvaan viestiin, koska vastausvaihtoehtoa ei näy ...
Menin juuri Manjarosta Linux Mintiin, koska se jumiutui käynnistettäessä, kun päivitin versioon 0.8.9 jälkeen (en muista kumpi). Lukujen mukaan tämä tapahtuu yleensä kannettavissa tietokoneissa. Kyseinen ongelmani ei ollut sama kuin tässä viestissä, luulen, että päädyin siihen johtopäätökseen, että se voisi liittyä energianhallintaan. Oli ihmisiä, jotka eivät jäätyneet, jos he käynnistivät kannettavan tietokoneen virran ollessa kytkettynä. Tällä hetkellä en muista, antoiko tämä minun mahdollisuuden aloittaa aina ongelmitta, mutta tietysti pystyin tekemään sen useamman kerran kustannuksella, että sen tekeminen kestää kauemmin.
Joka tapauksessa lopulta luovuin ja vaihdoin Fedoraan ja Linux Mintiin.
Sattumalta yritin eilen keskeyttää sen ilman laturia ja jatkaessani sen ripustamista ja minun piti käynnistää uudelleen.
Se on melko hauskaa, olen ollut Archin kanssa muutama kuukausi eikä minulla ole ollut yhtään ytimenpaniikkaa! Se on tapahtunut minulle Antergosin (Arch, johon on lisätty arkisto) kanssa elävästä ympäristöstä, mutta pidän sitä ymmärrettävämmin siellä. Voisiko se olla ongelma emolevyssä tai viallisessa RAM-moduulissa? Muistan noin 2 vuotta sitten, että RAM-moduuli aiheutti minulle useita sinisiä näyttöjä Windowsissa ja myös useita ytimen paniikkeja! Mandrivalla. Minun oli testattava jokainen muisti kerrallaan uudelleenkäynnistyksen ja uudelleenkäynnistyksen välillä.
Se on Arch-ongelma (joka sisältää kaikki johdannaiset), koska muissa distroissa ei ole tällaisia ongelmia. Minusta on noloa, että tässä vaiheessa he eivät ole ratkaisseet sitä. Se on ollut vain heitä vuosia! Olen lukenut vastaavia ongelmia vuodelta 2011. Olen selvä, että tämä tulee ja tulee, kun ne päivittyvät, koska versioiden 0.8.7, 0.8.8 ja 0.8.9 käyttäminen päivittämättä niitä ei tapahdu. Siitä lähtien kaikki menee paskaan, ja varmasti myös vanhoissa versioissa se tapahtui. Miksi se tapahtuu vain harvoille meistä? En tiedä, mutta en usko, että se on meidän ongelmamme, mutta Archin, koska, kuten jo todettiin, muut jakelut toimivat täydellisesti. Murdin sarvet jo hänen aikanaan ratkaisun löytämiseksi, mutta kyllästyin. Joten niin paljon kuin olen pahoillani, en aio käyttää Archia.
Kaari 0.8.7, 0.8.8 ja 0.8.9? Saan selville, että Arch käyttää tuota nimikkeistöä.
Voisiko olla, että käytät Manjaroa?
Ok, vastaan itselleni lukemalla edellisen kommenttisi, ja yksi asia on Manjaro ja toinen Arch.
Se, että distron syyttäminen tietystä ongelmasta ei ole myöskään johdonmukaista (ei oikeastaan johdonmukaista), ainakaan minun tapauksessani en voi syyttää kuinka monta distroa yritän uuden ja nVidia 6150SE -korttini ongelmasta, koska ongelma on Kuljettajan ja kortin MMIO-käsittely (nVidia tietää, mitä korjata, ja hullut asiat, jotka heidän on korjattava tämä yksityiskohta). Laitteisto voi myös olla ongelma, ja voit nähdä, että missä tahansa käyttöjärjestelmässä (Windows, Linux, BSD) ja kokemukseni mukaan tietokoneiden korjaamisessa olen nähnyt hyvin outoja laitteisto-ongelmia (kuten tietokone, joka kieltäytyy käynnistä, ellet muuta muistipaikkaa, ja sammutettaessa sinun on toistettava prosessi), enkä voi syyttää Windowsia ja Debiania siitä.
Minulla oli ydinpaniikki live-Ubuntu 12.04: n kanssa
Minulla on kiihkeä Secure HP Pavilion dm4 -kannettava, 8 Gt RAM-muistia, 500 kiintolevyä, sillä on yli 5 vuoden käyttöikä. En muista mikroprosessorin, Intel Core i5: n, nopeutta, mielestäni yli 2 MHz.
En voi kirjoittaa mitään päätelaitteelle. Etsin jatkuvasti lisätietoja ongelman ratkaisemiseksi.