Ovaj post želi pokazati kako riješiti problem pokretanja gotovo greškama Arch Linux. Nešto poput sljedeće slike:
Kao što se može vidjeti, vidimo da je ovo jedna od mnogih "kombinacija" grešaka koje se pojavljuju slučajno prilikom pokretanja operativnog sistema s ovim problemom. Kao što stoji u toj grešci, to ukazuje na to da bi mogao postojati problem u "Hardveru", međutim, kao što svi znamo u ovom operativnom sistemu, čak i loši trikovi onoga što ne pripada OS-u mogu se riješiti.
Dakle, opisat ću svoje iskustvo s ovim problemom. Koliko sam mogao iskusiti, problem je bio samo u tome Arch Linux ili neki drugi distro koji sam testirao izvana, jer je sa bilo kojim ubuntuom koji sam instalirao ili testirao počeo bez problema. Ali ako bih pokušao rastrgati Arch Linux instaliran na tvrdom disku, imao je problem što se morao ponovo pokrenuti oko 50 puta kako bi se OS mogao normalno pokrenuti i moći ga koristiti.
Ovo već nije bilo u redu sa mnom, jer sam mogao koristiti samo ubuntu koji sam instalirao da ga testiram, a nisam mogao učiniti ni polovinu stvari sa kojima sam mogao raditi 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 to počelo zabrinjavati, pa Morao sam otvoriti PC i provjeriti što se događa, međutim, to nije pomoglo.
Ali nešto što mi je pokazalo, od čega ne bih smio odustati, bilo je da ako Ubuntu Mogla bih jer Arch Linux ne (možda Ubuntu je bolje od svod…?). Tako sam počeo pisati parametre pokretanja u kernel od Arch Linux, stvari poput: 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 = copyds, acdt = apdi = pci = nocrs, rhgb, acpi = sila, pnpacpi = 0ff i drugi više ... Sve ovo je preporučeno na forumima koje sam pročitao.
Dok nisam morao unijeti dokumentaciju parametara jezgre, što usput preporučujem: https://www.kernel.org/doc/Documentation/kernel-parameters.txt
I otkrio 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. U početku je to funkcioniralo prilično dobro do kada sam koristio naredbu pacman-Syyu; bacio me jezgro bačeno o greška segmentacije.
Tako sam automatski primijetio da se nešto čudno događa, pa sam počeo izvoditi druge procese sve dok se odjednom sistem potpuno nije smrznuo i više nije radio, dok ga nisam ponovo 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; tako da 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 obično.
Tako sam i dalje isprobavao ostale parametre 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. Ovo, 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 prethodno morao ponovno pokrenuti sustav, mogu to smatrati "zaobilaznim rješenjem". U ostalom, do sada mi je dozvoljavao da koristim OS i napišem ovaj post koji trenutno čitate :-).
Nadam se da će vam pomoći i da nećete izaći GNU / Linux, što je najbolji operativni sistem koji su ikad izmislili. Kažem sigurno.
Vrlo zanimljive informacije. Nikad nisam imao te panike kernela u ArchLinuxu u godinama koje sam ga koristio, ali dobro je znati što učiniti ako se u bilo kojem trenutku problem javi. Hvala ti!
U svakom slučaju, Arch koristim već dugo (bio sam oko godinu dana bez Arch-a) i bez panike kernela.
Hvala na savjetu.
Najvjerojatnije, kao što sam spomenuo u postu, problem se događa zbog hardvera, jer u onome što koristim arch, ni to mi nije zadalo nikakav problem.
Još jedan sa izvrsnim rezultatima u Archu. Nikad nisam imao paniku kernela
Više od 2 godine sa GNU / Linuxom ... Već 2 godine sa ArchLinuxom, nikad panika u kernelu .. 😉
Mislim da su panike kernela posljedice više hardvera nego same distribucije. Nikada nisam vidio jezgro panike na laptopu koji sada koristim, osim kada sam u njega stavio Ubuntu alfu (a Arch Linux je bio ovdje dvije godine). S druge strane, u drugom laptopu koji imam, bilo koji distro koji stavim uvijek izaziva paniku u jezgru i širok spektar grešaka za svaki ukus.
Sa kernelom 3.14 na Debianu, naišao sam na problem panike kernela, osim toga kad god uključim svoj PC, dobijem poruku o "povezivanju / prekidu veze" (i također kada je isključim).
To mi se dogodilo u Fedori kao i u Archu, ali ne znam zašto i kako ne vidim razliku jer nisam proveo vrijeme istražujući ili rješavajući to (ako je problem).
Mislim da je razlog taj što su kompajlirani sa 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 ovo događa Arch Linuxu? Možda nije dovoljno s problemima koji se često javljaju sporošću ili vješanjem sistema do točke dobacivanja sistema na uzrujavanje.
Hej? O cemu pricas? o_O
Arch je distribucija KISS-a koja se može konfigurirati od baze samog operativnog sistema, u nekoliko riječi, ako je sistem težak, to je zato što ste ga tako izgradili, ako sistem ima greš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, a postupak instalacije bio je mnogo grublji i pomalo težak, sada je sve malo automatiziranije.
Optuživanje distroa za korisničke greške je tako ... Windows (?).
Optuživanje distribucije za greš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, izvinite) koju mi je neko 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 kasnije isprobao ne prolazi. Što se mene tiče, ne preostaje mi ništa drugo nego da mislim da je kriv distro. Ali, hej, ja to ne demoniziram ili nešto slično, štoviše, živcira me što ne mogu koristiti ništa na osnovu Arch-a, jer mi se to jako sviđa, ali taj prokleti problem me 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 vezano uz hardver, ali, vratimo 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.
"Optuživanje distroa za korisničke greške je tako ... Windows (?)."
Rekao bih vam da je krivnja korisnika za greške proizvoda toliko Apple. Iskreno sam o tome razmišljao hiljadu puta, ali ne vidim prednost upotrebe nečega čiji održavatelji u osnovi peru ruke, u bilo koju ozbiljnu svrhu. I kažem da s obzirom da GPL softver dolazi bez garancije.
Možete reći kako želite, ali ako je to isti slučaj sa izvještajima o nedostatku signala iPhoneu i ako je odgovor Applea "da ste to pogrešno shvatili" prije nekoliko godina. Ako napravite distro, obično želite pružiti određeni kvalitet i minimalnu podršku, a istina je da je Arch u osnovi hobistički sistem, gdje vidite da se njegovi programeri zabavljaju pakirajući nove stvari, ali da ih malo zanima istinska podrška. Svaki put kad vidim ovu vrstu posta, više cijenim rad iza distro-a 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 ... pa, da, očito postoji distro koji čini stvari dobro, a drugi pogrešno. Ako vam je zadovoljstvo koristiti Linux u stilu 90-ih, kada smo morali prekompajlirati jezgru svaki put kad smo priključili novi printer, eto vas.
Da li su kernel sastavili programeri? ili svoj vlastiti?
Panike kernela generiraju se kada određene komponente nisu odabrane (AND) prilikom kompajliranja 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đeni kernel (chrootingom). Ako su ubuntu i instalacijski CD Arch bili na vašem računaru, u kompilaciji postoji nešto što nije aktivirano.
To je bio kernel iz samog Archlinuxa, iz spremišta.
Kernel koji 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 može biti oštećena tablica u vašem bios acpi-u, normalno je da dežurni Kinezi čak dobro ne izračunaju kontrolnu sumu svake tablice, te se poruke obično pojavljuju sa $ dmesg -human na početku pokretanja.
Trebali biste isprobati i drugo napajanje, kad filtriranje ne uspije, mreškanje teži pravljenju takvih kvarova.
Prvo pokušajte promijeniti izvor i pogledajte što će se dogoditi, ako ostane isti, pokušajte konfigurirati kernel prilagođen vašem hardveru, na način da ćete u tom procesu bolje upoznati svoj računar.
Hvala na savjetima. Inače je to laptop, 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 novonastale momke i moju staru, zastarjelu i vrlo prašnjavu integriranu karticu nVidia 6150 SE (mislim dijelom i zato što su izvršili odličan 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).
Samo pokrenite 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 ponovo provjeren u Gentoo-u (upravo instaliran sa 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čunar koji imam s gentoo-om i integriranim nvidia video događa se isto sa 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 kernela prije nego što je prevedete, ako nije zakrpljena, grafički način rada će odbiti pokretanje.
Koraci su:
# nano -w /usr/src/linux-3.15.7-gentoo/drivers/acpi/osl.c
Pretražite ctrl + w unutar nano ovog teksta, acpi_os_wait_events_complete i nano vas vodi do ovog dijela:
void acpi_os_wait_events_complete (void)
{
flush_workqueue (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 sa 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 ili vlasnički nvidia modul, bez toga grafički način rada neće raditi.
# eselect listu kernela
# eselect set kernela x
# cd / usr / src / linux
#make
# napravi module_install
# mount / boot
# izvrši instalaciju
# dracut –iskreno »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 sada
Ako koristite genkernel, samo zakrpite tu datoteku i razumijem da se genkernel popravlja sam.
Pored toga, morate ukloniti drm podršku i nvidia upravljačke programe i druge video čipove iz jezgre kako se ne bi sudarali sa zatvorenim nvidia pogoniteljem koji je instaliran kao nvidia modul.
U slučaju korištenja bootplash-a, morate uključiti upravljački program uvesa u jezgru tako da podržava visoke rezolucije zaslona, jer zatvoreni upravljački program nvidia (ako se dobro sjećam) ne podržava više od 800 × 600 u terminalu tty1 «F1» pokretanja.
Ne znam za druge distro-ove, ali pretpostavljam da bi to trebalo raditi na bilo kojoj distro-u da su ovi koraci učinjeni, spremajući promjenu u nastajanju za bilo šta drugo.
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 grešaka, ali modul je odbio raditi), a sve i 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 sa Archom i drugim izvedenicama. Stoga vjerujem da je problem više njihov nego oni koji su pogođeni.
Pd: Nisam uspio odgovoriti direktno na relevantnu poruku jer se opcija odgovora ne pojavljuje ...
Prešao sam precizno s Manjara na Linux Mint, jer bi se zamrznuo prilikom pokretanja nakon nadogradnje na verziju nakon 0.8.9 (ne mogu se sjetiti koju). Koliko sam pročitao, to se obično događa na prenosnim računarima. Moj predmetni problem nije bio isti kao onaj u ovom postu, mislim da sam došao do zaključka da bi se mogao povezati 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 dužeg 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, visio je 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 dodatnim 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 uzrokovao 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 povlači sve njegove derivate), jer u drugim distro distribucijama nema problema te vrste. Neugodno mi je što u ovom trenutku to nisu riješili. To su samo oni godinama! Čitao sam slične probleme od 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 to događalo. 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? Otkrio sam 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 će morati popraviti taj detalj). Hardver također može predstavljati problem, a možete vidjeti da sam u bilo kojem OS-u koji koristite (Windows, Linux, BSD) i prema mom iskustvu popravljajući računare vidio vrlo čudne hardverske probleme (poput računara koji odbija boot, osim ako promijenite lokaciju 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 za svoj Secure HP pavilion dm4 notebook računar, 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 je veća od 2 MHz.
Ne mogu ništa napisati na ekran terminala. Nastavit ću tražiti više informacija kako bih riješio ovaj problem.