Dette indlæg skal vise, hvordan man "løser" næsten problemet med opstart med fejl Arch Linux. Noget som det følgende billede:
Som det kan ses, ser vi, at dette er en af de mange "kombinationer" af fejl, der vises tilfældigt, når du starter et operativsystem med dette problem. Som det står i denne fejl, indikerer det, at der kan være et problem i "Hardware", men som vi alle ved i dette operativsystem, kan selv de dårlige tricks af, hvad der ikke hører til OS, løses.
Så jeg vil beskrive min oplevelse af dette problem. Fra hvad jeg var i stand til at opleve, var problemet kun med Arch Linux eller en anden distro, som jeg testede eksternt, for med enhver ubuntu, som jeg havde installeret eller testet, startede den uden problemer. Men hvis han forsøgte at rive Arch Linux installeret på harddisken, havde det et problem, at det måtte genstarte ca. 50 gange for at operativsystemet kunne starte normalt og kunne bruge det.
Dette havde allerede noget galt med mig, fordi jeg kun kunne bruge den ubuntu, jeg havde installeret, til at teste den, og jeg kunne ikke engang gøre halvdelen af de ting, jeg kunne gøre med Arch Linux. Så jeg besluttede at løse dette problem og begyndte at undersøge, på udkig efter forumtråde, der havde det samme problem, de nævnte også, at det var en hardwarefejl, og at det var netop CPU'en, så det begyndte at bekymre mig, så Jeg fik til at åbne pc'en og kontrollere, hvad der skete, men det hjalp ikke.
Men noget der viste mig, at jeg ikke skulle give op, var at hvis Ubuntu Jeg kunne fordi Arch Linux nej (måske Ubuntu er bedre end Arch...?). Så jeg begyndte at skrive opstartsparametre til kernen af Arch Linux, ting som: lapic, nomce, intel_idle.max_cstate = 0, deaktiver_cpu_apic, acpi_skip_timer_override, acpi = stric, clk, apm, noapic, acpi = oldboot, acpi-cpufreq, intel_pstate = deaktiver, i8042.noacpi = 1, apm = acpi = kopi pci = nocrs, rhgb, acpi = kraft, pnpacpi = 0ff og andre mere ... Alt dette blev anbefalet i de fora, jeg læste.
Indtil jeg var nødt til at gå til dokumentationen for kerneparametrene, som jeg forresten anbefaler: https://www.kernel.org/doc/Documentation/kernel-parameters.txt
Og jeg fandt en ganske interessant parameter, som det for øjeblikket lykkedes mig at starte Arch Linux Intet problem:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce maxcpus = 0
Som angivet der, hvad denne parameter gør, er at begrænse brugen til en CPU uden at aktivere den symmetriske behandlingsmetode. Først fungerede det ganske godt, indtil da jeg brugte kommandoen pacman-Syyu; kastede mig en kerne dumpet o segmenteringsfejl.
Så jeg bemærkede automatisk, at der var noget mærkeligt, så jeg begyndte at køre andre processer, indtil systemet pludselig frøs helt og ikke fungerede mere, før jeg genstartede det. Så jeg gjorde den samme operation, men denne gang lykkedes det mig at udføre htop og det viste mig følgende:
Som forventet viste den kun en CPU, da den anden havde deaktiveret den, men det virkede meget underligt for mig, hvorfor programmerne kastede afvigelse, og kunne ikke engang starte det grafiske miljø; så det var noget, der i det mindste gav mig mere håb om, at hvis jeg indstillede kerneparametrene på en måde, ville det starte min Arch Linux som sædvanligt.
Så jeg fortsatte med at prøve de andre parametre, jeg skrev på listen, indtil jeg stødte på denne, hvilket er den bedste løsning i øjeblikket:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce isolcpus = 1
Denne parameter gør noget så simpelt som at isolere (ikke deaktivere) den anden kerne af CPU'en i symmetrisk behandling, dvs. behandlingsbelastningen gives til en enkelt kerne, mens den anden kun er komplementær. Dette, selvom det virker modstridende, påvirker ikke ydeevnen så meget, da dette fantastiske operativsystem var i stand til at køre applikationer på denne måde:
Så med dette er det eneste problem, som jeg har observeret, der opstår ved opstartstid, en eller to kernepanikker eller oops; Men sammenlignet med de 50 gange, jeg har haft at genstarte tidligere, kan jeg betragte det som en "løsning". For resten har det hidtil gjort det muligt for mig at bruge operativsystemet og skrive dette indlæg, som du læser lige nu :-).
Jeg håber, de hjælper dig og ikke kommer ud af det GNU / Linux, hvilket er det bedste operativsystem, de nogensinde har opfundet. Jeg siger det helt sikkert.
Meget interessant info. Jeg har aldrig haft disse kernepanikker i ArchLinux i de år, jeg har brugt det, men det er rart at vide, hvad jeg skal gøre, hvis problemet nogensinde opstår for mig. Tak skal du have!
Under alle omstændigheder har jeg brugt Arch i lang tid (jeg var som 1 år uden Arch) og uden kernepanik.
Tak for tipet.
Mest sandsynligt, som jeg nævnte i indlægget, opstår problemet på grund af hardwaren, for i det, jeg bruger arch, havde det heller ikke givet mig noget problem af denne type.
En anden med fremragende resultater i Arch. Jeg har aldrig haft en Kernel Panic
Mere end 2 år med GNU / Linux ... 2 år allerede med ArchLinux, aldrig en kernepanik .. 😉
Jeg tror, at kernepanik skyldes mere hardware end selve distro. Jeg har aldrig set en panikkerne på den bærbare computer, jeg bruger nu, undtagen når jeg først har lagt en Ubuntu-alfa i den (og Arch Linux var også her i to år). På den anden side, i en anden bærbar computer, som jeg har, giver enhver distro, som jeg lægger, altid kernepanik og en lang række fejl for enhver smag.
Med kerne 3.14 på Debian er jeg stødt på kernepanikproblemet, udover at når jeg tænder min pc, får jeg en meddelelse om "tilslut / afbryd timeout" (og også når jeg slukker den).
Det er sket mig så meget i Fedora som i Arch, men jeg ved ikke hvorfor, og hvordan jeg ikke kan se en forskel, da jeg ikke har brugt tid på at undersøge eller løse det (hvis det er et problem).
Jeg tror, at årsagen er, at de er samlet med gcc 4.9
http://libuntu.com/linus-torvalds-considera-que-la-version-4-9-de-gcc-es-una-pura-y-absoluta-mierda/
Mange tak for informationen. Nogle af de mange ting, vi kan prale af, er denne type forum
Hvorfor sker dette med Arch Linux? Måske er det ikke nok med de problemer, der ofte opstår med langsomhed eller ophængning af systemet når det punkt, hvor systemet kastes til båndet.
Hej? Hvad snakker du om? o_O
Arch er en KISS-distribution, der kan konfigureres fra selve operativsystemets base, med få ord, hvis systemet er tungt, er det fordi du byggede det på den måde, hvis systemet har fejl, er det fordi du genererede dem, eller fordi du ikke konfigurerede noget korrekt Arch wiki er ret komplet, for et par år siden var der ikke mange vigtige emner på spansk, det og installationsprocessen var meget hårdere og noget vanskeligt, nu er alt lidt mere automatiseret.
At bebrejde distro for brugerfejl er så ... Windows (?).
At bebrejde distro for fejl er at være konsekvent, simpelthen fordi det er sandheden. Efter at have haft et lignende problem med Manjaro prøvede jeg Arch, Antergos og en anden ukendt distribution (jeg kan ikke huske navnet nu, undskyld), som nogen anbefalede mig at forsikre mig om, at det ikke gav problemer, men intet; de giver det alle. I OpenSuse, Fedora, Mint, Mageia og alle dem, som jeg har prøvet bagefter, går det ikke. Så efter min mening har jeg intet andet valg end at tænke, at det er distros skyld. Men hej, jeg dæmoniserer det ikke eller noget, hvad mere er, det irriterer mig virkelig, at jeg ikke kan bruge noget baseret på Arch, fordi jeg kan lide det meget, men det forbandede problem forhindrer mig. Jeg tror heller ikke, at det handler om hardware, fordi mange af os, der sker med os, ikke skete, før vi brugte den samme skide. Nå skal det faktisk være noget relateret til hardware, men hvis jeg går tilbage til det samme, hvis jeg ikke har foretaget nogen ændringer, og jeg har problemer med det samme udstyr, som jeg ikke havde dem med før, vil det selvfølgelig skyldes en ændring foretaget af Arch, der har skruet mig.
"At bebrejde distro for brugerfejl er så ... Windows (?)."
Jeg vil fortælle dig, at det er så Apple at bebrejde brugerne for produktfejl. Jeg har ærligt talt over det tusind gange, men jeg kan ikke se fordelen ved at bruge noget, hvis vedligeholdere dybest set vasker deres hænder til noget seriøst formål. Og jeg siger, at i betragtning af at GPL-softwaren kommer uden garanti.
Du kan sige, som du vil, men hvis det er det samme tilfælde af rapporterne om manglende signal til iPhone, og Apples svar "er, at du får det forkert" fra flere år siden. Hvis du laver en distro, vil du normalt give noget kvalitet og minimal support, og sandheden er, at Arch dybest set er et hobbysystem, hvor du ser, at dets udviklere har det sjovt at pakke nye ting, men har ringe interesse i at tilbyde en ægte støtte. Hver gang jeg ser disse typer indlæg, værdsætter jeg mere arbejdet bag distroen, jeg bruger.
Og ja, det er et softwareproblem, hvis det ikke fungerer, hvis det holder op med at arbejde i en opdatering, eller hvis noget af hardwaren går i stykker. At en kerne panik distro, mens en anden ikke ... godt, ja, klart der er en distro, der gør tingene rigtige og en anden forkert. Hvis det nu er din fornøjelse at bruge Linux i stil med 90'erne, hvor vi var nødt til at kompilere kernen hver gang vi tilsluttede en ny printer ... der er du.
Er kernen udarbejdet af udviklerne? eller din egen?
Kernepanik genereres ved ikke at have valgt (OG) bestemte komponenter under kompilering eller ved ikke at have aktiveret nogle moduler til understøttelse af bestemt hardware. Med praksis og viden om din hardware (du skal åbne pc'en og se, hvilke mærker af chips den har), kan du oprette en brugerdefineret kerne (ved at chrooting). Hvis ubuntu og Arch installations-cd'en var på din computer, er der noget i kompileringen, der ikke er aktiveret.
Det var bestandskernen fra selve archlinux, fra arkiverne.
Kernen, du bruger, der er noget tilbage, som din hardware ikke kan lide, du skal have en sjælden version af en chip på dit bundkort eller endda en fejl i en chip (det sker normalt).
Det kan være en beskadiget tabel over din bios acpi, det er normalt, at kineserne på vagt ikke engang beregner kontrolsummen for hver tabel godt, disse meddelelser vises normalt med $ dmesg -human i starten af opstarten.
Du bør også prøve en anden strømforsyning, når filtreringen mislykkes, har krusningen tendens til at gøre netop den slags fejl.
Prøv først at ændre kilden og se hvad der sker, hvis det forbliver det samme, skal du prøve at konfigurere en kerne, der er skræddersyet til din hardware, forresten lærer du din pc bedre at kende i processen.
Tak for tipene. Forresten er det en bærbar computer, jeg synes, jeg skulle skifte batteri. Men jeg kan se, hvad du har fortalt mig, kan hjælpe mig.
Den ene kernepanik, der stadig gør mig vanvittig, er dels Nouveau-gutternes skyld og mit gamle, forældede og meget støvede nVidia 6150 SE integrerede kort (jeg mener dels fordi; de har gjort et fremragende stykke arbejde med at støtte et univers af grafikchips som dem, som nVidia har, og alt dette, der kun bruger reverse engineering, plus problemet opstår kun for nogle kort med NV4E-chipset).
Alt du skal gøre er at starte Openbox + Firefox og katastrofe strejker (intet smukkere end at se en helt tilfældig sort / hvid mosaik på din skærm). Og jeg har sunget det siden kerne 3.6 i Debian, Fedora, Archlinux, Slackware og nu genbekræftet igen i Gentoo (netop installeret med kerne 3.12), jeg gider ikke længere at tage en log til kernen eller give den tid til at skrive noget der vær ikke en kæmpe nonsens tegn.
Jeg giver dig løsningen, en pc, som jeg har med gentoo og integreret nvidia-video, er den samme med nouveau-driveren, så jeg havde intet andet valg end at bruge den lukkede nvidia-driver, min chip skal bruge 304.123-driveren
00: 0d.0 VGA-kompatibel controller [0300]: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] [10de: 03d6] (rev a2) (prog-if 00 [VGA-controller])
Du er nødt til at patch en kernefil, før du kompilerer den, hvis den ikke er patched, nægter grafiktilstanden at starte.
Trinene er:
# nano -w /usr/src/linux-3.15.7-gentoo/drivers/acpi/osl.c
Søg med ctrl + w inden for nano efter denne tekst, acpi_os_wait_events_complete og nano fører dig til denne del:
ugyldigt acpi_os_wait_events_complete (ugyldigt)
{
flush_workqueue (kacpid_wq);
flush_workqueue (kacpi_notify_wq);
}
EXPORT_SYMBOL (acpi_os_wait_events_complete);
Den patch, du skal tilføje, er denne sidste linje, der starter med EXPORT, ctrl + eller ctrl + x
Derefter kompilerer du kernen, installerer modulerne, installerer kernen, genererer initramfs, hvis du har brug for det, tilføjer splash til initramfs, hvis du bruger splash, regenererer poster for grub og til sidst og meget vigtigt skal du genopbygge de moduler, der ikke er fra kerne, det vil sige det proprietære nvidia-modul, uden at gøre dette fungerer den grafiske tilstand ikke for dig.
# vælg kerneliste
# vælg kernesæt x
# cd / usr / src / linux
# make
# lav modules_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
# shutdown -r nu
Hvis du bruger genkernel, lapper du bare den fil, og jeg forstår, at genkernel løser sig selv.
Derudover skal du fjerne drm-understøttelse og nvidia-drivere og andre videochips fra kernen, så de ikke kolliderer frontalt med den lukkede nvidia-driver, der er installeret som et nvidia-modul.
I tilfælde af brug af bootsplash skal du inkludere uvesa-driveren i kernen, så den understøtter høje skærmopløsninger, da den lukkede nvidia-driver (hvis jeg ikke husker det rigtigt) ikke understøtter mere end 800 × 600 i terminalen tty1 «F1» i opstarten.
Jeg kender ikke til andre distroer, men jeg formoder, at det skal køre på enhver distro, hvis disse trin blev udført, hvilket sparer den nye ændring til hvad som helst.
Dette er de retningslinjer, du skal følge for nvidia og uvesa:
http://wiki.gentoo.org/wiki/NVidia/nvidia-drivers/es
http://wiki.gentoo.org/wiki/Uvesafb
Tak for informationen, men jeg løste problemet netop ved at skifte til de proprietære. Jeg kan huske, at den forrige nVidia-driver (304.121) også skulle patches, når jeg gik til 3.13, fordi det havde et problem i kompilering af modulet (der var ingen fejl, men modulet nægtede at arbejde) og alt også på grund af ACPI-eventhåndteringen . I Debian fik jeg problemet og fandt også løsningen.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740097
Jeg har brugt Manjaro som et eksempel, men jeg har allerede nævnt før, at det samme skete med Arch og andre derivater. Derfor tror jeg, at problemet er mere deres end de berørte.
Pd: Jeg har ikke været i stand til at svare direkte på den relevante besked, fordi muligheden for at svare ikke vises ...
Jeg gik præcist fra Manjaro til Linux Mint, fordi det ville fryse, når jeg startede efter opdatering til en version senere end 0.8.9 (jeg kan ikke huske hvilken). Fra hvad jeg læser, sker dette normalt på bærbare computere. Mit spørgsmål i spørgsmålet var ikke det samme som det i dette indlæg, jeg tror, jeg kom til den konklusion, at det kunne være relateret til strømstyring. Der var mennesker, der ikke frøs, hvis de startede den bærbare computer, mens de var frakoblet. Lige nu kan jeg ikke huske, om det tillod mig altid at starte uden problemer, men selvfølgelig var jeg i stand til at gøre det flere gange på bekostning af at tage længere tid at gøre det.
I sidste ende opgav jeg og skiftede til Fedora og Linux Mint.
Tilfældigvis forsøgte jeg i går at suspendere den uden opladeren, og da den genoptages, hang den, og jeg måtte genstarte.
Det er ret sjovt, jeg har været sammen med Arch i et par måneder, og jeg har ikke haft en eneste Kernel Panic! Det er sket for mig med Antergos (Arch med et ekstra arkiv) fra det levende miljø, men der anser jeg det for mere forståeligt. Kan det være et problem med moderkortet eller et defekt RAM-modul? Jeg husker omkring 2 år siden, et RAM-modul forårsagede mig flere blå skærme i Windows og også flere Kernel Panics! på Mandriva. Jeg var nødt til at teste hver hukommelse ad gangen mellem genstart og genstart.
Det er et bueproblem (som bærer alle dets derivater), fordi der i andre distroer ikke er sådanne problemer. Hvad jeg finder pinligt, er at de på dette tidspunkt ikke har løst det. Det har været bare dem i årevis! Jeg har læst lignende problemer fra 2011. Jeg er klar over, at det er noget, der kommer og går, når de opdateres, for ved at bruge versioner 0.8.7, 0.8.8 og 0.8.9 uden at opdatere dem sker der intet. Fra da af går alt til lort, og helt sikkert i gamle versioner skete det også. Hvorfor sker det kun for nogle få af os? Jeg ved det ikke, men jeg synes ikke, det er vores problem, men Archs, for som tidligere sagt fungerer andre distributioner perfekt. Jeg brød allerede mine horn på hans tid for at finde en løsning, men jeg blev træt. Så så meget som jeg er ked af, vil jeg ikke bruge Arch.
Bue 0.8.7, 0.8.8 og 0.8.9? Jeg finder ud af, at Arch bruger den versionnomenklatur.
Kan det være, at du bruger Manjaro?
Ok, jeg svarer mig selv ved at læse din tidligere kommentar, og en ting er Manjaro, og en anden er Arch.
At bebrejde en distro for et bestemt problem er heller ikke konsekvent (ikke rigtig konsistent), i det mindste i mit tilfælde kan jeg ikke bebrejde, hvor mange distro jeg prøver på problemet med nouveau og mit nVidia 6150SE-kort, fordi problemet er MMIO-håndtering af driveren og kortet (nVidia ved, hvad de skal rette, og skøre ting, de bliver nødt til at rette den detalje). Hardware kan også være problemet, og du kan se, at uanset hvilket operativsystem du bruger (Windows, Linux, BSD) og i min erfaring med at reparere computere, har jeg set meget mærkelige hardwareproblemer (såsom en pc, der nægter at start medmindre du ændrer hukommelsesplaceringen, og når du lukker ned, skal du gentage processen), og jeg kan ikke bebrejde Windows og Debian for det.
Jeg havde en kernepanik med en levende Ubuntu 12.04
Jeg har hidsig min Secure HP pavilion dm4 Notebook PC, 8 GB RAM, 500 harddisk, den har mere end 5 års brug. Jeg kan ikke huske mikroprocessorens hastighed, en Intel core i5, jeg tror mere end 2 mhz.
Jeg kan ikke skrive noget på terminalskærmen. Jeg vil fortsætte med at lede efter flere oplysninger for at løse dette problem.