Ovaj post pokazuje kako "pogreške" gotovo riješiti problem pokretanja Arch Linux. Nešto poput sljedeće slike:
Kao što se može vidjeti, vidimo da je ovo jedna od mnogih "kombinacija" pogrešaka koje se pojavljuju slučajno prilikom pokretanja operativnog sustava s ovim problemom. Kao što stoji u toj pogrešci, to ukazuje na to da bi mogao postojati problem u "Hardveru", međutim, kao što svi znamo u ovom operativnom sustavu, mogu se riješiti čak i loši trikovi onoga što ne pripada OS-u.
Dakle, opisat ću svoje iskustvo s tim problemom. Koliko sam mogao doživjeti, problem je bio samo u tome Arch Linux ili neki drugi distro koji sam testirao izvana, jer je s bilo kojim ubuntuom koji sam instalirao ili testirao počeo bez problema. Ali ako je pokušao počupati Arch Linux instaliran na tvrdom disku, imao sam problem da sam se morao ponovno pokrenuti oko 50 puta kako bi se OS mogao normalno pokrenuti i koristiti.
Ovo već nije bilo u redu sa mnom, jer sam mogao upotrijebiti samo ubuntu koji sam instalirao da ga testiram, a nisam mogao učiniti ni pola stvari s kojima bih Arch Linux. Stoga sam odlučio riješiti ovaj problem i počeo istraživati, tražeći niti na forumu koje su imale isti problem, spomenuli su i da je riječ o hardverskoj pogrešci i da je to upravo CPU, pa me počeo zabrinjavati, pa Morao sam otvoriti računalo i provjeriti što se događa, međutim, to nije pomoglo.
Ali nešto što mi je pokazalo da ne bih smio odustati bilo je to ako Ubuntu Mogla bih jer Arch Linux ne (možda Ubuntu je bolje od Svod…?). Tako sam počeo pisati parametre pokretanja u jezgru Arch Linux, stvari kao: 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 = copyds, acm = apds = apds = acds, apd = apds = acds = pci = nocrs, rhgb, acpi = sila, pnpacpi = 0ff i drugi više ... Sve je to preporučeno na forumima koje sam pročitao.
Dok nisam morao otići u dokumentaciju za parametre jezgre, što usput preporučujem: https://www.kernel.org/doc/Documentation/kernel-parameters.txt
Pronašao sam prilično zanimljiv parametar koji sam trenutno uspio pokrenuti Arch Linux Nema problema:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce maxcpus = 0
Kao što je tamo naznačeno, ovaj parametar ograničava upotrebu na procesor bez aktiviranja simetričnog načina obrade. Isprva je djelovalo prilično dobro do kada sam koristio naredbu pacman-Syyu; dobacio mi a jezgra bačena o Greška segmentacije.
Tako sam automatski primijetio da se događa nešto neobično, pa sam počeo pokretati druge procese sve dok se odjednom sustav potpuno nije smrznuo i više nije radio, dok ga nisam ponovno pokrenuo. Dakle, napravio sam istu operaciju, ali ovaj put uspio sam izvršiti htop i pokazalo mi je sljedeće:
Očekivano, prikazao je samo jedan CPU, budući da ga je drugi onemogućio, međutim, činilo mi se vrlo čudnim zašto su programi bacali segfault, a nije mogao ni pokrenuti grafičko okruženje; pa je to bilo nešto što mi je barem dalo više nade da će, ako postavim parametre jezgre na jedan način, pokrenuti moj Arch Linux kao i obično.
Tako sam pokušavao s ostalim parametrima koje sam napisao na popisu dok nisam naišao na ovaj, što je trenutno najbolje rješenje:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce izolcpus = 1
Ovaj parametar čini nešto jednostavno poput izoliranja (ne deaktiviranja) druge jezgre CPU-a u simetričnoj obradi, odnosno opterećenje obrade daje se jednoj jezgri, dok je druga samo komplementarna. To, iako se čini kontradiktornim, ne utječe toliko na performanse, jer je ovaj sjajni OS bio u mogućnosti pokretati aplikacije na ovaj način:
Dakle, s ovim, jedini problem koji sam primijetio, a koji se javlja prilikom pokretanja, je jedan ili dva panika ili oops jezgre; ali u usporedbi s 50 puta kada sam se morao ponovno pokrenuti, mogu to smatrati "zaobilaznim rješenjem". U ostalom, do sada mi je dopuštao da koristim OS i napišem ovaj post koji trenutno čitate :-).
Nadam se da će vam pomoći i da nećete pobjeći GNU / Linux, što je najbolji operativni sustav koji su ikad izmislili. Kažem to sigurno.
Vrlo zanimljive informacije. Nikad nisam imao takvu paniku kernela u ArchLinuxu u godinama u kojima sam ga koristio, ali dobro je znati što učiniti ako se u bilo kojem trenutku problem pojavi. Hvala vam!
Svejedno, Arch koristim već duže vrijeme (bio sam otprilike godinu dana bez Archa) i bez panike kernela.
Hvala na savjetu.
Najvjerojatnije, kao što sam spomenuo u postu, problem se događa zbog hardvera, jer mi u onome što koristim arch također nije zadavao nikakav problem ove vrste.
Još jedan s izvrsnim rezultatima u Archu. Nikad nisam imao paniku kernel
Više od 2 godine s GNU / Linuxom ... Dvije godine već s ArchLinuxom, nikad panika kernela .. 😉
Mislim da su panike kernela posljedice više hardvera nego same distribucije. Nikada nisam vidio paničnu jezgru na prijenosnom računalu koje sada koristim, osim kad sam jednom stavio Ubuntu alfu (a Arch Linux je bio ovdje dvije godine). S druge strane, u drugom prijenosnom računalu koje imam, bilo koji distro koji stavim uvijek izaziva paniku jezgre i širok spektar pogrešaka za svaki ukus.
Sa kernelom 3.14 na Debianu, naišao sam na problem panike kernela, osim toga kad god uključim svoje računalo, dobijem poruku "vremensko ograničenje povezivanja / odspajanja" (i također kada ga isključim).
To mi se dogodilo toliko u Fedori koliko i u Archu, ali ne znam zašto i kako ne vidim nikakvu razliku jer nisam proveo vrijeme istražujući ili rješavajući to (ako je problem).
Mislim da je razlog taj što su kompilirani s gcc 4.9
http://libuntu.com/linus-torvalds-considera-que-la-version-4-9-de-gcc-es-una-pura-y-absoluta-mierda/
Puno vam hvala na informacijama. Neke od mnogih stvari kojima se možemo pohvaliti je ova vrsta foruma
Zašto se to događa Arch Linuxu? Možda nije dovoljno s problemima koji se često javljaju sporošću ili vješanjem sustava do točke dobacivanja sustava na uzrujavanje.
Hej? O čemu ti pričaš? o_O
Arch je distribucija KISS-a koja se može konfigurirati od baze samog operativnog sustava, u nekoliko riječi, ako je sustav težak, to je zato što ste ga tako izgradili, ako sustav ima pogreške, to je zato što ste ih generirali ili zato što nešto niste pravilno konfigurirali. Arch wiki je prilično cjelovit, prije nekoliko godina na španjolskom nije bilo puno važnih tema, to je i postupak instalacije bio puno grublji i pomalo težak, sada je sve malo automatiziranije.
Kriviti distribuciju za korisničke pogreške je tako ... Windows (?).
Optuživanje distribucije za pogreške je dosljedno, jednostavno zato što je to istina. Nakon što sam imao sličan problem s Manjarom, pokušao sam Arch, Antergos i drugu nepoznatu distribuciju (ne mogu se sada sjetiti imena, oprostite) koju mi je netko preporučio uvjeravajući me da to ne daje probleme, ali ništa; svi ga daju. U OpenSuseu, Fedori, Mint, Mageia i svima onima koje sam nakon toga isprobao ne prolazi. Što se mene tiče, ne preostaje mi drugo nego misliti da je kriv distro. Ali, hej, ja to ne demoniziram ili nešto slično, štoviše, živcira me što ne mogu koristiti bilo što temeljeno na Archu, jer mi se to jako sviđa, ali taj me prokleti problem sprečava. Niti mislim da je riječ o hardveru, jer se mnogi od nas koji nam se događaju nisu dogodili prije korištenja istog jebanja. Pa, zapravo to mora biti nešto povezano s hardverom, ali, vrativši se na istu stvar, ako nisam napravio nikakve promjene i imam problema s istom opremom s kojom ih prije nisam imao, očito će to biti zbog promjene od Archa koji me zeznuo.
"Kriviti distribuciju za korisničke pogreške je tako ... Windows (?)."
Rekao bih vam da je krivnja korisnika za pogreške proizvoda toliko Apple. Iskreno sam o tome razmišljao tisuću puta, ali ne vidim prednost korištenja nečega čiji održavatelji u osnovi peru ruke u bilo koju ozbiljnu svrhu. I kažem da s obzirom na to da GPL softver dolazi bez jamstva.
Možete reći kako želite, ali ako je to isti slučaj s izvješćima o nedostatku signala na iPhone i ako je odgovor Applea "da ste krivo shvatili" od prije nekoliko godina. Ako napravite distro, obično želite pružiti određenu kvalitetu i minimalnu podršku, a istina je da je Arch u osnovi hobistički sustav, gdje vidite da se njegovi programeri zabavljaju pakirajući nove stvari, ali da ih malo zanima ponuditi istinsku podršku . Svaki put kad vidim ovu vrstu posta, više cijenim rad iza distroa koji koristim.
I da, problem je u softveru ako ne radi, ako prestane raditi u ažuriranju ili ako se nešto od hardvera pokvari. Da kernel panično distribuira, dok drugi ne ... dobro, da, očito postoji distro koji čini stvari dobro, a drugi pogrešno. Sad, ako vam je zadovoljstvo koristiti Linux u stilu 90-ih, gdje smo morali prekompajlirati jezgru svaki put kad smo priključili novi pisač ... eto vas.
Jesu li kernel sastavili programeri? ili svoj vlastiti?
Panike kernela generiraju se kada određene komponente nisu odabrane (AND) prilikom prevođenja ili neki moduli nisu aktivirani da podržavaju određeni hardver. Uz praksu i znanje o vašem hardveru (morate otvoriti računalo i vidjeti koje marke čipova ima), možete izgraditi prilagođenu jezgru (chrootingom). Ako su ubuntu i instalacijski CD Arch bili na vašem računalu, u kompilaciji postoji nešto što nije aktivirano.
To je bio kernel iz samog Archlinuxa, iz spremišta.
Jezgra koju koristite, ostalo je nešto što se vašem hardveru ne sviđa, morate imati rijetku verziju čipa na matičnoj ploči ili čak grešku u čipu (to se obično događa).
To je možda oštećena tablica vašeg bios acpi-a, normalno je da dežurni Kinezi čak dobro ne izračunaju kontrolnu sumu svake tablice, te se poruke obično pojavljuju s $ dmesg -human na početku pokretanja.
Također biste trebali isprobati drugi izvor napajanja, kad filtriranje ne uspije, mreškanje obično pravi takve kvarove.
Prvo pokušajte promijeniti izvor i pogledajte što će se dogoditi, ako ostane isti, pokušajte konfigurirati kernel kako bi odgovarao vašem hardveru, usput tako što ćete u procesu bolje upoznati svoj računalo.
Hvala na savjetima. Inače je riječ o prijenosnom računalu, mislim da bih trebao promijeniti bateriju. Ali vidim da mi ono što ste mi rekli može pomoći.
Panika od jedra koja me još uvijek izluđuje djelomično je kriva za novopečene momke i moju staru, zastarjelu i vrlo prašnjavu integriranu karticu nVidia 6150 SE (mislim djelomično i zato što su izvršili izvrstan posao podržavajući svemir grafičkih čipova poput one koje ima nVidia, i sve to, koristeći samo obrnuti inženjering, plus problem se javlja samo kod nekih kartica s NV4E čipsetom).
Sve što morate učiniti je pokrenuti Openbox + Firefox i štrajkove katastrofe (ništa ljepše od gledanja potpuno slučajnog crno-bijelog mozaika na vašem ekranu). I pjevam je od kernela 3.6 u Debianu, Fedori, Archlinuxu, Slackwareu i sada ponovno provjeren u Gentoo-u (upravo instaliran s kernelom 3.12), više se ne trudim odnijeti zapisnik u kernel ili mu dati vremena da napiše nešto što ne budi glupi glupi likovi.
Dajem vam rješenje, računalo koje imam s gentooom i integriranim nvidijskim videozapisom isto je s nouveau upravljačkim programom, tako da nisam imao izbora nego koristiti zatvoreni nvidijin upravljački program, moj čip mora koristiti upravljački program 304.123
00: 0d.0 VGA kompatibilni kontroler [0300]: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] [10de: 03d6] (rev a2) (prog-if 00 [VGA kontroler])
Morate zakrpati datoteku jezgre prije nego što je sastavite, ako nije zakrpana, grafički način rada odbit će se pokrenuti.
Koraci su sljedeći:
# nano -w /usr/src/linux-3.15.7-gentoo/drivers/acpi/osl.c
Potražite ovaj tekst s ctrl + w unutar nano-a, acpi_os_wait_events_complete i nano vas vodi do ovog dijela:
void acpi_os_wait_events_complete (void)
{
isprani_radni red (kacpid_wq);
flush_workqueue (kacpi_notify_wq);
}
EXPORT_SYMBOL (acpi_os_wait_events_complete);
Zakrpa koju morate dodati je ovaj zadnji redak koji započinje s EXPORT, ctrl + ili ctrl + x
Zatim kompajlirate kernel, instalirate module, instalirate kernel, generirate initramfs ako vam je potreban, dodate splash u initramfs ako koristite splash, regenerirate unose za grub i na kraju i što je najvažnije morate obnoviti module koji nisu iz kernel, odnosno vlasnički nvidia modul, bez toga grafički način rada neće raditi za vas.
# eselect popis jezgri
# eselect skup jezgri x
# cd / usr / src / linux
# napraviti
# napravi module_install
# montiranje / pokretanje
# izvršite instalaciju
# dracut - čudno »3.15.7-gentoo - sila
# 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 sad
Ako koristite genkernel, samo zakrpite tu datoteku i razumijem da se genkernel popravlja sam.
Osim toga, morate ukloniti drm podršku i nvidia upravljačke programe i druge video čipove iz jezgre kako se oni ne bi sudarali frontalno sa zatvorenim nvidia pogoniteljem koji je instaliran kao nvidia modul.
U slučaju korištenja bootsplasha, morate uključiti upravljački program uvesa u jezgru tako da podržava visoke razlučivosti zaslona jer zatvoreni upravljački program nvidia (ako se dobro sjećam) ne podržava više od 800 × 600 u terminalu tty1 «F1» čizma.
Ne znam za druge distro-ove, ali pretpostavljam da bi se trebao izvoditi na bilo kojoj distro-u ako su ti koraci učinjeni, spremajući promjenu pojavljivanja za bilo što.
Ovo su smjernice koje morate slijediti za nvidiju i uvesu:
http://wiki.gentoo.org/wiki/NVidia/nvidia-drivers/es
http://wiki.gentoo.org/wiki/Uvesafb
Hvala na informacijama, ali problem sam riješio upravo promjenom vlasničkih. Sjećam se da je i prethodni upravljački program za nVidia (304.121) također morao biti zakrpan pri prelasku na 3.13 jer je imao problema u kompilaciji modula (nije bilo pogrešaka, ali modul je odbio raditi), a sve također zbog obrađivača događaja ACPI . U Debianu sam dobio problem i pronašao rješenje.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740097
Kao primjer sam koristio Manjaro, ali već sam prije spomenuo da mi se isto dogodilo s Archom i drugim izvedenicama. Stoga vjerujem da je problem više njihov nego oni koji su pogođeni.
Pd: Nisam uspio odgovoriti izravno na relevantnu poruku jer se opcija odgovora ne pojavljuje ...
Prešao sam precizno s Manjara na Linux Mint, jer bi se zamrzavao prilikom pokretanja nakon ažuriranja na verziju kasniju od 0.8.9 (ne mogu se sjetiti koju). Koliko sam pročitao, to se obično događa na prijenosnim računalima. Moj predmetni problem nije bio isti kao onaj u ovom postu, mislim da sam došao do zaključka da bi mogao biti povezan s upravljanjem energijom. Bilo je ljudi koji se nisu smrznuli ako su pokrenuli laptop dok su bili isključeni. Trenutno se ne sjećam je li mi to omogućilo da uvijek započnem bez problema, ali naravno, uspio sam to učiniti više puta po cijenu duljeg vremena.
Svejedno, na kraju sam odustao i prešao na Fedoru i Linux Mint.
Igrom slučaja, jučer sam ga pokušao suspendirati bez punjača, a kad sam ga nastavio, objesio se i morao sam ga ponovo pokrenuti.
Prilično je smiješno, s Archom sam nekoliko mjeseci i nisam imao niti jednu Kernel Panic! To mi se dogodilo s Antergosom (Arch s dodanim spremištem) iz živog okruženja, ali tamo to smatram razumljivijim. Može li to biti problem s matičnom pločom ili neispravnim RAM modulom? Sjećam se da mi je prije otprilike 2 godine RAM modul prouzročio nekoliko plavih ekrana u sustavu Windows i nekoliko Kernel Panics! na Mandrivi. Morao sam testirati svaku memoriju odjednom između ponovnog pokretanja i ponovnog pokretanja.
Riječ je o Arch problemu (koji nosi sve njegove izvedenice), jer u ostalim distro-ima takvih problema nema. Neugodno mi je što u ovom trenutku to nisu riješili. To su samo oni godinama! Čitao sam slične probleme iz 2011. Jasno mi je da je to nešto što dolazi i prolazi kad se ažuriraju, jer se pomoću verzija 0.8.7, 0.8.8 i 0.8.9 bez njihovog ažuriranja ništa ne događa. Od tada sve ide u sranja, a sigurno se i u starim verzijama dogodilo. Zašto se to događa samo nekolicini nas? Ne znam, ali mislim da to nije naš problem, već Archov, jer, kao što je već rečeno, druge distribucije rade savršeno. U njegovo sam vrijeme već slomio rogove kako bih pronašao rješenje, ali umorio sam se. Dakle, koliko god mi je žao, neću koristiti Arch.
Arch 0.8.7, 0.8.8 i 0.8.9? Otkrivam da Arch koristi tu verziju nomenklature.
Je li moguće da koristite Manjaro?
Ok, odgovaram sebi čitajući vaš prethodni komentar, a jedno je Manjaro, a drugo Arch.
Ni optuživanje distro-a za određeni problem nije dosljedno (nije baš dosljedno), barem u mom slučaju ne mogu kriviti koliko distro-a pokušavam za problem s nouveauom i mojom nVidia 6150SE karticom, jer je problem MMIO rukovanje vozačem i karticom (nVidia će znati što treba popraviti, a lude stvari morat će popraviti taj detalj). Hardver također može predstavljati problem, a možete vidjeti da u bilo kojem OS-u koji koristite (Windows, Linux, BSD) i prema mom iskustvu popravljajući računala vidio sam vrlo čudne hardverske probleme (poput računala koje odbija boot, osim ako promijenite mjesto memorije, a prilikom isključivanja morate ponoviti postupak), i za to ne mogu kriviti Windows i Debian.
Imao sam paniku kernela sa živim ubuntuom 12.04
Imam frenetik svog svog sigurnog HP pavilion dm4 prijenosnog računala, 8 GB RAM-a, 500 tvrdog diska i koristi više od 5 godina. Ne sjećam se brzine mikroprocesora, Intelove jezgre i5, mislim da više od 2 MHz.
Ne mogu ništa napisati na zaslon terminala. Nastavit ću tražiti više informacija kako bih riješio ovaj problem.