Ky postim është për të treguar se si të "rregullojmë" pothuajse problemin e fillimeve me gabime Arch Linux. Diçka si imazhi i mëposhtëm:
Siç mund të shihet, ne shohim se ky është një nga shumë "kombinimet" e gabimeve që shfaqen rastësisht kur filloni një sistem operativ me këtë problem. Siç thotë në atë gabim, kjo tregon se mund të ketë një problem në "Hardware", megjithatë, siç e dimë të gjithë në këtë sistem operativ, edhe truket e këqija të asaj që nuk i përket OS mund të zgjidhen.
Kështu që, unë do të përshkruaj përvojën time të këtij problemi. Nga ajo që isha në gjendje të përjetoja, problemi ishte vetëm tek Arch Linux ose një distro tjetër që kam testuar nga jashtë, pasi që me çdo ubuntu që kisha instaluar ose testuar, filloi pa probleme. Por nëse ai u përpoq të shqyej Arch Linux i instaluar në hard disk, kishte një problem që duhej të ristartohej rreth 50 herë në mënyrë që OS të nisej normalisht dhe të ishte në gjendje ta përdorte atë.
Kjo tashmë kishte diçka që nuk shkonte me mua, sepse unë mund të përdorja vetëm ubuntu që kisha instaluar për ta provuar dhe nuk mund të bëja as gjysmën e gjërave që mund të bëja Arch Linux. Kështu që vendosa ta zgjidh këtë problem dhe fillova të hetoj, duke kërkuar temat e forumit që kishin të njëjtin problem, ata gjithashtu përmendën se ishte një gabim harduer dhe se ishte pikërisht CPU, kështu që filloi të më shqetësonte, kështu që Unë kam për të hapur PC dhe për të verifikuar atë që po ndodhte, megjithatë, kjo nuk ka ndihmuar.
Por diçka që më tregoi, se nuk duhet të hiqja dorë ishte se nëse Ubuntu Mundem sepse Arch Linux jo (mbase Ubuntu është më mirë se Hark…?). Kështu që fillova të shkruaj parametrat e nisjes në kernelin e Arch Linux, gjëra të tilla si: 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 = çaktivizo, i8042.noacpi = 1, apm = cop, apm = cop, apm = cop, apm = cop, apm = cop pci = nocrs, rhgb, acpi = forcë, pnpacpi = 0ff dhe të tjerë më shumë ... E gjithë kjo u rekomandua në forume që lexova.
Derisa të më duhej të shkoja te dokumentacioni për parametrat e bërthamës, të cilin unë rekomandoj nga rruga: https://www.kernel.org/doc/Documentation/kernel-parameters.txt
Dhe gjeta një parametër mjaft interesant që për momentin arrita ta boot Arch Linux Nuk ka problem:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce maksimumi = 0
Siç tregohet atje, ajo që bën ky parametër është të kufizojë përdorimin në një CPU pa aktivizuar mënyrën simetrike të përpunimit. Në fillim ka punuar mjaft mirë deri kur kam përdorur komandën pacman-Syyu; më hodhi një thelbi i hedhur o faji i segmentimit.
Kështu që automatikisht vura re që diçka e çuditshme po ndodhte, kështu që fillova të zhvilloja procese të tjera derisa papritmas sistemi ngriu plotësisht dhe nuk funksionoi më, derisa e ristartova atë. Kështu që unë bëra të njëjtin operacion, por këtë herë arrita të ekzekutoj htop dhe kjo më tregoi sa vijon:
Siç pritej, ajo tregoi vetëm një CPU, pasi që tjetri e kishte çaktivizuar, megjithatë, më dukej shumë e çuditshme pse hodhën programet i parazgjedhur, dhe nuk mund të fillonte as mjedisi grafik; kështu që ishte diçka që të paktën më jepte më shumë shpresë se nëse vendosja parametrat e kernelit në një mënyrë do të fillonte Arch Linux si zakonisht.
Kështu që unë vazhdova të provoj parametrat e tjerë që kam shkruar në listë derisa e hasa këtë, e cila është zgjidhja më e mirë për momentin:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce izolpus = 1
Ky parametër bën diçka aq të thjeshtë sa izolimi (jo çaktivizimi) i bërthamës së dytë nga CPU në përpunimin simetrik, domethënë ngarkesa e përpunimit i jepet një bërthame të vetme ndërsa tjetra është vetëm plotësuese. Kjo, megjithëse duket kontradiktore, nuk ndikon aq shumë në performancë, pasi që ky OS i shkëlqyeshëm ishte në gjendje të ekzekutonte aplikacione në këtë mënyrë:
Pra, me këtë, problemi i vetëm që unë vërejta që ndodh në kohën e nisjes është një ose dy panik të kernelit ose oops; Por në krahasim me 50 herë që më është dashur të ristartoj më parë, mund ta konsideroj si një "zgjidhje". Për pjesën tjetër, deri më tani më ka lejuar të përdor OS dhe të shkruaj këtë post që po lexoni tani :-).
Shpresoj të të ndihmojnë dhe të mos dalin jashtë GNU / Linux, i cili është sistemi operativ më i mirë që ata kanë shpikur ndonjëherë. E them me siguri.
Informacion shume interesant. Unë kurrë nuk kam pasur ato paniket e kernelit në ArchLinux në vitet që e kam përdorur, por është mirë të dini se çfarë të bëni nëse në ndonjë moment ndodh problemi. Faleminderit!
Sidoqoftë, kam përdorur Arch për një kohë të gjatë (isha si 1 vit pa Arch) dhe pa një panik të kernelit.
Faleminderit për këshillën.
Me shumë mundësi, siç e përmenda në postim, problemi ndodh për shkak të harduerit, sepse në atë që përdor harkun, nuk më kishte dhënë as ndonjë problem të këtij lloji.
Një tjetër me rezultate të shkëlqyera në Arch. Unë kurrë nuk kam pasur një Panik të Kernelit
Më shumë se 2 vjet me GNU / Linux ... 2 vjet tashmë me ArchLinux, asnjëherë panik i kernelit ..
Unë mendoj se panikët e bërthamës janë më shumë për shkak të harduerit sesa për vetë distro-s. Unë kurrë nuk kam parë një bërthamë paniku në laptopin që përdor tani, përveç një herë kur vendosa një Ubuntu alfa në të (dhe Arch Linux ishte këtu për dy vjet gjithashtu). Nga ana tjetër, në një laptop tjetër që kam, çdo distro që vendos gjithmonë jep panik në kernel dhe një larmi të gjerë gabimesh për të gjitha shijet.
Me kernelin 3.14 në Debian, unë kam hasur në problemin e panikut të kernelit, përveç kësaj sa herë që ndez PC-në tim, marr një mesazh "lidh / shkëput kohën e mbarimit" (dhe gjithashtu kur e fik).
Më ka ndodhur aq shumë në Fedora sesa në Arch, por nuk e di pse dhe si nuk shoh ndryshim pasi nuk kam kaluar kohë për ta hetuar apo zgjidhur atë (nëse është problem).
Mendoj se arsyeja është se ato përpilohen me gcc 4.9
http://libuntu.com/linus-torvalds-considera-que-la-version-4-9-de-gcc-es-una-pura-y-absoluta-mierda/
Faleminderit shumë për informacionin. Disa nga shumë gjëra për të cilat mund të mburremi është ky lloj forumi
Pse i ndodh kjo Arch Linux? Ndoshta nuk mjafton me problemet që shfaqen shpesh me ngadalësinë ose varjen e sistemit duke arritur në pikën e hedhjes së sistemit në mërzi.
Hej Për çfarë po flet? o_O
Arch është një shpërndarje KISS e konfigurueshme nga baza e vetë sistemit operativ, me pak fjalë, nëse sistemi është i rëndë është sepse e keni ndërtuar në atë mënyrë, nëse sistemi ka gabime është sepse i keni gjeneruar ato ose sepse nuk keni konfiguruar diçka siç duhet. Arch wiki është mjaft i plotë, disa vite më parë nuk kishte shumë tema të rëndësishme në Spanjisht, dhe procesi i instalimit ishte shumë më i ashpër dhe disi i vështirë, tani gjithçka është pak më e automatizuar.
Fajësimi i distro për gabimet e përdoruesit është kaq so Windows (?).
Fajësimi i distro për gabimet është i qëndrueshëm, thjesht sepse është e vërteta. Pasi kisha një problem të ngjashëm me Manjaro, provova Arch, Antergos dhe një shpërndarje tjetër të panjohur (nuk e mbaj mend emrin tani, më falni) që dikush më rekomandoi të më siguronte se nuk jepte probleme, por asgjë; ata të gjithë e japin atë. Në OpenSuse, Fedora, Mint, Mageia dhe të gjitha ato që kam provuar më pas, nuk ndodh. Pra, për sa më përket mua, nuk më mbetet gjë tjetër veçse të mendoj se është faji i distros. Por, hej, unë nuk e demonizoj atë ose asgjë, për më tepër, kjo më bezdis që nuk mund të përdor asgjë bazuar në Arch, sepse më pëlqen shumë, por ai problem i dreq më pengon. As nuk mendoj se ka të bëjë me harduerin, sepse shumë prej nesh që na ndodhin nuk kanë ndodhur para se të përdorim të njëjtën gjë. Epo, në të vërtetë duhet të jetë diçka në lidhje me harduerin, por, duke u kthyer te e njëjta gjë, nëse nuk kam bërë ndonjë ndryshim dhe kam probleme me të njëjtën pajisje me të cilën nuk i kisha më parë, padyshim që do të jetë për shkak të një ndryshimi të bërë nga Arch që më ka vidhosur.
"Fajësimi i distro për gabimet e përdoruesit është kaq ... Windows (?)."
Unë do t'ju tregoja që fajësimi i përdoruesve për gabimet e produkteve është kaq shumë Apple. Sinqerisht e kam menduar atë një mijë herë, por nuk e shoh avantazhin e përdorimit të diçkaje mirëmbajtësit e së cilës në thelb lajnë duart, për ndonjë qëllim serioz. Dhe unë them se duke marrë parasysh që programi GPL vjen pa garanci.
Ju mund të thoni si të doni, por nëse është i njëjti rast i raporteve të mungesës së sinjalit në iPhone dhe përgjigja e Apple "është se po e kuptoni gabim" nga disa vjet më parë. Nëse bëni një distro zakonisht dëshironi të ofroni një cilësi dhe mbështetje minimale, dhe e vërteta është se Arch është në thelb një sistem hobi, ku shihni se zhvilluesit e tij argëtohen duke paketuar gjëra të reja, por kanë pak interes për të ofruar një mbështetje të vërtetë . Sa herë që shoh këtë lloj postimi vlerësoj më shumë punën pas distro-s që përdor.
Dhe po, është një problem i softuerit nëse nuk funksionon, nëse ndalon së punuari në një azhurnim, ose nëse prishet diçka nga hardueri. Se një berthame paniku bën distro ndërsa një tjetër nuk… mirë, po, qartë ka një distro që po i bën gjërat mirë dhe një tjetër gabim. Tani nëse është kënaqësia juaj të përdorni Linux në stilin e viteve '90 ku na duhej të rikompilonim kernelin sa herë që lidhnim një printer të ri ... atje ju.
A është përpiluar bërthama nga zhvilluesit? apo tuajat?
Paniku i kernelit gjenerohet duke mos zgjedhur (DHE) komponentë të caktuar kur përpiloni, ose duke mos aktivizuar disa module për të mbështetur pajisje të caktuara. Me praktikë dhe njohuri të pajisjes suaj (duhet të hapni kompjuterin dhe të shihni se çfarë markash patate të skuqura ka), ju mund të ndërtoni një bërthamë të personalizuar (duke chrooting). Nëse ubuntu dhe CD-ja e instalimit të Arch-it ishin në kompjuterin tuaj, ka diçka në përpilim që nuk është aktivizuar.
Ishte kerneli i aksioneve nga vetë Archlinux, nga depot.
Kerneli që po përdorni, ka mbetur diçka që nuk i pëlqen harduerit tuaj, duhet të keni një version të rrallë të një çipi në pllakën tuaj amë ose edhe një të mete në një çip (zakonisht ndodh).
Mund të jetë një tryezë e korruptuar në bios acpi, është normale që kinezët në detyrë as nuk e llogarisin mirë shumën e kontrollit të secilës tryezë, këto mesazhe zakonisht shfaqen me $ dmesg - njerëzore në fillim të boot.
Ju gjithashtu duhet të provoni një tjetër furnizim me energji elektrike, kur filtrimi dështon, valëzimi tenton të bëjë pikërisht atë lloj dështimi.
Së pari, provoni të ndryshoni burimin dhe shikoni se çfarë ndodh, nëse mbetet e njëjtë, provoni të konfiguroni një bërthamë që i përshtatet pajisjes tuaj, nga mënyra se si do të njiheni më mirë me kompjuterin tuaj gjatë procesit.
Faleminderit për këshillat. Nga rruga që është një kompjuter portativ, mendoj se duhet të ndryshoj baterinë. Por e shoh atë që më ke thënë mund të më ndihmojë.
Paniku i një bërthame që ende më çmend është pjesërisht faji i djemve të rinj dhe kartës sime të vjetër, të vjetëruar dhe shumë të pluhurosur të integruar nVidia 6150 SE (dua të them pjesërisht sepse; ata kanë bërë një punë të shkëlqyeshme duke mbështetur një univers të çipave grafikë ato që ka nVidia, dhe e gjithë kjo, duke përdorur vetëm inxhinieri të kundërt, plus problemi ndodh vetëm për disa karta me chipset NV4E).
Thjesht filloni Openbox + Firefox dhe sulmet e fatkeqësive (asgjë më e bukur sesa të shihni një mozaik bardh e zi krejtësisht të rastësishëm në ekranin tuaj). Dhe unë e kam kënduar që nga kerneli 3.6 në Debian, Fedora, Archlinux, Slackware dhe tani ri-verifikuar përsëri në Gentoo (i sapo instaluar me kernel 3.12), unë nuk jam më duke u munduar të marr një regjistër, në bërthamë ose t'i jap kohë për të shkruar diçka që mos jini personazhe të pakuptimta dajak.
Unë ju jap zgjidhjen, një kompjuter që kam me gentoo dhe video të integruar nvidia ndodh e njëjta gjë me shoferin nouveau, kështu që nuk kisha zgjidhje tjetër përveçse të përdorja shoferin e mbyllur nvidia, çipi im duhet të përdorë shoferin 304.123
00: 0d.0 Kontrollues i pajtueshëm me VGA [0300]: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] [10de: 03d6] (rev a2) (prog-nëse 00 [kontrollues VGA])
Ju duhet të arnoni një skedar të bërthamës përpara se ta përpiloni, nëse nuk është rregulluar, modaliteti grafik nuk do të fillojë.
Hapat janë:
# nano -w /usr/src/linux-3.15.7-gentoo/drivers/acpi/osl.c
Kërkoni me ctrl + w brenda nano këtë tekst, acpi_os_wait_events_complete dhe nano ju çon në këtë pjesë:
e pavlefshme acpi_os_wait_events_complete (e pavlefshme)
{
skuqje_shkrimi (kacpid_wq);
skuqja e punës (kacpi_notify_wq);
}
EXPORT_SYMBOL (acpi_os_wait_events_complete);
Patch-i që duhet të shtoni është kjo rresht i fundit që fillon me EXPORT, ctrl + ose ctrl + x
Pastaj ju përpiloni kernelin, instaloni modulet, instaloni kernelin, krijoni ininramfët nëse keni nevojë për të, shtoni spërkatjen në initramfs nëse përdorni spërkatjen, rigjeneroni shënimet për grub dhe së fundmi dhe shumë e rëndësishmja, ju duhet të rindërtoni modulet që nuk janë nga kernel ose moduli i pronarit nvidia, pa e bërë këtë modaliteti grafik nuk do të funksionojë.
# zgjedhni listën e kernelit
# zgjidh bashkësinë e kernelit x
# cd / usr / src / linux
# bëj
# bëj module_instalo
# montim / boot
# bëj instalimin
# dracut –hostonly »3.15.7-gentoo –forcë
# splash_geninitramfs –verbose –res 1400 × 1050 –append /boot/initramfs-3.15.7-gentoo.img emerge-world
# grub -mkconfig -o/boot/grub/grub.cfg
# dalin @ rindërtojnë modulin
# shumoj / boot
# mbyllje -r tani
Nëse përdorni genkernel ju thjesht arnoni atë skedar dhe unë e kuptoj që genkernel rregullohet vetë.
Për më tepër, ju duhet të hiqni mbështetjen e drm dhe drejtuesit nvidia dhe çipat e tjerë video nga kerneli në mënyrë që ata të mos përplasen kokë më kokë me drejtuesin e mbyllur nvidia që është instaluar si një modul nvidia.
Në rastin e përdorimit të bootsplash, duhet të përfshini shoferin uvesa në kernel në mënyrë që të mbështesë rezolucione të larta të ekranit pasi që shoferi i mbyllur nvidia (nëse më kujtohet saktë) nuk mbështet më shumë se 800 × 600 në terminalin tty1 «F1» të çizme
Unë nuk di për distro të tjera, por unë mendoj se duhet të funksionojë në çdo distro nëse këto hapa janë bërë, duke kursyer ndryshimin e dukshëm për çfarëdo.
Këto janë udhëzimet që duhet të ndiqni, për nvidia dhe uvesa:
http://wiki.gentoo.org/wiki/NVidia/nvidia-drivers/es
http://wiki.gentoo.org/wiki/Uvesafb
Faleminderit për informacionin, por unë e zgjidha problemin pikërisht duke kaluar në ato të pronarit. Mbaj mend që shoferi i mëparshëm i nVidia (304.121) gjithashtu duhej të rregullohej kur shkonte në 3.13 sepse kishte një problem në përpilimin e modulit (nuk kishte gabime, por moduli refuzoi të funksiononte) dhe gjithçka gjithashtu për shkak të mbajtësit të ngjarjes ACPI . Në Debian e kuptova problemin dhe gjeta edhe zgjidhjen.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740097
Unë kam përdorur Manjaron si shembull, por e kam përmendur më parë që e njëjta gjë më ka ndodhur me Arch dhe derivatet e tjerë. Prandaj besoj se problemi është më shumë i tyre sesa i prekurit.
Pd: Unë nuk kam qenë në gjendje t'i përgjigjem drejtpërdrejt mesazhit përkatës sepse opsioni për t'u përgjigjur nuk duket ...
Sapo shkova nga Manjaro në Linux Mint sepse do të ngrihej kur të nisej pas azhurnimit në një version pas 0.8.9 (nuk e mbaj mend se cilin). Nga sa kam lexuar, kjo zakonisht ndodh në laptopë. Problemi im në fjalë nuk ishte i njëjtë me atë në këtë post, mendoj se arrita në përfundimin se mund të kishte të bënte me menaxhimin e energjisë. Kishte njerëz që nuk ngrinin nëse fillonin laptopin ndërsa ishin në prizë. Tani për tani nuk më kujtohet nëse kjo më lejonte të filloja gjithmonë pa probleme, por natyrisht që isha në gjendje ta bëja atë më shumë herë me koston e marrjes më shumë kohë për ta bërë atë.
Gjithsesi, në fund hoqa dorë dhe kalova te Fedora dhe Linux Mint.
Rastësisht, dje u përpoqa ta pezulloj atë pa karikuesin dhe kur e rifilloja varej dhe më duhej të rinisja.
Quiteshtë mjaft qesharake, unë kam qenë me Arch për disa muaj dhe nuk kam pasur një Panik të vetëm të Kernel! Më ka ndodhur me Antergos (Harku me një depo të shtuar) nga ambienti i drejtpërdrejtë, por atje e konsideroj më të kuptueshëm. A mund të jetë një problem me bordin amë ose një modul RAM të gabuar? Mbaj mend rreth 2 vjet më parë një modul RAM më shkaktoi disa ekrane blu në Windows dhe gjithashtu disa Panic Kernel! në Mandriva. Unë kisha për të provuar çdo kujtesë në një kohë midis reboot dhe reboot.
Isshtë një problem Arch (i cili tërheq të gjithë derivatet e tij), sepse në distrot tjera nuk ka probleme të këtij lloji. Ajo që më duket e turpshme është se në këtë pikë ata nuk e kanë zgjidhur atë. Janë vetëm ata prej vitesh! Kam lexuar probleme të ngjashme nga viti 2011. Unë e kam të qartë se kjo është diçka që vjen dhe shkon ndërsa azhurnohen, sepse duke përdorur versionet 0.8.7, 0.8.8 dhe 0.8.9 pa i azhurnuar ato asgjë nuk ndodh. Prej atëherë gjithçka shkon në mut, dhe me siguri në versionet e vjetra gjithashtu ka ndodhur. Pse u ndodh vetëm disa prej nesh? Nuk e di, por nuk mendoj se është problemi ynë, por Arch, sepse, siç është thënë tashmë, shpërndarjet e tjera shkojnë në mënyrë perfekte. Unë tashmë i theva brirët në kohën e tij për të gjetur një zgjidhje, por u lodha. Pra, aq sa më vjen keq, unë nuk jam duke shkuar për të përdorur Arch.
Harku 0.8.7, 0.8.8 dhe 0.8.9? Zbuloj që Arch përdor nomenklaturën e këtij versioni.
Mund të jetë që ju jeni duke përdorur Manjaro?
Ok, i përgjigjem vetes duke lexuar komentin tënd të mëparshëm, dhe një gjë është Manjaro dhe një tjetër është Arch.
Që të fajësosh një distro për një problem të caktuar nuk është konsistent (jo vërtet i qëndrueshëm), të paktën në rastin tim nuk mund të fajësoj sa distro përpiqem për problemin me nouveau dhe kartën time nVidia 6150SE, sepse problemi është Trajtimi MMIO i shoferit dhe kartës (nVidia do të dijë çfarë të rregullojë dhe gjëra të çmendura që do të duhet të rregullojnë atë detaj). Hardware gjithashtu mund të jetë problemi, dhe ju mund të shihni se në çfarëdo OS që përdorni (Windows, Linux, BSD), dhe në përvojën time në riparimin e kompjuterëve kam parë probleme shumë të çuditshme të harduerit (të tilla si një PC që refuzon të boot nëse nuk e ndryshoni vendndodhjen e kujtesës, dhe kur mbylleni ju duhet të përsërisni procesin), dhe unë nuk mund të fajësoj Windows dhe Debian për këtë.
Kam pasur një panik të bërthamës me një ubuntu të drejtpërdrejtë 12.04
Unë kam frenetik në kompjuterin tim Notebook PC Secure HP pavilion dm4, 8 GB RAM, 500 hard disk, ka më shumë se 5 vjet përdorim. Nuk mbaj mend shpejtësinë e mikroprocesorit, një bërthamë Intel i5, mendoj se më shumë se 2 mhz.
Nuk mund të shkruaj asgjë në ekranin e terminalit. Unë do të vazhdoj të kërkoj më shumë informacion, për të zgjidhur këtë problem.