Dette innlegget skal vise hvordan du kan "løse" nesten problemet med oppstart med feil Arch Linux. Noe som følgende bilde:
Som vi kan se, ser vi at dette er en av de mange "kombinasjonene" av feil som vises tilfeldig når du starter et operativsystem med dette problemet. Som det står i den feilen, indikerer det at det kan være et problem i "Maskinvaren", men som vi alle vet i dette operativsystemet, kan til og med de dårlige triksene med det som ikke tilhører operativsystemet løses.
Så jeg vil beskrive min opplevelse av dette problemet. Fra det jeg klarte å oppleve, var problemet bare med Arch Linux eller en annen distro som jeg testet eksternt, siden det med enhver ubuntu som jeg hadde installert eller testet, startet uten problemer. Men hvis jeg prøvde å rive i Arch Linux installert på harddisken, hadde det et problem at den måtte starte på nytt omtrent 50 ganger for at operativsystemet kunne starte normalt og kunne bruke det.
Dette hadde allerede noe galt med meg fordi jeg bare kunne bruke ubuntu som jeg hadde installert for å teste det, og jeg kunne ikke engang gjøre halvparten av tingene jeg kunne gjøre med Arch Linux. Så jeg bestemte meg for å løse dette problemet og begynte å undersøke, på jakt etter forumtråder som hadde det samme problemet, de nevnte også at det var en maskinvarefeil og at det var nettopp CPU, så det begynte å bekymre meg, så jeg måtte åpne PC-en og verifiser hva som skjedde, men det hjalp ikke.
Men noe som viste meg, at jeg ikke skulle gi opp var at hvis Ubuntu Jeg kunne fordi Arch Linux nei (kanskje Ubuntu er bedre enn Arch...?). Så jeg begynte å skrive oppstartsparametere til kjernen av Arch Linux, ting som: 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 = deaktiver, i8042.noacpi = 1, apm = copyd apm = copyds, acdtpi = 0, apm = copyds pci = nocrs, rhgb, acpi = force, pnpacpi = XNUMXff og andre mer ... Alt dette ble anbefalt i forumene jeg leste.
Inntil jeg måtte gå til dokumentasjonen til kjerneparametrene, som jeg forresten anbefaler: https://www.kernel.org/doc/Documentation/kernel-parameters.txt
Og jeg fant en ganske interessant parameter som for øyeblikket klarte jeg å starte Arch Linux Ikke noe problem:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce maxcpus = 0
Som angitt der, hva denne parameteren gjør er å begrense bruken til en CPU uten å aktivere den symmetriske modusen for prosessering. Først fungerte det ganske bra til da jeg brukte kommandoen pacman-Syyu; kastet meg en kjerne dumpet o segmenteringsfeil.
Så jeg la automatisk merke til at noe rart skjedde, så jeg begynte å kjøre andre prosesser til systemet plutselig frøs helt og ikke fungerte lenger, før jeg startet det på nytt. Så jeg gjorde den samme operasjonen, men denne gangen klarte jeg å utføre htop og det viste meg følgende:
Som forventet viste den bare en CPU, siden den andre hadde deaktivert den, men det virket veldig rart for meg hvorfor programmene kastet skillefeil, og kunne ikke engang starte det grafiske miljøet; så det var noe som i det minste ga meg mer håp om at hvis jeg satte kjerneparametrene på en måte, ville det starte opp min Arch Linux som vanlig.
Så jeg fortsatte å prøve de andre parameterne som jeg skrev i listen til jeg kom over denne, som er den beste løsningen for øyeblikket:
linux /boot/vmlinuz-linux root=UUID=fbefe36c-1712-4f3b-b3e3-3eac759d71c9 notsc nomce isolcpus = 1
Denne parameteren gjør noe så enkelt som å isolere (ikke deaktivere) den andre kjernen fra CPU-en i symmetrisk behandling, det vil si at prosessbelastningen blir gitt til en enkelt kjerne mens den andre bare er komplementær. Dette, selv om det virker motstridende, påvirker ikke ytelsen så mye, siden dette flotte operativsystemet var i stand til å kjøre applikasjoner på denne måten:
Så med dette, er det eneste problemet jeg observerte som oppstår ved oppstartstid, en eller to kjernepanikker eller oops; men sammenlignet med de 50 gangene jeg måtte starte på nytt tidligere, kan jeg betrakte det som en "løsning". For resten har det så langt tillatt meg å bruke operativsystemet og skrive dette innlegget du leser akkurat nå :-).
Jeg håper de hjelper deg, og ikke kommer ut av det GNU / Linux, som er det beste operativsystemet de noensinne har oppfunnet. Jeg sier det helt sikkert.
Veldig interessant info. Jeg har aldri hatt disse kjernepanikkene i ArchLinux de årene jeg har brukt den, men det er godt å vite hva du skal gjøre hvis problemet på noe tidspunkt oppstår. Takk skal du ha!
Uansett, jeg har brukt Arch lenge (jeg var som 1 år uten Arch) og uten kjernepanikk.
Takk for tipset.
Mest sannsynlig, som jeg nevnte i innlegget, oppstår problemet på grunn av maskinvaren, for i det jeg bruker arch, hadde det heller ikke gitt meg noe problem av denne typen.
En annen med gode resultater i Arch. Jeg har aldri hatt en Kernel Panic
Mer enn 2 år med GNU / Linux ... 2 år allerede med ArchLinux, aldri en kjernepanikk .. 😉
Jeg tror kjernepanikk skyldes mer maskinvare enn selve distro. Jeg har aldri sett en panikkjerne på den bærbare datamaskinen jeg bruker nå, bortsett fra at jeg en gang satte en Ubuntu-alfa i den (og Arch Linux var også her i to år). På den annen side, i en annen bærbar datamaskin som jeg har, gir enhver distro som jeg legger alltid kjernepanikk og et bredt utvalg av feil for enhver smak.
Med kernel 3.14 på Debian har jeg fått kjernepanikaproblemet, i tillegg til at når jeg slår på PCen min, får jeg en "tilkobling / frakobling timeout" -melding (og også når jeg slår den av).
Det har skjedd meg så mye i Fedora som i Arch, men jeg vet ikke hvorfor, og hvordan jeg ikke ser forskjell fordi jeg ikke har brukt tid på å undersøke eller løse det (hvis det er et problem).
Jeg tror årsaken 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/
Tusen takk for informasjonen. Noen av de mange tingene vi kan skryte av er denne typen forum
Hvorfor skjer dette med Arch Linux? Kanskje er det ikke nok med problemene som ofte dukker opp med treghet eller henging av systemet når punktet for å kaste systemet til båndet.
Hei? Hva snakker du om? o_O
Arch er en KISS-distribusjon som kan konfigureres fra selve operativsystemet, med noen få ord, hvis systemet er tungt, er det fordi du bygde det på den måten. Hvis systemet har feil, er det fordi du genererte dem eller fordi du ikke gjorde det konfigurere noe riktig. Arch wiki er ganske komplett, for noen år siden var det ikke mange viktige emner på spansk, og installasjonsprosessen var mye tøffere og litt vanskelig, nå er alt litt mer automatisert.
Å klandre distro for brukerfeil er så ... Windows (?).
Å skylde på distro for feil er å være konsekvent, rett og slett fordi det er sannheten. Etter å ha hatt et lignende problem med Manjaro, prøvde jeg Arch, Antergos og en annen ukjent distribusjon (jeg kan ikke huske navnet nå, beklager) som noen anbefalte meg å forsikre meg om at det ikke ga problemer, men ingenting; de gir det alle. I OpenSuse, Fedora, Mint, Mageia og alle de som jeg har prøvd etterpå går det ikke over. Så så vidt jeg er bekymret, har jeg ikke noe annet valg enn å tenke at det er distroens feil. Men hei, jeg demoniserer det ikke eller noe, hva mer, det irriterer meg virkelig at jeg ikke kan bruke noe basert på Arch, fordi jeg liker det mye, men det forbanna problemet hindrer meg. Jeg tror heller ikke at det handler om maskinvaren, fordi mange av oss som skjedde med oss ikke skjedde før vi brukte samme jævla. Vel, det må faktisk være noe relatert til maskinvaren, men hvis jeg ikke har gjort noen endringer og har problemer med det samme utstyret som jeg ikke hadde dem før, vil det åpenbart skyldes til en endring gjort av Arch som skrudde meg.
"Å klandre distro for brukerfeil er så ... Windows (?)."
Jeg vil fortelle deg at det er så Apple å skylde brukere på produktfeil. Jeg har ærlig talt tenkt på det tusen ganger, men jeg ser ikke fordelen med å bruke noe hvis vedlikeholdspersoner i utgangspunktet vasker hendene, for noe seriøst formål. Og jeg sier at med tanke på at GPL-programvaren kommer uten garanti.
Du kan si som du vil, men hvis det er det samme tilfellet med rapporter om manglende signal til iPhone, og svaret fra Apple "er at du tar feil" for flere år siden. Hvis du lager en distro, vil du vanligvis gi litt kvalitet og minimal støtte, og sannheten er at Arch i utgangspunktet er et hobbysystem, hvor du ser at utviklerne har det gøy å pakke inn nye ting, men har liten interesse i å tilby ekte støtte . Hver gang jeg ser denne typen innlegg, setter jeg mer pris på arbeidet bak distroen jeg bruker.
Og ja, det er et programvareproblem hvis det ikke fungerer, hvis det slutter å fungere i en oppdatering, eller hvis noe av maskinvaren går i stykker. At en kjernepanikk distroerer mens en annen ikke ... vel, ja, det er tydeligvis en distro som gjør ting riktig og en annen feil. Nå hvis det er din glede å bruke Linux i stil med 90-tallet hvor vi måtte kompilere kjernen hver gang vi koblet til en ny skriver ... der du.
Er kjernen samlet av utviklerne? eller din egen?
Kjernepanikk genereres når visse komponenter ikke er valgt (AND) når du kompilerer, eller noen moduler ikke har blitt aktivert for å støtte bestemt maskinvare. Med praksis og kunnskap om maskinvaren din (du må åpne PCen og se hvilke merkevarer med chips den har), kan du bygge en tilpasset kjerne (ved å chrooting). Hvis ubuntu og Arch installasjons-CD var på datamaskinen din, er det noe i samlingen som ikke er aktivert.
Det var aksjekjernen fra selve archlinux, fra repositoriene.
Kjernen du bruker, det er noe til overs som maskinvaren ikke liker, du må ha en sjelden versjon av en brikke på hovedkortet eller til og med en feil i en brikke (det skjer vanligvis).
Det kan være en korrupt tabell i bios acpi, det er normalt at kineserne på vakt ikke en gang beregner sjekksummen for hver tabell godt, disse meldingene vises vanligvis med $ dmesg -human i starten av oppstarten.
Du bør også prøve en annen strømforsyning, når filtreringen mislykkes, har krusningen en tendens til å gjøre nettopp slike feil.
Først kan du prøve å endre kilden og se hva som skjer. Hvis det forblir det samme, kan du prøve å konfigurere en kjerne som er skreddersydd for maskinvaren din. Forresten vil du bli bedre kjent med PCen din i prosessen.
Takk for tipsene. Forresten er det en bærbar PC, jeg synes jeg burde bytte batteri. Men jeg ser det du har fortalt meg kan hjelpe meg.
Den ene kjernepanikken som fremdeles gjør meg gal er delvis feilen til nouveau-gutta og mine gamle, utdaterte og veldig støvete nVidia 6150 SE-integrerte kort som de som nVidia har, og alt dette, bare ved hjelp av reverse engineering, pluss problemet oppstår bare for noen kort med NV4E-brikkesettet).
Bare start Openbox + Firefox og katastrofe rammer (ingenting vakrere enn å se en helt tilfeldig svart-hvitt mosaikk på skjermen). Og jeg har sunget den siden kjerne 3.6 i Debian, Fedora, Archlinux, Slackware og nå bekreftet igjen i Gentoo (nettopp installert med kjerne 3.12), jeg gidder ikke lenger å ta en logg, til kjernen eller gi den tid til skriv noe som ikke er en hel tullfigur.
Jeg gir deg løsningen, en pc som jeg har med gentoo og integrert nvidia-video er den samme med nouveau-driveren, så jeg hadde ikke noe annet valg enn å bruke den lukkede nvidia-driveren, min chip må bruke 304.123-driveren
00: 0d.0 VGA-kompatibel kontroller [0300]: NVIDIA Corporation C61 [GeForce 7025 / nForce 630a] [10de: 03d6] (rev a2) (prog-if 00 [VGA-kontroller])
Du må lappe en kjernefil før du kompilerer den. Hvis den ikke er lappet, vil grafikkmodus nekte å starte.
Trinnene er:
# nano -w /usr/src/linux-3.15.7-gentoo/drivers/acpi/osl.c
Søk med ctrl + w i nano denne teksten, acpi_os_wait_events_complete og nano tar deg til denne delen:
ugyldig acpi_os_wait_events_complete (ugyldig)
{
flush_workqueue (kacpid_wq);
flush_workqueue (kacpi_notify_wq);
}
EXPORT_SYMBOL (acpi_os_wait_events_complete);
Plasteret du må legge til er denne siste linjen som starter med EXPORT, ctrl + eller ctrl + x
Deretter kompilerer du kjernen, installerer modulene, du installerer kjernen, du genererer initramfs hvis du trenger det, du legger til splash i initramfs hvis du bruker splash, du regenererer oppføringene for grub og til slutt og veldig viktig, må du gjenoppbyg modulene som ikke er fra kjernen, det vil si den proprietære nvidia-modulen, uten å gjøre dette, fungerer ikke grafikkmodusen.
# velg kjerneliste
# velg kjernesett x
# cd / usr / src / linux
# gjøre
# gjør modules_install
# montere / starte
# gjør installasjon
# 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 nå
Hvis du bruker genkernel, lapper du bare den filen, og jeg forstår at genkernel løser seg selv.
I tillegg må du fjerne drm-støtte- og nvidia-driverne og andre videobrikker fra kjernen, slik at de ikke kolliderer front-mot med den lukkede nvidia-driveren som er installert som en nvidia-modul.
I tilfelle du bruker bootsplash, må du ta med uvesa-driveren i kjernen slik at den støtter høye skjermoppløsninger siden den lukkede nvidia-driveren (hvis jeg ikke husker riktig) ikke støtter mer enn 800 × 600 i terminalen tty1 «F1» av støvelen.
Jeg vet ikke om andre distroer, men jeg antar at det skal fungere på noen distro hvis disse trinnene ble gjort, og lagre den nye endringen for hva som helst.
Dette er retningslinjene du må følge for nvidia og uvesa:
http://wiki.gentoo.org/wiki/NVidia/nvidia-drivers/es
http://wiki.gentoo.org/wiki/Uvesafb
Takk for informasjonen, men jeg løste problemet nettopp ved å bytte til de proprietære. Jeg husker at den forrige nVidia-driveren (304.121) også måtte patches når den gikk til 3.13 fordi den hadde et problem i kompilering av modulen (det var ingen feil, men modulen nektet å fungere) og alt også på grunn av ACPI hendelsesbehandler. I Debian fikk jeg problemet og fant løsningen også.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740097
Jeg har brukt Manjaro som et eksempel, men jeg har nevnt tidligere at det samme skjedde med Arch og andre derivater. Derfor tror jeg at problemet er mer deres enn de som er berørt.
Pd: Jeg har ikke vært i stand til å svare direkte på den aktuelle meldingen fordi muligheten til å svare ikke vises ...
Jeg gikk nettopp fra Manjaro til Linux Mint fordi det ville fryse når jeg startet opp etter oppdatering til en versjon etter 0.8.9 (jeg kan ikke huske hvilken). Fra det jeg leste, skjer dette vanligvis på bærbare datamaskiner. Problemet mitt i spørsmålet var ikke det samme som i dette innlegget, jeg tror jeg kom til at det kunne være relatert til strømstyring. Det var mennesker som ikke fryset hvis de startet den bærbare datamaskinen mens de var frakoblet. Akkurat nå husker jeg ikke om det tillot meg å alltid starte uten problemer, men selvfølgelig klarte jeg å gjøre det flere ganger på bekostning av å ta lengre tid å gjøre det.
Uansett, til slutt ga jeg opp og byttet til Fedora og Linux Mint.
Tilfeldigvis prøvde jeg i går å suspendere den uten laderen, og da jeg fortsatte den, hang den og jeg måtte starte på nytt.
Det er ganske morsomt, jeg har vært med Arch i noen måneder, og jeg har ikke hatt en eneste Kernel Panic! Det har skjedd meg med Antergos (Arch med et ekstra depot) fra det levende miljøet, men der anser jeg det som mer forståelig. Kan det være et problem med moderkortet eller en defekt RAM-modul? Jeg husker for omtrent 2 år siden, forårsaket en RAM-modul meg flere blå skjermer i Windows og også flere Kernel Panics! på Mandriva. Jeg måtte teste hvert minne om gangen mellom omstart og omstart.
Det er et bueproblem (som bærer alle dets derivater), for i andre distroer er det ingen problemer av den typen. Det jeg synes er flaut, er at de på dette tidspunktet ikke har løst det. Det har vært bare dem i årevis! Jeg har lest lignende problemer fra 2011. Jeg er tydelig på at dette er noe som kommer og går når de oppdateres, fordi det ikke skjer noe med bruk av versjoner 0.8.7, 0.8.8 og 0.8.9 uten å oppdatere dem. Fra da av går alt til dritt, og sikkert i gamle versjoner skjedde det også. Hvorfor skjer det bare noen få av oss? Jeg vet ikke, men jeg tror ikke det er vårt problem, men Arch, fordi, som allerede sagt, andre distribusjoner fungerer perfekt. Jeg knuste allerede hornene på hans tid for å finne en løsning, men jeg ble lei. Så, så mye som jeg beklager, skal jeg ikke bruke Arch.
Bue 0.8.7, 0.8.8 og 0.8.9? Jeg finner ut at Arch bruker den versjonsnomenklaturen.
Kan det være at du bruker Manjaro?
Ok, jeg svarer meg selv ved å lese den forrige kommentaren din, og en ting er Manjaro og en annen er Arch.
At skylden på en distro for et bestemt problem ikke er konsekvent heller (egentlig ikke konsistent), i det minste i mitt tilfelle kan jeg ikke klandre hvor mange distro jeg prøver for problemet med nouveau og nVidia 6150SE-kortet mitt, fordi problemet er MMIO håndtering av sjåføren og kortet (nVidia vil vite hva de skal fikse og sprø ting de må fikse den detaljene). Maskinvare kan også være problemet, og du kan se at uansett hvilket operativsystem du bruker (Windows, Linux, BSD), og etter min erfaring med å reparere datamaskiner, har jeg sett veldig rare maskinvareproblemer (for eksempel en PC som nekter å starte med mindre du endrer minneplasseringen, og når du slår av må du gjenta prosessen), og jeg kan ikke klandre Windows og Debian for det.
Jeg hadde en kjernepanikk med en live ubuntu 12.04
Jeg har vanvittig på min Secure HP pavilion dm4 bærbare PC, 8 GB RAM, 500 harddisk, den har mer enn 5 års bruk. Jeg husker ikke hastigheten til mikroprosessoren, en Intel core i5, jeg tror mer enn 2 mhz.
Jeg kan ikke skrive noe på terminalskjermen. Jeg vil fortsette å lete etter mer informasjon for å løse dette problemet.